idnits 2.17.1 draft-palet-ietf-v6ops-ipv6-only-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '..., in general, we MUST NOT talk about a...' RFC 2119 keyword, line 151: '... MUST NOT use the terminology "IPv6-...' RFC 2119 keyword, line 159: '... IPv6-only MUST be used only if, a c...' RFC 2119 keyword, line 167: '...only host/router MUST be used only if ...' RFC 2119 keyword, line 172: '...ly WAN or access MUST be used only if ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2017) is 2473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Palet Martinez 3 Internet-Draft Consulintel, S.L. 4 Intended status: Informational July 18, 2017 5 Expires: January 19, 2018 7 IPv6-only Terminology Definition 8 draft-palet-ietf-v6ops-ipv6-only-00 10 Abstract 12 This document clarify the terminology regarding the usage of 13 expressions such as "IPv6-only", ir order to avoid confusions when 14 using them in IETF and other documents, in reference to what is the 15 actual functionalities being used (not the actual protocol support). 17 Status of This Memo 19 This Internet-Draft is submitted 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). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 19, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. IPv6-only host/router . . . . . . . . . . . . . . . . . . . . 4 55 5. IPv6-only WAN/access . . . . . . . . . . . . . . . . . . . . 4 56 6. IPv6-only LAN . . . . . . . . . . . . . . . . . . . . . . . . 4 57 7. IPv6-only core . . . . . . . . . . . . . . . . . . . . . . . 4 58 8. Other cases . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 Due to the nature of the Internet and the different types of users, 67 part of a network, providers, flows, etc., there is no a single and 68 easy way to categorically say something such as "IPv6-only". 70 The goal of this document is to depict this situation and agree in a 71 common language to be used for IETF and other documents, in order to 72 facilitate ourselves and future readers, the correct understanting of 73 what we are talking about. 75 Note that al the references in this document are regarding the actual 76 usage of IPv4/IPv6, not the support of those. For example, a device 77 or access network may support both IPv4 and IPv6, however actually is 78 only using (forwarding at layer-2), IPv6. 80 2. Context 82 The transition from IPv4 to IPv6 is not something that can be done, 83 in the large majority of the cases, overnight and in a single step. 84 Consequently, in general, we MUST NOT talk about a whole network 85 having a "single and uniform" status regarding IPv6, at least not in 86 the early deployment stages. 88 Even if it is possible, it is not frequent to deploy new IPv6 89 networks which have no IPv4 connectivity at all, because at the 90 current phase of the universal goal of the IPv6 deployment, almost 91 every network still need to provide some kind of access to IPv4 92 sites. It is not feasible for most of the operators de tell their 93 customers "I can provide you IPv6 service, but you will not be able 94 to access all Internet because some of the contents or applications 95 still don't support it, so you will miss every content that it is 96 IPv4-only". 98 So what often happens is that some networks may have IPv6-only 99 support for specific purposes. For example, a DOCSIS provider may 100 have decided that is worth the effort to get rid of IPv4 for the 101 management network of the cable-modems. Or a network that provides 102 connectivity only to IoT devices, may be IPv6-only. 104 However, despite the IETF and vendor efforts to get rid-off IPv4 as 105 soon as possible in every network or part of it, there are many 106 devices, in both corporate and end-user networks (smartTV, IP 107 cameras, security devices, etc.), which are IPv4-only and it is not 108 feasible (vendors may even be out of the market, or devices have no 109 easy way to be updated with new firmware, or de vendor have more 110 interest in selling a new model, etc.), the "end-networks" in 111 general, need to keep supporting IPv4. 113 It is true that this IPv4 support maybe done by using tools, or sets 114 of them, developed by IETF as part of the transition mechanisms 115 efforts. So, we could talk today about a situation where we can have 116 "most parts" of operator (or even enterprises/organizations) networks 117 being IPv6-only, however have some kind of "IPv4" support, which in 118 general we are calling "IPv4-as-a-service", which means typically 119 that IPv4 is transported using the IPv6 layer-3 infrastructure as an 120 IPv4 layer-2 one (for example by means of encapsulation or 121 translation). 123 Let's describe the situation in the cellular networks. Because the 124 nature of the applications in those networks, it is easier to have 125 more control on how the developers work, and for example, mandate 126 IPv6 support in order to allow the apps to be installed in the 127 smartphones, as actually has been done by Apple. What that means is 128 that it is theoretically possible to have an IPv6-only access network 129 for a complete cellular operator network. It may be even possible 130 that the core and other parts of the operator network are IPv6-only 131 if all the management of those is done by means of IPv6. However, as 132 soon as any application in the smartphone requires access to 133 IPv4-only end sites (example web servers), there must be some kind of 134 IPv4 support in that network, for example PLAT (NAT64/DNS64) and 135 consequently, some IPv4 addresses, which allow the IPv4-only traffic 136 flow to end-sites by means of the upstream providers/peers. 138 Now, if those smartphones in an IPv6-only cellular network provide 139 tethering (sharing of a smartphone Internet connection with other 140 devices), they may also need to "transport" IPv4 (those devices may 141 be IPv4-only), in a seamless way, over the IPv6-only network. 143 We can extrapolate the example above to, instead of smartphones to 144 LTE routers, or CEs with any wired technology (FTTH, xDSL, Cable, 145 etc.). At the end, no matter which is the access technology, we 146 can't talk, in general, in the customer LANs, about IPv6-only, 147 because today is very common that we must provide still some sort of 148 IPv4 support ("IPv4-as-a-service"). 150 Consequently, if we want to be precise and avoid confusing others, we 151 MUST NOT use the terminology "IPv6-only" in a generic way, and we 152 need to define what part of the network we are referring to. 154 From that perspective, we define the "IPv6-only" status depending on 155 if there is actual layer-2 forwarding of IPv4. 157 3. IPv6-only 159 IPv6-only MUST be used only if, a complete network, end-to-end, is 160 actually not forwarding IPv4 at layer-2, which will mean that no-IPv4 161 addresses are configured, neither used for management, neither the 162 network is providing transition/translation support, neither there is 163 IPv4 transit/peering. 165 4. IPv6-only host/router 167 IPv6-only host/router MUST be used only if the host or router that we 168 are referring to, isn't actually forwarding IPv4 at layer-2. 170 5. IPv6-only WAN/access 172 IPv6-only WAN or access MUST be used only if the WAN or access 173 network that we are referring to, isn't actually forwarding IPv4 at 174 layer-2. 176 6. IPv6-only LAN 178 IPv6-only LAN (or LANs) MUST be used only if the LAN(s) that we are 179 referring to, isn't actually forwarding IPv4 at layer-2. 181 7. IPv6-only core 183 IPv6-only core MUST be used only if the core network that we are 184 referring to, isn't actually forwarding IPv4 at layer-2. 186 8. Other cases 188 Similar other cases or parts of the network MUST be considered as 189 IPv6-only if there is no actual forwarding of IPv4 at layer-2 over 190 them and in that case, after "IPv6-only" MUST be some word/short text 191 pointing to the specific case or part of the network. 193 9. Security Considerations 195 This document does not have any specific security considerations. 197 10. IANA Considerations 199 This document does not have any IANA considerations. 201 11. Acknowledgements 203 The author would like to acknowledge the inputs of TBD ... 205 Author's Address 207 Jordi Palet Martinez 208 Consulintel, S.L. 209 Molino de la Navata, 75 210 La Navata - Galapagar, Madrid 28420 211 Spain 213 Email: jordi.palet@consulintel.es 214 URI: http://www.consulintel.es/