Network Working Group F. Templin Internet-Draft Nokia Expires: February 15, 2005 August 15, 2004 IPv6 Addressing in the IPv4 Internet draft-templin-v6v4inet-02.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 February 15, 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 February 15, 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 behind Network Address Translators (NATs) [RFC1918][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 using basic IPv6-in-IPv4 encapsulation (i.e., "ISATAP encapsulation") and an intra-site 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 advanced 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 IPv4 network span over which packets can be forwarded from an IPv6 sender toward a particular 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, enterprise network entities have direct connection to the global IPv4 Internet and comprise 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 February 15, 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 IPv4 packet created via IPVLX encapsulation. IPVLX encapsulation: a method of encapsulating a segment of an IPv6 packet/fragment in an outer IPv4 header (described in section 4). IPVLX link adaptation: a method for segmenting an IPv6 packet/fragment into a chain of IPVLX packets (described in section 5) during encapsulation for later reassembly during decapsulation, e.g., to satisfy path MTU restrictions, etc. IPVLX interface: an interface that performs IPVLX encapsulation and link adaptation, but otherwise behaves the same as an ISATAP interface. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [BCP14]. 3. Autoconfiguration RPBSs should automatically discover 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 supporting services (e.g., DHCPv4 [RFC2131], DHCPv6 [RFC3315][RFC3633][RFC3736], Mobile IPv6 Home Agent [RFC3775], etc.) and advertise the 6to4 Relay anycast prefix ([RFC3068], section 2.3) for their associated hosts. Associated hosts can act as site border RPBSs for their own associated hosts to enable recursively-nested "sites within sites", with scaling properties limited only by enterprise/site addressing plans. Templin, et al. Expires February 15, 2005 [Page 3] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 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 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 act as IPv4 NATs for the packets they forward between sites. A new form of IPv6-in-IPv4 packet encapsulation (i.e., "IPVLX encapsulation") 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. Referring to ([RFC0791], Section 3.1), when an RPBS encapsulates an IPVLX packet it sets the IPv4 header "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 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. Setting the RF bit allows RPBSs to distinguish IPVLX packets from ordinary ip-protocol-41 packets. When an RPBS sends/forwards/receives 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 are initialized by the first hop RPBS and (possibly) modified by intermediate RPBSs on the path. The VCI/VPI values along with the packet's IPv4 source and destination addresses (which provide logical input/output interfaces) identify a virtual circuit (VC) that represents the (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple for the encapsulated IPv6 flow. Templin, et al. Expires February 15, 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/fragments of 1280 bytes or smaller to any neighbor on the link without returning an ICMPv6 "Packet too Big" error [RFC1981] to the source. (IPVLX interfaces must also avoid unnecessary fragmentation in the IPv4 Internet [FRAG]). IPVLX interfaces must therefore implement a link adaptation layer similar to ATM Adaptation Layer 5 (AAL5) [RFC2684] to segment each IPv6 packet/fragment 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 and all fields of the CPCS-PDU Trailer other than the 4-octet CRC are omitted. IPVLX link adaptation uses the CPCS-PDU Payload format for VC multiplexing of routed protocols ([RFC2684], section 6.1); the CRC is calculated across all payload bytes exactly as for AAL5. IPVLX interfaces use a default segment size (i.e., "SEGSIZE") of 48 bytes for IPVLX link adaptation to segment IPv6 packets/fragments into chains of IPVLX packets that comprise a 20 byte IPv4 header followed by a segment of the original packet no larger than 48 bytes. IPVLX interfaces can use a larger SEGSIZE, but in that case must use reliable mechanisms (e.g., out-of-band probing, etc.) to avoid ICMPv4 "fragmentation needed" messages [RFC1191] and/or path MTU-related black holes [RFC2923]. IPVLX interfaces can use a smaller SEGSIZE, but the size must be large enough to both satisfy the 1280 byte IPv6 minimum MTU and avoid poor performance. IPVLX link adaptation uses the five low order bits from the 13-bit IPv4 "Fragmentation Offset" field (see: section 4) to encode a monotonically increasing segment ID (i.e., "SEGID") between 0 - 31 in consecutive IPVLX packets of 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. IPVLX link adaptation splits an IPv6 packet/fragment (including the IPv6 header and all data bytes) into blocks of SEGSIZE bytes and encapsulates them in sequential order in a chain of no more than 32 IPVLX packets; all packets in the chain except the final one must be of equal length. (The final packet may be smaller than the other packets in the chain, but it must not be larger.) The trailing CRC is encoded as the final 4 data bytes in the chain in network byte order with no natural boundary alignment restrictions. The IPVLX packets in a chain are sent over the wire in sequential SEGID order, i.e., segment 0 first, followed by segment 1, etc. Templin, et al. Expires February 15, 2005 [Page 5] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 The Length, SEGID, MF and VC-related fields in the IPv4 headers of a chain of IPVLX packets provide sufficient information for reassembly with protection for minor packet reordering in the IPv4 network. The equal length restriction for non-final IPVLX packets provides a fixed hole size for reassembly algorithms [RFC0815]. The last hop RPBS performs CRC verification as the final step in reassembly to identify and discard IPVLX packet chains with data corruption. (Other reassembly algorithm details are FFS). IPv6 endpoints can use host-based IPv6 fragmentation (e.g., by setting the "USE_MINIMUM_MTU" socket option [RFC3542]) to avoid ICMPv6 "packet too big" messages. Since IPVLX packet chain reassembly provides a 4 byte CRC, IPv6 reassembly implementations can provide improved robustness and efficiency (e.g., for applications that use UDP-Lite [RFC3828]) by replacing any missing IPv6 fragments with replicated data from IPv6 fragments received in valid IPVLX packet chains rather than discarding the entire packet. The use of IPVLX link adaptation may lead to an overall increase in short chains of small packets in the Internet. Network administrators are advised to follow the recommendations in [BCP48] to minimize packet loss and packet reordering. Network middleboxes that forward IPVLX packet chains can reassemble and re-segment chains into different-sized IPVLX packets if they have sufficient storage/processing resources to avoid packet loss and can avoid path MTU black holes (see: section 7). 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 IPv4 NAT traversal as follows: Templin, et al. Expires February 15, 2005 [Page 6] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 6.1 From the First Hop RPBS to the Target's Enterprise/Site Border When an intermediate RPBS along the path from the first hop to the target's enterprise/site border receives an IPVLX packet for an unknown VC, it creates a new VC cache entry (managed as for IPv6 flow state [RFC3697]). When it forwards the packet into a topologically disjoint IPv4 addressing region, the RPBS also rewrites the IPv4 source address to the address of the IPv4 interface that will forward the packet and rewrites VCI/VPI to a unique value for the new IPv4 source and original IPv4 destination addresses. (The IPv4 destination address is not rewritten, since it already provides the topologically-correct address necessary to direct the packet toward the target enterprise.) Intermediate RPBS VC cache entries store mappings from: (VCI(in), VPI(in), IPv4_src(in), IPv4_dst(in)) to: (VCI(out), VPI(out), IPv4_src(out), IPv4_dst(out)) to support NAT traversal during a flow's lifetime. The first hop RPBS also caches a (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple to identify a flow's endpoints. 6.2. From the Target's Enterprise/Site Border to the Last-Hop RPBS For IPVLX packets entering an enterprise/site (and, for authentic 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 intermediate RPBS along the path from the enterprise/site border to the last hop RPBS before the target receives an IPVLX packet for an unknown VC, it creates a new VC cache entry (managed as for IPv6 flow state [RFC3697]). When it forwards the packet into a topologically disjoint IPv4 addressing region, the RPBS also rewrites the IPv4 destination address to the IPv4 address of the next hop RPBS, rewrites the IPv4 source address to the address of the IPv4 interface that will forward the packet, and rewrites VCI/VPI to a unique value for the new IPv4 source and destination addresses. Intermediate RPBS VC cache entries store mappings from: (VCI(in), VPI(in), IPv4_src(in), IPv4_dst(in)) to: (VCI(out), VPI(out), Templin, et al. Expires February 15, 2005 [Page 7] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 IPv4_src(out), IPv4_dst(out)) to support NAT traversal during a flow's lifetime. The last hop RPBS also caches a (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple to identify a flow's endpoints. 7. Error Handling RPBSs may receive authentic ICMPv4 messages that comprise an outer IPv4 header with the IPv4 source address of the node reporting the error, an inner IPv4 header from the IPVLX packet-in-error, and at least the first 8 bytes of the encapsulated IPv6 packet segment. When a first hop RPBS receives an authentic ICMPv4 message, it can use the VC information encoded in the IPv4 header from the packet-in- error to locate an (IPv6 src, IPv6 dst, IPv6 flow_label)-tuple in its VC cache for ICMPv6 error message translation [RFC2765]. When an intermediate RPBS receives an authentic ICMPv4 message, it can forward the message to the previous hop RPBS based on its VC cache. RPBSs can keep per-VC queues of recently-sent IPVLX packet chains with packets larger than 68 bytes for re-segmentation and retransmission when an authentic ICMPv4 "fragmentation needed" message is received, but this may not be possible for some intermediate RPBSs due to storage and/or processing limitations. RPBSs should discard (and may process as soft errors) any ICMPv4 messages that cannot be authenticated. In particular, RPBSs should not implement the per-VC queuing method described above for any VC for which ICMPv4 "fragmentation needed" messages that cannot be authenticated may occur. 8. Header Compression After the first hop 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 first hop RPBS can then use IPv6 header compression for subsequent packets sent over the same VC [RFC2507][RFC3095]. Templin, et al. Expires February 15, 2005 [Page 8] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 9. Discovering a Parent RPBS for the Site During IPv4 address autoconfiguration, RPBSs that do not connect directly to the global IPv4 Internet should discover an IPv4 address for a parent RPBS via, e.g., resolving a Fully-Qualified Domain Name (FQDN) in the site's name service (e.g., [LLMNR]), receiving a DHCPv4 option, etc. RPBSs may instead use the 6to4 Relay anycast address ([RFC3068], section 2.4) when no other mechanisms are available or when the overhead for using other mechanisms is unacceptable. Following IPv4 address discovery, RPBSs should next send IPVLX encapsulated (*) Router Solicitation messages to verify that the parent RPBS is up and to receive IPv6 autoconfiguration parameters. The Router Solicitation messages should use the following addresses: - in the IPv6 source address, a link-local address (preferably a link-local [CGA] address) - in the IPv6 destination address, a link-local ISATAP address ([ISATAP], section 6.2]) that embeds an IPv4 address for a parent RPBS - in the IPv4 source address, the IPv4 address from the underlying IPv4 interface that will send the encapsulated Router Solicitations - in the IPv4 destination address, the IPv4 address embedded in the IPv6 destination address When a [CGA] source address is used, the Router Solicitation should include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof- of-ownership verification. When the parent RPBS receives the Router Solicitation, it can 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 received in the Router Solicitation - in the IPv4 source address, an equivalent IPv4 unicast address ([RFC3068], section 2.6) - in the IPv4 destination address, the IPv4 source address received in the Router Solicitation Templin, et al. Expires February 15, 2005 [Page 9] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 When a [CGA] source address is used, the Router Advertisement should include SEcure Neighbor Discovery [SEND] parameters for [CGA] proof- of-ownership verification. The Router Advertisement should also include a SLLAO with an embedded global IPv4 unicast address ([RFC2529], section 5) associated with an enterprise border RPBS for the site, i.e., a 6to4 router [RFC3056] for the enterprise. (*) If the RPBS does not receive a Router Advertisement in response to IPVLX encapsulated Router Solicitations, it should instead send ISATAP encapsulated Router Solicitations [ISATAP]. In that case, link-local ISATAP addresses that embed the corresponding IPv4 addresses should be used in Router Solicitation/Advertisement messages instead of [CGA] addresses. 10. Discovering More-Specific Routes When an IPv6 endpoint initiates communications with a target endpoint, its first hop RPBS resolves the target's Fully-Qualified Domain Name (FQDN) using the DNS [RFC1035] or a name service for the site (e.g., [LLMNR]). If the name service returns a set of AAAA records including one with a 6to4 [RFC3056] address, the first hop RPBS can consider the IPv4 address embedded in the 6to4 prefix as the IPv4 destination address for the target node's enterprise border RPBS. For target nodes located in other sites/enterprises, the 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) [CGA] unicast address for the initiating IPv6 endpoint - 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 address from the underlying IPv4 interface that sends the IPVLX encapsulated Router Solicitation - in the IPv4 destination address, the 6to4-embedded IPv4 address The IPVLX encapsulated IPv6 Router Solicitation should include [SEND] parameters for [CGA] proof-of-ownership verification. Templin, et al. Expires February 15, 2005 [Page 10] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 When the last hop RPBS before the target receives a Router Solicitation, it can perform a reverse name service lookup on the IPv6 source address as a means of authenticating 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 [CGA] link-local 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 sends the IPVLX encapsulated Router Advertisement - in the IPv4 destination address, the IPv4 source address received in the Router Solicitation The IPVLX encapsulated IPv6 Router Advertisement should include a SLLAO with an embedded global IPv4 unicast address ([RFC2529], section 5) associated with an enterprise border RPBS for the target 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 match the IPv6 addresses received in AAAA records returned by the name service as a means of authorizing the target. 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 create IPv6 route cache entries with the link-local ISATAP 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]. The route cache entries should be managed in conjunction with name service cache entries, i.e., they should be deleted when the lifetime for the corresponding name service cache entry expires. Templin, et al. Expires February 15, 2005 [Page 11] 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 and discover 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. IPv6 nodes can use the features of Mobile IPv6 [RFC3775] to support movement to foreign enterprises or 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 native IPv6 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 native IPv6 neighbor discovery messages sent over the L2 media, etc. In many cases, IPv6 neighbors will be attached to different physical L2 media segments. To avoid issues associated with bridging dissimilar media (e.g., path MTU black holes) and to support IPv6 neighbor discovery security mechanisms, RPBSs should use either ISATAP encapsulation or IPVLX encapsulation for sending IPv6 packets to neighbors within the same site and use IPVLX encapsulation for sending IPv6 packets to neighbors in different sites. 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 segment payload for a 68 byte encapsulated packet to only 40 bytes. Templin, et al. Expires February 15, 2005 [Page 12] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 13. Security considerations RPBSs and associated hosts use the securing mechanisms for IPv6 neighbor discovery found in [CGA][SEND] according to the trust model appropriate for the given deployment scenario [RFC3756]. RPBSs and associated hosts use the securing mechanisms for IPv6 nodes found in ([NODEREQ], section 8). 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, Brian Carpenter, Ralph Droms, Alain Durand, Jim Fleming, Tim Gleeson, Jun- ichiro itojun Hagino, Brian Haberman, Bob Hinden, Christian Huitema, Eddie Kohler, Kevin Lahey, 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. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Templin, et al. Expires February 15, 2005 [Page 13] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 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. [STD3] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [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. [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. Templin, et al. Expires February 15, 2005 [Page 14] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [RFC2507] Degermark, M., Nordgren, B. and S. Pin, "IP Header Compression", RFC 2507, February 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. [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. Templin, et al. Expires February 15, 2005 [Page 15] Internet-Draft IPv6 Addressing in the IPv4 Internet July 2004 [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. [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, August 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. Templin, et al. Expires February 15, 2005 [Page 16] Internet-Draft IPv6 Addressing in the IPv4 Internet 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. [NODEREQ] J. Loughney, editor, "IPv6 Node Requirements", draft-ietf- ipv6-node-requirements, Work in Progress, August 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, 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 February 15, 2005 [Page 17] 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 February 15, 2005 [Page 18]