RouterOS v6 does not seem to support specifying the preferred IPv6 prefix size when using the /ipv6 dhcp-client. Please see the RFC3633 specification linked here for specifics on this issue. In summary, I should be able to configure the dhcpv6 client to request a larger prefix, like a /48, a /56, or a /60 instead of the default /64.
I am also definitely in favor of this feature being added to RouterOS. Many US ISPs, Comcast being the biggest, are now offering /60 IPv6 blocks to customers in almost all areas. I’d like to assign different /64s to my various vlans behind my RB750 at home.
maybe for DHCP-client you can use prefix-hint to request prefix from provider.
It seems that prefix-hint has been silently added sometime since 6.4 (the latest version when I originally made the topic), I don’t see it in the changelogs. Anyway, I will try upgrading my router to 6.7 and see if that works. I’d also note that prefix-hint isn’t in the wiki documentation yet. http://wiki.mikrotik.com/wiki/Manual:IPv6/DHCP_Client
I’ll post back shortly if prefix-hint works.
It was added in 6.5 and currently it is not in the wiki or changelogs.
Even though it didn’t work, I can’t believe I missed it as a config option..
It’s not visible via winbox as far as I can tell.
I tried to configure it via the terminal:
/ipv6 dhcp-client add add-default-route=yes interface=ether1-wan pool-name=comcastv6-pd
prefix-hint=::/60 use-peer-dns=no
Still receive a /64. I got some pcaps of the DHCPv6 transaction and here is what I see:
I SOLICIT or a /60 and it appears I receive two “DHCP Advertise” packets from the Comcast IPv6 server
The first contains a /60 and the second /64
RouterOS sends back a REQUEST for just the /64 and that’s what ends up in my IPv6 pool.
It looks like the /ipv6 dhcp-client release option doesn’t fully release the addresses as far as the server is concerned. I’m working with my ISP to get them to manually release my /64 and see if the prefix-hint works to request a /60. Will update when that’s done.
If this is Comcast, just disable the client for four days then re-enable it. This worked for me since their lease time is four days.
Sent from my Nexus 7 using Tapatalk 4
I have considered that, but frankly disabling IPv6 till the lease expires is a sorry excuse for a workaround to the router not releasing the lease properly. I expect the person I’m working with will be able to get it taken care of sometime tomorrow, and if not I’ll try disabling IPv6.
If you look at a sniffer trace, the pd is being released. I think it actually is due to a Comcast setting not ros.
Sent from my Nexus 7 using Tapatalk 4
Interesting. I actually was thinking about running a sniffer on it to see. The guy @ comcast I’m working with indicates their systems should accept a release, specifically I’ll quote him as saying, “I can delete that PD for you, your client isn’t doing a full release\renew.. I see this a lot..”, so I’m not sure where the discontinuity is. In either case, hopefully I’ll get the lease released soon and see if the hint works.
That is odd, as their DHCP servers respond to the DHCPv6 release with a DHCPv6 reply with a status code of success (0).
I am very sure this is a config issue or defect on their side. They should not have to delete the PDs from their system. It is very easy to get the sniffer trace on it (filter on just the dhcpv6 traffic - udp port 546 and 547) and you should get around 7 packets. Not sure how they can blame it on the the other devices (well, at least not on the ROS devices).
Comcast was able to release my lease manually. I started to receive a /60 via DHCP.
Next would be getting a GUA IPv6 address on my WAN port via IA_NA. As far as I know that’s the only way to get a public IP on the WAN interface on Comcast. It’s not necessary for v6 routing to work but it would be good to have for completeness.
I did some testing with the ISC dhcpv6 server and this is normal behavior. If you have a non timed out prefix assigned (even if released) the DHCP server will still give you the old PD even if the prefix-hint does not match the old PD. You either have to wait for a timeout or have the lease deleted. I will check the source to see if there is any code to handle prefix-hint differences vs existing PD leases.
I also did some testing with the sniffer. From what I see, if you have a lease, but release, and the router tries to renew, Comcast sends two advertisements back, the /60 you asked for, and your existing lease, in my case, a /64. What it does is set preference for the leases, the /60 you asked for has a preference of 0, and the lease you had (but released) has a priority of 255. So it seems that the router is just following the priority set by comcast, even though in theory you have the option of grabbing the /60.
If you look at the server DUIDs, they are different servers sending those advertise packets. It would be better if the existing server (with a 255 preference) would be able to see that your request for a prefix of different length would handle it by giving you the requested prefix of desired length (if available).
I got some progress!
I forced the issue by adding a firewall rule that dropped the packet advertising the /64, so even though the /60 had a lower priority, it had no other options.
/ipv6 firewall filter add chain=input action=drop protocol=udp dst-address=<YOUR PUBLIC INTERFACE LINK-LOCAL ADDRESS> in-interface=<YOUR PUBLIC INTERFACE> dst-port=546 nth=3,3
After adding that, running a release got me the /60, as in my case, the first packet would be the confirmation of the release, the second would be the advertisement of the /60 with low priority, and the third would be the /64.