IPng Transition Dan Harrington Internet Draft Digital Equipment Corp. Quaizar Vohra University of New Hampshire November 1996 Limiting the role of IPv4-compatible Addresses in IPv6 draft-harrington-ngtrans-v4comp-00.txt Abstract This draft presents a proposal to limit IPv4-compatible IPv6 addresses to tunnelling interfaces in the transition from IPv4 to IPv6. The reasons and context for restricting the usage in this manner will be presented. Status of This Memo This document is a submission to the NGtrans Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ngtrans@sunroof.end.sun.com mailing list. The authors invite discussion and feedback on this topic. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Table Of Contents 1. Introduction 3 2. Architectural and Philosophical Issues 3 3. Isolated Hosts 4 3.1. Class 1 Isolated Nodes 4 3.2. Class 2 Isolated Nodes 4 4. Other Issues 5 4.1. Host Issues 5 Expires May 1997 [Page 1] Internet Draft IPv4-compatible Addresses November 1996 4.2. Router Issues 5 5. Acknowledgements 6 6. References 6 7. Author's Addresses 6 Expires May 1997 [Page 2] Internet Draft IPv4-compatible Addresses November 1996 1. Introduction IPv4-compatible addresses are designed to ease the transition of IPv4 to IPv6, by utilizing the readily available IPv4 address space and protocols to provide IPv6 connectivity. They currently serve two roles, both related to tunnelling: - To allow isolated IPv6 nodes to come up on the Internet and communicate with other IPv6 nodes via automatic tunneling, which requires a minimal amount of configuration. - Identifying an IPv6 router's next-hop interface address over a manually configured tunnel. These tasks both require implementations to treat an IPv4 tunnel as a pseudo-NBMA link, where ::/96 is treated as an on-link IPv6 prefix for the tunnel interface. In this model, all IPv4-compatible addresses are on-link to the tunnel interface and the IPv4 Internet forms one large link layer, in which address resolution is a trivial function. Manually configured tunnels are used with static routes to IPv6 prefixes, where the next-hop is an IPv4-compatible address on the link. While this link type does not use the standard link-local prefix of FE80:: or Neighbor Discovery protocols, it does have its own characteristics and rules [V6TUNNELS]. Conceptually, then, it can be seen that IPv6 packets using IPv4-compatible addresses could be treated as using a special type of link-local address, and the Hop Limit could be set to a value of 1 with no dire consequences. The current Transition Mechanisms specification [RFC1933], however, also include a provision to allow an IPv4-compatible address to be assigned to an interface for native IPv6 communications, with all the requirements of Neighbor Discovery. It is this usage which we wish to prohibit, for the sake of reduced complexity and increased interoperability. 2. Architectural and Philosophical Issues Although IPv4 and IPv6 represent different network protocols, IPv4 addresses can be represented as IPv6 addresses. However, they still define an IPv4 endpoint, that is, an interface on a link connected to an IPv4 network, using IPv4 protocols. Using them in multiple fashions, for both IPv4 and IPv6 packets on a given interface as well as for tunnelling, can and will lead to interoperability problems, as has been reported on the NGTRANS mailing list [NGLIST]. This dual usage also leads to unnecessary implementation complexity; for example, the source address selection algorithm should not permit the use of an IPv4-compatible address (as source or destination) with a global IPv6 address (as destination or source). As mentioned above, the encapsulation of IPv6 packets in IPv4 packets essentially uses the IPv4 network as a specialized media type. The "Generic Packet Tunneling in IPv6" [V6TUNNELS] specification gives the mechanism by which one protocol may be run over another. In keeping with the general IP philosophy of an Expires May 1997 [Page 3] Internet Draft IPv4-compatible Addresses November 1996 address being associated with a particular interface [RFC1122], it should be held that a tunnel interface is not merely an abstraction, but a "real" interface to a specific media type, with its own rules and behaviours. Finally, restricting the usage of IPv4-compatible addresses will simplify the definition, implementation, and usage of this address form, and smooth the IPv4 to IPv6 transition. Simple, clear definitions are easy to explain; special cases and asterisks are not. If IPv6 is to be widely accepted and deployed, the training and educational aspects of the architecture must not be ignored. 3. Isolated Hosts Two interpretations of the term "Isolated Host" have been proposed in the course of discussing IPv4-compatible address usage. Both are presented below, and hopefully these definitions can be clarified, and consensus reached, through further discussion. 3.1. Class 1 Isolated Nodes The first interpretation of an isolated host is a host which does not have an on-link IPv6 router, and which thus must encapsulate all packets to off-link destinations. But this node is connected to an IPv6-capable Internet Service Provider (ISP) and thus has a provider based IPv6 address [RFC1897][V6PROVIDER], which we will refer to as PBA. This PBA is assigned to the tunnel interface and is used as source address in outgoing packets. The node has a manually configured tunnel to an ISP router. This PBA is based upon the ISP's prefix and the IPV4 address of the IPv4 interface through which the encapsulated packets get forwarded to the ISP. Note that the IPv4-compatible might be usable as the link-local address in a routing protocol, but this is yet to be determined. So this isolated node has global IPv6 connectivity via the ISP. This isolated node has a default IPv6 route (::/0) with the ISP router as next-hop, which may be identifed by an IPv4-compatible address. Examples of this class of isolated node can be found on the current 6-bone. [6BONE] 3.2. Class 2 Isolated Nodes The second form of isolated nodes are those nodes which are not connected to an IPv6-capable ISP, i.e. they don't have a PBA. All they have is an IPv4-compatible address and they communicate with other IPv6 nodes which have IPv4-compatible addresses using end-to-end automatic tunneling. This requires that the destination node also has an IPv4-compatible address, and implies that the packet will make a single hop (i.e. the IPv6 packet will not be forwarded). In the evolution of the 6bone, the second class of host is not represented. It remains to be seen how common this type of host will be as IPv6 is deployed commercially. For these nodes to Expires May 1997 [Page 4] Internet Draft IPv4-compatible Addresses November 1996 communicate with other IPv6 nodes on the Internet, the remote IPv6 system must have automatic tunneling enabled on every IPv6 node on the Internet. At some point in transition, when the IPv4 address space is exhausted, new IPv6 nodes will not be able to get IPv4-compatible addresses to do automatic tunneling. These nodes will only have PBAs and would not be able to communicate with class 2 isolated nodes. So while this class of system represents a simple configuration, it can be seen that from the beginning these nodes may only be able to communicate with a subset of the IPv6 network, and the percentage of unreachable hosts will likely increase over time. Also, the extensive use of IPv4-compatible addresses for communications between IPv6 systems will exercise the IPv4 routing infrastructure, without promoting the use of IPv6 hierarchical routing, thereby taxing an overburdened service without any gain in operational experience in the new technology. 4. Other Issues One important issue is whether IPv4-compatible addresses should be assigned to all physical interfaces having IPv4 addresses. We believe that this is not a good idea as it creates several problems without being a solution for any existing problem. There are other issues to consider as well. Another disadvantage is that IPv4-compatible addresses will have to be treated specially in name services like DNS and DHCP, with duplication of data and potential operational confusion resulting. 4.1. Host Issues Hosts may have to deal with multiple mechanisms for obtaining addresses, and support dual address lifetime (or lease) constructs. While DHCP is commonly used to obtain IPv4 addresses, DHCPv6 does not support the assignment of IPv4-compatible addresses, and thus the server will not recognize such addresses as belonging to any given client. [DHCPv6] Also, assigning an IPv4-compatible address to the interface on which IPv4 is running may not be generally possible. For example, an IPv4 host using SLIP could support an IPv6 implementation using tunnelling, but not a native interface. There may be other examples of media types which support one protocol but not the other. 4.2. Router Issues In addition to the issues presented above, which focus largely on the impact to IPv6 hosts, there are various concerns related to dual IPv6/IPv4 routers. In the current RFC 1933 model, dual protocol routers at the borders of IPv6 islands may be called upon to perform routing of packets using IPv4-compatible source and destination addresses. There are several reasons why this is not a good idea: - While encapsulation of IPv6 packets in IPv4 tunnels will be a necessary function of dual IPv4/IPv6 routers, it would be best Expires May 1997 [Page 5] Internet Draft IPv4-compatible Addresses November 1996 to reduce the need for this function by having the originating host use automatic tunnelling. - The routers may have greater memory requirements than otherwise. See the draft "IPv6 Routing Table Issues" [RJA] for details. 5. Acknowledgements The authors wish to thank Pedro Roque, Jim Bound, Ran Atkinson, Bill Lenharth and Matt Thomas for their input and consideration, as well as the growing community of IPv6 developers. 6. References [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [V6TUNNELS] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6", , Work in Progress, October 1996. [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication Layers", RFC 1122, October 1989. [NGLIST] Interoperability problem described on ngtrans mailing list, Wednesday March 13, 1996. [RFC1897] R. Hinden, "IPv6 Testing Address Allocation", RFC 1897, January 1996. [V6PROVIDER] Y. Rekhter et al, "An IPv6 Provider-Based Unicast Address Format", , Work in Progress, March 1996. [6BONE] http://www-cnr.lbl.gov/6bone [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", , Work in Progress, August 1996. [RJA] R. Atkinson, "IPv6 Routing Table Size Issues", , Work in Progress, October 1996. 7. Author's Addresses Dan Harrington P.O. Box 81W W. Townsend, MA Quaizar Vohra Interoperability Lab 7 Leavitt Lane Expires May 1997 [Page 6] Internet Draft IPv4-compatible Addresses November 1996 University of New Hampshire Durham, NH 03824 qv@iol.unh.edu Expires May 1997 [Page 7]