idnits 2.17.1 draft-baker-v6ops-cpe-autoconfigure-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2017) is 2498 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4941' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4339 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations F. Baker 3 Internet-Draft June 17, 2017 4 Intended status: Best Current Practice 5 Expires: December 19, 2017 7 Requirements for a Zero-Configuration IPv6 CPE 8 draft-baker-v6ops-cpe-autoconfigure-00 10 Abstract 12 This note is a breif exploration of what is required for a CPE to be 13 auto-configurable from the perspective on an ISP or other upstream 14 network. It assumes that the CPE may also be IPv4-capable (probably 15 using NAPT), but that the requirements for that are well understood 16 and need no further specification. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 19, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Operational Requirements . . . . . . . . . . . . . . . . . . 2 55 3. Expected Behavior . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Prefix Delegation . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 60 8. Human Rights Considerations . . . . . . . . . . . . . . . . . 5 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 10.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 We observe that, in today's offerings, "IPv6-capable" has many 71 different meanings. These often require specific configuration and 72 are non-interoperable. 74 The objective is to enable a customer to purchase a CPE router from a 75 mass market store, or for an ISP to purchase CPE Routers for its 76 managed service offering, that implement IPv6 [RFC2460] and can be 77 attached to any residential/SOHO network and any ISP or other 78 upstream network "as is out of the box", and work correctly. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Operational Requirements 88 The goal stated in Section 1 requires that downstream, which is to 89 say within the home or SOHO , the CPE must presume that there may 90 exist systems that will autoconfigure [RFC4862] themselves using 91 information in a Router Advertisement [RFC4861], and that there may 92 exist systems that require address assignment using DHCPv6 [RFC3315]. 93 It may offer a DNS service using a provider such as OpenDNS, Google 94 Public DNS, Amazon Route 53, or some other such service, or relay the 95 address of an ISP-provided DNS server. 97 Similarly, the stated goal requires that upstream, the CPE must 98 presume that it will be required to solicit and observe a Router 99 Advertisement [RFC4861], and 101 o learn an upstream DHCPv6 server address, 103 o either autoconfigure [RFC4862] its upstream address or derive one 104 using DHCPv6 [RFC3315], 106 o potentially learn an DNS server address from an RDNSS [RFC4339] or 107 from DHCPv6, 109 o and allocate IPv6 /64 prefixes for each of its interior subnets 110 using the IPv6 Prefix Options for DHCP [RFC3633]. 112 Given that, it is in a position to offer IPv6 services in the 113 residential/SOHO network depending on the upstream IPv6 capabilities. 115 3. Expected Behavior 117 As a result, a CPE needs to perform several steps, and come out of 118 the box configured to do so. These include: 120 1. Upon detecting the upstream interface as "up", emit a Router 121 Solicitation [RFC4861] on it. 123 2. If it receives a Router Advertisement [RFC4861], verify its 124 contents. These may include: 126 * If the RA contains a valid Prefix Information Option whose 127 prefix is available for autoconfiguration, create an address 128 in that prefix for that interface as specified in SLAAC 129 [RFC4862]. 131 * Failing that, use DHCPv6 [RFC3315] to request an address from 132 the upstream network. 134 * In that same DHCP request, it MAY request an IA_PD [RFC3633] 135 delegation of a set of prefixes as described in Section 4. 137 3. If it has not already done so, the router should request an IA_PD 138 [RFC3633] delegation of a set of prefixes as described in 139 Section 4. 141 4. Given an upstream interface and a delegation of prefixes to use 142 downstream, it should 144 * subdelegate a /64 prefix to each downstream interface 145 * allocate an address to each downstream interface using the 146 relevant prefixes 148 * start announcing a periodic RA on each downstream interface. 149 This RA should include, in addition to usual information 150 elements, the RDNSS [RFC4339]. 152 4. Prefix Delegation 154 When the CPE requests a set of prefixes from its upstream network, 155 there are several conditions that may apply: 157 o [RFC4291] and [RFC7421] presume a /64 prefix on each IPv6 subnet. 159 o Each LAN to which the CPE connects may be presumed to require a 160 subnet - if not immediately, at some point in the future. 162 o There may be LANs in the residential/SOHO network that are not 163 attached to the CPE, but require subdelegation within the network 164 using DHCPv6 or HNCP [RFC7788]. 166 The IA_PD requests a prefix, and indicates its preference for a 167 "Length for this prefix in bits". By nature, this is exponential: if 168 a home requires 17 subnets, it will require the prefix to be no 169 longer than 59 bits, and therefore technically requesting at least 32 170 /64 prefixes. In fact, some ISPs have stated privately that they 171 actually allocate prefix lengths of 56, 60, or 64 (and therefore sets 172 of 256, 16, or 1 /64) depending on the CPE's request. 174 The CPE should request as many as it thinks it might need, including 175 interior sub-delegation if it has an idea of what that may require. 177 5. IANA Considerations 179 This memo asks the IANA for no new parameters. 181 6. Security Considerations 183 This note describes the use of existing features, each of which has 184 its own Security Considerations, and as such adds no new security 185 vulnerabilities. 187 7. Privacy Considerations 189 This memo calls for no personally identifiable information. The data 190 conveyed may, however, be correlatable with other data that is 191 personally identifiable. Such things are beyond the scope of this 192 document. 194 8. Human Rights Considerations 196 Technologies described in this memo are not necessarily associated 197 with a human being, and as such violate no human rights. 199 9. Acknowledgements 201 10. References 203 10.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, 207 DOI 10.17487/RFC2119, March 1997, 208 . 210 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 211 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 212 December 1998, . 214 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 215 C., and M. Carney, "Dynamic Host Configuration Protocol 216 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 217 2003, . 219 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 220 Host Configuration Protocol (DHCP) version 6", RFC 3633, 221 DOI 10.17487/RFC3633, December 2003, 222 . 224 [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server 225 Information Approaches", RFC 4339, DOI 10.17487/RFC4339, 226 February 2006, . 228 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 229 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 230 DOI 10.17487/RFC4861, September 2007, 231 . 233 10.2. Informative References 235 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 236 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 237 2006, . 239 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 240 Address Autoconfiguration", RFC 4862, 241 DOI 10.17487/RFC4862, September 2007, 242 . 244 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 245 Extensions for Stateless Address Autoconfiguration in 246 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 247 . 249 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 250 Interface Identifiers with IPv6 Stateless Address 251 Autoconfiguration (SLAAC)", RFC 7217, 252 DOI 10.17487/RFC7217, April 2014, 253 . 255 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 256 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 257 Boundary in IPv6 Addressing", RFC 7421, 258 DOI 10.17487/RFC7421, January 2015, 259 . 261 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 262 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 263 2016, . 265 Appendix A. Change Log 267 Initial Version: Jun 13 2017 269 Author's Address 271 Fred Baker 272 Santa Barbara, California 93117 273 USA 275 Email: FredBaker.IETF@gmail.com