idnits 2.17.00 (12 Aug 2021) /tmp/idnits13238/draft-thaler-6man-unique-v4mapped-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2010) is 4458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3493 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Expires: September 1, 2010 February 28, 2010 6 Unique IPv4-Mapped Addresses 7 draft-thaler-6man-unique-v4mapped-00.txt 9 Abstract 11 This document proposes an IPv6 address format for uniquely 12 identifying IPv4 destinations. Today the IPv4-mapped format, when 13 used with private IPv4 addresses, does not provide this capability. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 1, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Address Format . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 5.2. Informative References . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The use of non-global ([RFC1918], [RFC3927]) IPv4 addresses presents 67 some problems for multihomed nodes, when attached to two networks 68 using the same address space. Typically, the impact is that 69 applications can only talk to destinations on one of the two 70 networks. The issue is that the address alone is ambiguous, and 71 typical application APIs do not provide a mechanism to distinguish 72 between them. 74 In IPv6, non-global addresses were also introduced in the form of 75 link-local addresses [RFC4291] and unique local addresses [RFC4193] 76 (as well as site-local addresses, which were deprecated in 77 [RFC3879]). To resolve the ambiguity, the basic IPv6 APIs were 78 defined (in [RFC3493]) to include a "scope id" field, where the scope 79 id is defined as a machine-local identifier for a set of interfaces. 81 The IPv6 address architecture [RFC4291] also defines an IPv6 address 82 format known as an IPv4-mapped IPv6 address, for representing the 83 addresses of IPv4 nodes as IPv6 addresses. These addresses were used 84 in the basic IPv6 APIs so that host stacks could let applications use 85 the IPv4 stack under an AF_INET6 socket, by using with addresses in 86 IPv4-mapped format (for more information see [RFC4038]). As such, 87 IPv4-mapped addresses also have a scope id in socket APIs, and in 88 theory this would provide an incentive for applications to use IPv6 89 APIs even when talking to IPv4-only destinations. However, there are 90 still several problems with using IPv6 APIs to disambiguate between 91 IPv4 destinations. 92 1. [RFC3484] section 3.3 specifies that IPv4-mapped addresses should 93 be treated as having global scope for purposes of address 94 selection. As a result, OS's have used a 0 scope id, as with all 95 global addresses per [RFC4007] section 11.2. 96 2. [RFC4007] specifies a textual address syntax with an '%' 97 character to indicate a scope id. However, this character is not 98 legal in an IPv6 literal within a URI (see [RFC3986] section 99 3.2.2). 100 3. Requiring use of a scope id in addition to an address is error 101 prone and confusing to developers and end users. These issues 102 are discussed in more detail in [RFC3879] and led to the 103 deprecation of site-local addresses. 105 2. Address Format 107 Unique local addresses [RFC4193] replaced the concept of a machine- 108 specific scope id value with a 40-bit shared network-specific 109 identifier that was embedded in the address itself. As a result, 110 addresses became unambiguous and were usable without requiring a 111 separate scope id. 113 We propose applying a similar solution for IPv4-mapped addresses. 114 The proposed format of the "Unique IPv4-mapped IPv6 address" is as 115 follows: 117 | 40 bits | 40 bits |16 bits| 32 bits | 118 +-------------------+-------------+-------+---------------------+ 119 | Well-Known Prefix | Global ID | Comp. | IPv4 address | 120 +----------------+--+-------------+-------+---------------------+ 122 Well-Known Prefix: The proposed prefix is 0:0:FF00::/40. The use of 123 a well-known prefix allows hosts and applications to easily detect 124 this type of address, e.g. to distinguish a native address from one 125 involving translation. (It is for this reason that a ULA is not used 126 for this purpose.) This prefix also ensures that the address range 127 cannot conflict with the IPv4-translatable address range defined in 128 [RFC2765] section 2.1 (which is ::ffff:0:a.b.c.d). 130 Global ID: A Global ID as specified in [RFC4193] section 3.2. For 131 hosts with Unique Local Addresses, the Global ID may be the same 132 Global ID as used in the IPv6 unique local addresses on the same 133 network. 135 Comp.: The 1's complement checksum of the first 80 bits of the 136 address, to avoid any changes to the transport protocol's pseudo 137 header checksum. 139 IPv4 address: The IPv4 address appears in the last 32 bits so that 140 dotted-decimal format can be used in the textual representation of an 141 address, as defined in [RFC4291] section 2.2. 143 3. Security Considerations 145 As noted in [RFC4007] section 12, requiring the use of a scope id in 146 addition to an address introduced some security complications. By 147 making an IPv4-mapped address unique, these addresses become more 148 usable in security contexts. 150 4. IANA Considerations 152 The Well-Known Prefix falls into the range ::/8 reserved by the IETF. 153 Hence this document has no actions for IANA. 155 5. References 156 5.1. Normative References 158 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 159 E. Lear, "Address Allocation for Private Internets", 160 BCP 5, RFC 1918, February 1996. 162 [RFC3484] Draves, R., "Default Address Selection for Internet 163 Protocol version 6 (IPv6)", RFC 3484, February 2003. 165 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 166 Stevens, "Basic Socket Interface Extensions for IPv6", 167 RFC 3493, February 2003. 169 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 170 Configuration of IPv4 Link-Local Addresses", RFC 3927, 171 May 2005. 173 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 174 Resource Identifier (URI): Generic Syntax", STD 66, 175 RFC 3986, January 2005. 177 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 178 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 179 March 2005. 181 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 182 Addresses", RFC 4193, October 2005. 184 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 185 Architecture", RFC 4291, February 2006. 187 5.2. Informative References 189 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 190 (SIIT)", RFC 2765, February 2000. 192 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 193 Addresses", RFC 3879, September 2004. 195 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 196 Castro, "Application Aspects of IPv6 Transition", 197 RFC 4038, March 2005. 199 Author's Address 201 Dave Thaler 202 Microsoft 203 One Microsoft Way 204 Redmond, WA 98052 205 USA 207 Phone: +1 425 703 8835 208 Email: dthaler@microsoft.com