idnits 2.17.1 draft-harrington-ngtrans-v4comp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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 Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 30 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 127 has weird spacing: '...e. Both are...' == Line 187 has weird spacing: '...without being...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10024 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 1933 (Obsoleted by RFC 2893) -- Possible downref: Non-RFC (?) normative reference: ref. 'V6TUNNELS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NGLIST' ** Obsolete normative reference: RFC 1897 (Obsoleted by RFC 2471) -- Possible downref: Non-RFC (?) normative reference: ref. 'V6PROVIDER' -- Possible downref: Non-RFC (?) normative reference: ref. '6BONE' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'RJA' Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Transition Dan Harrington 2 Internet Draft Digital Equipment Corp. 3 Quaizar Vohra 4 University of New Hampshire 5 November 1996 7 Limiting the role of IPv4-compatible Addresses in IPv6 9 draft-harrington-ngtrans-v4comp-00.txt 11 Abstract 13 This draft presents a proposal to limit IPv4-compatible IPv6 14 addresses to tunnelling interfaces in the transition from IPv4 to 15 IPv6. The reasons and context for restricting the usage in this 16 manner will be presented. 18 Status of This Memo 20 This document is a submission to the NGtrans Working Group of the 21 Internet Engineering Task Force (IETF). Comments should be 22 submitted to the ngtrans@sunroof.end.sun.com mailing list. The 23 authors invite discussion and feedback on this topic. 25 This document is an Internet-Draft. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as ``work in 34 progress.'' 36 To learn the current status of any Internet-Draft, please check the 37 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 38 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 40 ftp.isi.edu (US West Coast). 42 Distribution of this document is unlimited. 44 Table Of Contents 46 1. Introduction 3 47 2. Architectural and Philosophical Issues 3 48 3. Isolated Hosts 4 49 3.1. Class 1 Isolated Nodes 4 50 3.2. Class 2 Isolated Nodes 4 51 4. Other Issues 5 52 4.1. Host Issues 5 53 4.2. Router Issues 5 54 5. Acknowledgements 6 55 6. References 6 56 7. Author's Addresses 6 58 1. Introduction 60 IPv4-compatible addresses are designed to ease the transition of 61 IPv4 to IPv6, by utilizing the readily available IPv4 address space 62 and protocols to provide IPv6 connectivity. They currently serve 63 two roles, both related to tunnelling: 65 - To allow isolated IPv6 nodes to come up on the Internet 66 and communicate with other IPv6 nodes via automatic tunneling, 67 which requires a minimal amount of configuration. 69 - Identifying an IPv6 router's next-hop interface address over 70 a manually configured tunnel. 72 These tasks both require implementations to treat an IPv4 tunnel as 73 a pseudo-NBMA link, where ::/96 is treated as an on-link IPv6 prefix 74 for the tunnel interface. In this model, all IPv4-compatible 75 addresses are on-link to the tunnel interface and the IPv4 Internet 76 forms one large link layer, in which address resolution is a trivial 77 function. Manually configured tunnels are used with static routes to 78 IPv6 prefixes, where the next-hop is an IPv4-compatible address on 79 the link. While this link type does not use the standard link-local 80 prefix of FE80:: or Neighbor Discovery protocols, it does have its 81 own characteristics and rules [V6TUNNELS]. Conceptually, then, it 82 can be seen that IPv6 packets using IPv4-compatible addresses could 83 be treated as using a special type of link-local address, and the 84 Hop Limit could be set to a value of 1 with no dire consequences. 86 The current Transition Mechanisms specification [RFC1933], however, 87 also include a provision to allow an IPv4-compatible address to be 88 assigned to an interface for native IPv6 communications, with all 89 the requirements of Neighbor Discovery. It is this usage which we 90 wish to prohibit, for the sake of reduced complexity and increased 91 interoperability. 93 2. Architectural and Philosophical Issues 95 Although IPv4 and IPv6 represent different network protocols, IPv4 96 addresses can be represented as IPv6 addresses. However, they still 97 define an IPv4 endpoint, that is, an interface on a link connected 98 to an IPv4 network, using IPv4 protocols. Using them in multiple 99 fashions, for both IPv4 and IPv6 packets on a given interface as 100 well as for tunnelling, can and will lead to interoperability 101 problems, as has been reported on the NGTRANS mailing list [NGLIST]. 102 This dual usage also leads to unnecessary implementation complexity; 103 for example, the source address selection algorithm should not 104 permit the use of an IPv4-compatible address (as source or 105 destination) with a global IPv6 address (as destination or source). 107 As mentioned above, the encapsulation of IPv6 packets in IPv4 108 packets essentially uses the IPv4 network as a specialized media 109 type. The "Generic Packet Tunneling in IPv6" [V6TUNNELS] 110 specification gives the mechanism by which one protocol may be run 111 over another. In keeping with the general IP philosophy of an 112 address being associated with a particular interface [RFC1122], it 113 should be held that a tunnel interface is not merely an abstraction, 114 but a "real" interface to a specific media type, with its own rules 115 and behaviours. 117 Finally, restricting the usage of IPv4-compatible addresses will 118 simplify the definition, implementation, and usage of this address 119 form, and smooth the IPv4 to IPv6 transition. Simple, clear 120 definitions are easy to explain; special cases and asterisks are 121 not. If IPv6 is to be widely accepted and deployed, the training 122 and educational aspects of the architecture must not be ignored. 124 3. Isolated Hosts 126 Two interpretations of the term "Isolated Host" have been proposed 127 in the course of discussing IPv4-compatible address usage. Both are 128 presented below, and hopefully these definitions can be clarified, 129 and consensus reached, through further discussion. 131 3.1. Class 1 Isolated Nodes 133 The first interpretation of an isolated host is a host which does 134 not have an on-link IPv6 router, and which thus must encapsulate all 135 packets to off-link destinations. But this node is connected to an 136 IPv6-capable Internet Service Provider (ISP) and thus has a provider 137 based IPv6 address [RFC1897][V6PROVIDER], which we will refer to as 138 PBA. This PBA is assigned to the tunnel interface and is used as 139 source address in outgoing packets. The node has a manually 140 configured tunnel to an ISP router. This PBA is based upon the ISP's 141 prefix and the IPV4 address of the IPv4 interface through which the 142 encapsulated packets get forwarded to the ISP. Note that the 143 IPv4-compatible might be usable as the link-local address in a 144 routing protocol, but this is yet to be determined. 146 So this isolated node has global IPv6 connectivity via the ISP. This 147 isolated node has a default IPv6 route (::/0) with the ISP router as 148 next-hop, which may be identifed by an IPv4-compatible address. 149 Examples of this class of isolated node can be found on the current 150 6-bone. [6BONE] 152 3.2. Class 2 Isolated Nodes 154 The second form of isolated nodes are those nodes which are not 155 connected to an IPv6-capable ISP, i.e. they don't have a PBA. All 156 they have is an IPv4-compatible address and they communicate with 157 other IPv6 nodes which have IPv4-compatible addresses using 158 end-to-end automatic tunneling. This requires that the destination 159 node also has an IPv4-compatible address, and implies that the 160 packet will make a single hop (i.e. the IPv6 packet will not be 161 forwarded). 163 In the evolution of the 6bone, the second class of host is not 164 represented. It remains to be seen how common this type of host 165 will be as IPv6 is deployed commercially. For these nodes to 166 communicate with other IPv6 nodes on the Internet, the remote IPv6 167 system must have automatic tunneling enabled on every IPv6 node on 168 the Internet. At some point in transition, when the IPv4 address 169 space is exhausted, new IPv6 nodes will not be able to get 170 IPv4-compatible addresses to do automatic tunneling. These nodes 171 will only have PBAs and would not be able to communicate with class 172 2 isolated nodes. So while this class of system represents a simple 173 configuration, it can be seen that from the beginning these nodes 174 may only be able to communicate with a subset of the IPv6 network, 175 and the percentage of unreachable hosts will likely increase over 176 time. Also, the extensive use of IPv4-compatible addresses for 177 communications between IPv6 systems will exercise the IPv4 routing 178 infrastructure, without promoting the use of IPv6 hierarchical 179 routing, thereby taxing an overburdened service without any gain in 180 operational experience in the new technology. 182 4. Other Issues 184 One important issue is whether IPv4-compatible addresses should be 185 assigned to all physical interfaces having IPv4 addresses. We 186 believe that this is not a good idea as it creates several problems 187 without being a solution for any existing problem. There are other 188 issues to consider as well. 190 Another disadvantage is that IPv4-compatible addresses will have to 191 be treated specially in name services like DNS and DHCP, with 192 duplication of data and potential operational confusion resulting. 194 4.1. Host Issues 196 Hosts may have to deal with multiple mechanisms for obtaining 197 addresses, and support dual address lifetime (or lease) constructs. 198 While DHCP is commonly used to obtain IPv4 addresses, DHCPv6 does 199 not support the assignment of IPv4-compatible addresses, and thus 200 the server will not recognize such addresses as belonging to any 201 given client. [DHCPv6] 203 Also, assigning an IPv4-compatible address to the interface on which 204 IPv4 is running may not be generally possible. For example, an IPv4 205 host using SLIP could support an IPv6 implementation using 206 tunnelling, but not a native interface. There may be other examples 207 of media types which support one protocol but not the other. 209 4.2. Router Issues 211 In addition to the issues presented above, which focus largely on 212 the impact to IPv6 hosts, there are various concerns related to dual 213 IPv6/IPv4 routers. In the current RFC 1933 model, dual protocol 214 routers at the borders of IPv6 islands may be called upon to perform 215 routing of packets using IPv4-compatible source and destination 216 addresses. There are several reasons why this is not a good idea: 218 - While encapsulation of IPv6 packets in IPv4 tunnels will be a 219 necessary function of dual IPv4/IPv6 routers, it would be best 220 to reduce the need for this function by having the originating 221 host use automatic tunnelling. 223 - The routers may have greater memory requirements than otherwise. 224 See the draft "IPv6 Routing Table Issues" [RJA] for details. 226 5. Acknowledgements 228 The authors wish to thank Pedro Roque, Jim Bound, Ran Atkinson, Bill 229 Lenharth and Matt Thomas for their input and consideration, as well 230 as the growing community of IPv6 developers. 232 6. References 234 [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for 235 IPv6 Hosts and Routers", RFC 1933, April 1996. 237 [V6TUNNELS] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6", 238 , Work in Progress, 239 October 1996. 241 [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication 242 Layers", RFC 1122, October 1989. 244 [NGLIST] Interoperability problem described on ngtrans mailing 245 list, Wednesday March 13, 1996. 247 [RFC1897] R. Hinden, "IPv6 Testing Address Allocation", RFC 1897, 248 January 1996. 250 [V6PROVIDER] Y. Rekhter et al, "An IPv6 Provider-Based Unicast Address 251 Format", , 252 Work in Progress, March 1996. 254 [6BONE] http://www-cnr.lbl.gov/6bone 256 [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol 257 for IPv6 (DHCPv6)", , 258 Work in Progress, August 1996. 260 [RJA] R. Atkinson, "IPv6 Routing Table Size Issues", 261 , Work in 262 Progress, October 1996. 264 7. Author's Addresses 266 Dan Harrington 267 P.O. Box 81W 268 W. Townsend, MA 270 Quaizar Vohra 271 Interoperability Lab 272 7 Leavitt Lane 273 University of New Hampshire 274 Durham, NH 03824 275 qv@iol.unh.edu