Can anybody running ROS v7 beta check if the IPv6 address from pool setting is fixed yet?

Scenario:

• device receives /56 prefix and populates /ipv6 pool
• administrator configures a /64 address in the following matter:
  
  Code: Select all

  /ipv6 address
  add address=::1:0:0:0:1/64 from-pool=<IPv6 pool> interface=<some interface>
  

  The mentioned command finishes in ROS 6.45.7 just fine, but print shows that address is invalid with comment
  

  ;;; address pool error: bad preferred prefix length! (1)

The thing is that address assignment command checks the prefix length passed to command, but doesn't really check it against prefix length of the prefix in pool. Seems like it assumes the leading non-zero digit to be double-byte (in the example ::1:0:0:0:1/64) ... and yes, if it was meant to set the highlited part as 0001, then this would be an error. However, if it's meant to be interpreted as **01, then the intended address fits the prefix length of /56.

I've reported the bug to support in the beginning of January 2019, they confirmed the bug and informed me that "... will try to fix it as soon as possible." And a few days later, after another beta was released, "This problem is not fixed yet. It will take while until problem will be fixed since it will be more like a new feature. I can not provide any ETA for this fix/new implementation at the moment."
BTW, it was in the time of 6.44beta ...
And, BTW, I don't see this as "a new feature", this bug clearly prevents from using all /64 subnets from pool except for the lowest one (with leading bytes equal to 0).

It might happen that this bug does not bite if received prefix length is /48 though ...

It shouldn't be true that this prevents other /64's from being used. I get a /56 from a pool and do this successfully right now, except I don't use your syntax, which would be invalid for my configuration. What do you have set as the "Pool Prefix Length" in your DHCPv6 client - is it set to 64 or 56?

Prefix length of the pool is 56.

Do you mind sharing your way of setting router's IPv6 address using address from a pool?

Re preventing other /64's being used: what happens is this: I'm getting my /56 prefix from ISP, which is (let's say) XXXX:XXXX:XXXX:XX00::/56. The syntax I'm using (and MTK support didn't have problem with it) is to use 'abbreviated' address in form of ::YYYY:YYYY:YYYY:YYYY/64 ... when using this kind of address notation together with from-pool=, it takes the leading zeroes as wildcard and combines it with prefix to form full IPv6 address XXXX:XXXX:XXXX:XX00:YYYY:YYYY:YYYY:YYYY ...
Notice those two zeroes in the middle? That is the MSB of my /56 subnet. Now, when I try to use longer 'abbreviated' address in assignment command, e.g. ::ZZ:YYYY:YYYY:YYYY:YYYY/64, ROS should combine that with my pool prefix length into address XXXX:XXXX:XXXX:XXZZ:YYYY:YYYY:YYYY:YYYY/64.
However it seems that it interprets my 'abbreviated' address as if I wanted to explicitly set byte 7 to zeroes ... as if I put ::00ZZ:YYYY:YYYY:YYYY:YYYY there which would translate into full IPv6 address XXXX:XXXX:XXXX:00ZZ:YYYY:YYYY:YYYY:YYYY ... which, of course, is not correct because resulting address is out of assigned /56 prefix.

Hence the problem: I can only set 64-bit 'abbreviated' address and 8 most signifficant bits of my /56 cannot be set when assigning address in this manner.

Of course I can statucally set any IPv6 address from my pool and other hosts in same subnet then follow the /64 prefix ... actually I can set just any address when assigning it statically.
And I can request setting a random address from the pool, but then I don't have any control over which /64 prefix it'll use nor which address within prefix it's gonna use. The problem is that I want to use particular addresses from given /64 for particular servers/routers/... but setting addresses statically is not something I should be doing, theoretically the prefix I get might change and in that case I would very much like that addresses follow automatically.

I think you may have a misunderstanding here. When you set "Pool Prefix Length" in the DHCPv6 client, it configures how the prefix given by the ISP should be divided up in your router, not what you are requesting.

In other words, if the ISP gives you a /56 and you set "Pool Prefix Length" to 56, you are telling the MikroTik to create a pool of /56 subnets that just has a single /56 in it (since the ISP only gives you one).

I think what you actually want is a "Pool Prefix Length" of 64 which means that when the ISP gives you a /56 you slice that up into 256 individual /64's which go into the pool.

Once that is done, you simply add addresses to individual interfaces as follows. For instance, if you take say a SOHO hEX device and remove the bridge, and ether1 is your uplink, you can get individual subnets on ether2-ether5 as follows:

/ipv6 address
add address=::1/64 from-pool=IPv6-Pool interface=ether2
add address=::1/64 from-pool=IPv6-Pool interface=ether3
add address=::1/64 from-pool=IPv6-Pool interface=ether4
add address=::1/64 from-pool=IPv6-Pool interface=ether5

The router tracks each /64 in the pool as individual units and so it will not give a duplicate /64 to two different interfaces. Although you don't really have control over which they get, they shouldn't change unless you get a new prefix from the ISP.

Adding the ability to specify a fixed MSB for each IPv6 address pulled from the pool is something that has been requested previously on the forums as a feature request. I can't seem to find the thread right now. But I would agree with MikroTik support when they say it is a "new feature" since the problem here is not using the /64's (which you can do), it is having fine grained control of who gets the first /64, who gets the second, etc.

I've changed the pool-prefix-length setting in dhcp-client to 64 and it doesn't change a thing regarding to the problem I described.

I agree, your method works. And that way it is possible to use up all prefixes. However, you don't have any control over which /64 will get used on particular interface. But I want to have that control and mentioned bug prevents me from having that control.

I agree, your method works. And that way it is possible to use up all prefixes. However, you don't have any control over which /64 will get used on particular interface. But I want to have that control and mentioned bug prevents me from having that control.

It isn't a bug though - they never designed the capability to give you that control. It is a new feature you are requesting.

There are other problems with the current implementation of pools in IPv6 - namely the inability to hand out addresses via DHCPv6 server (which prevents many home router models from working with MikroTik IPv6 on the ISP side), and also the fact that AFAIK you can only really give out prefixes of a fixed size - if you divide the pool up into /56's, you can only give a /56, not something smaller or larger. The "prefix hint" option they added to the DHCPv6 client only seems to work with non-MikroTik DHCPv6 server. Ideally I would like to see a more robust design for IPv6 pools in general that not only addressed your issue but also those other things.

Adding the ability to specify a fixed MSB for each IPv6 address pulled from the pool is something that has been requested previously on the forums as a feature request. I can't seem to find the thread right now. But I would agree with MikroTik support when they say it is a "new feature" since the problem here is not using the /64's (which you can do), it is having fine grained control of who gets the first /64, who gets the second, etc.

Well, it's almost done ... you can specify address within /64 using this method, you can't choose which /64 out of pool to be used. ROS already checks whether address 'postfix' is correct (could be it only checks the length), it could easily check if 'extended' address postfix, ORed with pool prefix, gives valid address from the pool.

And yes, IPv6 in ROS lacks many features, no doubt about that. However they're partially unrelated and can be fixed independently. Flexible address-from-pool selection doesn't have much to do with DHCPv6 server (and I, as an annoying home user, don't care about those problems at all ).

We have this wildcard feature, it is not something new, and it is working somehow.
But the expected behaviour should be that the maximum wildcard size can match the size of the pool, not the size of the prefixes it hand out.
So I still think of it to be a bug.

However they're partially unrelated and can be fixed independently. Flexible address-from-pool selection doesn't have much to do with DHCPv6 server (and I, as an annoying home user, don't care about those problems at all ).

Not necessarily, since the problem here is that if a pool can contain different subnets of different sizes (instead of having it contain just a uniform size of subnet), the MSB bits may be in a different place depending on the particular subnet that you are given, so the available options would be different. Suppose that a /56 pool could have unequal size sub-groups, like a bunch of /60's and /64's. The valid options for MSB would be quite different than simply having 256 equal size /64's in the /56.

... the problem here is that if a pool can contain different subnets of different sizes (instead of having it contain just a uniform size of subnet), the MSB bits may be in a different place depending on the particular subnet that you are given ...

So ROS should check availability of requested subnet ... right now it simply dismisses request if wildcard size is anything larger than /64. Even if prefixes haded out were non-uniform in size ... we all know what prefix size means and how it's applied to prefixes and addresses. Prefix of any size is still contigous and it's quite easy to track availability of parts of address space (a bit mask with length of 128 bits would do for quick job, but pool handling code already tracks usage so this is not really a problem).

Even in ISP case of assigning prefixes (of different lengths if you wish) to clients I can envision need to specify prefix for some clients if they require static prefixes so that they can use fixed addresses for their internet facing servers.

right now it simply dismisses request if wildcard size is anything larger than /64.

Not exactly, if your pool’s prefix length is larger than /64, you can use larger wildcard.
Tried with /48 pool and /56 prefix length.
Wildcard size is tied to to the wrong setting.

right now it simply dismisses request if wildcard size is anything larger than /64.

Not exactly, if your pool’s prefix length is larger than /64, you can use larger wildcard.
Tried with /48 pool and /56 prefix length.
Wildcard size is tied to to the wrong setting.

Could be, I don't have freedom to choose different prefix size (/56 is what I get from ISP so /64 subnets on interfaces are the only choice I have).

But anyway, wildcard size should be only tied to length of prefix, stored in pool, and nothing else ... and it ideally would be tied implicitly which would help if one had multiple pools with different prefix lengths so it wouldn't be necessary to manually change wildcard length when changing pool used.

Reading brief description about IPv6 address setup from manual it hits me that the problem might lie in different code part: the handling of address pool. It could be that pool always gives back a randomly chosen prefix with pool's prefix length ... and in this case setting address wildcard longer than (128-prefix length) clashes with prefix delivered ... If this is the case, then pool handling code should be changed so that whoever requests a prefix (DHCPv6 server or internal address handling or ..) could pass both wanted prefix length and address wildcard ... with fallback to /64 prefixes and short/no wildcard as default (which is current behaviour). This would allow DHCPv6 server to deliver various prefix sizes (including prefixes for larger or smaller subnets, such as /60 or /96 or whatever fits prefix stored in pool).

Well, thinking about many implications with this functionality implemented right I can see why MT devs consider this a feature request rather than bug report ... there's lots of things to be done, including some engineering/decission making. Even though from users' perspective it's not feature request because user interface doesn't change a bit, only behaviour changes to match implicit expectations ...

Not exactly, if your pool’s prefix length is larger than /64, you can use larger wildcard.
Tried with /48 pool and /56 prefix length.
Wildcard size is tied to to the wrong setting.

Could be, I don't have freedom to choose different prefix size (/56 is what I get from ISP so /64 subnets on interfaces are the only choice I have).

Having /56 you can test it with /60 prefix length.

But anyway, wildcard size should be only tied to length of prefix, stored in pool, and nothing else ...

Exactly!

This issue concerns me a lot. I have IPv6 completely functional both for private and guest network. Maybe I do not understand the above mentioned issue correctly. There is one problem left.

My provider serves me with a /56 fixed address as long as the MAC-address of my router does not change. Currently I have two /64 pools, as already explained one for private and one for guests. In the private pool is the IPv6 address to my server. That I need to configure at my hosting provider of my domain.

So my configuration is: zzzz:zzzz:zzzz:zzpp:aaaa:aaaa:aaaa:aaaa/128 where:
”z” = Fixed by the provider
“p” = Given by the Mikrotik ROS
“a” = provided by the router on base of the MAC address of the equipment.

Is there a way to influence “pp” in the complete address? Currently I have seen 00, 01, 02, 07, and 08. If one requires fixed IPv6 addresses this needs to be set somewhere? I would like them "00" for my private pool and "01" for my guest pool. Both fixed.

Maybe there is a solution?