Network Working Group F. Templin Internet-Draft Nokia Expires: January 29, 2005 July 29, 2004 IPv6 Addressing in the IPv4 Internet draft-templin-v6v4inet-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 29, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4, but the proliferation of IPv4 in the global Internet continues via private addressing domains behind Network Address Translators (NATs). For these reasons, deployment of IPv6 at the end nodes with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. This document proposes a coexistence scenario with IPv6 for end to end addressing and IPv4 for network traversal. Templin, et al. Expires January 29, 2005 [Page 1] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 1. Introduction The IPv6 128-bit address space was designed as a solution for the 32-bit limitation of IPv4 and offers the promise of scalable end to end addressing, but the proliferation of IPv4 in the global Internet continues via private addressing domains [RFC1918] behind Network Address Translators (NATs) [RFC2993]. For these reasons, deployment of IPv6 at the end nodes with minimal perturbation of IPv4 networks presents a natural long-term transition and coexistence alternative. The Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] connects IPv6 nodes separated by IPv4 networks via IPv6-in-IPv4 encapsulation and a virtual link abstraction similar to the Non-Broadcast, Multiple Access (NBMA) model [RFC2491][RFC2492]. ISATAP nodes that also implement the relay/proxy/bridge/server (RPBS), IPv4 Network Address Translation (NAT), and packet encapsulation functions described in this document can extend this virtual link to reach nodes in other enterprises/sites and located many IPv4 hops away. 2. Terminology The terminology of [ISATAP][RFC2460][RFC2461] applies to this document. The following additional terms are defined: logical interface: the same as defined in ([STD3], section 3.3.4.1). virtual link: the network span over which packets can be forwarded from a sender toward a particular IPv6 target endpoint (e.g., a peer application) without the Hop Limit field in the IPv6 header being decremented. enterprise: the same as defined in ([RFC1918], section 1). For the purpose of this document, an enterprise is a network entity that has direct connection to the global IPv4 Internet and comprises one or more sites. site: a network entity that is a proper subset of an enterprise (or parent site) and determines its own addressing plan and address assignments; a site comprises a relay/proxy/bridge/server (RPBS) and its associated hosts. Templin, et al. Expires January 29, 2005 [Page 2] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 relay/proxy/bridge/server (RPBS): an IPv4 NAT that provides relaying, proxying, bridging, and/or service provisioning capabilities to form the logical nucleus for a site. RPBSs also serve as routers for their co-located IPv6 endpoints and endpoints on IPv6-only hosts; enterprise border RPBSs are 6to4 routers [RFC3056]. associated host: an RPBS or IPv6-only node that associates with a parent RPBS. An RPBS that is an associated host within a parent site can also serve as a parent RPBS for associated hosts in child sites. IP Virtual Link eXtension (IPVLX) packet: an IPv6 packet (or packet segment) encapsulated in an outer IPv4 header constructed as described in section 4. IPVLX interface: an interface that performs IPVLX packet encapsulation/decapsulation, but otherwise behaves the same as an ISATAP interface. 3. Autoconfiguration RPBSs should automatically discover, e.g., the addresses of parent RPBSs, enterprise border RPBSs, DNS recursive name servers, etc., at startup time or when moving to a new link. They should also configure DHCPv4 [RFC2131], DHCPv6 [RFC3315][RFC3633][RFC3736] and Mobile IPv6 Home Agent [RFC3775] services to support their associated hosts. Associated hosts should obtain autoconfiguration information from a parent RPBS and (optionally) configure themselves as site border RPBSs for their own associated hosts. In this way, RPBSs and associated hosts can automatically configure recursively-nested "sites within sites", with scaling properties limited only by enterprise/site addressing plans. RPBSs should register their name-to-address mappings via secure, dynamic updates to the DNS [RFC2136][DNSSEC]. (RPBSs that do not receive IPv6 address assignments and/or prefix delegations via autoconfiguration mechanisms should configure unique local addresses [UNIQ1][UNIQ2].) RPBSs should provide basic packet forwarding services if possible within constraints such as memory, battery power, RF link quality, etc. They should also use dynamic route discovery protocols such as those from the IETF MANET working group [RFC3561][RFC3626][RFC3684][DSR]. Unification of the MANET protocols with existing routing/bridging protocols (e.g., OSPF [RFC2740], IEEE Templin, et al. Expires January 29, 2005 [Page 3] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 802.1D spanning tree [STP], etc.) and an efficient flooding mechanism is currently under investigation. 4. IPVLX Encapsulation RPBSs determine the IPv4 addressing plans for their associated hosts, which can in turn serve as RPBSs that determine the IPv4 addressing plans for their own associated hosts in child sites. Since these recursively-nested IPv4 addressing plans may be topologically disjoint, RPBSs must provide a form of IPv4 NAT traversal for the packets they forward between sites. A new form of IPv6-in-IPv4 packet encapsulation (i.e., IPVLX) is therefore required to provide "mutable" bits in the IPv4 header that an RPBS can rewrite at the same time it rewrites the IPv4 source and/or destination address. The mutable bits serve the same function as the TCP/UDP source port number (i.e., as for NAT with port translation, or "NAPT") to enable scalable NAT traversal. When an RPBS uses IPVLX to encapsulate an IPv6 packet in an outer IPv4 header ([RFC0791], Section 3.1), it sets the "Protocol" field to '41' and also sets bits 0 and 1 in the "Flags" field (i.e., the "Reserved Fragmentation (RF)" and "Don't Fragment (DF)" bits) to 1. Setting the DF bit frees the 13 "Fragment Offset" and 16 "Identification" bits in the IPv4 header for use as mutable bits (since setting the DF bit disables IPv4 fragmentation and since the encapsulating IPv4 header is not included in the pseudo-header checksum calculations of upper layer protocols), while setting the RF bit allows RPBSs to distinguish IPVLX packets from ordinary ip- protocol-41 packets. When an RPBS encapsulates/forwards an IPVLX packet, it treats the 16-bit "Identification" field as a 16-bit virtual circuit identifier (VCI) and the high-order 8-bits of the "Fragment Offset" field as an 8-bit virtual path identifier (VPI). The VCI/VPI values in each IPVLX packet identify a virtual circuit (VC) that represents the (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple for the encapsulated IPv6 flow. Each such VC is associated with specific logical input/output interfaces identified by the IPVLX packet's IPv4 source and destination addresses. Templin, et al. Expires January 29, 2005 [Page 4] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 5. MTU and Link Adaptation All IPv6 interfaces must support the IPv6 minimum MTU of 1280 bytes, i.e., they must be able to send IPv6 packets of 1280 bytes or smaller to any neighboring node without returning an ICMPv6 "Packet too Big" error [RFC1981] to the source and without causing unnecessary fragmentation in the IPv4 nework [FRAG]. IPVLX interfaces must therefore implement a link adaptation layer similar to ATM Adaptation Layer 5 (AAL5) [RFC2684] to segment IPv6 packets into a chain of IPVLX packets no larger than the MTU of the outgoing IPv4 interface. IPVLX link adaptation uses the AAL5 PDU format ([RFC2684], section 4) except that the PAD field may be omitted, and uses the AAL5 CPCS-PDU format for VC multiplexing of routed protocols ([RFC2684], section 6.1). The nominal IPVLX link adaptation packet size is 68 bytes (20 bytes for the IPv4 header plus 48 bytes for the encapsulated IPv6 packet segment), i.e., the IPv4 minimum link MTU. Interfaces that use a larger IPVLX packet size must be prepared to deal with ICMPv4 "fragmentation needed" messages [RFC1191], but are advised that path MTU-related black holes may result along some paths [RFC2923]. Interfaces that use a smaller IPVLX packet size may not be able to support the 1280 byte IPv6 minimum MTU due to a limited IPVLX packet chain length (see below). IPVLX link adaptation uses the five low order bits from the 13-bit IPv4 "Fragmentation Offset" field (see: section 4) to encode a segment ID between 0 - 31 in each IPVLX packet in a chain. The "More Fragments" (MF) bit is set as for ordinary IPv4 fragmentation, i.e., the MF bit is set in all IPVLX packets in the chain except the final one. Each IPVLX packet in a chain except the final one must be of equal length. The length, segment ID, and MF fields in the IPv4 headers of a chain of IPVLX packets provide sufficient information for reassembly of a packet belonging to a specific VC with protection for minor packet reordering in the legacy IPv4 network. The equal length restriction for IPVLX packets provides a fixed hole size for reassembly algorithms [RFC0815] with no possibility for overlap or underrun (reassembly algorithm details are FFS). IPv6 endpoints can set the "USE_MINIMUM_MTU" socket option [RFC3542] such that large IPv6 packets will be fragmented to a maximum IPv6 fragment size of 1280 bytes, i.e., to ensure interoperation with IPVLX link adaptation. IPv6 endpoints that send whole IPv6 packets larger than 1280 bytes may incur a higher instance of ICMPv6 "packet too big" messages (along with corresponding packet loss inefficiency) over some paths. Templin, et al. Expires January 29, 2005 [Page 5] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 Network middleboxes that forward a chain of IPVLX packets can reassemble the IPv6 packet encoded in the chain and segment it into different-sized IPVLX packets as long as care is taken to deal with ICMPv4 "fragmentation needed" messages that may result. (Middleboxes that do not provide sufficient storage, processing, etc. for this procedure risk introducing a black hole in the nework, and should avoid this intermediary link adaptation.) When IPVLX link adaptation is used, loss of a single IPVLX packet results in loss of an entire IPv6 packet/fragment. IPv6 reassembly implementations can therefore provide greater efficiency for some applications (e.g., those that use UDP-Lite [RFC3828]) by reassembling and delivering IPv6 packets with "holes" when one or more of the fragments are missing. (The 32-bit AAL5 CRC ensures that the IPv6 fragments received contain valid data.) The use of IPVLX link adaptation may result in an overall increase of short chains of small packets in the Internet. Network administrators should therefore follow the recommendations in [BCP48] to minimize packet loss and packet reordering. 6. Virtual Link Extension When a local IPv6 endpoint sends IPv6 packets toward a target endpoint, the virtual link from the sender's first-hop RPBS can be extended to the last-hop RPBS before the target via NAT traversal as follows: 6.1 From the First-Hop RPBS to the Target's Enterprise/Site Border When an RPBS along the path from the initial RPBS to the target's enterprise/site border receives an IPVLX packet with an unknown VCI/VPI for the input interface, it creates a new VC cache entry (managed as for IPv6 flow state [RFC3697]). When forwarding the packet on an output interface into a topologically disjoint IPv4 addressing region, the RPBS also rewrites the packet's IPv4 source address to the address of the IPv4 interface that will forward the packet and rewrites the VCI/VPI to new values for the output interface. (The IPv4 destination address is not rewritten, since it already provides the topologically-correct address necessary to steer the packet toward the target enterprise.) Intermediate RPBSs cache the (VCI(in), VPI(in), input_interface, VCI(out), VPI(out), output_interface)-tuple to support packet fowarding for the flow, and the initial RPBS also caches a (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple to identify the flow's endpoints. Templin, et al. Expires January 29, 2005 [Page 6] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 6.2. From the Target's Enterprise/Site Border to the Last-Hop RPBS For IPVLX packets entering an enterprise/site (and, for ICMPv4 messages reporting errors for IPVLX packets that previously exited the enterprise/site) each intermediate RPBS along the path toward the target should use some form of static/dynamic IPv6 route discovery to determine the next hop RPBS among their associated hosts. (Possible route discovery mechanisms include static prefix delegations, routes learned via dynamic routing protocols, etc.) Intermediate RPBSs should not decapsulate the packet as an IPv6 router would do, but instead relay the packet to the next hop RPBS via IPv4, leaving the "Hop Limit" field in the IPv6 header unchanged. The last-hop RPBS in the path will be an IPv6 router for the target that decapsulates the packet. To support this relaying, when an RPBS along the path from the enterprise/site border inwards toward the final RPBS before the target receives an IPVLX packet with an unknown VCI/VPI for the input interface, it creates a new VC cache entry as described in section 6.1. When forwarding the packet on an output interface into a topologically disjoint IPv4 addressing region, the RPBS also rewrites the packet's IPv4 destination address to the IPv4 address of the next hop RPBS, rewrites the packet's IPv6 source address to the address of the IPv4 interface that will forward the packet, and rewrites the VCI/VPI to new values for the output interface. Intermediate RPBSs cache the (VCI(in), VPI(in), input_interface, VCI(out), VPI(out), output_interface)-tuple to support packet fowarding for the flow, and the final RPBS also caches a (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple to identify the flow's endpoints. 7. Error Handling Both initiating and intermediate RPBSs may receive ICMPv4 messages reporting errors for the IPVLX packets they send/forward. These error messages consist of an outer IPv4 header with the IPv4 source address of the node reporting the error, an inner IPv4 header from the packet-in-error, and at least the first 8 bytes of the encapsulated IPv6 packet segment. Initiating RPBSs can use the VCI/VPI encoded in the IPv4 header from the packet-in-error to locate an (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple in their VC cache to translate the ICMPv4 error message to an ICMPv6 error message [RFC2765]. Intermediate RPBSs can use the VCI/VPI encoded in the IPv4 header from the packet-in-error to locate the previous-hop RPBS to which it can forward the error message. Templin, et al. Expires January 29, 2005 [Page 7] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 Both initiating and intermediate RPBSs can keep a small queue of recently-sent IPVLX packets for each VC in its cache for error translation and/or retransmission in case legitimate ICMPv4 "fragmentation needed" messages are received. (This may be difficult for intermediate RPBSs that occur in the middle of the network, i.e., not close to the source or destination IPv6 endpoints.) 8. Header Compression After the initiating RPBS selects the IPv6 source and destination addresses for communication with the target and sends the initial IPVLX packets of the flow, any intermediate RPBSs in the path should have VC cache state established. The initiating RPBS can then use IPv6 header for subsequent packets sent over the same VC [RFC2507][RFC3095]. 9. Discovering a Default IPv6 Router Following IPv4 autoconfiguration (e.g., via DHCPv4 delegations from a parent RPBS), an RPBS that does not connect directly to the global IPv4 Internet should send IPVLX encapsulated Router Solicitation messages to discover a default IPv6 router and IPv6 autoconfiguration parameters for its local enterprise. The router so discovered will be an enterprise border RPBS (i.e., a 6to4 router [RFC3056]) as seen from inside the enterprise. The Router Solicitation messages should use the following addresses: - in the IPv6 source address, a global (or unique local) IPv6 unicast address for the initiator (preferably a Cryptographically Generated Address [CGA]) - in the IPv6 destination address, a link-local Mobile IPv6 Home-Agents anycast address [RFC2526] - in the IPv4 source address, an IPv4 address from the underlying IPv4 interface that will send the encapsulated Router Solicitations - in the IPv4 destination address, the 6to4 relay anycast address [RFC3068] The encapsulated IPv6 Router Solicitation should also include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof-of-ownership verification. When an enterprise border RPBS receives the Router Solicitation (due to configuring the Mobile IPv6 Home-Agents anycast address and 6to4 relay anycast address) it can verify that the solicitor owns the CGA Templin, et al. Expires January 29, 2005 [Page 8] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 then send back an IPVLX-encapsulated Router Advertisement with the following addresses: - in the IPv6 source address, a link-local address (preferably a link-local [CGA] address) - in the IPv6 destination address, the IPv6 source address from the Router Solicitation - in the IPv4 source address, an address from the underlying IPv4 interface that will send the encapsulated Router Advertisement - in the IPv4 destination address, the IPv4 address received in the Router Solicitation The encapsulated IPv6 Router Advertisement should include a SLLAO with an embedded IPv4 address ([RFC2529], section 5) that is the equivalent IPv4 unicast address associated with the 6to4 router ([RFC3068], section 2.6). It should also include [SEND] parameters for [CGA] proof-of-ownership verification and any [RFC2461] Router Advertisement parameters for autoconfiguration in the enterprise. 10. Discovering More-Specific Routes When an RPBS's local IPv6 endpoint initiates communications with a target endpoint, it first resolves the target's Fully-Qualified Domain Name (FQDN) using the DNS [RFC1035] or an enterprise-internal name service, e.g., [LLMNR]. If the name service returns a set of AAAA records including one with a 6to4 [RFC3056] address, the initiator can interpret the IPv4 address embedded in the 6to4 prefix as the IPv4 destination address for the target node's enterprise border RPBS. The initiator's first-hop RPBS can then send IPVLX encapsulated IPv6 Router Solicitation messages (to discover a more-specific route for the target [DEFLT]) with the following addresses: - in the IPv6 source address, a global (or unique local) IPv6 unicast address for the initiator (preferably a [CGA] address) - in the IPv6 destination address, a global (or unique local) IPv6 unicast address for the target returned by the name service - in the IPv4 source address, an IPv4 address from the underlying IPv4 interface that sends the encapsulated Router Solicitation Templin, et al. Expires January 29, 2005 [Page 9] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 - in the IPv4 destination address, the 6to4-embedded IPv4 address The encapsulated IPv6 Router Solicitation should include [SEND] parameters for [CGA] proof-of-ownership verification. When the target's RPBS receives a Router Solicitation, it can perform a reverse name service lookup on the initiator's IPv6 source address as a means of authorizing the initiator. It can then send an IPVLX encapsulated Router Advertisement back toward the soliciting RPBS with the following addresses: - in the IPv6 source address, a link-local address (preferably a link-local [CGA] address) - in the IPv6 destination address, the IPv6 source address from the Router Solicitation - in the IPv4 source address, an IPv4 address from the underlying IPv4 interface that sends the encapsulated Router Advertisement - in the IPv4 destination address, the IPv4 source address received in the Router Solicitation The encapsulated IPv6 Router Advertisement should include a SLLAO that embeds the IPv4 source address ([RFC2529], section 5) and [SEND] parameters for [CGA] proof-of-ownership verification. It should also include as many of the target's IPv6 addresses as possible in Route Information Options [DEFLT]. When the soliciting RPBS receives a Router Advertisement, it can verify that the IPv6 addresses in Route Information Options sent by the target (or, an RPBS in the target's enterprise) match the IPv6 addresses received in AAAA records returned by the name service as a means of authorizing the target's RPBS. This assumes the name service can be used as a suitable trust anchor for router authorization without the need for ([SEND], section 6) authorization delegation discovery. Following authorization, the soliciting RPBS can add IPv6 routes with the IPVLX address constructed from the IPv4 address in the Router Advertisement's SLLAO as the next hop toward the target's IPv6 addresses, and use IPv6 address selection rules to determine the best IPv6 source and destination addresses to choose for communications with the target [RFC3484]. Templin, et al. Expires January 29, 2005 [Page 10] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 11. Mobility When an RPBS moves to a different network point of attachment, it will receive new IPv4 autoconfiguration information from a new parent RPBS that potentially resides in a different enterprise. Upon reattachment, the mobile RPBS should send IPv6 Router Solicitation messages using secure neighbor discovery mechanisms [SEND][CGA] to its home enterprise border RPBS (i.e., its home 6to4 router) to update the router's neighbor cache and dynamic routing information in any intermediate RPBSs. Whether the Mobile IPv6 binding update mechanism should also be used to directly inform the home agent of a new enterprise point of attachment is FFS. IPv6 nodes can use the features of Mobile IPv6 [RFC3775] to support movement to foreign enterprises and to different IPv6 prefix regions within the home enterprise. The Mobile IPv6 home agent function can be deployed on RPBSs to support associated hosts that have moved to a different network point of attachment. Whether the binding update mechanisms of Mobile IPv6, or ICMPv6 Redirect messages using secure neighbor discovery mechanisms [SEND][CGA] should be used to provide mobile node location updates to correspondent nodes is FFS. 12. Analysis of Encapsulation Alternatives IPv6 peers that connect to the same physical L2 media segment can use IPv6 without IPv4 encapsulation directly over the L2 media. Attachment to the same physical L2 media segment can be detected based on, e.g., passive message snooping, whether/not a neighbor responds to unencapsulated IPv6 neighbor discovery messages sent over the L2 media, etc. To avoid issues associated with bridging dissimilar media (e.g., path MTU black holes), to avoid ICMPv4-ICMPv6 error translation issues, and to support IPv6 neighbor discovery security mechanisms, RPBSs should use IPVLX encapsulation for sending IPv6 packets to neighbors that do not attach to the same physical L2 media segment. When legacy NAT boxes that do not support the mechanisms described in this document are in the path, RPBSs should use explicit NAT traversal mechanisms (e.g., [TEREDO]) since they provide a lowest- common denominator approach supported by most legacy NATs. However, the IPv6/UDP/IPv4 encapsulation used by explicit NAT traversal mechanisms requires an extra 8 bytes of overhead for each encapsulated packet; effectively reducing the payload to 40 bytes for a 68 byte encapsulated packet. Templin, et al. Expires January 29, 2005 [Page 11] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 13. Security considerations Securing mechanisms for IPv6 neighbor discovery messages (e.g., [CGA], [SEND], etc.) are used according to the trust model appropriate for the given deployment scenario [RFC3756]. End-to-end IP security mechanisms should be used to provide confidentiality. 14. Acknowledgments This document represents the author's best effort to anticipate, interpret and describe emerging trends rooted in firm scientific principles. The author acknowledges the many individuals whose many years of effort have helped shape them. The following are acknowledged for their helpful insights on path MTU discovery: Jari Arkko, Iljitsch van Beijnum, Jim Bound, Ralph Droms, Alain Durand, Jim Fleming, Tim Gleeson, Jun-ichiro itojun Hagino, Brian Haberman, Bob Hinden, Christian Huitema, Eddie Kohler, Kevin Lahey, Hakgoo Lee, Masataka Ohta, Matt Mathis, Jeff Mogul, Erik Nordmark, Soohong Daniel Park, Chirayu Patel, Charles Perkins, Michael Richardson, Pekka Savola, Hesham Soliman, Mark Smith, Dave Thaler, Margaret Wasserman, Michael Welzl, Lixia Zhang, and the members of the Nokia NRC/COM Mountain View team. "...and I'm one step ahead of the shoe shine, Two steps away from the county line, Just trying to keep my customers satisfied, Satisfi-i-ied!" - Paul Simon, 1969 Appendix A. The IPv6 minimum MTU The 1280 byte IPv6 minimum MTU was agreed through working group consensus in November 1997 discussions on the IPv6 mailing list. Informative References [BCP48] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001. [STD3] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Templin, et al. Expires January 29, 2005 [Page 12] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [RFC0815] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, July 1982. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2491] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999. [RFC2507] Degermark, M., Nordgren, B. and S. Pin, "IP Header Compression", RFC 2507, February 1999. [RFC2526] Johnson, D., and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [RFC2529] Carpenter, B., and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2684] Grossman, D., and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. Templin, et al. Expires January 29, 2005 [Page 13] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [RFC2740] Colton, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3095] Bormann, C. (Ed.), "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3315] Droms, R., Bound, J., Volz. B, Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC3561] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Option for Dynamic Host Configuration Protocol (DHCP) version 6)", RFC 3633, December 2003. [RFC3684] Ogier, R., Templin, F. and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. Templin, et al. Expires January 29, 2005 [Page 14] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery Trust Models and Threats", RFC 3756, May 2004. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., editor and G. Fairhurst, editor, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga, Work in Progress, April 2004. [DEFLT] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", draft-ietf-ipv6-router-selection, Work in Progress, June 2004. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro, Work in Progress, July 2004. [DSR] Johnson, D., Malz, D. and Hu, Y., "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr, Work in Progress, April 2003. [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August 1987. [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap, Work in Progress, May 2004. [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns, Work in Progress, July 2004. [NDPROXY] Thaler, D., Talwar, M. and C. Patel, "Bridge-Like Neighbor Discovery Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy, Work in Progress, February 2004. [RBRIDGE] Perlman, R., Touch, J., and A. Yegin, "RBridges: Transparent Routing", draft-perlman-rbridge-00, Work in Progress, April 2004. Templin, et al. Expires January 29, 2005 [Page 15] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt, Work in Progress, July 2004. [STP] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 1998, http://standards.ieee.org/getieee802/download/802.1D-1998.pdf. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo, Work in Progress, February 2004. [UNIQ1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, June 2004. [UNIQ2] Hinden, R., and B. Haberman, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central, Work in Progress, June 2004. Authors' Addresses Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94110 US Phone: +1 650 625 2331 EMail: ftemplin@iprg.nokia.com Templin, et al. Expires January 29, 2005 [Page 16] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin, et al. Expires January 29, 2005 [Page 17]