idnits 2.17.1 draft-ietf-v6ops-clatip-01.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 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3627 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-to-be-xxx' is mentioned on line 128, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Cameron Byrne 3 Updates: [RFC6333] (if approved) T-Mobile US 4 Intended Status: Informational May 19, 2014 5 Expires: November 20, 2014 7 IPv4 Service Continuity Prefix 8 draft-ietf-v6ops-clatip-01 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. The Case of 464XLAT . . . . . . . . . . . . . . . . . . . . . 3 57 3. Choosing 192.0.0.0/29 . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 DS-Lite [RFC6333] directs IANA to reserve 192.0.0.0/29 for the Basic 68 Bridging BroadBand (B4) element. This memo generalizes that IANA 69 reservation to include other cases where a non-routed IPv4 interface 70 must be numbered in an IPv6 transition solution. IANA shall list the 71 address block 192.0.0.0/29 reserved for IPv4 Service Continuity 72 Prefix. The result is that 192.0.0.0/29 may be used in any system 73 that requires IPv4 addresses for backward compatibility with IPv4 74 communications in an IPv6-only network, but does not emit IPv4 75 packets "on the wire". 77 This generalization does not impact the use of the IPv4 Service 78 Continuity Prefix in a DS-Lite context. 80 2. The Case of 464XLAT 82 464XLAT [RFC6877] describes an architecture for providing IPv4 83 communication over an IPv6-only access network. One of the methods 84 described in [RFC6877] is for the client side translator (CLAT) to be 85 embedded in the host, such as a smartphone or a CPE (Customer 86 Premises Equipment). In such scenarios, the host must have an IPv4 87 address configured to present to the host network stack and for 88 applications to bind IPv4 sockets. 90 3. Choosing 192.0.0.0/29 92 To avoid conflicts with any other network that may communicate with 93 the CLAT or other IPv6 transition solution, a locally unique IPv4 94 address must be assigned. 96 IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333], 97 which is dedicated for DS-Lite. As defined in [RFC6333], this subnet 98 is only present between the B4 and the AFTR and never emits packets 99 from this prefix "on the wire". 464XLAT has the same need for a non- 100 routed IPv4 prefix, and this same need may be common for other 101 similar solutions. It is most prudent and effective to generalize 102 192.0.0.0/29 for the use of supporting IPv4 interfaces in IPv6 103 transition technologies rather than reserving a prefix for every 104 possible solution. 106 With this memo, 192.0.0.0/29 is now generalized across multiple IPv4 107 continuity solutions such as 464XLAT and DS-lite. It is important 108 that a host never enable 2 active IPv4 continuity solutions 109 simultaneously in a way that would cause a node to have overlapping 110 address from 192.0.0.0/29. 112 4. Security Considerations 113 No new security considerations beyond what is described [RFC6333] and 114 [RFC6877]. 116 5. IANA Considerations 118 This document requests IANA to update the IPv4 Special-Purpose 119 Address Registry available at (http://www.iana.org/assignments/iana- 120 ipv4-special-registry/iana-ipv4-special-registry.xhtml) as follows: 122 OLD: 124 192.0.0.0/29 DS-Lite [RFC6333] 126 NEW: 128 192.0.0.0/29 IPv4 Service Continuity Prefix [RFC-to-be-xxx] 130 6. Acknowledgements 132 This document has been substantially improved by specific feedback 133 from Dave Thaler, Fred Baker, Wes George, Lorenzo Colitti, and 134 Mohamed Boucadair. 136 7. References 138 7.1. Normative References 140 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 141 Stack Lite Broadband Deployments Following IPv4 142 Exhaustion", RFC6333, August 2011. 144 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 145 Combination of Stateful and Stateless Translation", 146 RFC6877, April 2013. 148 Authors' Addresses 150 Cameron Byrne 151 Bellevue, WA, USA 152 Email: Cameron.Byrne@T-Mobile.com