Navigation

Table Of Contents

Previous topic

7   IP version 4

Next topic

9   Routing-Update Algorithms

8   IP version 6

What has been learned from experience with IPv4? First and foremost, more than 32 bits are needed for addresses; the primary motive in developing IPv6 was the specter of running out of IPv4 addresses (something which, at the highest level, has already happened; see the discussion at the end of 1.10   IP - Internet Protocol). Another important issue is that IPv4 requires a modest amount of effort at configuration; IPv6 was supposed to improve this.

By 1990 the IETF was actively interested in proposals to replace IPv4. A working group for the so-called “IP next generation”, or IPng, was created in 1993 to select the new version; RFC 1550 was this group’s formal solicitation of proposals. In July 1994 the IPng directors voted to accept a modified version of the “Simple Internet Protocol”, or SIP (unrelated to the “Session Initiation Protocol”), as the basis for IPv6.

SIP addresses were originally to be 64 bits in length, but in the month leading up to adoption this was increased to 128. 64 bits would probably have been enough, but the problem is less the actual number than the simplicity with which addresses can be allocated; the more bits, the easier this becomes, as sites can be given relatively large address blocks without fear of waste. A secondary consideration in the 64-to-128 leap was the potential to accommodate now-obsolete CLNP addresses, which were up to 160 bits in length (but compressible).

IPv6 has to some extent returned to the idea of a fixed division between network and host portions: in most ordinary-host cases, the first 64 bits of the address is the network portion (including any subnet portion) and the remaining 64 bits represent the host portion. While there are some configuration alternatives here, and while the IETF occasionally revisits the issue, at the present time the 64/64 split seems here to stay. Routing, however, can, as in IPv4, be done on different prefixes of the address at different points of the network. Thus, it is misleading to think of IPv6 as a return to Class A/B/C address allocation.

IPv6 is now twenty years old, and yet usage remains quite modest. However, the shortage in IPv4 addresses has begun to loom ominously; IPv6 adoption rates may rise quickly if IPv4 addresses begin to climb in price.

8.1   The IPv6 Header

The IPv6 fixed header looks like the following; at 40 bytes, it is twice the size of the IPv4 header. The fixed header is intended to support only what every packet needs: there is no support for fragmentation, no header checksum, and no option fields. However, the concept of extension headers has been introduced to support some of these as options; some IPv6 extension headers are described below. Some fixed-header header fields have been renamed from their IPv4 analogues: the IPv4 TTL is now the IPv6 Hop_Limit (still decremented by each router with the packet discarded when it reaches 0), and the IPv4 DS field has become the IPv6 Traffic Class.

_images/ip6header.png

The Flow Label is new. RFC 2460 states that it

may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or “real-time” service.

Senders not actually taking advantage of any quality-of-service options are supposed to set the Flow Label to zero.

When used, the Flow Label represents a sender-computed hash of the source and destination addresses, and perhaps the traffic class. Routers can use this field as a way to look up quickly any priority or reservation state for the packet. All packets belonging to the same flow should have the same Routing Extension header, below. Note that the Flow Label will in general not include any information about the source and destination port numbers, except that only some of the connections between a pair of hosts may make use of this field.

A flow, as the term is used here, is one-way; the return traffic belongs to a different flow. Historically, the term “flow” has been used at various other scales: a single TCP connection, multiple related TCP connections, or even all traffic from a particular subnet (eg the “computer-lab flow”).

8.1.1   IPv6 addresses

IPv6 addresses are written in eight groups of four hex digits, separated by colons, and with leading 0’s optionally removed, eg

FEDC:BA98:1654:310:FEDC:BA98:7654:3210

If an address contains a long run of 0’s, as would be the case if the IPv6 address had an embedded IPv4 address, then when writing the address the string ”::” may be used to represent however many blocks of 0000 as are needed to create an address of the correct length; to avoid ambiguity this can be used only once. Also, embedded IPv4 addresses may continue to use the ”.” separator:

::FFFF:147.126.65.141

The above is an example of the standard IPv6 format for representing IPv4 addresses. A separate representation of IPv4 addresses, with the “FFFF” block replaced by 0-bits, is used for tunneling IPv6 traffic over IPv4. The IPv6 loopback address is ::1 (that is, 127 0-bits followed by a 1-bit).

Network address prefixes may be written with the “/” notation, as in IPv4:

12AB:0:0:CD30::/60

RFC 3513 suggested that initial IPv6 unicast-address allocation be initially limited to addresses beginning with the bits 001, that is, the 2000::/3 block (20 in binary is 0010 0000).

Generally speaking, IPv6 addresses consist of a 64-bit network prefix (perhaps including subnet bits) and a 64-bit host identifier. See 8.8.1   Network Prefixes.

8.2   Host identifier

If desired, the second 64 bits of an IPv6 address can be a host identifier derived from the LAN address. To create the host identifier from a 48-bit Ethernet address, for example, 0xFFFE is inserted between the first three bytes and the last three bytes, to get 64 bits in all. The seventh bit of the first byte (the Ethernet “universal/local” flag) is then set to 1. The result is officially known as the Modified EUI-64 Identifier, where EUI stands for Extended Unique Identifier; details can be found in RFC 4291. For example, for a host with Ethernet address 00:a0:cc:24:b0:e4, the EUI-64 address would be 02a0:ccff:fe24:b0e4 (note the leading 00 becomes 02 when the seventh bit is turned on).

8.4   Anycast addresses

IPv6 also introduces anycast addresses. An anycast address might be assigned to each of a set of routers (in addition to each router’s own unicast address); a packet addressed to this anycast address would be delivered to only one member of this set. Note that this is quite different from multicast addresses; a packet addressed to the latter is delivered to every member of the set.

It is up to the local routing infrastructure to decide which member of the anycast group would receive the packet; normally it would be sent to the “closest” member. This allows hosts to send to any of a set of routers, rather than to their designated individual default router.

8.4.1   IPv6 Multicast

IPv6 has moved away from LAN-layer broadcast, instead providing a wide range of LAN-layer multicast groups. (Note that LAN-layer multicast is straightforward; it is general IP-layer multicast (18.5   Global IP Multicast) that is problematic. See 2.1.1   Ethernet Multicast for the Ethernet implementation.) This switch to multicast is intended to limit broadcast traffic in general, though many switches still propagate LAN multicast traffic everywhere, like broadcast.

An IPv6 multicast address is one beginning with the eight bits 1111 1111; numerous specific such addresses, and even classes of addresses, have been defined. For actual delivery, IPv6 multicast addresses correspond to LAN-layer (eg Ethernet) multicast addresses through a well-defined static correspondence; specifically, if x, y, z and w are the last four bytes of the IPv6 multicast address, in hex, then the corresponding Ethernet multicast address is 33:33:x:y:z:w (RFC 2464). A typical IPv6 host will need to join (that is, subscribe to) several Ethernet multicast groups.

The IPv6 multicast address with the broadest scope is all-nodes, with address FF02::1; the corresponding Ethernet multicast address is 33:33:00:00:00:01. This essentially corresponds to IPv4’s LAN broadcast, though the use of LAN multicast here means that non-IPv6 hosts should not see packets sent to this address. Another important IPv6 multicast address is FF02::2, the all-routers address. This is meant to be used to reach all routers, and routers only; ordinary hosts do not subscribe.

Generally speaking, IPv6 nodes on Ethernets send LAN-layer Multicast Listener Discovery (MLD) messages to multicast groups they wish to start using; these messages allow multicast-aware Ethernet switches to optimize forwarding so that only those hosts that have subscribed to the multicast group in question will receive the messages. Otherwise switches are supposed to treat multicast like broadcast; worse, some switches may simply fail to forward multicast packets to destinations that have not explicitly opted to join the group.

8.4.2   IPv6 Extension Headers

In IPv4, the IP header contained a Protocol field to identify the next header; usually UDP or TCP. All IPv4 options were contained in the IP header itself. IPv6 has replaced this with a scheme for allowing an arbitrary chain of IPv6 headers. The IPv6 Next Header field can indicate that the following header is UDP or TCP, but can also indicate one of several IPv6 options. These optional, or extension, headers include:

  • Hop-by-Hop options header
  • Destination options header
  • Routing header
  • Fragment header
  • Authentication header
  • Mobility header
  • Encapsulated Security Payload header

These extension headers must be processed in order; the recommended order for inclusion is as above. Most of them are intended for processing only at the destination host; the routing header is an exception.

8.5   Hop-by-Hop Options Header

This consists of a set of ⟨type,value⟩ pairs which are intended to be processed by each router on the path. A tag in the type field indicates what a router should do if it does not understand the option: drop the packet, or continue processing the rest of the options. The only Hop-by-Hop options provided by RFC 2460 were for padding, so as to set the alignment of later headers.

RFC 2675 later defined a Hop-by-Hop option to support IPv6 jumbograms: datagrams larger than 65,535 bytes. The need for such large packets remains unclear, in light of 5.3   Packet Size. IPv6 jumbograms are not meant to be used if the underlying LAN does not have an MTU larger than 65,535 bytes; the LAN world is not currently moving in this direction.

8.6   Destination Options Header

This is very similar to the Hop-by-Hop Options header. It again consists of a set of ⟨type,value⟩ pairs, and the original specification only defined options for padding. The Destination header is intended to be processed at the destination, before turning over the packet to the transport layer.

8.7   Routing Header

The routing header contains a list of IPv6 addresses through which the packet should be routed. These do not have to be contiguous: if the list to be visited en route to destination D is ⟨R1,R2,...,Rn⟩, then the IPv6 option header contains ⟨R2,R3,...,Rn,D⟩ and the initial destination address is R1; R1 then updates this header to ⟨R1,R3,...,Rn,D⟩ (that is, the old destination R1 and the current next-router R2 are swapped), and sends the packet on to R2. This continues on until Rn addresses the packet to the final destination D. The header contains a Segments Left pointer indicating the next address to be processed, so that when the packet arrives at D the Routing Header contains the routing list ⟨R1,R3,...,Rn⟩ This is, in general principle, very much like IPv4 Loose Source routing. Note, however, that routers between the listed routers R1...Rn do not need to examine this header; they process the packet based only on its current destination address.

8.8   Fragment Header

IPv6 supports limited IPv4-style fragmentation via the Fragment Header. This header contains a 13-bit Fragment Offset field, which contains – as in IPv4 – the 13 high-order bits of the actual 16-bit offset of the fragment. This header also contains a 32-bit Identification field; all fragments of the same packet must carry the same value in this field.

IPv6 fragmentation is done only by the original sender; routers along the way are not allowed to fragment or re-fragment a packet. Sender fragmentation would occur if, for example, the sender had an 8KB IPv6 packet to send via UDP, and needed to fragment it to accommodate the 1500-byte Ethernet MTU.

If a packet needs to be fragmented, the sender first identifies the unfragmentable part, consisting of the IPv6 fixed header and any extension headers that must accompany each fragment (these would include Hop-by-Hop and Routing headers). These unfragmentable headers are then attached to each fragment.

IPv6 also requires that every link on the Internet have an MTU of at least 1280 bytes beyond the LAN header; link-layer fragmentation and reassembly can be used to meet this MTU requirement (which is what ATM links do).

Generally speaking, fragmentation should be avoided at the application layer when possible. UDP-based applications that attempt to transmit filesystem-sized (usually 8 KB) blocks of data remain persistent users of fragmentation.

8.8.1   Network Prefixes

We have been assuming that an IPv6 address, at least as seen by a host, is composed of a 64-bit network prefix and a 64-bit host portion. As of this writing this is a requirement; RFC 4291 (IPv6 Addressing Architecture) states:

For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long....

This /64 requirement is occasionally revisited by the IETF, but we will assume here that it remains in force. This is a departure from IPv4, where the host/subnet division point has depended, since the development of subnets, on local configuration.

Note that while the net/host division point is fixed, routers may still use CIDR and may still route on any shorter prefix than /64.

A typical IPv6 site may involve a variety of specialized network prefixes, including the link-local prefix and prefixes for anycast and multicast addresses. Private IPv6 address prefixes, corresponding to IPv4’s 10.0.0.0/8, may also be in use.

The most important class of 64-bit network prefixes, however, are those supplied by a provider or other address-numbering entity, and which represent the first half of globally routable IPv6 addresses. These are the prefixes that will be visible to the outside world.

IPv6 customers will typically be assigned a relatively large block of addresses, eg /48 or /56. The former allows 64−48 = 16 bits for local “subnet” specification within a 64-bit network prefix; the latter allows 8 subnet bits. These subnet bits are – as in IPv4 – supplied through router configuration. The closest IPv6 analogue to the IPv4 subnet mask is that all network prefixes are supplied to hosts with an associated length, although that length will often always be 64 bits.

Many sites will have only a single externally visible address block. However, some sites may be multihomed and thus have multiple independent address blocks.

Sites may also have private unique local address prefixes, corresponding to IPv4 private address blocks like 192.168.0.0/16 and 10.0.0.0/8. They are officially called Unique Local Unicast Addresses and are defined in RFC 4193; these replace an earlier site-local address plan formally deprecated in RFC 3879. The first 8 bits of such a prefix are 1111 1101 (FD00::/8); the related prefix 1111 1100 (FC00::/8) is reserved for future use. The last 16 bits of the 64-bit prefix represent the subnet ID, and are assigned either administratively or via autoconfiguration. The 40 bits in between, from bit 8 up to bit 48, represent the Global ID. A site is to set the Global ID to a pseudorandom value.

The resultant prefix is “almost certainly” globally unique, although it is not supposed to be routed and a site would generally not admit any packets from the outside world addressed to a destination with the Global ID as prefix. One rationale for choosing unique Global IDs for each site is to accommodate potential later mergers of organizations without the need for renumbering; this has been a chronic problem for sites using private IPv4 address blocks. Another justification is to accommodate VPN connections from other sites. For example, if I use IPv4 block 10.0.0.0/8 at home, and connect using VPN to a site also using 10.0.0.0/8, it is possible that my printer will have the same IPv4 address as their application server.

8.8.2   Neighbor Discovery

IPv6 Neighbor Discovery, or ND, is a protocol that replaces (and combines) several IPv4 tools, most notably ARP, ICMP redirects and most non-address-assignment parts of DHCP. The original specification for ND is in RFC 2461, later updated by RFC 4861. ND provides the following services:

  • Finding a local host’s LAN address, given its IPv6 address
  • Finding the local router(s)
  • Finding the set of network address prefixes that can be reached via local delivery (IPv6 allows there to be more than one)
  • Determining that some neighbors are now unreachable
  • Detecting duplicate IPv6 addresses

8.9   Router Advertisement

IPv6 routers periodically send Router Advertisement packets; these are also sent in response to Router Solicitation requests sent by hosts to the all-routers multicast group. Router Advertisement packets serve to identify the routers; this process is sometimes called Router Discovery. These RA packets also contain a list of all network address prefixes in use on the LAN. These packets may contain other important information about the LAN as well, such as an agreed-on MTU; much of the information included in RA packets is, in IPv4, sent via DHCP.

These IPv6 router messages represent a marked change from IPv4, in which routers need not send anything besides forwarded packets, and in which hosts typically discover their default routers via DHCP. IPv6 routers may even interact directly with ordinary hosts, if the SLAAC configuration mechanism (below) is used. To become an IPv4 router, a node need only enable IPv4 forwarding in the kernel. To become an IPv6 router, by comparison, in addition to forwarding a node “MUST” (RFC 4294) also run software to support Router Advertisement; the linux radvd package is one option here.

8.10   Prefix Discovery

Closely related to Router Discovery is the Prefix Discovery process by which hosts learn what IPv6 network-address prefixes, above, are valid on the network. It is also where hosts learn which prefixes are considered to be local to the host’s LAN, and thus reachable at the LAN layer instead of requiring router assistance for delivery. IPv6, in other words, does not limit determination of whether delivery is local to the IPv4 mechanism of having a node check a destination address against each of the network-address prefixes assigned to the node’s interfaces.

Even IPv4 allows two IPv4 network prefixes to share the same LAN (eg a private one 10.1.2.0/24 and a public one 147.126.65.0/24), but a consequence of IPv4 routing is that two such subnets can only reach one another via a router on the LAN, even though they should in principle be able to communicate directly. IPv6 drops this restriction.

The Router Advertisement packets sent by the router should contain a complete list of valid network-address prefixes, as the Prefix Information option. In simple cases this list may contain a single externally routable 64-bit prefix. If a particular LAN is part of multiple (overlapping) physical subnets, the prefix list will contain an entry for each subnet; these 64-bit prefixes will themselves likely have a common prefix of length N<64. For multihomed sites the prefix list may contain multiple unrelated prefixes corresponding to the different address blocks. Finally, private and local IPv6 address prefixes may also be included.

Each prefix will have an associated lifetime; nodes receiving a prefix from an RA packet are to use it only for the duration of this lifetime. On expiration (and likely much sooner) a node must obtain a newer RA packet with a newer prefix list. The rationale for inclusion of the prefix lifetime is ultimately to allow sites to easily renumber; that is, to change providers and switch to a new network-address prefix provided by a new router. Each prefix is also tagged with a bit indicating whether it can be used for autoconfiguration, as in 8.13   Stateless Autoconfiguration (SLAAC) below.

8.11   Neighbor Solicitation

Neighbor Solicitation messages are the IPv6 analogues of IPv4 ARP requests. These are essentially queries of the form “who has IPv6 address X?” While ARP requests were broadcast, IPv6 Neighbor Solicitation messages are sent to the solicited-node multicast address, which at the LAN layer usually represents a rather small multicast group. This address is FF02::0001:x.y.z.w, where x, y, z and w are the low-order 32 bits of the IPv6 address the sender is trying to look up. Each IPv6 host on the LAN will need to subscribe to all the solicited-node multicast addresses corresponding to its own IPv6 addresses (normally this is not too many).

Neighbor Solicitation messages are repeated regularly, but followup verifications are initially sent to the unicast LAN address on file (this is common practice with ARP implementations, but is optional). Unlike with ARP, other hosts on the LAN are not expected to eavesdrop on the initial Neighbor Solicitation message. The target host’s response to a Neighbor Solicitation message is called Neighbor Advertisement; a host may also send these unsolicited if it believes its LAN address may have changed.

The analogue of Proxy ARP is still permitted, in that a node may send Neighbor Advertisements on behalf of another. The most likely reason for this is that the node receiving proxy services is a “mobile” host temporarily remote from the home LAN. Neighbor Advertisements sent as proxies have a flag to indicate that, if the real target does speak up, the proxy advertisement should be ignored.

Hosts may also use the Authentication Header or the Encapsulated Security Payload Header to supply digital signatures for ND packets. If a node is statically configured to require such checks, then the IPv6 analogue of ARP spoofing (7.7.2   ARP security) can be prevented.

Finally, IPv4 ICMP Redirect messages have also been moved in IPv6 to the Neighbor Discovery protocol.

8.11.1   IPv6 Host Address Assignment

IPv6 provides two competing ways for hosts to obtain their full IP addresses. One is DHCPv6, based on IPv4’s DHCP (7.8   Dynamic Host Configuration Protocol (DHCP)). In addition to DHCPv6, IPv6 also supports StateLess Address AutoConfiguration, or SLAAC. The original idea behind SLAAC was to support complete plug-and-play network setup: hosts on a completely isolated LAN could talk to one another out of the box, and if a router was introduced connecting the LAN to the Internet, then hosts would be able to determine unique, routable addresses from information available from the router.

In the early days of IPv6 development, in fact, DHCPv6 may have been intended only for address assignments to routers and servers, with SLAAC meant for “ordinary” hosts. In that era, it was still common for IPv4 addresses to be assigned “statically”, via per-host configuration files. RFC 4862 states that SLAAC is to be used when “a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable.”

SLAAC and DHCPv6 evolved to some degree in parallel. While SLAAC solves the autoconfiguration problem quite neatly, at this point DHCPv6 solves it just as effectively, and provides for greater administrative control. For this reason, SLAAC may end up less widely deployed. On the other hand, SLAAC gives hosts greater control over their IPv6 addresses, and so may end up offering hosts a greater degree of privacy by allowing endpoint management of the use of private and temporary addresses (below).

When a host first begins the Neighbor Discovery process, it receives a Router Advertisement packet. In this packet are two special bits: the M (managed) bit and the O (other configuration) bit. The M bit is set to indicate that DHCPv6 is available on the network for address assignment. The O bit is set to indicate that DHCPv6 is able to provide additional configuration information (eg the name of the DNS server) to hosts that are using SLAAC to obtain their addresses.

8.12   Duplicate Address Detection

Whenever an IPv6 host obtains a unicast address – a link-local address, an address created via SLAAC, an address received via DHCPv6 or a manually configured address – it goes through a duplicate-address detection (DAD) process. The host sends one or more Neighbor Solicitation messages (that is, like an ARP query), as in 8.8.2   Neighbor Discovery, asking if any other host has this address; if anyone answers, then the address is a duplicate. As with IPv4 ACD (7.7.1   ARP Finer Points), but not as with the original IPv4 self-ARP, the source-IP-address field of this NS message is set to a special “unspecified” value; this allows other hosts to recognize it as a DAD query.

Because this NS process may take some time, and because addresses are in fact almost always unique, RFC 4429 defines an optimistic DAD mechanism. This allows limited use of an address before the DAD process completes; in the meantime, the address is marked as “optimistic”.

Outside the optimistic-DAD interval, a host is not allowed to use an IPv6 address if the DAD process has failed. RFC 4862 in fact goes further: if a host with an established address receives a DAD query for that address, indicating that some other host wants to use that address, then the original host should discontinue use of the address.

8.13   Stateless Autoconfiguration (SLAAC)

To obtain an address via SLAAC, defined in RFC 4862, a host first generates its link-local address, as above in 8.3   Link-local addresses, appending the standard 64-bit link-local prefix to its 64-bit host identifier (8.2   Host identifier) derived from the LAN address. The host must then ensure that its newly configured link-local address is in fact unique; it uses DAD (above) to verify this. Assuming no duplicate is found, then at this point the host can talk to any other hosts on the same LAN, eg to figure out where the printers are.

The next step is to see if there is a router available. The host sends a Router Solicitation (RS) message to the all-routers multicast address. A router – if present – should answer with a Router Advertisement (RA) message that also contains a Prefix Information option; that is, a list of IPv6 network-address prefixes (8.10   Prefix Discovery). The RA message will mark with a flag those prefixes eligible for use with SLAAC; if no prefixes are so marked, then SLAAC should not be used. All prefixes will also be marked with a lifetime, indicating how long the host may continue to use the prefix; once the prefix expires, the host must obtain a new one via a new RA message.

The host chooses an appropriate prefix, stores the prefix-lifetime information, and, in the original version of SLAAC, appends the prefix to the front of its host identifier to create what should now be a routable address. The prefix length plus the host-identifier length must equal 128 bits; in the most common case each is 64 bits. The address so formed must now be verified through the duplicate-address-detection mechanism above.

An address generated in this way will, because of the embedded host identifier, uniquely identify the host for all time. This includes identifying the host even when it is connected to a new network and is given a different network prefix. Therefore, RFC 4941 defines a set of privacy extensions to SLAAC: optional mechanisms for the generation of alternative host identifiers, based on pseudorandom generation using the original LAN-address-based host identifier as a “seed” value. The probability of two hosts accidentally choosing the same host identifier in this manner is very small; the Neighbor Solicitation mechanism with DAD must, however, still be used to verify that the address is in fact unique. DHCPv6 also provides an option for temporary address assignments, also to improve privacy, but one of the potential advantages of SLAAC is that this process is entirely under the control of the end system.

Regularly (eg every few hours, or less) changing the host portion of an IPv6 address will make external tracking of a host slightly more difficult. However, for a residential “site” with only a handful of hosts, a considerable degree of tracking may be obtained simply by using the common 64-bit prefix.

In theory, if another host B on the LAN wishes to contact host A with a SLAAC-configured address containing the original host identifier, and B knows A’s IPv6 address AIPv6, then B might extract A’s LAN address from the low-order bits of AIPv6. This was never actually allowed, however, even before the RFC 4941 privacy options, as there is no way for B to know that A’s address was generated via SLAAC at all. B would always find A’s LAN address through the usual process of IPv6 Neighbor Solicitation.

A host using SLAAC may receive multiple network prefixes, and thus generate for itself multiple addresses. RFC 6724 defines a process for a host to determine, when it wishes to connect to destination address D, which of its own multiple addresses to use. For example, if D is a site-local address, not globally visible, then the host will likely want to use an address that is also site-local. RFC 6724 also includes mechanisms to allow a host with a permanent public address (eg corresponding to a DNS entry) to prefer alternative “temporary” or “privacy” addresses for outbound connections.

At the end of the SLAAC process, the host knows its IPv6 address (or set of addresses) and its default router. In IPv4, these would have been learned through DHCP along with the identity of the host’s DNS server; one concern with SLAAC is that there is no obvious way for a host to find its DNS server. One strategy is to fall back on DHCPv6 for this. However, RFC 6106 now defines a process by which IPv6 routers can include DNS-server information in the RA packets they send to hosts as part of the SLAAC process; this completes the final step of the autoconfiguration process.

How to get DNS names for SLAAC-configured IPv6 hosts into the DNS servers is an entirely separate issue. One approach is simply not to give DNS names to such hosts. In the NAT-router model for IPv4 autoconfiguration, hosts on the inward side of the NAT router similarly do not have DNS names (although they are also not reachable directly, while SLAAC IPv6 hosts would be reachable). If DNS names are needed for hosts, then a site might choose DHCPv6 for address assignment instead of SLAAC. It is also possible to figure out the addresses SLAAC would use (by identifying the host-identifier bits) and then creating DNS entries for these hosts. Hosts can also use Dynamic DNS (RFC 2136) to update their own DNS records.

8.14   DHCPv6

The job of the DHCPv6 server is to tell an inquiring host its network prefix(es) and also supply a 64-bit host-identifier. Hosts begin the process by sending a DHCPv6 request to the All_DHCP_Relay_Agents_and_Servers multicast IPv6 address FF02::1:2 (versus the broadcast address for IPv4). As with DHCPv4, the job of a relay agent is to tag a DHCP request with the correct current subnet, and then to forward it to the actual DCHPv6 server. This allows the DHCP server to be on a different subnet from the requester. Note that the use of multicast does nothing to diminish the need for relay agents; use of the multicast group does not necessarily identify a requester’s subnet. In fact, the All_DHCP_Relay_Agents_and_Servers multicast address scope is limited to the current link; relay agents then forward to the actual DHCP server using the site-scoped address All_DHCP_Servers.

Hosts using SLAAC to obtain their address can still use a special Information-Request form of DHCPv6 to obtain their DNS server and any other “static” DHCPv6 information.

Clients may ask for temporary addresses. These are identified as such in the DHCPv6 request, and are handled much like “permanent” address requests, except that the client may ask for a new temporary address only a short time later. When the client does so, a different temporary address will be returned; a repeated request for a permanent address, on the other hand, would usually return the same address as before.

When the DHCPv6 server returns a temporary address, it may of course keep a log of this address. The absence of such a log is one reason SLAAC may provide a greater degree of privacy. Another concern is that the DHCPv6 temporary-address sequence might have a flaw that would allow a remote observer to infer a relationship between different temporary addresses; with SLAAC, a host is responsible itself for the security of its temporary-address sequence and is not called upon to trust an external entity.

A DHCPv6 response contains a list (perhaps of length 1) of IPv6 addresses. Each separate address has an expiration date. The client must send a new request before the expiration of any address it is actually using; unlike for DHCPv4, there is no separate “address lease lifetime”.

In DHCPv4, the host portion of addresses typically comes from “address pools” representing small ranges of integers such as 64-254; these values are generally allocated consecutively. A DHCPv6 server, on the other hand, should take advantage of the enormous range (264) of possible host portions by allocating values more sparsely, through the use of pseudorandomness. This makes it very difficult for an outsider who knows one of a site’s host addresses to guess the addresses of other hosts. Some DHCPv6 servers, however, do not yet support this; such servers make the SLAAC approach more attractive.

8.15   Manual Configuration

Like IPv4 addresses, IPv6 addresses can also be set up purely by manual configuration. In theory, this would be done only in the absence of an IPv6 router, in which case a unique-local prefix (8.8.1   Network Prefixes) would likely be appropriate. See 8.18   Manual address configuration for one example. While it might be convenient to distribute only the /64 prefix via manual configuration, and have SLAAC supply the low-order 64 bits, this option is not described in the SLAAC RFCs and seems not to be available in common implementations.

8.15.1   Globally Exposed Addresses

Perhaps the most striking difference between a contemporary IPv4 network and an IPv6 network is that on the former, many hosts are likely to be “hidden” behind a NAT router (1.14   Network Address Translation). On an IPv6 network, on the other hand, every host is likely to be globally visible to the IPv6 world (though NAT may still be used to allow connectivity to legacy IPv4 servers).

Legacy IPv4 NAT routers provide a measure of each of privacy, security and nuisance. Privacy in IPv6 can be handled, as above, through private or temporary addresses.

The degree of security provided via NAT is largely if not entirely due to the fact that all connections must be initiated from the inside; no packet from the outside is allowed through the NAT firewall unless it is a response to a packet sent from the inside. This feature, however, can also be implemented via a conventional firewall (IPv4 or IPv6); one might need to configure the firewall with a list of inside addresses (or subnets) meant to be globally visible. Furthermore, given such a conventional firewall, it would then be straightforward to modify it so as to support limited and regulated connections from the outside world as desired; an analogous modification of a NAT router is quite difficult. (It remains true, however, that as of this writing consumer-grade IPv6 firewalls of the type described here do not really exist.) Finally, one of the major reasons for hiding IPv4 addresses is that with IPv4 it is easy to map a /24 subnet by pinging or otherwise probing each of the 254 possible hosts; such mapping may reveal internal structure. In IPv6 such mapping is impractical as a /64 subnet has 264 ≃ 18 quintillion hosts.

As for nuisance, NAT has always broken protocols that involve negotiation of new connections (eg TFTP, or SIP, used by VoIP); IPv6 should make these much easier to manage.

8.15.2   ICMPv6

RFC 4443 defines an updated version of the ICMP protocol. It includes an IPv6 version of ICMP Echo Request / Echo Reply, upon which the “ping” command is based. It also handles the error conditions below; this list is somewhat cleaner than the corresponding ICMPv4 list:

Destination Unreachable

In this case, one of the following numeric codes is returned:

  1. No route to destination, returned when a router has no next_hop entry.
  2. Communication with destination administratively prohibited, returned when a router has a next_hop entry, but declines to use it for policy reasons. Codes 5 and 6 are special cases; these more-specific codes are returned when appropriate.
  3. Beyond scope of source address, returned when a router is, for example, asked to route a packet to a global address, but the return address is site-local. In IPv4, when a host with a private address attempts to connect to a global address, NAT is almost always involved.
  4. Address unreachable, a catchall category for routing failure not covered by any other message. An example is if the packet was successfully routed to the last_hop router, but Neighbor Discovery failed to find a LAN address corresponding to the IPv6 address.
  5. Port unreachable, returned when, as in ICMPv4, the destination host does not have the requested UDP port open.
  6. Source address failed ingress/egress policy, see code 1.
  7. Reject route to destination, see code 1.

Packet Too Big

This is like ICMPv4’s “Fragmentation Required but DontFragment flag sent”; IPv6 however has no router-based fragmentation.

Time Exceeded

This is used for cases where the Hop Limit was exceeded, and also where source-based fragmentation was used and the fragment-reassembly timer expired.

Parameter Problem

This is used when there is a malformed entry in the IPv6 header, eg an unrecognized Next Header value.

8.15.3   Routerless Connection Examples

Most IPv6 networks require at least one IPv6 router; both SLAAC and DHCPv6 configuration requires this. However, link-local addresses are quite serviceable, as long as one remembers that the interface must be specified; manually configured addresses are another option. Here are some examples. One practical problem with link-local addresses is that application documentation describing how to include a specification of the interface is sometimes sparse.

8.16   ping6

We will start with the linux version of ping6, the IPv6 analogue of the familiar ping command. It is used to send ICMPv6 Echo Requests. The ping6 command supports an option to specify the interface (-I eth0); as noted above, this is mandatory when sending to link-local addresses.

ping6 ::1: This allows me to ping my own loopback address.

ping6 -I eth0 ff02::1: This pings the all-nodes multicast group on interface eth0. I get these answers:

  • 64 bytes from fe80::3e97:eff:fe2c:2beb (this is the host I am pinging from)
  • 64 bytes from fe80::2a0:ccff:fe24:b0e4 (another linux host)

My VoIP phone – on the same subnet but apparently supporting IPv4 only – remains mute.

ping6 -I eth0 fe80::6267:20ff:fe72:8960: This pings the link-local address of the other linux host answering the previous query. Note the “ff:fe” in the host identifier. Also note the flipped seventh bit of the two bytes 02a0; the other linux host has Ethernet address 00:a0:cc:24:b0:e4.

8.18   Manual address configuration

The use of manually configured addresses, 8.15   Manual Configuration, is also possible; this avoids the need to specify an interface. The first step is to pick a unique-local prefix, eg fd37:dead:beef:cafe::0/64 (note that this particular prefix does not meet the randomness rules for unique-local address prefixes). Low-order bits can then be added and addresses assigned manually; on linux this is done with:

  • host1: ip -6 address add fd37:dead:beef:cafe::1 dev eth0
  • host2: ip -6 address add fd37:dead:beef:cafe::2 dev eth0

Now on host1 the command

ssh fd37:dead:beef:cafe::2

should work, again assuming ssh is listening for IPv6 connections. Because the address here is not link-local, /etc/host entries may also be created, eg the following on host1:

fd37:dead:beef:cafe::2  host2-6

Now to connect all that should be needed is

ssh host2-6

8.19   Node Information Messages

In addition to ICMPv6, IPv6 also has Node Information (NI) Messages, defined in RFC 4620. One form of NI query allows a host to be asked directly for its name; this is accomplished in IPv4 via DNS reverse-name lookups. Other NI queries allow a host to be asked for its other IPv6 addresses, or for its IPv4 addresses.

8.19.1   IPv6-to-IPv4 connectivity

What happens if you switch to IPv6 completely, perhaps because your ISP has run out of IPv4 addresses? Ideally you will only need to talk to IPv6 servers. For example, the DNS name microsoft.com corresponds to an IPv4 address, but also to an IPv6 address. If there is not IPv6 connectivity between you and the IPv6 server you are trying to reach, tunneling of IPv6 traffic over IPv4 can be used.

But what do you do if you have only an IPv6 address and want to reach an IPv4-only server? IPv4 and IPv6 cannot directly interoperate; while IPv6 could have been modified to support an interoperability feature, a change of such magnitude in IPv4 is politically and economically impossible. Thus, you will have to find some sort of translator, such as an IPv6-to-IPv4 NAT router. RFC 2766 defines an IPv6-to-IPv4 flavor of NAT that also includes any necessary translation of the higher transport layer as well. The NAT translator will have an IPv4 address (otherwise it cannot talk to other IPv4 nodes), but that address can be shared among multiple IPv6 clients.

8.19.2   Epilog

IPv4 has run out of large address blocks, as of 2011. IPv6 has reached a mature level of development. Most common operating systems provide excellent IPv6 support.

Yet conversion has been slow. Many ISPs still provide limited (to nonexistent) support, and inexpensive IPv6 firewalls to replace the ubiquitous consumer-grade NAT routers do not really exist. Time will tell how all this evolves. However, while IPv6 has now been around for twenty years, top-level IPv4 address blocks disappeared just three years ago. It is quite possible that this will prove to be just the catalyst IPv6 needs.

8.19.3   Exercises

1. Each IPv6 address is associated with a specific solicited-node multicast address. Explain why, on a typical Ethernet, if the original IPv6 host address was obtained via SLAAC then the LAN multicast group corresponding to the host’s solicited-node multicast addresses is likely to be small, in many cases consisting of one host only. (Packet delivery to small LAN multicast groups can be much more efficient than delivery to large multicast groups.)

(b). What steps might a DHCPv6 server take to ensure that, for the IPv6 addresses it hands out, the LAN multicast groups corresponding to the host addresses’ solicited-node multicast addresses will be small?

2. If an attacker sends a large number of probe packets via IPv4, you can block them by blocking the attacker’s IP address. Now suppose the attacker uses IPv6 to launch the probes; for each probe, the attacker changes the low-order 64 bits of the address. Can these probes be blocked efficiently? If so, what do you have to block? Might you also be blocking other users?

3. Suppose someone tried to implement ping6 so that, if the address was a link-local address and no interface was specified, the ICMPv6 Echo Request was sent out all non-loopback interfaces. Could the end result be different than conventional ping6 with the correct interface supplied? If so, how likely is this?

4. Create an IPv6 ssh connection as in 8.15.3   Routerless Connection Examples. Examine the connection’s packets using WireShark or the equivalent. Does the TCP handshake (12.3   TCP Connection Establishment) look any different over IPv6?

5. Create an IPv6 ssh connection using manually configured addresses as in 8.18   Manual address configuration. Again use WireShark or the equivalent to monitor the connection. Is DAD (8.12   Duplicate Address Detection) used?

Navigation

© Copyright 2014, Peter L Dordal. Created using Sphinx 1.1.3.