idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.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: '..., due to the L-bit set, it SHOULD send...' RFC 2119 keyword, line 237: '... router MUST therefore be lower than...' RFC 2119 keyword, line 280: '... 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 (May 17, 2017) is 2534 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: November 18, 2017 Nokia 6 May 17, 2017 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 11 Abstract 13 In some IPv6 environments, the need has arisen for hosts to be able 14 to utilize 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 unique 31 IPv6 prefix over a unique IPv6 address from the service provider 32 include improved subscriber isolation and enhanced subscriber 33 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 November 18, 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 Neighbor 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 'regular' end-user-equipment, as 88 well as a server in a datacentre, assuming a shared network (wired or 89 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 current deployments, User Equipment (UE) IPv6 address 96 assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] 97 and/or DHCP IA_NA RFC3315 [RFC3315]. During the time when this 98 approach was developed and subsequently deployed, it has been 99 observed that some operating systems do not support the use of DHCPv6 100 for the acquisition of IA_NA per RFC7934 [RFC7934]. As such the use 101 of IPv6 SLAAC based subscriber and address management for provider 102 managed shared network services is the recommended technology of 103 choice, as it does not exclude any known IPv6 implementation. In 104 addition an IA_NA-only network is not recommended per RFC 7934 105 RFC7934 [RFC7934] section 8. This document will detail the mechanics 106 involved for IPv6 SLAAC based address and subscriber management 107 coupled with stateless 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 to 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 directly connected devices and remote devices. 149 The work detailed in this document is focused on providing details 150 regarding best common practices of the IPv6 neighbor discovery and 151 related IPv6 address management settings between the First Hop router 152 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 a 157 unique IPv6 prefix to hosts/subscribers devices connected to the 158 provider managed shared network. Each unique IPv6 prefix can 159 function as control-plane anchor point to make sure that each 160 subscriber is receiving 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 two 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 220 this traffic to the First Hop Provider Router. 222 After the UE/subscriber received the RA, and the associated flags, it 223 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 Neighbor 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. One 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 a 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 a consideration to make regarding resource consumption 263 (i.e. memory, neighbor state) on the First Hop Router. To reduce 264 undesired resource consumption on the First Hop Router the desire is 265 to remove UE/subscriber context in the case of non-permanent UE, such 266 as in the case of WiFi hotspots as quickly as possible. A possible 267 solution is to use a subscriber inactivity timer which, after 268 tracking a pre-defined (currently unspecified) number of minutes, 269 deletes the subscriber context on the First Hop Router. 271 When employing stateless IPv6 address assignment, a number of widely 272 deployed operating systems will attempt to utilize RFC 4941 RFC4941 273 [RFC4941] temporary 'private' addresses. 275 Similarly, when using this technology in a datacentre, the UE server 276 may need to use several addresses from the same /64, for example 277 because is using multiple virtual hosts, containers, etc. in the 278 bridged virtual switch. This can lead to the consequence that a UE 279 has multiple /128 addresses from the same IPv6 prefix. The First Hop 280 Provider Router MUST be able to handle the presence and use of 281 multiple globally routable IPv6 addresses. 283 For accounting purposes, the First Hop Provider Router must be able 284 to send usage statistics per UE/subscriber using Radius attributes. 286 6. IANA Considerations 288 No IANA considerations are defined at this time. 290 7. Security Considerations 292 No additional security considerations are made in this document. 294 8. Acknowledgements 296 The authors would like to thank the following, in alphabetical order, 297 for their contributions: 299 Tim Chown, Lorenzo Colitti, Killian Desmedt, Brad Hilgenfeld, Wim 300 Henderickx, Erik Kline, Warren Kumari, Thomas Lynn, Jordi Palet, Phil 301 Sanderson, Colleen Szymanik, Eric Vyncke, Sanjay Wadhwa 303 9. Normative References 305 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 306 C., and M. Carney, "Dynamic Host Configuration Protocol 307 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 308 2003, . 310 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 311 Address Autoconfiguration", RFC 4862, 312 DOI 10.17487/RFC4862, September 2007, 313 . 315 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 316 Extensions for Stateless Address Autoconfiguration in 317 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 318 . 320 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 321 "IPv6 Router Advertisement Options for DNS Configuration", 322 RFC 6106, DOI 10.17487/RFC6106, November 2010, 323 . 325 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 326 "Host Address Availability Recommendations", BCP 204, 327 RFC 7934, DOI 10.17487/RFC7934, July 2016, 328 . 330 Authors' Addresses 332 John Jason Brzozowski 333 Comcast Cable 334 1701 John F. Kennedy Blvd. 335 Philadelphia, PA 336 USA 338 Email: john_brzozowski@cable.comcast.com 340 Gunter Van De Velde 341 Nokia 342 Antwerp 343 Belgium 345 Email: gunter.van_de_velde@nokia.com