We’ve just released a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources. For that purpose a number of lab tests were conducted.
In short, it’s a mess. Again, RFC ambiguity and/or (perceived) vendor implementation freedom suck big time. For us practitioners out (t)here this means (once more) we need extensive test labs and good troubleshooting guides for large scale IPv6 deployments.
The detailed results can be found in this paper. We hope to contribute to a better understanding of IPv6 specifics. I mean, after all it’s here already.
Everybody have a good week and don’t forget to enable IPv6 on something 😉
Enno
Our department has deployed IPv6 with DHCPv6 internally for almost two years now, but recently some Mac clients have had problems with IPv6, causing me to question the sanity of my IPv6 setup.
Then I found the paper “IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations” (strangely missing from your DHCPv6 tage page http://www.insinuator.net/tag/dhcpv6/) which cleared up many of my questions. I think we almost use your Case 4 (M=1,A=1,O=1,DHCPv6 server, but no RDNSS).
While the experiments in your paper are very enlightening, it leaves me with a question (crying to Heaven):
* If you decide to manage IPv6 clients using DHCPv6, what are the recommended, correct or optimal flags to use in Router Advertisements?
Your paper exposed the many ways to configure RAs, and surely some ways are better than others? Also, the DNS resolver address can be configured in both the RAs and in the DHCPv6 responses, but which way should be recommended?
FYI: We use Henri Wahl’s DHCPv6 server from https://dhcpy6d.ifw-dresden.de/ which allows us to manage clients based upon their MAC addresses. This has worked extremely well for us.
Hi Ole,
thanks for the feedback.
As for your question:
> * If you decide to manage IPv6 clients using DHCPv6, what are the recommended, correct or optimal flags to use in Router Advertisements?
In short: it depends 😉
Seriously: it depends heavily on the client base you want to support. Here’s some thoughts:
– in case there’s Android devices, your routers should advertise RDNSS info (RFC 6106), else the Android clients will have to rely on their IPv4 DNS or manual kludges. RFC 6106 is supported since Lollipop.
– in case you don’t have Android devices, you might go _without_ advertising RDNSS in RAs, for the simple reason of reducing potential for errors/”unexpected behavior”.
– once you go with m-flag DHCPv6 clearing the A-flag in prefix information, but leaving the L-flag set (to “circumvent RFC 5942”) is usually a good idea. see my post from Oct 31 2014 (which you’ve probably already noted) and https://www.ernw.de/download/ERNW_Troopers15_IPv6SecSummit_DHCPv6.pdf.
– in any case it greatly helps to understand the intrinsics of the individual OS you have to support, as of the paper which brought you here ;-). admitted: probably this is not an easy task in your type of (presumably academic) environment though…
best
Enno
Thanks for your suggestions. Our network is a cabled Ethernet (WiFi is provided by the university network/IT services), so we have no Android or other wireless clients. We have the usual mix of clients (Win7/8, Linuxes, Macs, RaspberryPi, etc.) Routers are also managed by the central IT service people, and the Cisco routers send RAs to our network. I run my own DHCPv6 service (using dhcpy6d, highly recommended).
I already tested setting the RA A=0 flag, but then the router’s link-local address disappeared from the clients, so all routing stopped 🙁 Very unsuccessful experiment.
Using RAs with M=1,A=1,O=1 has worked well until a Mac user found that he couldn’t connect to the link-local subnet, whereas Windows and Linux PCs have no problem. The OS X 10.10.3 reports a 128-bit prefix (as does Linuxes) and fails to ping6 any IPv6 on the link-local net only. I’m still fighting to find out why. I tried setting
sudo sysctl net.inet6.icmp6.rediraccept=1
without any luck. This could be a subtle bug in OS X rather than an error in my IPv6 setup.
hi,
did you consider in your paper if windows ignores icmpv6.nd.ra.flag.prf ?
it seems that windows, in a case of 2 RAs, installs 2 default gateways without honoring the preference flag.
it does not happen with
MAC Darwin Kernel Version 15.4.0
GNU/LINUX 3.13.0-85-generic
FreeBSD 10.3-RELEASE
thank you
—
antonio
Hi Antonio,
thanks for reaching out.
Actually Windows installs two default routes but they have a different metric (the one received with router preference = “high” has a better [lower] one), so only that (better) one is used. Once both have the same metric, Win uses ECMP with per packet load sharing (iirc).
In any case it respects the flag.
have a good one
Enno
hi,
really?
just tested on a pair of windows7 boxes, but they install 2 GWs with the same metric (266) despite the fact that one RA is advertising a high priority route and another one is advertising a low priority route.
as already said, it doesn’t happen on different OSes.
have you any hint, or further check?
thank you
—
antonio
Hi,
to be honest I’ve no idea as for your scenario. Over the yrs I’ve seen dozens of Win systems of different flavors & version which all behave correctly (different metrics, with a better one for the RA with router pref = high).
How do you send/generate the RAs? What do you see in Wireshark?
thanks
Enno
I’m sending RAs via radvd with “AdvDefaultPreference high;”
tcpdump shows correctly “pref high” from one RA
10:18:47.670250 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 144) fe80::a236:9fff:fe3a:ff5c > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 144
hop limit 64, Flags [managed, other stateful], pref high, router lifetime 60s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): sisinf.vlans.xxxxxxxx.it/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
0x0000: 40e0 0001 5180 0000 3840 0000 0000 2a02
0x0010: cdc5 9715 0022 0000 0000 0000 0000
route info option (24), length 24 (3): ::/0, pref=medium, lifetime=60s
0x0000: 0000 0000 003c 0000 0000 0000 0000 0000
0x0010: 0000 0000 0000
rdnss option (25), length 24 (3): lifetime 20s, addr: sisinf.vlans.xxxxxxxx.it
0x0000: 0000 0000 0014 2a02 cdc5 9715 0022 0172
0x0010: 0031 0022 0001
dnssl option (31), length 32 (4): lifetime 20s, domain(s): sisinf.xxxxxxxx.it.
0x0000: 0000 0000 0014 0673 6973 696e 6609 636f
0x0010: 6d75 6e65 7362 7402 6974 0000 0000
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
source link-address option (1), length 8 (1): a0:36:9f:3a:ff:5c
0x0000: a036 9f3a ff5c
tcpdump shows correctly “pref low” from the other RA
10:18:49.536624 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 144) fe80::a236:9fff:fe3b:1e > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 144
hop limit 64, Flags [managed, other stateful], pref low, router lifetime 60s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): sisinf.vlans.xxxxxxxx.it/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
0x0000: 40e0 0001 5180 0000 3840 0000 0000 2a02
0x0010: cdc5 9715 0022 0000 0000 0000 0000
route info option (24), length 24 (3): ::/0, pref=medium, lifetime=60s
0x0000: 0000 0000 003c 0000 0000 0000 0000 0000
0x0010: 0000 0000 0000
rdnss option (25), length 24 (3): lifetime 20s, addr: sisinf.vlans.xxxxxxxx.it
0x0000: 0000 0000 0014 2a02 cdc5 9715 0022 0172
0x0010: 0031 0022 0001
dnssl option (31), length 32 (4): lifetime 20s, domain(s): sisinf.xxxxxxxx.it.
0x0000: 0000 0000 0014 0673 6973 696e 6609 636f
0x0010: 6d75 6e65 7362 7402 6974 0000 0000
mtu option (5), length 8 (1): 1500
0x0000: 0000 0000 05dc
source link-address option (1), length 8 (1): a0:36:9f:3b:00:1e
0x0000: a036 9f3b 001e
ipv6 routing table on windows shows that both default routes have the same metric
IPv6 Route Table
============================================================
Active Routes:
If Metric Network Destination Gateway
17 266 ::/0 fe80::a236:9fff:fe3b:1e
17 266 ::/0 fe80::a236:9fff:fe3a:ff5c
thank you
—
antonio
Hi,
Antonio wrote:
> I’m sending RAs via radvd with “AdvDefaultPreference high;”
> tcpdump shows correctly “pref high” from one RA
yes, but those RAs also include route information options (RIO/option 24, as of RFC 4191) which shouldn’t be there (and those have *both* “medium” pref).
Please clear the respective “route definition” parts of your radvd.conf, you don’t need those (as hosts install a default route by mere reception of an RA => option 24 doesn’t need to be there and different OS interpret it differently, in particular when “containing a default route” which seems to apply in your case).
best
Enno
hi enno,
you’re right.
removing RIO type 24 did the trick.
now windows is installing 2 default routes with different metric
thank you
—
antonio
Hi Enno,
Great article with interesting scenarios!
What is your experience regarding rdnssd package on ubuntu? I think the ubuntu rdnssd daemon is processing only nameservers from RA package, search domain entries are ignored. Am I missing smth?
Regards