idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-02.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 215: '...rver, however it SHOULD NOT use statef...' RFC 2119 keyword, line 219: '...e to the L-bit set it SHOULD send this...' RFC 2119 keyword, line 237: '... router MUST therefore be lower than...' RFC 2119 keyword, line 278: '... Provider Router MUST be able to handl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Brzozowski 3 Internet-Draft Comcast Cable 4 Intended status: Best Current Practice G. Van De Velde 5 Expires: September 14, 2017 Nokia 6 March 13, 2017 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 11 Abstract 13 In some IPv6 environments the need has arisen for hosts to be able to 14 utilise a unique IPv6 prefix even though the link or media may be 15 shared. Typically hosts (subscribers) on a shared network, either 16 wired or wireless, such as Ethernet, WiFi, etc., will acquire unique 17 IPv6 addresses from a common IPv6 prefix that is allocated or 18 assigned for use on a specific link. 20 In most deployments today IPv6 address assignment from a single IPv6 21 prefix on a shared network is done by either using IPv6 stateless 22 address auto-configuration (SLAAC) and/or stateful DHCPv6. While 23 this is still viable and operates as designed there are some large 24 scale environments where this concept introduces significant 25 performance challenges and implications, specifically related to IPv6 26 router and neighbor discovery. 28 This document outlines an approach utilising existing IPv6 protocols 29 to allow hosts to be assigned a unique IPv6 prefix (instead of a 30 unique IPv6 address from a shared IPv6 prefix). Benefits of a unique 31 IPv6 prefix compared to a unique IPv6 address from the service 32 provider are going from improved subscriber isolation to enhanced 33 subscriber management. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 14, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 70 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 71 4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 72 5. IPv6 Neighbourship Discovery Best Practices . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The concepts in this document are originally developed as part of a 82 large scale, production deployment of IPv6 support for a provider 83 managed shared network service. In this document IPv6 support does 84 not preclude support for IPv4, however, the primary objectives for 85 this work was to make it so that user equipment (UE) were capable of 86 an IPv6 only experience from a network operators perspective. In the 87 context of this document, UE can be a 'regular' end-user-equipment, 88 as well as a server in a datacentre, assuming a shared network (wired 89 or wireless). 91 Details of IPv4 support are out of scope for this document. This 92 document will also, in general, outline the requirements that must be 93 satified by UE to allow for an IPv6 only experience. 95 In most deployments today User Equipment (UE) IPv6 address assignment 96 is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] and/or 97 DHCP IA_NA RFC3315 [RFC3315]. During the time when this approach was 98 developed and subsequently deployed it has been observed that some 99 operating systems do not support the use of DHCPv6 for the 100 acquisition of IA_NA per RFC7934 [RFC7934]. As such the use of IPv6 101 SLAAC based subscriber and address management for provider managed 102 shared network services is the recommended technology of choice as it 103 does not exclude any known IPv6 implementation. In addition an 104 IA_NA-only network is not recommended per RFC 7934 RFC7934 [RFC7934] 105 section 8. This document will detail the mechanics involved for IPv6 106 SLAAC based address and subscriber management coupled with stateless 107 DHCPv6, where beneficial. 109 This document will focus upon the process for UEs to obtain a unique 110 IPv6 prefix. 112 2. Motivation and Scope of Applicability 114 The motivation for this work falls into the following categories: 116 o Deployment advice for IPv6 that will allow stable and secure IPv6 117 only experience, even if IPv4 support is present 119 o Ensure support for IPv6 is efficient and does not impact the 120 performance of the underlying network and in turn the customer 121 experience 123 o Allow for the greatest flexibility across host implementation to 124 allow for the widest range of addressing and configuration 125 mechanisms to be employed. The goal here is the ensure that the 126 widest population of UE implementations can leverage the 127 availability of IPv6 129 o Lay the technological foundation for future work related to the 130 use of IPv6 over shared media requiring optimized subscriber 131 management 133 o Two devices (subscriber/hosts), both attached to the same provider 134 managed shared network should only be able to communicate through 135 the provider managed First Hop Router 137 o Provide guidelines regarding best common practices around IPv6 138 neighborship discovery and IPv6 address managent settings between 139 the First Hop router and directly connected hosts/subscribers. 141 3. Design Principles 143 The First Hop router discussed in this document is the L3-Edge router 144 responsible for the communication with the devices (hosts and 145 subscribers) directly connected to a provider managed shared network, 146 and to transport traffic between the directly connected devices and 147 between directy connected devices and remote devices. 149 The work detailed in this document is focussed to provide details 150 regarding best common practices of the IPv6 neighborship discovery 151 and related IPv6 address management settings between the First Hop 152 router and directly connected hosts/subscribers. The documented Best 153 Current Practice helps a service provider to better manage the shared 154 provider managed network on behalf of the connected devices. 156 The Best Current Practice documented in this note is to provide 157 hosts/subscribers devices connected to the provider managed shared 158 network with a unique IPv6 prefix while at the same functioning as 159 control-plane anchor point to make sure that each subscriber is 160 receiving the expected subscriber policy and service levels 161 (throughput, QoS, security, parental-control, subscriber mobility 162 management, etc.). 164 4. IPv6 Unique Prefix Assignment 166 When a UE connects to the shared provider managed network and is 167 attached it will initiate IP configuration phase. During this phase 168 the UE will from an IPv6 perspective attempt to learn the default 169 IPv6 gateway, the IPv6 prefix information, the DNS information 170 RFC6106 [RFC6106], and the remaining information required to 171 establish globally routable IPv6 connectivity. For that purpose the 172 the UE/subscriber sends a RS (Router Solicitation) message. 174 The First Hop Router receives this UE/subscriber RS message and 175 starts the process to compose the response to the UE/subscriber 176 originated RS message. The First Hop Provider Router will answer 177 using a unicast RA (Router Advertisement) to the UE/subscriber. This 178 RA contains a few important parameters for the EU/subscriber to 179 consume: (1) a /64 prefix and (2) flags. The /64 prefix can be 180 derived from a locally managed pool or aggregate IPv6 block assigned 181 to the First Hop Provider Router or from a centrally allocated pool. 182 The flags indicate to the UE/subscriber to use SLAAC and/or DHCPv6 183 for address assignment, it may indicate if the autoconfigured address 184 is on/off-link and if 'Other' information (e.g. DNS server address) 185 needs to be requested. 187 The IPv6 RA flags used for best common practice in IPv6 SLAAC based 188 Provider managed shared networks are: 190 o M-flag = 0 (UE/subscriber address is not managed through DHCPv6), 191 this flag may be set to 1 in the future if/when DHCPv6 prefix 192 delegation support is desired) 194 o O-flag = 1 (DHCPv6 is used to request configuration information 195 i.e. DNS, NTP information, not for IPv6 addressing) 197 o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) 199 o L-flag = 0 (The UE/subscriber is off-link, which means that the 200 UE/subscriber will ALWAYS send packets to its default gateway, 201 even if the destination is within the range of the /64 prefix) 203 The use of a unique IPv6 prefix per UE adds an additional level of 204 protection and efficiency as it relates to how IPv6 Neighbor 205 Discovery and Router Discovery processing. Since the UE has a unique 206 IPv6 prefix all traffic by default will be directed to the First Hop 207 provider router. Further, the flag combinations documented above 208 maximize the IPv6 configurations that are available by hosts 209 including the use of privacy IPv6 addressing. 211 The architected result of designing the RA as documented above is 212 that each UE/subscriber gets its own unique /64 IPv6 prefix for which 213 it can use SLAAC or any other method to select its /128 unique 214 address. In addition it will use stateless DHCPv6 to get the IPv6 215 address of the DNS server, however it SHOULD NOT use stateful DHCPv6 216 to receive a service provider managed IPv6 address. If the UE/ 217 subscriber desires to send anything external including other UE/ 218 subscriber devices (assuming device to device communications is 219 enabled and supported), then due to the L-bit set it SHOULD send this 220 traffic to the First Hop Provider Router. 222 Now that the UE/subscriber received the RA and the associated flags, 223 it will assign itself a 128 bit IPv6 address using SLAAC. Since the 224 address is composed by the UE/subscriber device itself it will need 225 to verify that the address is unique on the shared network. The UE/ 226 subscriber will for that purpose perform Duplicate Address Detection 227 algorithm. This will occur for each address the UE attempts to 228 utilize on the shared provider managed network. 230 5. IPv6 Neighbourship Discovery Best Practices 232 An operational consideration when using IPv6 address assignment using 233 IPv6 SLAAC is that after the onboarding procedure the UE/subscriber 234 will have a prefix with certain preferred and valid lifetimes. The 235 First Hop Provider Router extends these lifetimes by sending an 236 unsolicited RA, the applicable MaxRtrAdvInterval on the first hop 237 router MUST therefore be lower than the preferred lifetime. As a 238 consequence of this process is that the First Hop Router never knows 239 when a UE/subscriber stops using addresses from a prefix and 240 additional procedures are required to help the First Hop Router to 241 gain this information. When using stateful DHCPv6 IA_NA for IPv6 UE/ 242 subscriber address assignment this uncertainty on the First Hop 243 Router is not of impact due to the stateful nature of DHCPv6 IA_NA 244 address assignment. 246 Following is reference table of the key IPv6 router discovery and 247 neighbor discovery timers for provider managed shared networks: 249 o IPv6 Router Advertisement Interval = 300s 251 o IPv6 Router LifeTime = 3600s 253 o Reachable time = 30s 255 o IPv6 Valid Lifetime = 3600s 257 o IPv6 Preferred Lifetime = 1800s 259 o Retransmit timer = 0s 261 The stateless nature of the UE/subscriber IPv6 SLAAC connectivity 262 model provides value to make sure that the UE/subscriber context is 263 timely removed from the First Hop Router to avoid ongoing resource 264 depletion in the case of non-permanent UE, such as in the case of 265 WiFi hotspots. A possible solution is to use a subscriber inactivity 266 timer which after tracking a pre-defined (currently unspecified) # of 267 minutes deletes the subscriber context on the First Hop Router. 269 When employing stateless IPv6 address assignment a number of widely 270 deployed operating systems will attempt to utilize RFC 4941 RFC4941 271 [RFC4941] temporary 'private' addresses. 273 Similarly, when using this technology in a datacentre, the UE server 274 may need to use several addresses from the same /64, for example 275 because is using multiple virtual hosts, containers, etc. in the 276 bridged virtual switch. This can lead to the consequence that a UE 277 has multiple /128 addresses from the same IPv6 prefix. The First Hop 278 Provider Router MUST be able to handle the presence and use of 279 multiple globally routable IPv6 addresses. 281 For accounting purposes the First Hop Provider Router must be able to 282 send usage statistics per UE/subscriber using Radius attributes. 284 6. IANA Considerations 286 No IANA considerations are defined at this time. 288 7. Security Considerations 290 No additional security considerations are made in this document. 292 8. Acknowledgements 294 The authors would like to thank the following, in alphabetical order, 295 for their contributions: 297 Tim Chown, Lorenzo Colitti, Killian Desmedt, Brad Hilgenfeld, Wim 298 Henderickx, Erik Kline, Thomas Lynn, Jordi Palet, Phil Sanderson, 299 Colleen Szymanik, Eric Vyncke, Sanjay Wadhwa 301 9. Normative References 303 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 304 C., and M. Carney, "Dynamic Host Configuration Protocol 305 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 306 2003, . 308 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 309 Address Autoconfiguration", RFC 4862, 310 DOI 10.17487/RFC4862, September 2007, 311 . 313 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 314 Extensions for Stateless Address Autoconfiguration in 315 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 316 . 318 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 319 "IPv6 Router Advertisement Options for DNS Configuration", 320 RFC 6106, DOI 10.17487/RFC6106, November 2010, 321 . 323 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 324 "Host Address Availability Recommendations", BCP 204, 325 RFC 7934, DOI 10.17487/RFC7934, July 2016, 326 . 328 Authors' Addresses 330 John Jason Brzozowski 331 Comcast Cable 332 1701 John F. Kennedy Blvd. 333 Philadelphia, PA 334 USA 336 Email: john_brzozowski@cable.comcast.com 338 Gunter Van De Velde 339 Nokia 340 Antwerp 341 Belgium 343 Email: gunter.van_de_velde@nokia.com