Some years ago Christopher wrote two posts (2016, 2015) about the IPv6-related characteristics of the WiFi network at Cisco Live Europe. To somewhat continue this tradition and for mere technical interest I had a look at some properties of this year’s setting.
There were two SSIDs of interest: a dual-stacked one (“CiscoLive2019”) and one with v6-only plus NAT64 (“CL-NAT64”). For some background on the underlying infrastructure components you might look at this thread by Nicolas Darchis from the NOC or at this tweet from Dominik Pickhardt. Some stats on IPv6 usage at CLEUR can be found here.
Let’s have a look at a few IPv6 parameters of those SSIDs.
SSID “CiscoLive2019” (Dual-Stack)
Here, Router Advertisements are sent out by two entities (fe80::7a72:5dff:fe1b:75c1 & fe80::7a72:5dff:fe1b:70c1) and except for Option 1 (“Source link-layer address”) they carry the exact same parameters:
The Router lifetime and the Reachable time are tweaked in a way common for WiFi networks, for reasons which Chris had laid out when discussing our own setup at Troopers (see his “Building a Secure and Reliable IPv6 Guest Wifi Network” talk from the TR16 IPv6 Security Summit or this post).
First-Hop Redundancy
One might note that both entities send their RAs with the same Router Preference (that is the default/Medium) and that no typical HSRPv2 MAC address is involved (see here for some information on HSRPv2 MAC addresses). To me these observations seem to indicate that neither an IPv6 First Hop Redundancy Protocol (FHRP, like HSRPv2 or VRRPv3) nor a RA-based HA approach (as the one laid out in the “Are Router Advertisements Good Enough?” section in Ivan Pepelnjak‘s “IPv6 High Availability Strategies” talk from the Troopers 2014 IPv6 Security Summit) are in use but that potentially some redundancy approach on the device layer (like VSS) is performed.
My laptop running Windows Server 2016 subsequently installed both addresses as IPv6 default routes with the same metric (excerpt from routing table):
13 301 ::/0 fe80::7a72:5dff:fe1b:75c1
13 301 ::/0 fe80::7a72:5dff:fe1b:70c1
I’m not sure what this means from a traffic handling perspective (from the top of my head I seem to recall that older Windows versions used per-packet load sharing in such scenarios but I didn’t quickly find a link and I did not perform any testing). Still I could imagine that different OSs might behave differently in such a setting (as RFC 4861 sect. 6.3.6 is quite vague in this regard) so, honestly, I’m a bit hesitant if this is a good approach (but evidently I might overlook sth here).
DHCPv6 & DNS
The reader might also note that DHCPv6 is not in use at all, neither stateful nor stateless (no corresponding RA flags are set). Also the RAs do not carry the option 25 (RDDNS) as of RFC 8106. This means that clients associated to the CiscoLive2019 SSID don’t have any IPv6-based DNS resolver information at all, which purists might hence not call a “fully dual-stacked network” (but ofc AAAA records can be resolved by the IPv4-based DNS servers given DNS is agnostic as for any relationship between the underlying IP transport of DNS queries coming in and the type of records they ask for). Andrew Yourtchenko commented that this approach was mainly chosen in order to “avoid complexity with troubleshooting”.
Misc
Furthermore option 5 (MTU) being set to 9000 caught my eye. When asked about this Andrew responded: “ended up like that by accident, we slightly changed the topology this year and wireless clients got their own L3 switch, with jumbo frame support 🙂 but hopefully the clients are smart enough not to try to send the 9K frames :)”. He has a point with the latter comment and actually my laptop didn’t pick the 9000 bytes MTU:
netsh int ipv6 sh int 13
IfLuid : wireless_32768
IfIndex : 13
State : connected
Metric : 45
Link MTU : 1492 bytes
It should be noted that RFC 4861 sect. 6.3.4 on “Processing Received Router Advertisements” specifies as follows:
“If the MTU option is present, hosts SHOULD copy the option’s value
into LinkMTU so long as the value is greater than or equal to the
minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value
specified in the link-type-specific document (e.g., [IPv6-ETHER]).” with the latter being a reference to RFC 2464 which in turn states:
“If a Router Advertisement received on an
Ethernet interface has an MTU option specifying an MTU larger than
1500, or larger than a manually configured value, that MTU option may
be logged to system management but must be otherwise ignored.”
I’m a bit scratching my head here as for the implications of these two (RFCs) on IPv6 Jumbograms (as of RFC 2675) but I will skip this for the moment and for the purpose of the present post.
SSID “CL-NAT64”
Obviously I was more interested in the configuration of this one and indeed some very interesting observations could be made here.
Overall the RAs look quite similar but with one notable difference, that is that here they actually include option 25/RDDNS (and, ofc, a different prefix is used):
Evidently in this (type of) network IPv6-based DNS Resolver information is needed for the clients. So far so good but looking closer another (from my perspective: stunning) detail becomes obvious, that is the configuration of
DHCPv6
Apparently no stateful DNS, which would then distribute DNS resolver information to clients not supporting RFC 8106 and hence unable to receive this type of information from RAs, is used. When asked about this Andrew responded as follows:
While we’re happy to see Chris’ post on “RDNSS (RFC 8106) Support in Windows 10 Creators Update” being referenced here I consider this a really bold move. We know some people currently performing v6-only+NAT64 pilot installations on a large scale (namely for WiFi networks with “unmanaged clients”) and those persons usually insist that proper distribution of v6 DNS information by both technical ways (option 25 in RAs plus stateless DHCPv6 with DNS information) is crucial to support as many clients as possible. In practice this meant that at CLEUR I couldn’t use the CL-NAT64 SSID with my own laptop (running Server 2016 which does not support RFC 8106, see also this post on its IPv6-related properties).
In this SSID/network there was another DHCPv6-related thing I observed and I didn’t have a proper explanation for. Both L3-devices (the “75c1” & “70c1”, see above) responded to the typical Windows-originated DHCPv6 Solicit messages with DHCPv6 Advertise messages, but “completely empty ones” (no IA, no options => subsequently no DHCPv6 Request message from the client’s side happened). This looked like this:
and here’s details on the “content” of the DHCPv6 advertise messages:
I’m not sure as for the purpose of this; actually I suppose some configuration remnants from the earlier approach incl. stateless DNS here. Also, strictly speaking this behavior (from the DHCPv6 “server” side) seems to violate RFC 8415 sect. 18.3.9 where it’s stated
“The server MUST include IA options in the Advertise message
containing any addresses and/or delegated prefixes that would be
assigned to IAs contained in the Solicit message from the client.”
On the other hand the DHCPv6 space doesn’t have a reputation of a huge degree of conformance with RFCs anyway ;-).
Getting back to the topic of v6-only & NAT64 I have to say that I was connected with my iPhone to the CL-NAT64 pretty much the whole time and I did not observe a single issue (incl. testing of some common applications like Threema, iMessage, DB Navigator and others). But this is only an anecdotal contribution which is why we’re currently building a proper test lab to test a variety of devices and applications in a v6-only+NAT64 setting. Chris and I will give a talk about this and further aspects of such networks (like monitoring, measuring progress or incentivizing its use) in the NGI IPv6 track at TR19. At CLEUR Mark Townsley gave a very interesting talk on “Beyond Dual-Stack: Using IPv6 like you’ve never imagined” which provided further thought what one can do with v6-only in 2019; it even included some nice live demos this year.
We’ll publish a follow-up once we have initial results of the lab. Stay tuned and/or see you at #TR19.
Cheers, Enno