Network Working Group F. Templin Internet-Draft Nokia Category: Best Current Practice June 30, 2004 Expires: December 30, 2004 IPv6 Addressing in the IPv4 Internet draft-templin-v6v4inet-00.txt Status of this Memo 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 Section 6 of RFC XXXY. 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 December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract IPv6 includes a 128-bit address space designed as a solution for the 32-bit limitation of IPv4. But, IPv4 proliferation in the global Internet continues via private addressing domains behind Network Address Translators (NATs). Furthermore, a formerly popular viewpoint that IPv6 networking would soon replace IPv4 seems to be yielding to an emerging viewpoint of long-term coexistence. This document proposes a coexistence scenario with IPv6 for end-to-end addressing and IPv4 for inter/intra-network routing. Templin, et al. Expires December 30, 2004 [Page 1] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 1. Introduction IPv6 includes a 128-bit address space designed as a solution for the 32-bit limitation of IPv4 and offers the promise of end-to-end addressing for nodes that implement the protocol. But, IPv4 proliferation 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 the IPv4 Internet presents a natural transition and coexistence alternative for the long term. The Intra-Site Automatic Tunnel Addressing Protocol [ISATAP] connects IPv6 hosts/routers separated by an IPv4 network via IPv6-in-IPv4 encapsulation (i.e., ip-protocol-41) and a virtual link abstraction similar to the Non-Broadcast, Multiple Access (NBMA) model [RFC2491][RFC2492]. ISATAP nodes connected to IPv4 networks with NATs that use the simple relay/proxy/bridge/server (RPBS) enhancements described in this document can extend the virtual link to reach decapsulation endpoints located many IPv4 hops away. The use of ip-protocol-41 encapsulation and these NAT enhancements provide the advantages of both the 128-bit IPv6 address space (for end-to-end addressing) and the ubiquitous deployment of IPv4 (for inter/intra network routing). 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). For the purpose of this document, the soft state associated with an IPv6 flow [RFC3697] is seen as a logical interface associated with an ISATAP interface. virtual link: the IPv4 network span over which ip-protocol-41 packets can be forwarded toward a particular IPv6 destination without the Hop Limit field in the IPv6 header being decremented. enterprise: the same as defined for "enterprise" in ([RFC1918], section 1) except that, for the purpose of this document, an enterprise has direct connection to the global IPv4 Internet and comprises one or more sites. Templin, et al. Expires December 30, 2004 [Page 2] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 site: the same as defined for "enterprise" in ([RFC1918], section 1) except that, for the purpose of this document, a site is a proper subset of either an enterprise or a parent site. A site entity comprises a relay/proxy/bridge/server (RPBS) and its associated hosts. relay/proxy/bridge/server (RPBS): an enhanced NAT that provides the logical nucleus for a site and provides relaying, proxying, bridging, and/or service provisioning capabilities for its associated hosts. (See also: [RBRIDGE][NDPROXY].) associated host: a node that associates with an RPBS. A node that acts as an associated host within a parent site can also act as an RPBS for sub-sites within the parent site (a low-end node may choose not to act as an RPBS). ISATAP node: the same as defined in ([ISATAP], section 3). For the purpose of this document, ISATAP nodes should be able to act as an RPBS, an associated host, or both. 3. Enterprise Network Autoconfiguration ISATAP nodes should support ad-hoc deployment in an enterprise network, i.e., they should be able to discover enough information about their environment (e.g., addresses of site border RPBSs, DNS recursive name servers, etc.) to automatically configure themselves for operation. ISATAP nodes should be able to act as enterprise/site border RPBSs, mobile RPBSs, or simple associated hosts depending on their topological orientation. ISATAP nodes that connect directly to the global IPv4 Internet (e.g., via an ISP, a 3GPP network, etc.) should automatically configure themselves as enterprise border RPBSs and configure DHCPv6 services [RFC3315][RFC3633][RFC3736] to support associated hosts. Other ISATAP nodes should obtain configuration information from an RPBS in a parent site and (optionally) configure themselves as RPBSs to support associated hosts within sub-sites. In this way, ISATAP nodes in an enterprise can automatically configure recursively-nested "sites within sites", with scaling properties limited only by the enterprise's addressing strategy. When an ISATAP node configures itself as an enterprise/site border RPBS, but does not receive prefix delegations from an upstream provider, it should configure unique local prefix(es) [UNIQUE] for Templin, et al. Expires December 30, 2004 [Page 3] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 intra-site and/or intra-organizational communications. All IPv6 nodes (including ISATAP and IPv6-only nodes) should provide basic packet forwarding services if possible within constraints such as memory, battery power, RF link quality, etc. They should also use a dynamic route discovery protocol 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 802.1D spanning tree [STP], etc.) and an efficient flooding mechanism is currently under investigation. 4. Inter-Enterprise Communications When an ISATAP node sends ip-protocol-41 packets toward an IPv6 target node located in a remote enterprise, the virtual link can theoretically extend all the way from the sender to the target's enterprise border (or even to the target itself) given appropriate enhancements in RPBSs along the path as follows: 4.1 From the Sender to the Target's Enterprise Border Any RPBSs along the path from the sender to the target's enterprise border that rewrite a packet's IPv4 source address should implement a simple enhancement to support extension of the virtual link. In particular, each such RPBS should also rewrite any matching IPv4 addresses embedded in the packet's IPv6 source address and (for IPv6 Neighbor Discovery messages) in Source/Target Link Layer Address Options [RFC2529] at the same time the IPv4 source address is rewritten (i.e., an operation commonly referred to as proxying [NDPROXY]). Each such RPBS should also cache IPv6 flow soft state [RFC3697] as a logical interface identifying the sender and take care that no two flows with the same (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple exit the enterprise/site at the same time. If two or more flows attempt to use the same (non-zero) IPv6 flow label and IPv4 destination address, an RPBS can break the tie by assigning distinct IPv4 addresses to the flows when it re-writes the IPv4 source address and matching IPv4 addresses in ip-protocol-41 packets. (This requires each RPBS to assign multiple IPv4 addresses to its outgoing interfaces.) 4.2. From the Target's Enterprise Border to the Target For ip-protocol-41 packets entering an enterprise (and, for ICMPv4 messages reporting errors for ip-protocol-41 packets that previously exited the enterprise) each enterprise/site border RPBS along the path toward the final destination should use some form of static/dynamic route discovery to determine the next hop RPBS (or, Templin, et al. Expires December 30, 2004 [Page 4] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 the final destination itself) among their associated hosts. 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 final RPBS in the path will either be an IPv6 router or the final destination itself.) To support this relaying, each intermediate RPBS along the path from the enterprise boundary inward toward the final destination should rewrite the IPv4 destination address of each relayed packet to the IPv4 address of either the next hop RPBS or the final destination. If the value in the packet's IPv6 flow label field found in the leading portion of the encapsulated IPv6 header immediately following the IPv4 header is non-zero, the RPBS should also cache the (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple in flow soft state [RFC3697] as a logical interface identifying the target. Next hop determination is based on the type of packet being relayed as follows: - for ip-protocol-41 packets that contain a full IPv6 header, next hop determination is based on the IPv6 destination address. - for ip-protocol-41 packets that contain a partial IPv6 header (e.g., a compressed header that includes the IPv6 flow label but not the destination address), next hop determination is based on flow state cached for the packet's (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple. - for ICMPv4 error messages that report errors for ip-protocol-41 packets, next hop determination is based on flow state cached for the (IPv4 src, IPv4 dst, IPv6 flow_label)-tuple taken from the packet-in-error. 5. Intra-Enterprise Communications When an ISATAP node sends ip-protocol-41 packets toward an IPv6 target node located in the same enterprise, the sender's packets will either reach the target directly without requiring IPv4 address rewriting by an RPBS, or they will eventually reach a parent site border RPBS (possibly the border RPBS for the enterprise itself) that is also the parent for the target's site. In the latter case, the parent site border RPBS will behave as a virtual enterprise boundary for the target. The operation of RPBSs in the path from the sender to this virtual boundary will be exactly the same as in section 4.1, and the operation of RPBSs in the path from Templin, et al. Expires December 30, 2004 [Page 5] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 this virtual boundary to the target will be exactly the same as in section 4.2. 6. Addressing When an ISATAP node's application initiates communications with a target peer, 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] subnet router anycast address, the initiating node can use the IPv4 address embedded in the 6to4 prefix as the IPv4 destination address for the target node's enterprise border RPBS. (The address can also be used to determine whether the initiator and target reside in the same enterprise.) The initiator can then send ip-protocol-41 encapsulated IPv6 Router Solicitation messages toward the target with the following addresses: - in the IPv6 destination address, an IPv6 global unicast address returned by the name service for the target - in the IPv6 source address, an IPv6 global unicast addresses for the initiator - in the IPv4 source address, an IPv4 address from the underlying interface - in the IPv4 destination address, the 6to4-embedded IPv4 address The encapsulated IPv6 Router Solicitation should also include a Source Link Layer Address Option that embeds the IPv4 source address as specified in ([RFC2529], section 5). When the target (or, an RPBS in the target's enterprise) receives a Router Solicitation, it can perform a reverse name service lookup on the initiator's IPv6 source address as a means of authenticating the initiator. It can then send an ip-protocol-41 encapsulated Router Advertisement back to the initiator with the following addresses: - in the IPv6 destination address, the IPv6 source address from the Router Solicitation - in the IPv6 source address, an ISATAP link-local address ([ISATAP], section 6) formed from an IPv4 address from the underlying interface - in the IPv4 source address, the same IPv4 address as above Templin, et al. Expires December 30, 2004 [Page 6] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 - in the IPv4 destination address, the IPv4 address received in the Source Link Layer Address Option The encapsulated Router Advertisement should include as many of the target's IPv6 addresses as possible in Route Information Options [DEFLT]. When it receives a Router Advertisement, the initiator can verify that the IPv6 addresses in Route Information Options sent by the target (or, and RPBS in the target's enterprise) match the IPv6 addresses received in AAAA records returned by the name service as a means of authenticating the target. The ISATAP node can then add IPv6 routes with the IPv6 link local address from the Router Advertisement's IPv6 source address 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]. 7. Header Compression After the ISATAP node selects the IPv6 source and destination addresses for communication with the target peer and sends the initial ip-protocol-41 packets of the session, any RPBSs in the path should have flow state information established as described in section 4 (assuming the application assigns a non-zero value for the flow label). The ISATAP node can then invoke header compression by truncating the headers of the ip-protocol-41 packets it sends for the flow to include only the first four octets of the IPv6 inner header following the IPv4 outer header. It should also write a value other than 6 (e.g., 0) in the version field in the first four bits of the IPv6 inner header to inform the peer that the header is compressed. If the ISATAP node determines that flow state in some RPBSs along the path may be lost, it can send full IPv6 headers in ip-protocol-41 packets (i.e., with the version field set to 6) for a short time to refresh the flow state before resuming header compression. Templin, et al. Expires December 30, 2004 [Page 7] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 8. Error Handling ISATAP nodes may receive ICMPv4 messages reporting errors for the ip-protocol-41 packets they send. These error messages consist of an outer IPv4 header with the IPv4 source address of the node (or enterprise/site border RPBS) reporting the error, an inner IPv4 header from the packet-in-error with the IPv4 source address of the ISATAP node itself, and at least the first 8 bytes of the encapsulated IPv6 packet. If the ISATAP node maintains a small per-flow queue of recently-sent ip-protocol-41 packets (or packet headers), it can use the IPv4 id field and the IPv6 flow_label field from the packet-in-error to identify the original IPv6 packet in the per-flow queue for use in translating the ICMPv4 error message to an ICMPv6 message [RFC2765]. This implies that error translation state lifetime is bounded by the time it takes for the 16-bit IPv4 id field to wrap, which requires only a 50 Mbps stream of 100 byte packets to wrap the field in 1 second. 9. Native IPv6 vs IPv6-in-IPv4 Encapsulation IPv6 nodes that connect to the same physical L2 media segment can use native IPv6 (i.e., without IPv4 encapsulation) directly over the L2 media. Attachment to the same physical L2 media segment can be detected based on passive message snooping or on whether/not a neighbor responds to native IPv6 neighbor discovery messages sent over the L2 media. Arbitrarily complex IPv6-only networks with many native IPv6 nodes that have an ISATAP node as their IPv6 access router can interfere with the ISATAP node's ability to perform effective ICMPv4-to-ICMPv6 error translation due to the IPv4 id wraparound issue and the potential for flow state explosion. For this reason, further research, additional mechanisms, and/or careful planning may be necessary to support future growth of IPv6-only networks. To normalize 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, ISATAP nodes should use IPv4 as the common encapsulation layer for sending IPv6 packets to neighbors that do not attach to the same physical L2 media segment. ISATAP nodes should use simple ip-protocol-41 encapsulation whenever possible, since it provides sufficient functionality for sending packets to IPv6 neighbors attached to the same virtual link. When legacy NAT boxes that do not support the simple enhancements Templin, et al. Expires December 30, 2004 [Page 8] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 described in this document are in the path, nodes should instead use explicit NAT traversal mechanisms (e.g., [TEREDO]). 10. Mobility In the scenario described in this document, nodes can use the features of Mobile IPv6 [RFC3775] to support movement to different IPv6 subnets within the home enterprise or foreign enterprises. The Mobile IPv6 home agent function can be deployed on RPBSs to support mobile nodes that move to different IPv6 subnets. 11. MTU and Fragmentation An ISATAP node's ip-protocol-41 network driver can set the Don't Fragment (DF) bit in the IPv4 headers of packet it encapsulates and use the mechanism described in section 8 to ensure that ICMPv4 "Fragmentation Needed" messages [RFC1191] are properly translated into ICMPv6 "Packet Too Big" messages [RFC1981]. Due to well-known issues with path MTU discovery [RFC2923], however, some applications may realize better performance by either only sending IPv6 packets that are no larger than 1280bytes or by operationally disabling path MTU discovery by having the IPv6 layer fragment large packets to the minimum IPv6 MTU of 1280bytes ([RFC3542], section 11). Even so, IPv6 packets/fragments encapsulated by the ip-protocol-41 network driver that are no larger than 1280 bytes may still require host-based IPv4 fragmentation, e.g., when an underlying link has a small IPv4 MTU [BCP48]. While this host-based fragmentation is not considered harmful, unmitigated IPv4 fragmentation caused by the network can cause poor performance [FRAG]. For example, since the minimum IPv4 fragment size is only 8 bytes, network middleboxes could shred a single 1280 byte encapsulated packet into as many as 160 IPv4 fragments with obvious negative performance implications. When a node experiences poor performance related to excessive network-based IPv4 fragmentation along a path, it can reduce the size of the tunneled packets it sends until a size that yields improved performance is found. A lower bound of 68 bytes is used in this packet size determination, since every Internet module must be able to forward 68 byte datagrams without further IPv4 fragmentation. Appendix A provides informative text on the derivation of the 1280 byte IPv6 minimum MTU. Appendix B provides informative text on an optional IPv4 reassembly cache management procedure that decapsulators can use to improve efficiency. Templin, et al. Expires December 30, 2004 [Page 9] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 12. 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]. 13. Acknowledgments This document represents the author's best effort to anticipate, interpret and document 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, 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. The size was chosen to allow extra room for link layer encapsulations without exceeding the Ethernet MTU of 1500 bytes, i.e., the practical physical cell size of the Internet. The 1280 byte MTU also provides a fixed upper bound for the size of IPv6 packets/fragments with a maximum store-and-forward delay budget of ~1 second assuming worst case link speeds of ~10Kbps [BCP48], thus providing a convenient value for use in reassembly buffer timer settings. Finally, the 1280 byte MTU allows transport connections (e.g., TCP) to configure a large-enough maximum segment size for improved performance even if the IPv4 interface that will send the tunneled packets uses a smaller MTU. Templin, et al. Expires December 30, 2004 [Page 10] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 Appendix B. Optional IPv4 Reassembly Cache Management Procedure Decapsulating ISATAP nodes can provide greater efficiency for tunnels that incur excessive network-based IPv4 fragmentation by implementing a simple IPv4 reassembly cache management procedure. When the initial fragment of an encapsulated packet arrives, the packet's IPv4 reassembly timer is set to 1 second (i.e., the worst case store and forward delay budget for a 1280 byte packet). If an encapsulated packet's IPv4 reassembly timer expires: - If enough contiguous leading bytes of the packet have arrived (e.g., see: [UDPLITE]), reassemble the packet using zero-filled or heuristically-chosen replacement data bytes in place of any missing fragments. (Otherwise, garbage-collect the reassembly buffer and return from processing.) - Mark the packet as "INCOMPLETE", and also mark it with an "ACTUAL_BYTES" length that encodes the actual number of data bytes in fragments that arrived. - Deliver the packet to the ip-protocol-41 network driver, and do not send an ICMPv4 "time exceeded" message. When the ip-protocol-41 network driver processes this "INCOMPLETE" packet, it can send a message (e.g., an IPv6 Router Advertisement with an MTU option) to inform the far end of the tunnel that network-based IPv4 fragmentation may be causing poor performance along the path. The "INCOMPLETE" packet can also be forwarded to the final destination since some applications might realize greater efficiency by accepting partial information and requesting selective retransmission of missing portions, e.g., when [UDPLITE] is used. Normative References [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. 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. Templin, et al. Expires December 30, 2004 [Page 11] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 [STD3] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [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. [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. [RFC2529] Carpenter, B., and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [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. Templin, et al. Expires December 30, 2004 [Page 12] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 [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. [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. [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. [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. Templin, et al. Expires December 30, 2004 [Page 13] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 [FRAG] Mogul, J. and C. Kent, "Fragmentation Considered Harmful", In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August 1987. [LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", draft-ietf-dnsext-mdns, Work in Progress, June 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. [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B. and P. Nikander, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ndopt, Work in Progress, April 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. [UDPLITE] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The UDP-Lite Protocol", draft-ietf-tsvwg-udp-lite, Work in Progress, August 2003. [UNIQUE] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr, Work in Progress, January 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 December 30, 2004 [Page 14] Internet-Draft IPv6 Addressing in the IPv4 Internet April 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in RFC XXXX and except as set forth therein, the authors retain all their rights. 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. Intellectual Property 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 RFC XXXX and RFC XXXY. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Templin, et al. Expires December 30, 2004 [Page 15]