Network Working Group D. Thaler Internet-Draft Microsoft Expires: September 1, 2010 February 28, 2010 Unique IPv4-Mapped Addresses draft-thaler-6man-unique-v4mapped-00.txt Abstract This document proposes an IPv6 address format for uniquely identifying IPv4 destinations. Today the IPv4-mapped format, when used with private IPv4 addresses, does not provide this capability. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 September 1, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Thaler Expires September 1, 2010 [Page 1] Internet-Draft Unique IPv4-Mapped Addresses February 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Address Format . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Thaler Expires September 1, 2010 [Page 2] Internet-Draft Unique IPv4-Mapped Addresses February 2010 1. Introduction The use of non-global ([RFC1918], [RFC3927]) IPv4 addresses presents some problems for multihomed nodes, when attached to two networks using the same address space. Typically, the impact is that applications can only talk to destinations on one of the two networks. The issue is that the address alone is ambiguous, and typical application APIs do not provide a mechanism to distinguish between them. In IPv6, non-global addresses were also introduced in the form of link-local addresses [RFC4291] and unique local addresses [RFC4193] (as well as site-local addresses, which were deprecated in [RFC3879]). To resolve the ambiguity, the basic IPv6 APIs were defined (in [RFC3493]) to include a "scope id" field, where the scope id is defined as a machine-local identifier for a set of interfaces. The IPv6 address architecture [RFC4291] also defines an IPv6 address format known as an IPv4-mapped IPv6 address, for representing the addresses of IPv4 nodes as IPv6 addresses. These addresses were used in the basic IPv6 APIs so that host stacks could let applications use the IPv4 stack under an AF_INET6 socket, by using with addresses in IPv4-mapped format (for more information see [RFC4038]). As such, IPv4-mapped addresses also have a scope id in socket APIs, and in theory this would provide an incentive for applications to use IPv6 APIs even when talking to IPv4-only destinations. However, there are still several problems with using IPv6 APIs to disambiguate between IPv4 destinations. 1. [RFC3484] section 3.3 specifies that IPv4-mapped addresses should be treated as having global scope for purposes of address selection. As a result, OS's have used a 0 scope id, as with all global addresses per [RFC4007] section 11.2. 2. [RFC4007] specifies a textual address syntax with an '%' character to indicate a scope id. However, this character is not legal in an IPv6 literal within a URI (see [RFC3986] section 3.2.2). 3. Requiring use of a scope id in addition to an address is error prone and confusing to developers and end users. These issues are discussed in more detail in [RFC3879] and led to the deprecation of site-local addresses. 2. Address Format Unique local addresses [RFC4193] replaced the concept of a machine- specific scope id value with a 40-bit shared network-specific identifier that was embedded in the address itself. As a result, addresses became unambiguous and were usable without requiring a Thaler Expires September 1, 2010 [Page 3] Internet-Draft Unique IPv4-Mapped Addresses February 2010 separate scope id. We propose applying a similar solution for IPv4-mapped addresses. The proposed format of the "Unique IPv4-mapped IPv6 address" is as follows: | 40 bits | 40 bits |16 bits| 32 bits | +-------------------+-------------+-------+---------------------+ | Well-Known Prefix | Global ID | Comp. | IPv4 address | +----------------+--+-------------+-------+---------------------+ Well-Known Prefix: The proposed prefix is 0:0:FF00::/40. The use of a well-known prefix allows hosts and applications to easily detect this type of address, e.g. to distinguish a native address from one involving translation. (It is for this reason that a ULA is not used for this purpose.) This prefix also ensures that the address range cannot conflict with the IPv4-translatable address range defined in [RFC2765] section 2.1 (which is ::ffff:0:a.b.c.d). Global ID: A Global ID as specified in [RFC4193] section 3.2. For hosts with Unique Local Addresses, the Global ID may be the same Global ID as used in the IPv6 unique local addresses on the same network. Comp.: The 1's complement checksum of the first 80 bits of the address, to avoid any changes to the transport protocol's pseudo header checksum. IPv4 address: The IPv4 address appears in the last 32 bits so that dotted-decimal format can be used in the textual representation of an address, as defined in [RFC4291] section 2.2. 3. Security Considerations As noted in [RFC4007] section 12, requiring the use of a scope id in addition to an address introduced some security complications. By making an IPv4-mapped address unique, these addresses become more usable in security contexts. 4. IANA Considerations The Well-Known Prefix falls into the range ::/8 reserved by the IETF. Hence this document has no actions for IANA. 5. References Thaler Expires September 1, 2010 [Page 4] Internet-Draft Unique IPv4-Mapped Addresses February 2010 5.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 5.2. Informative References [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. Thaler Expires September 1, 2010 [Page 5] Internet-Draft Unique IPv4-Mapped Addresses February 2010 Author's Address Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 Email: dthaler@microsoft.com Thaler Expires September 1, 2010 [Page 6]