IPv6 multicast background traffic (Part 2) – Multicast and IPv6 Stack Auto-Configuration

If you would like to read the other parts in this article series please go to:

• IPv6 multicast background traffic (Part 1): Box Chatter – IPv6 Multicast Backgrounder
• IPv6 multicast background traffic (Part 3) – Multicast and IPv6 Stack Auto-Configuration (Cont.)
• IPv6 multicast background traffic (Part 4) – Box Chatter – P2P Multicast and the Zero Config Wars
• IPv6 multicast background traffic (Part 5) – Microsoft’s Multicast IPv6 Service Discovery Protocols
• IPv6 multicast background traffic (Part 6) – Apple’s Bonjour
• IPv6 multicast background traffic (Part 7) – iChatter and the Future of Zero Config

DHCPv6 Solicitation

Self-assigned addresses exist in IPv4 – a PC that doesn’t have a static IP address and can’t find a DHCP server can configure a link-local address from the 169.254.0.0/16 address space. Microsoft’s Automatic Private Internet Protocol Addressing (APIPA) is an example many people are familiar with, but typically one only sees it on corporate LANs when a PC is misconfigured and a technician needs to be dispatched to fix it.

IPv6 flips the equation on its head: unless you go out of your way to configure static addresses or set up a pool of DHCPv6 addresses, IPv6 automatically sets up unique addresses from the vast 128-bit space it has at its disposal. Known somewhat ponderously as stateless auto-configuration, this approach is the norm in IPv6 deployments. Typically, the only IPv6 setup work organizations do is to configure a 64-bit prefix, which as we discuss later is provided via an extension to ICMP.

DHCPv6 thus isn’t ordinarily used to allocate IPv6 addresses. Instead, it’s used to provide other networking info such as the DNS search list, FQDN, etc.

If you left your Windows 7 IPv6 stack at its default auto-configuration setting:

Figure 1

Then the first IPv6 activity Windows tries for each NIC at boot up is a DHCPv6 solicitation to ff02::1:2, the All DHCP Agents or Relays, Link-Local Scope multicast address. Right off the bat we can see a major difference versus IPv4: in the older protocol, DHCP solicitations go to the broadcast address 255.255.255.255, effectively disturbing every node on the local link. In IPv6, DHCP requests go to a dedicated multicast address, which in normal circumstances only the router is likely to be listening on, that was designed into the protocol for just this one specific purpose. Here’s what Wireshark, the open source protocol analyzer, shows:

Figure 2

As you can see, the PC is trying to obtain DNS-related info (and not an IP address). If there’s no DHCPv6 server set up on your LAN, then after an initial two failed tries, Windows keeps sending out DHCPv6 solicitation packets at intervals of 1 / 2 / 4 / 8 / 16 / 32 seconds, followed by a 364 second pause. (I should note that in Windows 7, there are special “tunneling” adapters for ISATAP, a so-called transition technology that allows IPv6 stacks to tunnel over an IPv4 intranet. These adapters don’t send out the DHCPv6 solicitations that regular physical adapters do).

Neighbor Discovery

To communicate with other IP hosts, a PC needs to know the MAC address of its target (either another device on the same LAN or a router). In addition, in order to configure a proper global unicast address, an IPv6 host needs to know its 64-bit routing prefix. Prefixes are obtained through processes known as Router Solicitation and Advertisement. Finally, even if a PC only uses a link-local fe80 address, it needs to establish that the address is unique on the local LAN and does so by issuing a special packet with an empty source address. Collectively, these techniques are known in IPv6-speak as Neighbor Discovery, or ND.

Four types of ICMPv6 packets are commonly used for ND:

Table 1

When a Windows 7 PC boots up, each NIC sends up to three Router Solicitation ND packets to ff02::2:

Figure 3

If an IPv6 router is listening on that multicast address it will respond, otherwise the PC will quit trying after three attempts. Alternatively, routers that are configured for IPv6 periodically send out Router Advertisement (RA) packets that optionally supply an IPv6 prefix.

Lab Work: Using the Vyatta Open Source IPv6 router

Here’s an experiment you can try in your lab environment. Set up an isolated network segment, e.g. in VMware create an isolated vSwitch. Download and install the free community edition of the Vyatta open source router (it’s available in several convenient forms, LiveCD and VMware OVA for example). Login with default username and password of “vyatta” and use the following sample sequence of configuration commands:

configure
set interfaces ethernet eth0 address 2001:db8:2::1/64
set interfaces ethernet eth0 ipv6 router-advert prefix 2001:db8:2::/64
set interfaces ethernet eth0 ipv6 router-advert send-advert true
commit
save
exit
# Verify that things work
show interfaces
ping6 2001:db8:2::1

What you’ve done here is configure Vyatta as an IPv6 router, set it up to supply a 64-bit global prefix 2001:db8:2::1 and told it to advertise the prefix. The Vyatta router now periodically (every 16 seconds or so) emits RA packets such as:

Figure 4

Any IPv6 host on the LAN listening on ff02::1, the Link-Local All Nodes multicast address that receives the RA packet above now has the info it needs to auto-configure a global unicast IPv6 address. A Windows 7 PC with an unconfigured IPv6 stack received this packet and instantly created two unicast addresses with the 2001:db8:2:0 prefix:

C:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:db8:2:0:cd0f:d0a1:bcda:7848
Temporary IPv6 Address. . . . . . : 2001:db8:2:0:b49e:d4e6:e113:a6e4
Link-local IPv6 Address . . . . . : fe80::cd0f:d0a1:bcda:7848%11
IPv4 Address. . . . . . . . . . . : 192.168.1.41
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::20c:29ff:feac:d7c7%11
192.168.1.1

Notice that the NIC “Local Area Connection” has one IPv4 address and three IPv6 addresses. While some IPv4 adapters have multiple IP addresses, this is ordinarily only on servers. In IPv6, on the other hand, adapters typically have multiple addresses even on regular PCs. In this case we’ve got a link-local fe80 address that’s only valid on the local LAN and two globally-unique IPv6 unicast addresses.

Note also the address labeled “Temporary” – I won’t go into it at length here, but this is a privacy feature unique to IPv6 that allows hosts to create throwaway IP addresses so they can’t be tracked. Privacy is at greater risk with globally-unique IPv6 addresses that, unlike IPv4, cannot be made invisible behind a NAT. On the other hand, there are concerns about spammers and criminals hiding behind untraceable IP addresses. Microsoft’s implementation of these IPv6 privacy extensions has been questioned but this is a topic for another day.

Finally, I should note that, as with any dynamic run-time operation, the Bad Guys have looked for flaws in Router Advertisements and how clients, especially Windows PCs, handle stateless auto-configuration. An ethical hacker recently discovered a Denial-of-Service attack that allegedly takes advantage of a flaw in the Windows 7 IPv6 stack. He discusses some interesting possible defenses, such as playing with Windows Firewall rules and creating an explicit whitelist of router addresses from which RA packets will be deemed legitimate:

Figure 5

More drastically, you optionally can tell Windows to ignore Router Advertisements entirely by:

netsh interface ipv6 set interface “Local Area Connection” routerdiscovery=disabled

changing “Local Area Connection” to the desired interface. If you do this, however, you’d need to supply the prefix via alternative means, such as DHCPv6. Curiously, I have not found a Microsoft-supported way to assign IPv6 prefix via Windows Group Policy or a registry key.

In the next post, we’ll finish Neighbor Discovery with a look at IPv6’s replacement for ARP, Neighbor Solicitation and Advertisement, wrap up stack auto-configuration with a look at MLDv2 and then we’ll be in a solid position to look into IPv6 Peer-to-Peer traffic and the Zero Config wars.