Although most technical aspects of IPv6 have been defi ned for some time, deploy-ment of IPv6 is occurring gradually. Initially, IPv6 is being deployed within isolated islands with interconnectivity among the islands being achieved by the existing IPv4 infrastructure, and a number of transition mechanisms have been defi ned to interconnect such islands.
Th ere is an additional need for support for IPv6 hosts and routers that need to interoperate with legacy IPv4 hosts, and an overview of such mechanisms for this purpose is provided in RFC 2893. Th at RFC defi nes the following types of nodes with respect to the transition to IPv6.
IPv4-only node: A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. Th e installed base of IPv4 hosts and routers are examples of IPv4-only nodes.
IPv6/IPv4 node: A host or router that implements both the IPv4 and IPv6 protocols.
IPv6-only node: A host or router that implements IPv6 and does not imple-ment IPv4.
IPv6 node: Any host or router that implements IPv6. IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes.
IPv4 node: Any host or router that implements IPv4. IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes.
Th e RFC also defi nes the IPv4-compatible IPv6 address, e.g., ::156.55.23.5, discussed previously in the section on IPv6 address space. IPv4-compatible IPv6 addresses are used to implement a simple automatic tunneling mechanism.
In addition to connectivity issues at the IP layer, the transition to IPv6 is also not entirely transparent to the networking layers above IP. As discussed previously, IPv6 addresses are signifi cantly longer in size than IPv4 addresses and thus will require a change in application programming interfaces (APIs) or service primitive parameters that include IP addresses. Applications must also be extended to select the appropriate protocol, IPv4 or IPv6, when a DNS lookup returns both types of addresses. In general, legacy applications written for IPv4 either need to be rewrit-ten or amended to support IPv6. For example, the application layer fi le transfer protocol (FTP) embeds IP addresses in its protocol fi elds, and could thus require changes to both the client and server FTP applications.
Th e IETF has defi ned a number of specifi c mechanisms to assist in transition-ing to IPv6. Th ese mechanisms are generally classifi ed as belonging to the follow-ing categories:
Dual-Stack—Th e principal building block for transitioning is the dual-stack approach. Dual-stack nodes, as the name suggests, maintain two protocol stacks that operate in parallel and thus allow the end system or router to operate via either protocol. In end systems they enable both IPv4 and IPv6 capable applications to operate on the same node. Dual-stack capabilities in routers allow handling of both IPv4 and IPv6 packet types.
Translation—Translation refers to the direct conversion of protocols (e.g., between IPv4 and IPv6) and may include transformation of both the proto-col header and the protoproto-col payload. Translation can occur at several layers in the protocol stack, including IP, transport, and application layers. Note that protocol translation can results in feature loss where there is no clear mapping between the features provided by translated protocols. For instance, transla-tion of an IPv6 header into an IPv4 header will lead to the loss of the IPv6 fl ow label and its accompanying functionality.
Tunneling (or Encapsulation)—Tunneling is used to interconnect compatible networking nodes or domains across incompatible networks. It can be viewed technically as the transfer of a payload protocol data unit by an encapsulating carrier protocol. For IPv6 transition, the IPv6 protocol data unit is generally carried as the payload of an IPv4 packet. Encapsulation of the payload pro-tocol data unit is performed at the tunnel entrance and de-encapsulation is performed at the tunnel exit point.
Note that a transition mechanism may employ techniques from more than one of these categories. For example, when an end system or router creates an IPv6 in IPv4 tunnel, this could be classifi ed as both dual stack (having both an IPv4 and IPv6 address) and tunneling.
References
[CIS200801] Cisco Documentation. Enabling IPv6 routing and confi guring IPv6 address-ing. www.cisco.com.
[MSD200401] Microsoft Corporation. Internet protocol. MSDN Library, 2004. http://
msdn.microsoft.com.
[RFC2460] Deering, S., and R. Hinden Internet Protocol, Version 6 (IPv6) Specifi cation, RFC 2460, Dec. 1998. Copyright (C) Th e Internet Society (1998). All Rights Reserved. Th is document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implemen-tation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.
[RFC2461] Narten, T., E. Nordmarket, and W. Simpson. Request for Comment: 2461, Neighbor Discovery for IPv6, RFC 2461, Dec. 1998.
[RFC2893] Gilligan, R., and E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers, RFC 2893, Aug. 2000. Copyright (C) Th e Internet Society (2000). All Rights Reserved. Th is document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implemen-tation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.
[RFC3022] Srisuresh, P., and K. Egevang. Request for Comments: 3022, Traditional IP Network Address Translator (Traditional NAT), RFC 3022, Jan. 2001.
[RFC3315] Droms, R., ed., J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney.
Dynamic Host Confi guration Protocol for IPv6 (DHCPv6), RFC 3315, July 2003.
Copyright (C) Th e Internet Society (2003). All Rights Reserved. Th is document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.
[RFC3513] Hinden, R., and S. Deering. Internet Protocol Version 6 (IPv6) Addressing Architecture, RFC 3513, Apr. 2003. Copyright (C) Th e Internet Society (2003). All Rights Reserved. Th is document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.
[RFC3775] Johnson, D., C. Perkins, and J. Arkko. Request for Comments: 3775, Mobility Support in IPv6, RFC 3775, June 2004.
[RFC3879] Huitema, C., and B. Carpenter. Request for Comments: 3879, Deprecating Site Local Addresses, Sept. 2004.
[RFC4038] Shin, M-K., ed., Y-G. Hong, J. Hagino, P. Savola, and E. M. Castro. Request for Comments: 4038, Application Aspects of IPv6 Transition, RFC 4038, Mar. 2005.
Appendix A: Neighbor Discovery for IP Version 6 (IPv6) Protocol
Th is section provides a brief overview of the Neighbor Discovery for IP Version 6 (IPv6) protocol, also known as Neighbor Discovery Protocol (NDP) based directly on RFC 2461 [RFC2461].
Functionality
As covered briefl y earlier in the chapter, the Neighbor Discovery for IP Version 6 (IPv6) protocol solves a set of problems related to the interaction between nodes attached to the same link. It defi nes mechanisms for solving each of the following problems:
Router Discovery: How hosts locate routers that reside on an attached link.
Prefi x Discovery: How hosts discover the set of address prefi xes that defi ne which destinations are on-link for an attached link. (Nodes use prefi xes to distin-guish destinations that reside on-link from those only reachable through a router.)
Parameter Discovery: How a node learns such link parameters as the link MTU or such Internet parameters as the hop limit value to place in outgoing packets.
Address Autoconfi guration: How nodes automatically confi gure an address for an interface.
Address resolution: How nodes determine the link-layer address of an on-link destination (e.g., a neighbor), given only the destination’s IP address.
Next-hop determination: Th e algorithm for mapping an IP destination address into the IP address of the neighbor to which traffi c for the destination should be sent. Th e next-hop can be a router or the destination itself.
Neighbor Unreachability* Detection: How nodes determine that a neighbor is no longer reachable. For neighbors used as routers, alternate default routers can be tried. For both routers and hosts, address resolution can be per-formed again.
Duplicate Address Detection: How a node determines that an address it wishes to use is not already in use by another node.
Redirect: How a router informs a host of a better fi rst-hop node to reach a par-ticular destination.
Neighbor Discovery defi nes fi ve diff erent ICMP packet types: A pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation and Neighbor Advertisements messages, and a Redirect message. Th e messages serve the following purpose:
Router Solicitation (RS): When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time.
Router Advertisement (RA): Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefi xes that are used for on-link determination or address confi guration, a suggested hop limit value, and so forth.
Neighbor Solicitation (NS): Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor Solicitations are also used for Duplicate Address Detection.
Neighbor Advertisement (NA): A response to a Neighbor Solicitation message.
A node may also send unsolicited Neighbor Advertisements to announce a link-layer address change.
Redirect: Used by routers to inform hosts of a better fi rst hop for a destination.
On multicast-capable links, each router periodically multicasts a Router Advertisement packet announcing its availability. A host receives Router Advertisements from all routers, building a list of default routers. Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of
adver-*For neighboring routers, reachability means that packets sent by a node’s IP layer are delivered to the router’s IP layer, and the router is indeed forwarding packets (i.e., it is confi gured as a router, not a host). For hosts, reachability means that packets sent by a node’s IP layer are deliv-ered to the neighbor host’s IP layer. Unreachability means being in a state where reachability is not achieved at the time in question.
tisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection.
Router Advertisements contain a list of prefi xes used for on-link determination or autonomous address confi guration; fl ags associated with the prefi xes specify the intended uses of a particular prefi x. Hosts use the advertised on-link prefi xes to build and maintain a list that is used in deciding when a packet’s destination is on-link or beyond a router. Note that a destination can be on-on-link even though it is not covered by any advertised on-link prefi x. In such cases a router can send a Redirect informing the sender that the destination is a neighbor.
Router Advertisements (and per-prefi x fl ags) allow routers to inform hosts how to perform Address Autoconfi guration. For example, routers can specify whether hosts should use stateful (DHCPv6) or autonomous (stateless) address confi guration.
Router Advertisement messages also contain Internet parameters such as the hop limit that hosts should use in outgoing packets and, optionally, link parameters such as the link MTU. Th is facilitates centralized administration of critical param-eters that can be set on routers and automatically propagated to all attached hosts.
Nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. Neighbor Solicitation mes-sages are multicast to the solicited-node multicast address of the target address. Th e target returns its link-layer address in a unicast Neighbor Advertisement message.
A single request-response pair of packets is suffi cient for both the initiator and the target to resolve each other’s link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.
Neighbor Solicitation messages can also be used to determine if more than one node has been assigned the same unicast address.
Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confi rma-tion that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor Unreachability Detection uses confi r-mation from two sources: When possible, upper-layer protocols provide a positive confi rmation that a connection is making “forward progress,” that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). When positive confi rmation is not forthcoming through such
“hints,” a node sends unicast Neighbor Solicitation messages that solicit Neighbor Advertisements as reachability confi rmation from the next hop. To reduce unneces-sary network traffi c, probe messages are only sent to neighbors to which the node is actively sending packets.
In addition to addressing the above general problems, Neighbor Discovery also handles the following situations:
Link-layer address change—A node that knows its own link-layer address has changed can multicast a few (unsolicited) Neighbor Advertisement packets to all nodes to quickly update cached link-layer addresses that have become
invalid. Note that the sending of unsolicited advertisements is a performance enhancement only (e.g., unreliable). Th e Neighbor Unreachability Detection algorithm ensures that all nodes will reliably discover the new address, though the delay may be somewhat longer.
Inbound load balancing—Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses.
Load balancing is handled by allowing routers to omit the source link-layer address from Router Advertisement packets, thereby forcing neighbors to use Neighbor Solicitation messages to learn link-layer addresses of routers.
Returned Neighbor Advertisement messages can then contain link-layer addresses that diff er depending on who issued the solicitation.
Anycast addresses—Anycast addresses identify one of a set of nodes providing an equivalent service, and multiple nodes on the same link may be confi gured to recognize the same Anycast address. Neighbor Discovery handles anycasts by having nodes expect to receive multiple Neighbor Advertisements for the same target. All advertisements for anycast addresses are tagged as being non-Override advertisements. Th is invokes specifi c rules to determine which of potentially multiple advertisements should be used.
Proxy advertisements—A router willing to accept packets on behalf of a target address that is unable to respond to Neighbor Solicitations can issue non-Override Neighbor Advertisements. Th ere is currently no specifi ed use of proxy, but proxy advertising could potentially be used to handle cases like mobile nodes that have moved off -link. However, it is not intended as a general mechanism to handle nodes that, for example, do not implement this protocol.
A short comparison with IPv4 follows.
Th e IPv6 Neighbor Discovery protocol corresponds to a combination of the IPv4 protocols ARP, ICMP Router Discovery, and ICMP Redirect. In IPv4 there is no gen-erally agreed upon protocol or mechanism for Neighbor Unreachability Detection, although Hosts Requirements does specify some possible algorithms for Dead Gateway Detection (a subset of the problems Neighbor Unreachability Detection tackles).
Th e Neighbor Discovery protocol provides a multitude of improvements over
◾
the IPv4 set of protocols:
Router Discovery is part of the base protocol set; there is no need for hosts to
◾
“snoop” the routing protocols.
Router advertisements carry link-layer addresses; no additional packet
◾
exchange is needed to resolve the router’s link-layer address.
Router advertisements carry prefi xes for a link; there is no need to have a
◾
separate mechanism to confi gure the “netmask.”
Router advertisements enable Address Autoconfi guration.
◾
Routers can advertise an MTU for hosts to use on the link, ensuring that all
◾
nodes use the same MTU value on links lacking a well-defi ned MTU.
Address resolution multicasts are “spread” over 4 billion (2
◾ 32) multicast addresses
greatly reducing address resolution related interrupts on nodes other than the target. Moreover, non-IPv6 machines should not be interrupted at all.
Redirects contain the link-layer address of the new fi rst hop; separate address
◾
resolution is not needed upon receiving a redirect.
Multiple prefi xes can be associated with the same link. By default, hosts learn
◾
all on-link prefi xes from Router Advertisements. However, routers may be confi gured to omit some or all prefi xes from Router Advertisements. In such cases hosts assume that destinations are off -link and send traffi c to routers. A router can then issue redirects as appropriate.
Unlike IPv4, the recipient of an IPv6 redirect assumes that the new next-hop is on-link. In IPv4, a host ignores redirects specifying a next-hop that is not on-link according to the link’s network mask. Th e IPv6 redirect mechanism is expected to be useful on nonbroadcast and shared media links in which it is undesirable or not possible for nodes to know all prefi xes for on-link destinations.
Neighbor Unreachability Detection is part of the base signifi cantly improving the robustness of packet delivery in the presence of failing routers, partially failing or partitioned links, and nodes that change their link-layer addresses. For instance, mobile nodes can move off -link without losing any connectivity due to stale ARP caches.
Unlike ARP, Neighbor Discovery detects half-link failures (using Neighbor Unreachability Detection) and avoids sending traffi c to neighbors with which two-way connectivity is absent.
Unlike IPv4 Router Discovery, the Router Advertisement messages do not con-tain a preference fi eld. Th e preference fi eld is not needed to handle routers of diff er-ent “stability”; the Neighbor Unreachability Detection will detect dead routers and switch to working ones.
Th e use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefi xes.
Using the Hop Limit equal to 255 trick, Neighbor Discovery is immune to off -link senders that accidentally or intentionally send ND messages. In IPv4, off --link senders can send both ICMP Redirects and Router Advertisement messages.
Placing address resolution at the ICMP layer makes the protocol more media-independent than ARP and makes it possible to use standard IP authentication and security mechanisms as appropriate.
Appendix B: Mobile IP Version 6 (MIPv6)
Th is appendix provides a short introduction to MIPv6, based directly on RFC 3775 [RFC3775]. RFC 3775 is a lengthy RFC due to the complexity of the topic.
Only the most basic capabilities are covered here, and the reader and developer
Only the most basic capabilities are covered here, and the reader and developer