Four-Layer IPv6 Architectural Model

A chart depicts the four-layer I P v 6 model. It has an application layer, a transport layer, an internet layer, and a link layer.

In the following discussion, traffic really flows both down from the Application Layer to the Link Layer (then out the wire) and from the wire up through the Link Layer to the Application Layer. For clarity, only the downward path is described in the following. When traffic goes up through the layers, each layer strips off one header and hands off the remaining bytes to the layer above.

The Application Layer implements the protocols most people are familiar with (e.g., HTTP). The software routines for these are typically contained in application programs such as browsers or web servers that make system calls to subroutines (or “functions” in C terminology) in the “socket API” (an API is an Application Program Interface, or a collection of related subroutines, typically supplied with the operating system or programming language). The application code creates outgoing data streams and then calls routines in the API to actually send the data via TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). Output to the Transport Layer is [DATA] using IP addresses.

The Transport Layer implements TCP (the Transmission Control Protocol) and UDP (the User Datagram Protocol). These routines are internal to the socket API. They add a TCP or UDP packet header to the data passed down from the Application Layer and then pass the data down to the Internet Layer for further processing. Output to the Internet Layer is [TCP HDR [DATA]], using IP addresses.

The Internet Layer implements IPv6 (the Internet Protocol) and various other related protocols such as ICMPv6 (which includes the “ping” function among other things). The IP routine takes the data passed down from the Transport Layer routines, adds an IPv6 packet header onto it, and then passes the now complete IPv6 packet down to routines in the Link Layer. Output to the Link layer is [IPv6 HDR [TCP HDR [DATA]]] using IP addresses. ND (Neighbor Discovery) is actually a part of ICMPv6. It helps locate the Link Layer address of other nodes on the link in addition to other functionality.

The Link Layer contains routines that actually read and write packets (as fed down to it by routines in the Internet Layer) onto the network wire, in compliance with Ethernet or other standards. Output to wire is Ethernet frame using MAC addresses (or the equivalent if other network hardware is used, such as Wi-Fi), which includes the entire IPv6 packet.

Link Layer Issues with IPv6

IPv6 Packet Header Structure

So what are these packet headers mentioned previously? In IPv6 packets, there is an IPv6 packet header, then zero or more packet header extensions, then a TCP or UDP header, and finally the packet data. Each header and header extension is a structured collection of data, including things such as the IPv6 address of the sending node and the IPv6 address of the destination node. Why are we getting down to this level of detail? Because some of the big changes from IPv4 to IPv6 have to do with the new and improved IP packet header architecture in IPv6. In this chapter, we’ll cover the IPv6 packet header. Here it is.

A model depicts the I P v 6 packet header. It has I P version, traffic class, flow label, payload length, next header, hop limit, source I P address, and destination I P address as its elements.

The IP Version field (4 bits) contains the value 6 (imagine that!), which in binary is “0110.” This field allows IPv4 and IPv6 traffic to be mixed in a single network.

The Traffic Class field (8 bits) is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets, in a manner virtually identical to that of IPv4 “Type of Service.”

The Flow Label field (20 bits) is something new in IPv6. It can be used to tag up to 2²⁰ (1,048,576) distinct traffic flows, for purposes such as fine-grained bandwidth management (QoS). Its use is still experimental. Hosts or routers that do not support this function should set it to zero when originating a packet or ignore it when receiving a packet. The semantics and usage of this field are covered in RFC 8200. Further information is found in RFCs 3595, 6294, 6437, 6438, and 7098. Even today, very few routers actually act on the contents of this field. Until they do, it will be of limited value.

The Payload Length field (16 bits) is the length of the IPv6 packet payload in bytes, not counting the standard packet header (as it is in IPv4 Total Length), but counting the size of any extension headers, which don’t exist in IPv4. You can think of packet extension headers as being the first part of the Data field (payload) of the IPv6 packet.

The Next Header field (8 bits) indicates the type of header immediately following the standard IPv6 packet header. It uses the same values as the IPv4 Protocol field, as defined in RFC 1700, “Assigned Numbers,” October 1994. If this value contains the code for TCP, then the TCP header and packet payload (data) begins immediately after the IPv6 packet header. Otherwise, one or more IPv6 extension headers will be found before the TCP header and data begins. Since each extension header has another Next Header field (and a Header Length field), this constitutes a linked list of headers before the final extension header, which is followed by the data. UDP packets can also have extension headers.

The Hop Limit field (8 bits) is to prevent packets from being shuttled around indefinitely on a network. Every time a packet crosses a switch or router, the hop count is decremented by one. If it reaches zero, the packet is dropped. Typically, if this happens, an ICMPv6 message (“Time Exceeded”) is returned to the packet sender. This mechanism is how the traceroute command works.

The Source IP Address field (128 bits) contains the IPv6 address of the packet sender.

The Destination IP Address field (128 bits) contains the IPv6 address of the packet recipient.

IPv6 Packet Fragmentation and Path MTU Discovery

The fields related to fragmentation are now found in the Fragment extension header, which exists only in fragmented packets (no need to clutter up unfragmented packets, as in IPv4). In IPv6, only the originating node can fragment packets (no intervening node is supposed to do this). The originating node uses MTU Path Discovery to determine the “width” of the proposed path (the maximum packet size that it can handle). MTU stands for Maximum Transmitted Unit (maximum packet length). Any packets larger than that size must be fragmented before transmission by the originating node and reassembled upon receipt by the destination node. There is a default packet size that any IPv6 node must be able to handle (1280 bytes). MTU Path Discovery allows the sender to determine if larger (more efficient) packets can be used. The originating node assumes the path MTU is the MTU of the first hop in the path. A trial packet of this size is sent out. If any link is unable to handle it, an ICMPv6 Packet Too Big message is returned. The originating node iteratively tries smaller packet sizes until it gets no complaints from any node and then uses the largest MTU that was acceptable along the entire path. This process takes place automatically in the Internet Layer. There is no corresponding mechanism in IPv4.

Extension Headers (New in IPv6)

After the main header, there can be zero or more extension headers , before the payload (actual packet data). This approach makes IPv6 highly extensible, for new functionality in years to come. Several extension headers are already defined, and doubtless more will be defined over time.

The first byte of each extension header contains a Next Header field, identical to the same named field in the main IPv6 packet header (using codes from RFC 1700). The second byte of each extension header contains a Header Extension Length field, which specifies the length of this header, in 8-byte units, not including the first 8 bytes. Thus, every extension header is at least 8 bytes long and is a multiple of 8 bytes in length. The following header (or data, if no more extension headers) will begin immediately after the end of this extension header. This effectively defines a linked list (a data structure familiar to all programmers). Here are some typical packet header sequences to illustrate how each chains to the next.

A model depicts the typical I P v 6 packet header with extensions. It has a basic I P v 6 headers, T C P header, data, routing extension header, fragment extension header, and first fragment of data as some of the elements

Two extension headers are used for IPsec (IP Layer security). The IPsec Authentication extension header (IPsec AH) is defined in RFC 2402, “IP Authentication Header,” November 1998. The Encapsulating Security Payload header (IPsec ESP) is defined in RFC 2406, “IP Encapsulating Security Payload (ESP),” November 1998.

Hop-by-Hop Options header: Used to carry optional information that must be examined by every node along a packet’s delivery path. This option is indicated by a Next Header value of 0.

Routing header: Used by an IPv6 source node to list one or more intermediate nodes to be “visited on the way” to a packet’s destination. This is similar to IPv4’s Loose Source and Record Route option. The Routing header is identified by a Next Header value of 43.

Fragment header: Used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. In IPv6, packet fragmentation is performed only by the source node, which must use MTU discovery to determine the maximum packet size along the proposed path. The Fragment header is identified by a Next Header value of 44.

Destination Options header: Used to carry optional information that needs to be examined only by a packet’s destination node(s). The Destination Options header is identified by a Next Header value of 60.

For the specific details on each of the above header extension packets, see RFC 8200. The Authentication header and ESP packet headers will be described later, under IPsec.

IPv6 Addressing Model

Some people are aware that you can use IPv4 addresses instead of nodenames in web URIs, for example: http://123.45.67.89/main.html. You can also use IPv6 addresses, but because colons demark other things in URIs (such as nonstandard port number), you cannot use IPv6 addresses “as is”; enclose them in square brackets ([]). For example, http://[2001:df8:5403:3000::d]/nagios is a valid URI that includes an IPv6 numeric address.

When an RIR (e.g., APNIC) allocates a “/32” block of addresses to an ISP, they assign the first 32 bits of those addresses, based on the next available “/32” block from the unallocated pool at that time. A “/32” block contains 65,536 “/48” blocks to allocate to customers. If the ISP allocates all those, then the RIR will give them a new “/32” block, each address of which will have a completely different first 32 bits from the addresses in the previous “/32” block given to the ISP. The leftmost, or most significant, 32 bits of every address in a given “/32” block will all be the same. All addresses from smaller blocks (like a “/48” block or “/64” block) carved out of that “/32” block by the ISP (for allocation to customers) will have the same first 32 bits. For example, many of NTT America’s IPv6 allocations include addresses that start with “2001:418::/32”. No other ISP in the world will ever be allocated a “/32” block with those particular first 32 bits. Up to 65,536 of NTT America’s customers might get “/48” blocks whose addresses start with those 32 bits.

When an ISP allocates a “/48” block for a customer from their “/32” block, the next 16 bits (following the first 32 bits) are chosen by that ISP, so that the first 48 bits will be unique to that customer in the entire world. The first 48 bits of every address in a “/48” block given to an end-user organization will all be the same but will be different from the first 48 bits of the addresses in any other “/48” block in the world. You can think of this 48-bit sequence as the organization prefix. All addresses in our “/48” block from HE happens to start with “2001:470:ed3a::/48”. No other customer of HE has ed3a in the third 16-bit field of their addresses. When a customer deploys subnets, they choose a further 16-bit value (unique within their organization) for each subnet, which, together with the organization’s 48-bit prefix, creates a globally unique 64-bit prefix for a working subnet. This can be used to manually configure 128-bit addresses for nodes on that subnet, or they can be configured on the Router Advertisement Daemon that supplies prefixes to nodes in that subnet for Stateless Address Autoconfiguration. If using stateful DHCPv6, the administrator can also create pools of addresses for assignment, where each 128-bit address in a pool has that same 64-bit subnet prefix.

IPv6 Packet Transmission Types

In IPv4, there were several packet transmission types (unicast, anycast, and multicast). IPv4 multicast uses class D addresses, while all other addresses are unicast (or reserved). There is no real concept of scope in IPv4 (the part of the network in which a given address is valid and unique). IPv4 “private addresses” are a step in this direction, but IPv6 defines real scope rules for certain kinds of addresses. These concepts are defined in RFC 4291, “IP Version 6 Addressing Architecture,” February 2006. Note: In Windows, “ping” is used for both IPv4 and IPv6. In Linux and BSD, the “ping” command is used just for IPv4 – in IPv6, the command is “ping6.” In the following, I use just the generic “ping,” but be aware that for IPv6 on some platforms, “ping6” would actually be used.

IPv6 Address Scopes

IPv6 Address Types

An anycast address can specify any of a group of addresses (usually on different nodes). A packet sent to an anycast address will be delivered to exactly one of those interfaces, typically the “nearest” one (in the network sense, not geographic sense). Anycast addresses look just like unicast addresses and differ only in being injected into the routing protocol at multiple locations in the network.

With the scopes larger than the organization, multicast addresses must be specifically configured on nodes (you have to “subscribe to that channel”). If you ping the multicast address ff0e::1, you are not going to get a response from every node on earth, unless you can first talk everyone into adding that address to their nodes. Even then, various routers along the way would probably block that packet. An organization’s routers enforce the scope rules so that link-local multicast addresses will not cross any routers, organization-local multicast addresses will not cross the organization’s border router, but global multicast addresses will cross any router (in the real world, this is actually managed by the MLD, the Multicast Listener Discovery protocol, and PIM, the Protocol Independent Multicast protocol).

These addresses are used by ND (the Neighbor Discovery protocol) in the process of mapping IPv6 addresses to Link Layer (MAC) addresses.

There is no broadcast address in IPv6, but a multicast to all nodes on the local link multicast group ff02::1 will have pretty much the same result.

Perhaps someday there will be a central authority to coordinate use (and allow reservation) of multicast group IDs. No such authority currently exists. Once IPv6 multicast broadcasters start making their programming available over large regions (or even worldwide), such coordination will be necessary and corresponds to the FCC’s management of broadcast frequencies that prevent stations from interfering with each other. Because the number of potential group IDs is so large (2¹¹² or about 5.19 e+33), for now, choosing them randomly is sufficient. The probability of any two randomly generated group IDs being the same is quite low, even with millions of people using this scheme. You might think of these group IDs as being in some sense channel numbers as found today on TVs. I can envision a search engine that would allow you to find multicast channels associated with programming that caters to specific tastes, such as Bollywood music videos over IPTV.

Special Case: IPv4-Compatible IPv6 Addresses (Now Deprecated)

The entire 4.3 billion addresses of IPv4 were mapped into the IPv6 address space, not just once, but twice – once as IPv4- compatible IPv6 addresses (::w.x.y.z) and a second time as IPv4-mapped IPv6 addresses (::ffff:w.x.y.z).

The addresses in the first special block all start with 96 bits of 0, followed by a 32-bit IPv4 address (which can be specified in dotted decimal). When you send traffic to an IPv4-compatible IPv6 address, it is sent as an IPv6 packet, but encapsulated with an IPv4 header, with the Protocol field of the IPv4 packet header set to 41 to indicate that the payload is an IPv6 packet. The IPv4 header allows the traffic to travel across an IPv4-only infrastructure. Upon receipt, the packet payload (the IPv6 packet) is passed to IPv6. This is called automatic IPv6 tunneling over IPv4 networks (defined in RFC 2893, “Transition Mechanisms for IPv6 Hosts and Routers,” August 2000).

IPv4-compatible IPv6 addresses were deprecated in RFC 4291, “IP Version 6 Addressing Architecture,” February 2006. No current transition mechanism uses them. New implementations are not required to support these addresses. Note however that two special addresses that are widely used actually fall into this range, the “unspecified” address (all zeros, or “::”) and the loopback address (“::1”).

Special Case: IPv4-Mapped IPv6 Addresses (Still Valid)

In general, it is best to avoid use of these addresses since support varies from operating system to operating system, behavior is implementation dependent, and there are potential vulnerabilities if it is enabled. It was originally intended as a transition mechanism, but it caused more problems than it solved, so it is better left unused and, ideally, disabled.

Simple IPv6 Address Assignment Scheme (for Manually Assigned Addresses)

The following is not part of any standard, IETF or otherwise. It is a best-practices recommendation, which may help you in migration to IPv6.

Many administrators have adopted a simple scheme for assigning IPv6 addresses manually to nodes, based on existing IPv4 address conventions or actual addresses. It could be argued that it can lead to confusion (by humans) between decimal and hexadecimal. It uses the same numeric digits that are currently used in your IPv4 scheme, to create what are really hexadecimal fields. It is possible to use the numeric digits (0–9) to create up to three hex digits in each of the four 16-bit groups in the IPv6 interface identifier. The resulting address may look strange in binary, but this scheme will make it easier for you to keep track of your IPv6 nodes and is especially useful in dual-stack networks, where you can use what appears to be the “same” address (not counting the prefix) on a given node, in both IPv4 and IPv6.

Using only the IPv4 interface identifier is less likely to produce addresses that collide with automatically generated addresses but requires a good understanding of IPv4 subnetting (see the preceding discussion). Use whichever scheme makes the most sense to you but try to be consistent.

Note that the addresses 123.45.67.1/24 and 192.168.0.1/16 would both produce fe80::1 as the equivalent IPv6 address, but this would not produce a conflict since they are in different subnets, and link-local addresses are valid only within a single subnet.

Obviously, no addresses generated with Stateless Address Autoconfiguration will use this convention, although you should be careful to make sure there are no conflicts between addresses you create and automatically generated addresses. Duplicate Address Detection during automated address creation should detect such conflicts. On the other hand, you can easily create DHCPv6 address pools that will be consistent with these schemes.

I recommend that you avoid use of this mixed notation altogether. If you use the Simple IPv6 Address Assignment scheme , be very careful to use colons (not dots) between all fields, as software that understands the mixed address syntax will interpret addresses with dots in the last four groups as perfectly valid “mixed” notation. This will result in some odd problems. The mixed notation was really intended for use with IPv4-mapped IPv6 addresses, but it works anywhere. You should never create addresses using it, but you need to know about it in case you see addresses written in it by someone else.

Multiple IPv6 Subnet Numbers on a Single Network Link

A single network link can actually have addresses with more than one 16-bit subnet number at any given time. For example, the prefix 2001:df8:5403:1600::/64 may be used with stateless autoconfiguration, while the prefix 2001:df8:5403:1601::/64 could be used with stateful autoconfiguration using DHCPv6 on the same network link. You could also have manually assigned addresses using a third prefix (e.g., 2001:df8:5403:1602::/64) on the same network link. Addresses with different subnet numbers, but the same interface identifier, are not in conflict. Normally, you only broadcast one 64-bit prefix with Router Advertisement messages onto a given network link, so all addresses created with stateless autoconfiguration in a given subnet will have only that one 64-bit prefix. It is possible in some implementations to advertise many prefixes on each network link. If multiple prefixes are advertised, there will still be only one default gateway, which is the link-local address of the gateway that is sending Router Advertisement messages. Another alternative is to define a subnet size greater than /64 on a single network link that includes all the desired subnet numbers. With a “/60” subnet, you can actually have 16 sequential /64 subnet numbers in a single network link (the first subnet number has to be an integral multiple of 16). This is called supernetting. Do this only if you really understand what you are doing.

Multiple IPv6 Addresses on a Single Node

Unlike with IPv4, it is completely normal for IPv6 nodes to have multiple valid addresses. They don’t even all have to have the same subnet number (if you are running multiple subnet numbers on a single link ). A single node could have addresses with each of the preceding 64-bit prefixes (or even multiple manually assigned addresses) at any given time. It could also have various multicast addresses. One of the unicast addresses (chosen at random) will be used as the source address of packets sent by that node, but incoming packets addressed to any of the addresses owned by the node will be accepted.

Automatically Generated Interface Identifiers Based on EUI-64

By default, every IPv6 interface will create a unique link-local address (fe80::w:x:y:z). If there is a Router Advertisement Daemon configured and running on the link, the node will also automatically create a global unicast address by using the 64-bit subnet prefix from the Router Advertisement message. It either can generate the interface identifier (low 64 bits) from the node’s MAC address (using EUI-64) or can use a random 64-bit value. This is described in RFC 4291, “IP Version 6 Addressing Architecture,” and RFC 2464, “Transmission of IPv6 Packets over Ethernet Networks.”

This is a reversible mapping, so given an EUI-64 identifier, it is trivial to determine the MAC address of the node (discard the FFFE in the middle 16 bits and invert the seventh bit of the remaining 48-bit value). Note: The seventh bit in the first byte of all valid Organizationally Unique Identifiers, hence of all MAC addresses, will always be 0.

One of the security advantages of IPv6 is supposed to be that the number of possible addresses in a subnet (2⁶⁴) is so large that it is impractical to scan all of them to discover all the nodes on a subnet (this is called mapping a subnet). If EUI-64 interface identifiers are used, there are so few of these (in comparison with the total possible number of interface identifiers) that it is possible to scan for them (especially with the knowledge of which Organizationally Unique Identifiers are actually in use, which is not difficult to determine).

Randomized Interface Identifiers

The reason you might want to disable randomization is that some servers will only accept a connection from nodes for which they can perform a reverse DNS lookup. This often will fail with randomized identifiers. Note that use of randomized interface identifiers can make it very difficult to determine to whom specific traffic in a log belongs, unless a record is kept of randomized interface identifiers used by each node.

When a randomized address changes, the old address is kept around for some time, but marked as deprecated, which means your node will not use it for further outgoing connections. It will accept incoming replies addressed to a deprecated address until that address becomes invalid, which it eventually will be. Since you aren’t making new outgoing connections with it, replies to it will cease fairly quickly. Addresses with randomized interface identifiers are used primarily for outgoing connections (and replies thereto). A node that can accept incoming connections from anyone should have (possibly in addition to other addresses) a static (unchanging) unicast address, which is published in DNS. This would be used by other nodes that want to connect to it. A node that only ever makes outgoing connections need not have such a static address assigned to it, and there is no need to publish its name and IPv6 address in DNS (at least not in your external DNS). Remember in IPv6, it is much more likely that other nodes will be connecting to your node (for VoIP, VPNs, P2P, etc.). The age of NAT (and one-way connectivity) is over.

IPv6 Address Allocation

The standard allocation block to be given to organizations is a “/48,” which is 65,536 subnets, each of which is a “/64” block consisting of 2⁶⁴ or about 18 billion, billion addresses (about 4 billion times the total number of addresses in the Second Internet). Some ISPs may choose to allocate only a single “/64” block to individuals or home users, who have no need for multiple subnets. It is not practical to allocate only a single IPv6 address (a “/128” block) to a user, due to the fact that nodes often create new addresses. One “/48” block will supply 65,536 individuals or homes with “/64” blocks. Perhaps I’m a bit unusual, but I already have two subnets in my home today (one dual stack, one IPv6-only). Who knows, I might have a bunch someday! My company has a “/48” (2001:df8:5403::/48), which we divided into 16 “/52” sub-blocks, each of which has 4096 subnets. I have one of these “/52” sub-blocks (subnets 3000–3fff) routed to my house. That should just about take care of me for some time to come. A single “/64” block should work for most home users.

ISPs are allocated really big “/32” blocks of addresses, which are enough to allocate “/48” blocks for up to 65,536 customers. Should they use up an entire “/32” block, there are plenty more “/32” blocks where that one came from (about 536 million of them just in the 2000::/3 block marked for allocation). The RIRs (ARIN, RIPE, APNIC, LACNIC, and AfriNIC) will be happy to give an ISP all they can use. If you assume there are 7 billion people alive, there are over 5000 “/48” blocks for every human alive, just out of the 2000::/3 range currently marked for allocation. It is extremely unlikely that any single human will ever be able to use any appreciable percentage of their “fair share” of addresses, let alone have the IANA run out. The folks in Taiwan say they want to connect 3 billion devices to the Internet in the next couple of years. This would take three-fourths of the entire Second Internet’s address space but could be handled with a tiny fraction (less than 1 billionth) of a single “/64” block with IPv6, should they want to have them all in one block for some bizarre reason. It will be quite a while before anyone worries about IPv6 address space exhaustion (famous last words?).

The People’s Republic of China believes that they were cheated out of sufficient IPv4 addresses to participate fully in the Second Internet. By the time China started deploying IPv4, if they had taken all the remaining addresses, over 90% of the people there would not have gotten one. The Second Internet recently passed an interesting threshold. There are now more Chinese-speaking users on it than English-speaking users. If you recall the chart of allocated addresses earlier in this book, the United States has over 43% (28% ARIN + 15% legacy, both of which are mostly US users) of the total IPv4 address space for less than 5% of the world’s population. In comparison, APNIC, which includes China, India, and several other populous countries (all together about 50% of the world’s population), has only 16% of the IPv4 address space. When the IPv4 addresses were all gone in September 2011, APNIC would probably still have less than 20% of the IPv4 address space (about .28 addresses per person), while the United States would probably have about 45% (about 6.4 addresses per person). However, note that about one-third of that 45% are held by fewer than 50 organizations (like MIT, Apple, HP, etc.). The distribution of addresses in the Second Internet was (and remains) anything but equitable. It’s really pretty much impossible to do anything about that now. We’re doing it right on the Third Internet. The Second Internet was really an American thing that they shared (to some extent) with the rest of the world. The Third Internet is the first truly global Internet. Every country can have as many public addresses as they can conceivably use.

Should We Reserve Some IPv6 Addresses for Developing Nations?

There has been talk from the ITU (International Telecommunication Union ) about reserving some IPv6 address space for developing nations to make absolutely certain that nobody ever gets left out again, as has happened in the Second Internet. There are so many IPv6 addresses that there is essentially no chance of this ever happening. The ITU might as well try to reserve a few trillion grains of sand (maybe a dump truck’s worth) to make sure that every country can be assured of getting their fair share of grains of sand. The total number of IPv6 addresses is on the same general scale as the number of grains of sand on earth.

Note that block 2000::/3 (which you can also think of as blocks 2000::/16 through 3fff::/16) is currently the only part of the overall space marked for unicast address allocation. This is only one-eighth of the total IPv6 address space. Even so, this is still 2¹²⁵, or about 4.15 e+37, addresses. You can also view this as 2⁴⁵ (about 35.2 trillion) “/48” blocks or just over 5000 “/48” blocks per human alive in 2010 (using the worldwide population as 7 billion). Should we ever use this up, there are still at least 5.5 times that much space currently not used for anything (from 4000::/16 to efff::/16) that we could repurpose for additional allocation.

I personally don’t think there is any reason to reserve a special block of addresses for anyone, including developing nations. Unlike with IPv4, there are plenty of addresses for everyone this time around.

The People’s Republic of China (and every other country) will have plenty of addresses in the Third Internet, and this is one reason they are investing so heavily in it. India is now determined to deploy IPv6 nationwide and had quite a bit deployed by the end of 2010. By some measure they were at 60% deployment in 2019. The inequitable distribution of addresses in the Second Internet may also account for some of the lack of urgency to migrate to the Third Internet in the United States. Unfortunately, it is not simply a matter of still having enough IPv4 addresses. Imagine if the United States stayed with Standard-Definition NTSC TV, while the entire rest of the world went with globally standard High-Definition TV. The United States would not be able to export their programming to anyone else nor import programming from the rest of the world. If they choose to stay with IPv4, they will be isolating themselves in some very serious ways. It’s not completely ridiculous to think that the United States might decide not to deploy the Third Internet. Look what happened with the metric system. If IPv4 is “riding horses” and IPv6 is “driving cars,” you don’t need to wait until the last horse dies before you get a car. The “cars” (IPv6) are ready and widely available today. Those who adopt cars first will leave those still riding horses way behind. I’d suggest you migrate to IPv6 as soon as possible. Countries that master it and start creating products and applications based on it will have a giant head start in the twenty-first century over those who wait until the last possible minute.

How Is the Entire IPv6 Address Space Divided Up?

The 6bone was an early worldwide IPv6 testbed. It used addresses from 3ffe::/16 (as per RFC 2471,⁹ “IPv6 Testing Address Allocation,” December 1998). These have since been returned to the overall allocation pool as per RFC 3701,¹⁰ “6bone (IPv6 Testing Address Allocation) Phase-Out,” March 2004, once the 6bone had served its purpose and was shut down. Interestingly, some addresses from this block still show up on the IPv6 backbone. Among other places, they are still used in IPv6-ready tests, so if an IPv6-ready test network is connected to the main Internet, those addresses could be accidentally routed. Even though they are just more IPv6 unicast addresses now, I would recommend against using them in production systems, just in case. It’s not like there aren’t plenty of other IPv6 unicast addresses to use.

Note that this data does not reflect the actual number of addresses or the volume of traffic, just the number of distinct 48-bit prefixes, which is a rough indication of the number of organizations investigating IPv6. Much of this in the United States is probably research or academic. As percentages of the gigantic total number of “/48” blocks available for allocation, all these are essentially zero (pretty much all the 2000::/3 IPv6 address space is still available for allocation). This tiny percentage is more an indication of the colossal size of the IPv6 address space than of any lack of interest or activity.

Here is a graph of the percentage of traffic that is IPv6, for the world and the five RIRs, as of late 2018. You can see how much things changed since 2010.

A line graph depicts the percentage of networks that includes I P v 6 over the years and depicts an increasing trend. It covers four specific regions and all countries.

Classless Inter-Domain Routing (CIDR)

There is no reason to implement CIDR for IPv6. It was done in IPv4 only to extend the lifetime of the IPv4 address space long enough for IPv6 to be fully developed, which has now happened. There is no need to extend the lifetime of the IPv6 address space. If IPv6 had been ready and we had migrated to it in the mid-1990s, we would never have had to suffer through the complexities brought about by CIDR and NAT. The reason we are having to deal with these issues today is that we have already stayed with IPv4 far too long. Imagine trying to do serious work today with an 8-bit processor and 64K bytes of RAM.

Network Ports

Network ports work exactly the same way under IPv6 as they do in IPv4. There are still 65,536 of them associated with every IPv6 address. They could have gone to 32-bit port numbers (yielding 4.3 billion ports for each address), but this would have required even more changes in packet headers and other places, so this was not done. 65,536 is plenty for almost any need, especially since you can assign any number of global unicast addresses to a single interface (each of which has 65,536 ports). The same well-known port numbers are used in IPv6 as in IPv4. The only difference is that you will never see port numbers on IPv6 addresses being shifted by a NAPT gateway, since there is no NAT for IPv6 to IPv6. Note that a given port being used over IPv4 does not prevent it from being used by the same or even a different application, over IPv6 (and vice versa).

Subnetting in IPv6

There is no CIDR in IPv6 (although the CIDR “slash notation” is still used). As a result, subnetting is much simpler in IPv6. All subnets are “/64.” The only exception is if you do supernetting (e.g., a “/60” subnet) to allow multiple “/64” blocks to be used on a single network link. This will likely only be done in large, advanced corporate networks, so most network engineers will never see anything but “/64” subnets.

The only reason for doing this might be to use different “/64” subnets for specific purposes, such as 1000 for SLAAC, 1001 for DHCPv6-assigned addresses, and 1002 for manually assigned addresses. If you use EUI-64 interface identifiers for SLAAC, it is not difficult to partition a single “/64” so there will be no overlap between SLAAC, DHCPv6, and manual assignments. If you use random interface identifiers, they may fall anywhere in a “/64” address space. However, the probability of one colliding with an address assigned manually or via DHCPv6 stateful mode is incredibly low, and Duplicate Address Detection should prevent the odd collision. Having at least two “/64” subnets in a single network (one for SLAAC, one for manually and DHCPv6-assigned addresses) removes all possibility of an address collision.

Each subnet needs to be at least a “/64,” since EUI-64 can generate “node within subnet” values that are 64 bits long. Randomized interface identifiers are also 64 bits in length. But a “/64” subnet is already larger than any organization could conceivably use (18 billion, billion addresses). There are so many “/64” blocks in a single “/48” (65,536) that we can use them even for subnets between a border router and a firewall, which have only two addresses. There is never an excuse to use any subnet smaller than a “/64,” although I have seen some old-school IPv4-trained administrators allocate “/124” IPv6 subnets for the link between a border gateway and firewall case (in IPv4, tiny subnets like /30 would be used in such a case). Old habits die hard. After living with increasing scarcity with IPv4 addresses, it is hard for some of us to realize that there are PLENTY of addresses this time around.

Link Layer Addresses

The software in the Application Layer, the Transport Layer, and the Internet Layer of the IPv6 stack think in terms of IP addresses. But the Link Layer (and the hardware) thinks in terms of MAC addresses. In IPv6 the mapping from IPv6 address to Link Layer (MAC) address is done with the Neighbor Discovery protocol. Note that in this book, I often use the terms Link Layer address and MAC address interchangeably.

IPv6 addresses are not actually used at the lowest layer of the IPv6 network stack (the Link Layer). The 48-bit MAC addresses covered in Chapter 3 still exist and are used the same way at the Link Layer (at least for Ethernet networks).

Router Discovery

IPv6 router discovery corresponds roughly to IPv4 router discovery (which was defined in RFC 1256, “ICMP Router Discovery Messages,” September 1991), but in IPv6 it is a part of the base protocol. There is no need for hosts to snoop the routing protocols to discover a router. IPv4 router discovery contains a preference field, which is not needed in IPv6 router discovery because of Neighbor Unreachability Detection. IPv4 Router Advertisements and Solicitations (ICMP type 9) work only with multicast-capable IPv4 routers and are not commonly used. All IPv6 nodes support multicast, and Router Advertisements are a fundamental part of almost every nontrivial network.

Address Resolution (Mapping IPv6 Addresses to MAC Addresses)

Prefix Discovery

Duplicate Address Detection (DAD)

Stateless Address Autoconfiguration (SLAAC)

This is one of the most important new aspects of IPv6. It is specified in RFC 4682,¹² “IPv6 Stateless Address Autoconfiguration ,” September 2007. It is primarily used to allow IPv6-capable hosts (as opposed to routers) to automatically obtain address information (link-local and global unicast node addresses and link-local default gateway). Routers use it to generate and validate their link-local addresses (but not their global addresses, which must be statically configured). The process makes strong use of link-local and multicast addresses, and all network communication is done with ICMPv6 messages that are part of ND. If a source of Router Advertisement messages (e.g., a router or firewall) is available, then at least one global unicast IPv6 address will also be generated. The acronym for Stateless Address Autoconfiguration is “SLAAC.”

A flowchart depicts the stateless address autoconfiguration operation. An I P v 6 host is connected to a I P v 6 router via router solicitation and router advertisement message.

Anytime a link-local or global address lifetime expires (enters the INVALID state), address regeneration is done. If using randomized interface identifiers, a different random interface identifier is created for each address regeneration. If using EUI-64 interface identifiers, the regeneration process basically just confirms that the addresses are still valid – they don’t actually change. If something has changed since the last validation (e.g., gateway down, link broken, etc.), the SLAAC process may fail, and the address is marked INVALID.

Next-Hop Determination

If the address is on-link, then the next-hop address is the same as the destination address. If the address is off-link, then the next-hop address is selected from the default router list.

Neighbor Unreachability Detection (NUD)

Note that there is nothing comparable to Neighbor Unreachability Detection in IPv4. IPv6 NUD improves packet delivery in the presence of failing routers and over partially failing or partitioned links. It improves delivery to nodes that change their link-layer (MAC) addresses. For example, mobile nodes can move off-link without losing any connectivity due to stale ARP caches. NUD detects dead routers and dead switches that block access to working routers.

Redirect

A router can send a Redirect message to a packet sender, if there is a better first-hop router or if the destination is an on-link neighbor. In the first case, the Target Address field contains the link-local address of the better first-hop router. In the second case, the Target Address field contains a copy of the destination address. The Destination Address field contains the address of the ultimate packet destination. The router uses its knowledge of the larger environment to generate this information. You might think of a Redirect message as saying something like “There is a bridge out down that road – try going down this road, instead.”

IPv6 redirects contain the link-layer (MAC) address of the new first hop, which eliminates the need for an additional packet exchange to resolve the IP address. Unlike with IPv4 redirects, the recipient of an IPv6 redirect assumes that the new next hop is on-link. The IPv6 redirect is useful on non-broadcast and shared media links. On such links, nodes should not check for all prefixes for on-link destinations.

Viewing the Neighbor Cache

IPv6 Broadcast

Most things that you would use broadcast for in IPv4, you would use some form of multicast, with a more restricted scope, in IPv6. A multicast transmission to the address ff01::2 would go to the same nodes (all nodes on local link) as an IPv4 broadcast . However, there are other scopes, such as site, organization, and global for multicast, that (unlike IPv4 broadcast) will cross routers, but other than “all nodes in local link,” multicast to the wider scopes requires that all recipients intentionally add the necessary multicast address to their node.

IPv6 Multicast

The basic multicast address type has been covered, but there is a lot more to a full multicast system, as you saw in the section “IPv4 Multicast.” For an in-depth discussion of all aspects of IPv6 multicast, I recommend Chapter 6, “Providing IPv6 Multicast Services,” from the book Deploying IPv6 Networks ,¹⁵ by Ciprian Popoviciu, Eric Levy-Abegnoli, and Patrick Grossetete, Cisco Press, 2006.

Multicast exists in IPv4, but there are some serious problems with it, which are resolved in IPv6.

Not all IPv4 routers support multicast. In general, it is difficult to deploy except in a “walled garden,” such as the customers of a single ISP like Comcast. In IPv6, support for multicast is mandatory – all compliant routers support it, and it works across ISPs, even worldwide.

The Internet Group Management Protocol (IGMP) is not part of IPv4, and not all IPv4 routers include it. In IPv6, the Multicast Listener Discovery (MLD) protocol is standardized and is actually just a subset of the ICMPv6 messages. Because of this, all IPv6-compliant routers include it.

Multicast in IPv4 was an afterthought, grafted on long after the original protocol was designed. In IPv6, multicast was incorporated from the beginning and is present in all address scopes. Multicast link-local addresses are used extensively in SLAAC and other places.

For IPTV applications, IPv6 networks will be the first time that really global Internet TV services can be deployed and work reliably. This is as exciting as when Ted Turner first relayed the signal from his small UHF TV station via a satellite. That breakthrough resulted in WTBS, CNN, CNN Headline News, TNT, Cartoon Network, and, indirectly, the entire multibillion-dollar satellite/cable television network industry.

There are many other areas in which working, scalable multicast can be used to improve applications. You could build chat, VoIP, or even video conferencing clients that could build fully meshed networks, with each new participant subscribing to all existing clients’ multicast “channels” and all existing clients subscribing to the new participant’s multicast “channel.” Even if the initial participant left, all remaining participants would still have a fully functional mesh network. This also eliminates the need for any central exchange point (other than perhaps a search or directory facility to help in setting up the conference and allowing participants to locate each other).

Multicast Listener Discovery (MLD) Protocol

MLD is used by IPv6 routers to discover the presence of multicast listeners (nodes that wish to receive multicast packets) and the specific multicast addresses to which they want to subscribe. MLD (defined in RFC 2710) is commonly referred to as MLDv1. It is the IPv6 equivalent to IPv4’s IGMPv2 (defined in RFC 2236). MLDv1 and IGMPv2 multicast protocols are used to set up any-source multicast (ASM), which allows multiple sources in a group (*,G) or “channel.” This is also known as traditional multicast.

MLDv2 extends the definition of MLDv1 by adding support for “source filtering.” It includes all the functionality of MLDv1, so there is no need to deploy both on a given node. This allows a node to indicate interest only in packets from specific source addresses (INCLUDE mode) or in packets from all multicast addresses except for specific source addresses (EXCLUDE mode). MLDv2 is the IPv6 equivalent of IPv4’s IGMPv3. MLDv2 and IGMPv3 multicast protocols are used to set up source-specific multicast (SSM), which allows a specific source (S) in a group (G) to deliver packets to all members that join (S,G) known as a “channel.” This is described in RFC 4604,¹⁶ “Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast,” and in RFC 4607,¹⁷ “Source-Specific Multicast (SSM) for IP.”

There is another RFC that defines MLD proxying: RFC 4605,¹⁸ “Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD Proxying”).” A proxy would exist on a forwarding gateway that links together multiple subnets and relay messages across that gateway between an MLD Querier on one subnet and MLD listeners on a different subnet.

MLDv1 and MLDv2 are sub-protocols of ICMPv6. All MLDv2 messages are just additional ICMPv6 messages. All IPv6-compliant devices should include support for MLD. MLD messages must be sent with a link-local IPv6 source address, a Hop Limit of 1, and an IPv6 Router Alert Option in the Hop-by-Hop Options extension packet header. When used in Neighbor Discovery protocol’s Stateless Address Autoconfiguration, the source address can be the unspecified address (::). IGMP is not a sub-protocol of ICMPv4. It does not use ICMPv4 messages, but an entirely new protocol. IGMP is not mandatory on all IPv4 routers.

MLD can co-exist with IGMPv3 in a dual-stack network, as MLD (v1 or v2) will only involve IPv6 messages and IGMP (v1, v2, or v3) will only involve IPv4 messages. However, in general, multicast will work far better on IPv6 than on IPv4.

With MLD, there is a “router role” (performed by at most one router in a subnet) and a “listener role” (performed by any number of listener nodes in that subnet) in the protocol.

For the router role, only one router on a subnet can be the Querier at any given time. If there is more than one router on a subnet, there is an election mechanism that selects one of them to be the Querier. Should that router fail at some point, all other routers on that subnet have been listening in and maintaining state, so another election will select one of the surviving routers on that subnet to become the Querier. Only the Querier sends periodic or triggered Query messages on its subnet.

General queries are sent from the Querier to all listeners on the subnet periodically to learn multicast address listener information, to build and refresh state inside all multicast routers on the subnet. Even though only the Querier sends out periodic queries, all routers listen to the responses and update their state.

When a listener node gets a General Query message, it responds by sending a Current State Report, with its per-interface state information. It is also possible for a listener node to immediately report a state change (such as someone “unsubscribing” to a multicast channel) through an unsolicited State Change Report. Current State Reports are sent only once (if one is lost, it will probably be received in response to the next periodic query). State Change Reports are sent multiple times for robustness (to increase the probability of all routers getting the message).

When the Querier gets a State Change Report from a listener, it sends a multicast address–specific query to see if there are still any other listeners to that multicast address. If not, the Querier will delete that multicast address from its multicast address listener state table, which stops relaying the corresponding traffic. If there are source-specific listeners, the Querier will send a multicast address– and source-specific query instead.

There must be a service interface (API routines) available, which allows an application to cause a State Change Report to be sent to the Querier. A sample API is documented in RFC 3678,¹⁹ “Socket Interface Extensions for Multicast Source Filters,” January 2004. The full API includes the ability to JOIN or LEAVE a multicast group (“subscribe to a multicast channel”) and to BLOCK and UNBLOCK specific source addresses, as well as to set and retrieve source filter sets.

For details on the syntax of the various MLDv2 messages, see RFC 3810.²⁰

Protocol Independent Multicast (PIM) for IPv6

PIM for IPv6 does not include routing, but provides multicast forwarding by using static IPv6 routes or routing tables created by IPv6 unicast routing protocols, such as RIPng, OSPFv3, IS-ISv6, or BGP4+.

PIM Dense Mode is defined in RFC 3973,²¹ “Protocol Independent Multicast – Dense Mode (PIM-DM),” January 2005 (for both IPv4 and IPv6). This uses dense multicast routing, which builds shortest-path trees by flooding multicast traffic domain-wide and then pruning branches where no receivers are present. It does not scale well.

PIM Sparse Mode is defined in RFC 4601,²² “Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006 (for both IPv4 and IPv6). As in IPv4, PIM-SM builds unidirectional shared trees routed at a rendezvous point per group and can create shortest-path trees per source. It scales fairly well for wide-area use.

Bidirectional PIM is defined in RFC 5015,²³ “Bidirectional Protocol Independent Multicast (BIDIR-PIM),” October 2007 (for both IPv4 and IPv6). It builds shared bidirectional trees. It never builds a shortest-path tree, so there may be longer end-to-end delays, but it scales very well.

TCP Packet Header

No changes are required to the TCP packet header, as port numbers are still 16 bits in length. The only differences are in how the header checksum is calculated (using the IPv6 pseudo header) and the availability of Jumbograms.

Relevant RFCs for DHCPv6

DHCPv6 has a failover mechanism. Two servers can manage a single pool of addresses for redundancy (in case of failure of one of the servers). This also can be used for load balancing.

All IPv6 hosts have automatically generated link-local addresses that can be used to exchange packets with any other node on the local link. DHCPv4 requires some complex hacks to allow hosts to communicate before they get an address. All IPv6 hosts support link-local multicast. All DHCPv6 servers listen to DHCPv6 multicast groups. With DHCPv4, clients have to do a general broadcast to all nodes on the link, which generates significant broadcast traffic on the link and unnecessary traffic handling on all nodes.

With DHCPv6, a single request can configure all interfaces on a node. The server can offer multiple addresses, one for each interface, and each interface can even have different options. With DHCPv4, each interface would require a separate DHCP operation.

There are several implementations of DHCPv6 already on the market. Windows Server 2008 contains a very complete implementation, in addition to its DHCPv4 server. You can view the IPv6-ready phase 2 products list for other options, including my own company’s Sixscape DNS appliance. Some implementations only support stateless mode, which means they can supply stateless information (like DNS addresses) but not actually allocate addresses. Be sure the DHCPv6 server you select includes full support for stateful mode as well (where it can supply addresses to each node, in addition to stateless information). You should also be sure that the gateway router or firewall you select has the ability to inform nodes that DHCPv6 servers are available on the subnet.

Address Reservations with DHCPv6

In the case of DHCPv4, it is possible to make an address reservation , linked to the MAC address of a node. Anytime the node with a MAC address for which an address reservation has been made asks DHCPv4 for an address, it will get the specific address that was reserved for that MAC address. In the case of DHCPv6, the same concept applies, except that you use two identifiers called the IAID (Interface Association ID) and DUID (DHCP Unique IDentifier ).

Viewing Your Node’s DUID

You can also see a DHCPv6 IAID value (in this case 234887307). This identifies a particular Identity Association, which allows a server and a client to identify, group, and manage a set of related IPv6 addresses. Each IA consists of an IAID, one or more IPv6 addresses, and the time T1 and T2 for that IA. Each IA is associated with exactly one interface. For further details, see RFC 3315, section 11.

DHCPv6 Ports and Messages

Clients and servers exchange DHCPv6 messages using UDP over IPv6. The client uses a link-local address, or addresses obtained via other mechanisms, as the source address for transmitting and receiving DHCPv6 messages. Servers receive messages from clients using a reserved link-scoped multicast address, so that clients don’t need to be configured with the addresses of DHCPv6 servers. To allow hosts to communicate with servers on other links, DHCPv6 relay agents are used. Clients listen for DHCPv6 messages on UDP port 546. Servers and relay agents listen for DHCPv6 messages on UDP port 547.

The link-scoped multicast address used by a client to communicate with an on-link relay agent or server is ff02::1:2. All DHCPv6 servers and relay agents are members of this multicast group.

The site-scoped multicast address used by a relay agent to communicate with servers is ff05::1:3, if it wants to send a message to all DHCPv6 servers or does not know the unicast address of the servers. All DHCPv6 servers in a given site are members of this multicast group.

DHCPv6 Status Codes

DHCPv6 Message Syntax

The DHCPv6

DHCPv6 works in somewhat the same way as DHCPv4, except that different messages are used and communication between client and server takes place using link-local scoped multicast and unicast addresses.

When it first comes up, before any DHCPv6 operation, an IPv6-capable client node obtains a link-local unicast address through ND (and possibly a global unicast address as well, using information from a Router Advertisement message). If a Router Advertisement message is seen, then the client can check the M and O bits in it to determine if there is stateful DHCPv6, stateless DHCPv6, or no DHCPv6 available. If no Router Advertisement is available, a client can still attempt DHCPv6 server discovery, as follows.

For Further Information on DHCPv6

For details on how clients send and respond to DHCPv6 messages, see RFC 3315, section 17.

For details on DHCP Client-initiated Configuration Exchanges, see RFC 3315, section 18.

For details on DHCP Server-initiated Configuration Exchanges, see RFC 3315, section 19.

For details on relay agent behavior, see RFC 3315, section 20.

For details on the optional authentication mechanism, for use of DHCPv6 in unsecured environments, such as wireless networks, see RFC 3315, section 21.

For available DHCPv6 message options and their syntax, see RFC 3315, section 22.

Stateless DHCPv6 assumes that assigned IPv6 addresses are obtained some other way, such as Stateless Address Autoconfiguration, and that only stateless information (IPv6 addresses of DNS servers, SIP servers, etc.) will be obtained from DHCPv6. RFC 3736, “Stateless Dynamic Host Configuration Protocol (DHCP) Server for IPv6,” April 2004, defines the subset of messages and options from the full (stateful) DHCPv6 functionality that are required to provide stateless DHCPv6 service.

For details on publishing the address of SIP servers with DHCPv6, see RFC 3633, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.

For details on publishing the address of DNS servers with DHCPv6, see RFC 3646, “DNS Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” December 2003.

For details on publishing the address of NIS (Network Information Service) servers with DHCPv6, see RFC 3898, “Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” October 2004.

For details on publishing the address of SNTP (Simple Network Time Protocol) servers with DHCPv6, see RFC 4075, “Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6,” May 2005.

Useful Commands Related to DHCPv6

Manual Network Configuration for IPv6-Only

It is possible to perform IPv6 configuration manually , either by editing ASCII configuration files, as in FreeBSD or Linux, or via GUI configuration tools, as in Windows. If you have understood the material in this chapter, it should be fairly easy to configure your node(s). In most cases, if you have ISP service, the ISP will give you all the information necessary to configure your node(s). In the coverage of dual-stack networks, we will show configuration of both IPv4 and IPv6 on a single node.

Auto Network Configuration Using Stateless Address Autoconfiguration

It is easy for a FreeBSD node to be automatically configured using Stateless Address Autoconfiguration . Note that the global unicast address will be created with the EUI-64 algorithm from your MAC address.

You need to edit the following files (you will need root privilege to do this):

Auto Network Configuration Using Manually Specified (Static) IPv6 Address

You need to edit the following files (you will need root privilege to do this):

This is different from the behavior of Windows 7 and Linux, where the addition of a manually configured global unicast address does not stop the node from obtaining the link-local default gateway automatically.