Why does ipv6 suffix needs to be of even character

Recently I noticed ipv6 suffix in static leases doesn't take odd number of characters.

So, 99 works as an ipv6 suffix. But 100 doesn't. It says expecting a hexadecimal encoded value. If we want to set, we need to use 0100 instead. I don't get it, what does hexadecimal encoded values have to do with even number of characters.

Is there a legit reason for this? Doesn't it like, pad 0's anyway before the suffix? Why does it need to be of even characters?

Edit:The issue is with luci, not with uci via cli. Using luci if we try to set the IPv6-Suffix (hex) from network>dhcp and dns>static leases.

If we try to use odd number of hex characters this happens.


We can fix it by adding 0 before it and make it even number of characters.

Note: we can do odd number of characters here using uci in cli without any problem.

I noticed this too, someone set a restriction on prefix now to 8 characters instead of 4 plus even characters

It is being fixed to 16 characters.

why don't you both give and show concrete examples what worked and what not? And more importantly what you think what worked before? Nobody here has a magic glass ball and is able to guess your thoughts....

1 Like

To add on to @_bernd's sentiments:

Just to be clear, you are referring to a subnet, whose network number must be even, correct?

See: https://en.wikipedia.org/wiki/Subnet#Internet_Protocol_version_6

Or do you mean this:

Are you trying to add:

0099

and

0100

I don't want to assume - are you saying you attempted to add 100 and it failed?

Since both would involves a [hexadecimal] significant digit inquiry, it's important you specify (unless you wanna calculate each time for those who need it, I don't). From my cursory read of this issue, it's possible you're 1.) not specifying a valid subnet in hexadecimal or 2.) not numbering with all significant digits.

EDIT:

0x01 == 1
0x10 == 16
0x0100 == 256
0x1000 == 4096

:bulb: (for all, these can be quickly done on most OSes' by changing your calculator to programmer mode or number system mode, entering the number either in Hex (hexadecimal) or Dec (decimal), hitting enter, and switching the other mode)

:spiral_notepad: In the first example of 0x01, the 0 preceding the 1 is NOT significant, and is the crux of numbering 100. The same applies for 0x0100; but expresses all IPv6 digits needed in IPv6 notation (and happens to be even).

In hexdecimal, position is important (0x is the most common method of saying "the number written is in hex").

See:

1 Like

Maybe to add another thought.

Example: the user gets a /56 from the ISP, then the user can set 00 to ff on the ip6hint option.

1 Like

It may be good to note to the posters that in hexadecimal (and decimal in parenthesis) - the number [immediately] proceeding 0x99 (153) is not 0x100 (256), it's 0x9A (154).

And just for f***s sake we should say that within the UCI config the ip6hint option just takes the hex value without the leading/prefix of 0x.

1 Like

Sorry for the confusion. @_bernd @lleachii

I was not clear that, I was mentioning to luci.

The issue is with luci, not with uci via cli. Using luci if we try to set the IPv6-Suffix (hex) from network>dhcp and dns>static leases.

If we try to use odd number of hex characters this happens.


We can fix it by adding 0 before it and make it even number of characters.

Note: we can do odd number of characters here using uci in cli without any problem.

1 Like

LuCI validates all hexstring fields in groups of 2 chars. It’s not specific to that field.

2 Likes

Not sure but at least in this use case it sounds like a bug.