Building

IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations

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

 

Comments

  1. 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.

    1. 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

  2. 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.

  3. 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

    1. 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

  4. 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

    1. 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

  5. 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

    1. 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

Leave a Reply

Your email address will not be published. Required fields are marked *