idnits 2.17.1 draft-ietf-v6ops-clatip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC6333, but the abstract doesn't seem to directly say this. It does mention RFC6333 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2014) is 3550 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) == Missing Reference: 'RFC-to-be-xxx' is mentioned on line 136, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6877 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Cameron Byrne 3 Updates: 6333 (if approved) T-Mobile US 4 Intended Status: Standards Track August 4, 2014 5 Expires: February 5, 2015 7 IPv4 Service Continuity Prefix 8 draft-ietf-v6ops-clatip-04 10 Abstract 12 DS-Lite, defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 13 for the B4 element. This memo directs IANA to generalize that 14 reservation to include other cases where a non-routed IPv4 interface 15 must be numbered as part of an IPv6 transition solution. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2014 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 Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The Case of 464XLAT . . . . . . . . . . . . . . . . . . . . . 3 58 4. Choosing 192.0.0.0/29 . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the Basic 69 Bridging BroadBand (B4) element. This memo generalizes that IANA 70 reservation to include other cases where a non-routed IPv4 interface 71 must be numbered in an IPv6 transition solution. IANA shall list the 72 address block 192.0.0.0/29 reserved for IPv4 Service Continuity 73 Prefix. The result is that 192.0.0.0/29 may be used in any system 74 that requires IPv4 addresses for backward compatibility with IPv4 75 communications in an IPv6-only network, but does not emit IPv4 76 packets "on the wire". 78 This generalization does not impact the use of the IPv4 Service 79 Continuity Prefix in a DS-Lite context. 81 2. Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. The Case of 464XLAT 89 464XLAT [RFC6877] describes an architecture for providing IPv4 90 communication over an IPv6-only access network. One of the methods 91 described in [RFC6877] is for the client side translator (CLAT) to be 92 embedded in the host, such as a smartphone or a CPE (Customer 93 Premises Equipment). In such scenarios, the host must have an IPv4 94 address configured to present to the host network stack and for 95 applications to bind IPv4 sockets. 97 4. Choosing 192.0.0.0/29 99 To avoid conflicts with any other network that may communicate with 100 the CLAT or other IPv6 transition solution, a locally unique IPv4 101 address must be assigned. 103 IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], 104 which is dedicated for DS-Lite. As defined in [RFC6333], this subnet 105 is only present between the B4 and the AFTR and never emits packets 106 from this prefix "on the wire". 464XLAT has the same need for a non- 107 routed IPv4 prefix, and this same need may be common for other 108 similar solutions. It is most prudent and effective to generalize 109 192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6 110 transition technologies rather than reserving a prefix for every 111 possible solution. 113 With this memo, 192.0.0.0/29 is now generalized across multiple IPv4 114 continuity solutions such as 464XLAT and DS-lite. A host MUST NOT 115 enable two active IPv4 continuity solutions simultaneously in a way 116 that would cause a node to have overlapping 192.0.0.0/29 address 117 space. 119 5. Security Considerations 121 No new security considerations beyond what is described [RFC6333] and 122 [RFC6877]. 124 6. IANA Considerations 126 This document requests IANA to update the IPv4 Special-Purpose 127 Address Registry available at (http://www.iana.org/assignments/iana- 128 ipv4-special-registry/iana-ipv4-special-registry) as follows: 130 OLD: 132 192.0.0.0/29 DS-Lite [RFC6333] 134 NEW: 136 192.0.0.0/29 IPv4 Service Continuity Prefix [RFC-to-be-xxx] 138 +----------------------+-----------------------------------+ 139 | Attribute | Value | 140 +----------------------+-----------------------------------+ 141 | Address Block | 192.0.0.0/29 | 142 | Name | IPv4 Service Continuity Prefix | 143 | RFC | RFC TBD | 144 | Allocation Date | June 2014 | 145 | Termination Date | N/A | 146 | Source | True | 147 | Destination | True | 148 | Forwardable | True | 149 | Global | False | 150 | Reserved-by-Protocol | False | 151 +----------------------+-----------------------------------+ 153 7. Acknowledgements 155 This document has been substantially improved by specific feedback 156 from Dave Thaler, Fred Baker, Wes George, Lorenzo Colitti, and 157 Mohamed Boucadair. 159 8. References 161 8.1. Normative References 163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 164 Requirement Levels", BCP 14, RFC 2119, March 1997. 166 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 167 Stack Lite Broadband Deployments Following IPv4 168 Exhaustion", RFC6333, August 2011. 170 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 171 Combination of Stateful and Stateless Translation", 172 RFC6877, April 2013. 174 Authors' Addresses 176 Cameron Byrne 177 Bellevue, WA, USA 178 Email: Cameron.Byrne@T-Mobile.com