idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-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 379: '...rver, however it SHOULD NOT use statef...' RFC 2119 keyword, line 383: '...e to the L-bit set it SHOULD send this...' RFC 2119 keyword, line 475: '...l on the WLAN-GW MUST therefore be low...' RFC 2119 keyword, line 518: '...ix. The WLAN-GW 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 (October 19, 2015) is 3083 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) == Missing Reference: 'RFC3633' is mentioned on line 448, but not defined ** Obsolete undefined reference: RFC 3633 (Obsoleted by RFC 8415) == Unused Reference: 'RFC6180' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-v4v6tran-framework' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC6343' is defined on line 602, but no explicit reference was found in the text ** 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) ** Downref: Normative reference to an Informational RFC: RFC 6180 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 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: April 21, 2016 Alcatel-Lucent 6 October 19, 2015 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-00 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, like Wi- 16 Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6 17 prefix that is allocated or assigned for use on a specific link. 18 Benefits of a unique IPv6 prefix compared to a unique IPv6 address 19 from the service provider are going from enhanced subscriber 20 management to improved isolation between subscribers. 22 In most deployments today IPv6 address assignment from a single IPv6 23 prefix on a shared network is done by either using IPv6 stateless 24 address auto-configuration (SLAAC) and/or stateful DHCPv6. While 25 this is still viable and operates as designed there are some large 26 scale environments where this concept introduces significant 27 performance challenges and implications, specifically related to IPv6 28 router and neighbor discovery. This document outlines an approach 29 utilising existing IPv6 protocols to allow hosts to be assigned a 30 unique IPv6 prefix (instead of a unique IPv6 address from a shared 31 IPv6 prefix). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 21, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 69 3. Design Princinples . . . . . . . . . . . . . . . . . . . . . 4 70 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Community Wi-Fi Network Topology Description . . . . . . 4 72 4.2. Wi-Fi Subscriber Onboarding Procedures . . . . . . . . . 6 73 4.3. UE IPv6 Addressing and Configuration . . . . . . . . . . 10 74 4.3.1. IPv6 Addressing . . . . . . . . . . . . . . . . . . . 10 75 4.3.2. IPv6 Configuration . . . . . . . . . . . . . . . . . 11 76 5. Operational Considerations . . . . . . . . . . . . . . . . . 11 77 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 10.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The concepts in this document were originally developed as part of a 89 large scale, production deployment of IPv6 support for a community 90 Wi-Fi service. In this document IPv6 support does not preclude 91 support for IPv4, however, the primary objectives for this work was 92 to make it so that user equipment (UE) were capable of an IPv6 only 93 experience from a network operators perspective. Details of IPv4 94 support are out of scope for this document. This document will also, 95 in general, outline the requirements that must be satified by UE to 96 allow for an IPv6 only experience. 98 In most deployments today User Equipment (UE) IPv6 address assignment 99 is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] and/or 100 DHCP IA_NA RFC3315 [RFC3315]. However, at current time there is a 101 non-trivial UE/subscriber base not supporting DHCPv6 IA_NA, making 102 IPv6 SLAAC based subscriber and address management for community Wi- 103 Fi services the technology of choice as it does not exclude any known 104 IPv6 implementation. This document will detail the mechanics 105 involved for IPv6 SLAAC based address and subscriber management 106 coupled with stateless DHCPv6, where beneficial. 108 A community Wi-Fi service is an environment to allow subscribers 109 (hosts) to connect to a shared network providing Internet and/or 110 closed network services. Often Service providers use community Wi-Fi 111 networks to provide enhanced subscriber connectivity experiences. 112 Additionally retail owners frequently provide community Wi-Fi 113 services to improve their customers retail experience. 115 Upon further exploration the approach documented here has 116 applicability in other environments including corporate, enterprise, 117 or university settings where IPv6 support is desired over a shared 118 media. Where applicable details related to the same will be 119 provided. 121 2. Motivation and Scope of Applicability 123 The motivation for this work falls into the following categories: 125 o Deploy support for IPv6 that will allow for an IPv6 only 126 experience, even if IPv4 support is present 128 o Ensure support for IPv6 is efficient and does not impact the 129 performance of the underlying network and in turn the customer 130 experience 132 o Allow for the greatest flexibility across host implementation to 133 allow for the widest range of addressing and configuration 134 mechanisms to be employed. The goal here is the ensure that the 135 widest population of UE implementations can leverage the 136 availability of IPv6. 138 o Lay the technological foundation for future work related to the 139 use of IPv6 over shared media like Wi-Fi 141 While this work was originally conceived in the context of large 142 scale Wi-Fi networks, the scope of applicability is much broader. 143 The techniques and concepts or subsets of the same may also be 144 applicable in residential or SOHO networking environments. 146 3. Design Princinples 148 The Wireless LAN Gateway (WLAN-GW) discussed in this document is the 149 L3-Edge router responsible for the communication with the Wi-Fi 150 subscribers (hosts) and to aggregate the traffic from the Wi-Fi 151 subscribers and the Wireless LAN network towards the community Wi-Fi 152 provider. 154 The goal of a WLAN-GW is to provide sufficient data-plane throughput 155 capacity to aggregate all Wi-Fi subscriber traffic, while at the same 156 time it is functioning as control-plane anchor point to make sure 157 that each subscriber is receiving the expected subscriber policy and 158 service levels (throughput, QoS, security, parental-control, 159 subscriber mobility management, etc.). 161 The work detailed in this document intends to provide details 162 regarding the WLAN-GW Wi-Fi subscriber/host addressing methodology. 163 Evolved WLAN-GW capabilities regarding fixed/mobile convergence, 164 traffic steering, etc. are not the main focus and are outside the 165 scope of this document. 167 4. Behaviour 169 This section outlines the essential components of the described 170 system and interaction amongst the same. 172 4.1. Community Wi-Fi Network Topology Description 174 The topology and design referenced in this document is a generalized 175 description of functional components currently deployed in a large 176 scale subscriber oriented network. 178 +-----+ 179 | AAA | 180 +-----+ 181 / 182 Radius 183 / 184 +----+ 185 | CP | 186 +----+ +---------+ 187 UE--802.11--| AP |---Soft_GRE---| WLAN-GW |----Internet/WAN access 188 +----+ +---------+ 189 | 190 IP/HTTP 191 | 192 +---------------------+ 193 | HTTP Captive Portal | 194 +---------------------+ 196 Figure 1 198 o UE: User Equipment. 200 o 802.11: Wireless Network 202 o AP: Access Point. 204 o Soft-GRE: Stateless GRE tunnel 206 o WLAN-GW: Wireless LAN Gateway 208 o CP: Control Plane component of the WLAN-GW 210 o AAA: Accounting, Authorisation and Authentication 212 o HTTP Captive Portal: Captive portal used to redirect traffic 213 towards during subscriber onboarding process 215 While there are many ways for UE to associate to a Wi-Fi network 216 (e.g. EAP-SIM, EAP-AKA, WPA2-PSK, etc.), community Wi-Fi 217 predominantly leverages an HTTP Captive Portal. The key function for 218 the Captive Portal is to identify the UE/subscriber and create on the 219 WLAN-GW the corresponding UE/subscriber context for policy and 220 accounting. 222 The Soft-GRE session is a stateless GRE tunnel between AP and the 223 WLAN-GW. The AP is configured with the IP address or FQDN of the 224 tunnel concentrator or aggregation point and initiates the GRE 225 tunnel, over IPv6 preferrably, by encapsulating packets towards the 226 WLAN-GW. The WLAN-GW is configured as a GRE tunnel head-end server 227 and accepts these GRE packets, while at the same time creating 228 correct tunnel context to identify the AP. Soft-GRE is a very well 229 established pragmatic technology. The use of GRE over IPv4 only 230 furthers an operators dependence on IPv4 and should be deprecated by 231 using GRE over IPv6 only. 233 The AP has, as seen in the illustration, an interface attached to the 234 Wi-Fi network and will bridge traffic received on this Wi-Fi 235 interface over the Soft-GRE tunnel to the WLAN-GW. This will include 236 traffic from newly attached UE/subscribers which have not been 237 identified or authorized on the Wi-Fi network. At the same time the 238 AP implements split-horizon for BUM (broadcast, unknown and 239 multicast) traffic, making sure that there is no undesired leakage of 240 traffic between UE/subscribers attached to the Wi-Fi network. 242 The Control Plane (CP) of the WLAN-GW is a key component used during 243 onboarding of UE/subscribers to identify the UE/subscriber and to 244 exchange IP address related details. For that purpose it can make 245 usage of DHCP, ARP, DHCPv6, ICMPv6 (RS/RA/NS/NA), Radius, Diameter, 246 etc. 248 4.2. Wi-Fi Subscriber Onboarding Procedures 250 This section provides detail about Best Practice operational steps to 251 onboard a UE/subscriber and the key architectural technology used to 252 create the WLAN-GW UE/subscriber policy and IP addressing context. 254 The flow chart pictured below is providing a sequential overview of 255 the operational steps performed to onboard a UE onto a community Wi- 256 Fi network. 258 UE WLAN-GW AAA Captive-Portal DNS 259 | | | | | 260 | | | | | 261 |--------RS-------->| | | | 262 | |---Access-Req---->| | | 263 | |<--Access-Acc-----| | | 264 | |(=Radius UE info) | | | 265 |<-------RA---------| | | | 266 |(/64; M,L=0; O,A=1)| | | | 267 | | | | | 268 |------NS(DAD)----->| | | | 269 | | | | | 270 |-DHCPv6(info Req)->| | | | 271 | (Ask DNS IP addr.)| | | | 272 | | | | | 273 |<---DHCPv6 Reply---| | | | 274 | | | | | 275 |--------------------------------DNS----------------------------->| 276 | | | | | 277 |------HTTP GET---->| | | | 278 |<--HTTP Redirect---| | | | 279 | | | | | 280 |--------------------------------DNS----------------------------->| 281 | | | | | 282 |<------------------------HTTP Login------------------->| | 283 | | | | | 284 | | |<-UE Identified-| | 285 | |<--Radius CoA-----| | | 286 | |(remove HTTP Red.)| | | 287 | | | | | 288 |<--------UE/Subscriber connected to Internet/WAN-------------------> 289 | | | | | 290 | | | | | 292 Figure 2 294 Note that the Wireless Access Point (AP) is not pictured in the flow 295 chart above. This is because the AP is from architectural 296 perspective functioning as a L2 bridge between the UE and WLAN-GW. 297 For Wi-Fi community service the AP is configured to setup a Soft-GRE 298 tunnel towards the WLAN-GW and to bridge relevant Wi-Fi traffic upon 299 the Soft-GRE tunnel. The AP is also configured for split-horizon 300 towards the Wi-Fi interface for subscriber isolation and security 301 purpose. The AP will for the remainder of this document be silently 302 inserted between UE and WLAN-GW to bridge traffic between the WLAN-GW 303 and AP and vice versa 304 When a new UE connects to the community Wi-Fi it connects to the Wi- 305 Fi network by attaching to the relevant 'open' SSID advertised for 306 use as part of the community Wi-Fi offering. Once the UE/subscriber 307 is attached to the Wi-Fi SSID it will initiate IP configuration. The 308 focus of this document is to share IPv6 address assignment Best 309 Practices, and hence will focus around those topics, eventhough there 310 are many more aspects to deploy a quality community Wi-Fi service 311 offering successfully. 313 Once the UE is connected to the Wi-Fi shared network, it will from an 314 IPv6 perspective attempt to learn the default IPv6 gateway, the IPv6 315 prefix information, the DNS information, and the remaining 316 information required to establish globally routable IPv6 317 connectivity. For that purpose the the UE/subscriber sends a RS 318 (Router Solicitation) message. This RS is forwarded by the AP-bridge 319 over the Soft-GRE interface, however due to the split-horizon 320 configuration for BUM traffic it is not relayed to any other UE/ 321 Subscribers attached to the Wi-Fi network. 323 The WLAN-GW received this UE/subscriber RS message, and because it is 324 the first time this UE/subscriber attaches to the Wi-Fi the UE/ 325 subscriber is by default not authorized. The WLAN-GW will now try to 326 discover additional information about the subscriber information by 327 querying the AAA server. This is done by sending a Radius Access- 328 Request. 330 The Radius server receives this Access-Request, and performs a lookup 331 in its policy database. If radius server discovers that the UE/ 332 subscriber is a fresh device trying to gain access onto the Wi-Fi 333 network it will identify some parameters (e.g. IPv6 /64 prefix) to 334 send back to the WLAN-GW together with a message to install a HTTP- 335 redirect to a Captive Portal for further UE/subscriber 336 identification. This will be sent from the AAA server to the WLAN-GW 337 in a Radius Access-Ackowledge message. 339 The WLAN-GW will use the received Radius information to compose the 340 response to the UE/subscriber originated RS message. The WLAN-GW 341 will answer using a unicast RA (Router Advertisement) to the UE/ 342 subscriber. This RA contains a few important parameters for the EU/ 343 subscriber to consume: (1) a /64 prefix and (2) flags. The /64 344 prefix can be derived from a locally managed pool or aggregate IPv6 345 block assigned to the WLAN-GW or from a pool signalled by the Radius 346 server in a radius attribute. The flags may indicate to the UE/ 347 subscriber to use SLAAC and/or DHCPv6 for address assignment, it may 348 indicate if the autoconfigured address is on/off-link and if 'Other' 349 information (e.g. DNS server address) needs to be requested. 351 The IPv6 RA flags used for best common practice in IPv6 SLAAC based 352 community Wi-Fi are: 354 o M-flag = 0 (UE/subscriber address is not managed through DHCPv6), 355 this flag may be set to 1 in the future if/when DHCPv6 prefix 356 delegation support over Wi-Fi is desired) 358 o O-flag = 1 (DHCPv6 is used to request configuration information 359 i.e. DNS, NTP information, not for IPv6 addressing) 361 o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) 363 o L-flag = 0 (The UE/subscriber is off-link, which means that the 364 UE/subscriber will send packets ALWAYS to his default gateway, 365 even if the destination is within the range of the /64 prefix) 367 The use of a unique IPv6 prefix per UE adds an additional level of 368 protection and efficiency as it relates to how IPv6 Neighbor 369 Discovery and Router Discovery processing. Since the UE has a unique 370 IPv6 prefix all traffic by default will be directed to the WLAN-GW. 371 Further, the flag combinations documented above maximize the IPv6 372 configurations that are available by hosts including the use of 373 privacy IPv6 addressing. 375 The architected result of designing the RA as documented above is 376 that each UE/subscriber gets its own unique /64 IPv6 prefix for which 377 it can use SLAAC or any other method to select its /128 unique 378 address. In addition it will use stateless DHCPv6 to get the IPv6 379 address of the DNS server, however it SHOULD NOT use stateful DHCPv6 380 to receive a service provider managed IPv6 address. If the UE/ 381 subscriber desires to send anything external including other UE/ 382 subscriber devices (assuming device to device communications is 383 enabled and supported), then due to the L-bit set it SHOULD send this 384 traffic to the WLAN-GW. 386 Now that the UE/subscriber received the RA and the associated flags, 387 it will assign itself a 128 bit IPv6 address using SLAAC. Since the 388 address is composed by the UE/subscriber device itself it will need 389 to verify that the address is unique on the shared network. The UE/ 390 subscriber will for that purpose perform Duplicate Address Detection 391 algorithm. This will occur for each address the UE attempts to 392 utilize on the Wi-Fi network. 394 At this stage the UE/subscriber has acquired a valid IPv6 address, 395 however it may not have received one or more DNS server IPv6 address. 396 The UE/subscriber can use stateless DHCPv6 exchange to identify a 397 valid DNS server address(es). An alternative solution, albeit less 398 supported by IPv6 hosts is to signal DNS server addresses is by 399 utilising RA extensions described in RNDSS RFC6106 [RFC6106] in which 400 the router uses Router Advertisement options to advertise a list of 401 DNS recursive server addresses and a DNS Search List to IPv6 UE/ 402 subscribers. The use of RNDSS and stateless DHCPv6 for the 403 configuration of hosts are not mutually exclusive. Both methods can 404 and should be enabled simultaneously allowing for the widest range of 405 hosts or UEs to learn and use DNS over IPv6. DNS server IPv6 406 address(es) sent via DHCPv6 and RDNSS must be identical. 408 At this moment the UE/subscriber has all information to be connected 409 to the Internet, nevertheless the community Wi-Fi service provider 410 has no idea about the identity or credentials of the UE/subscriber. 411 For that purpose the Service provider has installed on the WLAN-GW a 412 HTTP redirect for this particular UE/subscriber towards HTTP captive 413 portal. First the subscriber utilises DNS to correlate the domain 414 name with an IP address, next the HTTP GET is intercepted and an HTTP 415 Redirect is issued to Redirect the HTTP session towards the Captive 416 portal. The ultimate goal of this process is for the service 417 provider to identify the UE/subscriber. From the moment the UE/ 418 subscriber identified itself on the captive portal (login-ID/PW, PIN 419 Challenge, etc.) then the captive portal informs the WLAN-GW about 420 the correct policies (QoS, policing, etc.) and to remove the HTTP- 421 redirect. 423 From now onwards the WLAN-GW has identified the UE/subscriber and 424 installed all the subscriber context for identification, billing, 425 traffic conditioning. The UE/subscriber can access the Internet/WAN 426 within his agreed commuity Wi-Fi parameters. 428 4.3. UE IPv6 Addressing and Configuration 430 An over arching objective for any IPv6 deployment where subscriber 431 endpoints or UEs are concerned must include an IPv6 only experience. 432 Specifically, similar to residential broadband networks, Wi-Fi 433 networks that support IPv6 must ensure there are no dependencies on 434 IPv4. Due to fragmented support for various IPv6 address and 435 configuration mechanisms network operators must effectively enable 436 and support every combination of IPv6 address and configuration 437 technique. Coordinating the configuraiton and values for the same is 438 important to ensure proper UE behavior. 440 4.3.1. IPv6 Addressing 442 Stateless IPv6 address autoconfiguration is expected to be the 443 primary mechanism for UEs to leverage when establing globally 444 routable IPv6 connectivity. Stateful DHCPv6 is currently not 445 utilized in this model for host addressing since stateful DHCPv6 is 446 not universally supported for address acquisition. Stateful DHCPv6 447 may be considering in the future as part of enabling support for IPv6 448 prefix delegation [RFC3633]. 450 4.3.2. IPv6 Configuration 452 In order to make an IPv6 only experience possible Wi-Fi network 453 operators must ensure that UEs are able to reach all critical network 454 services over IPv6. Today, many host operating systems still prefer 455 querying DNS over IPv4. Additionally, widely deployed hosts do not 456 truly leverage a single common approach for IPv6 configuration. As 457 such the following should be expected to be available to support a 458 proper IPv6 only configuration: 460 o RDNSS [RFC6106] is enabled by default and is expected to contain 461 one or more globally routable IPv6 addresses 463 o Stateless DHCPv6 [RFC3315] is enabled by default and will 464 minimally transmit one or more DNS server IPv6 addresses. To 465 ensure the desired behavior is triggered IPv6 router 466 advertisements transmitted by the WLAN-GW will set the M flag to 0 467 and the O flag to 1. 469 5. Operational Considerations 471 An operational consideration when using IPv6 address assignment using 472 IPv6 SLAAC is that after the onboarding procedure the UE/subscriber 473 will have a prefix with certain preferred and valid lifetimes. The 474 WLAN-GW extends these lifetimes by sending an unsolicited RA, the 475 applicable MaxRtrAdvInterval on the WLAN-GW MUST therefore be lower 476 than the preferred lifetime. As a consequence of this process is 477 that the WLAN-GW never knows when a UE/subscriber stops using 478 addresses from a prefix and additional procedures are required to 479 help the WLAN-GW to gain this information. When using stateful 480 DHCPv6 IA_NA for IPv6 UE/subscriber address assignment this 481 uncertainty on the WLAN-GW is not of impact due to the stateful 482 nature of DHCPv6 IA_NA address assignment. 484 Following is reference table of the key IPv6 router discovery and 485 neighbor discovery timers: 487 o IPv6 Router Advertisement Interval = 300s 489 o IPv6 Router LifeTime = 3600s 491 o Reachable time = 30s 493 o IPv6 Valid Lifetime = 3600s 494 o IPv6 Preferred Lifetime = 1800s 496 o Retransmit timer = 0s 498 The stateless nature of the UE/subscriber IPv6 SLAAC connectivity 499 model provides value to make sure that the UE/subscriber context is 500 timely removed from the WLAN-GW to avoid ongoing resource depletion. 501 A possible solution is to use a subscriber inactivity timer which 502 after tracking a pre-defined (currently unspecified) # of minutes 503 deletes the subscriber context on the WLAN-GW. 505 When using SLAAC the UE/subscriber the IP address assignment happens 506 without a WLAN-GW controlled state machine, and as result there is no 507 state-information on the WLAN-GW about actual IPv6 address usage. To 508 accomodate this the WLAN-GW can periodically perform a Subscriber 509 Host Connectivity Verification (i.e. periodically ping each IPv6 UE/ 510 subscriber from the WLAN-GW) to make sure that the subscriber table 511 on the WLAN-GW is correct and that the inactive UE/subscribers are 512 removed. 514 When employing stateless IPv6 address assignment a number of widely 515 deployed operating systems will attempt to utilize RFC 4941 RFC4941 516 [RFC4941] temporary 'private' addresses. This can lead to the 517 consequence that a UE has multiple /128 addresses from the same IPv6 518 prefix. The WLAN-GW MUST be able to handle the presence and use of 519 multiple globally routable IPv6 addresses. 521 When geo-localisation is of importance the WLAN-GW needs to have 522 information about the Access Point to which the UE/subscriber is 523 connected. In an environment using DHCPv6 IA_NA for IPv6 address 524 assignment this is achieved by having the AP insert an interface-id 525 RFC3315 [RFC3315] in the UE/subscriber DHCPv6 Solicit message. The 526 interface-id format expected is [ap-mac;ssid;[o-s]], e.g. 527 [00:11:22:33:44:55;example;o] (o stands for open, s for secure). 528 This way the service provider can learn both the AP-MAC (identifies 529 location) and the SSID (identifies service). When a service provider 530 uses SLAAC IPv6 address assignment it becomes harder for the service 531 provider to rely on this type of information and alternate solutions 532 have to be used to acquire the MAC address of the Access Point to 533 which the UE/subscriber is connected. A solution could be for the 534 WLAN-GW to support NSoGRE to harvest the Access-Point MAC address to 535 which the UE/subscriber is connected. 537 For security purposes it will be important for the service provider 538 to have the capability on the WLAN-GW to have supported mechanics for 539 LI (Lawfull Intercept) and the installation of IPv6 filters per 540 subscriber. 542 For accounting purposes the WLAN-GW must be able to send usage 543 statistics per UE/subscriber using Radius attributes. 545 6. Future work 547 o Support for IPv6 prefix delegation over Wi-Fi 549 7. IANA Considerations 551 No IANA considerations are defined at this time. 553 8. Security Considerations 555 No Additional Security Considerations are made in this document. 557 9. Acknowledgements 559 The authors would like to thank the following, in alphabetical order, 560 for their contributions: 562 Lorenzo Colitti, Killian Desmedt, Brad Hilgenfeld, Wim Henderickx, 563 Erik Kline, Thomas Lynn, Phil Sanderson, Colleen Szymanik, Sanjay 564 Wadhwa 566 10. References 568 10.1. Normative References 570 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 571 C., and M. Carney, "Dynamic Host Configuration Protocol 572 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 573 2003, . 575 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 576 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 577 RFC4862, September 2007, 578 . 580 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 581 Extensions for Stateless Address Autoconfiguration in 582 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 583 . 585 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 586 "IPv6 Router Advertisement Options for DNS Configuration", 587 RFC 6106, DOI 10.17487/RFC6106, November 2010, 588 . 590 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 591 Transition Mechanisms during IPv6 Deployment", RFC 6180, 592 DOI 10.17487/RFC6180, May 2011, 593 . 595 10.2. Informative References 597 [I-D.ietf-v6ops-v4v6tran-framework] 598 Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for 599 IP Version Transition Scenarios", draft-ietf-v6ops- 600 v4v6tran-framework-02 (work in progress), July 2011. 602 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 603 RFC 6343, DOI 10.17487/RFC6343, August 2011, 604 . 606 Authors' Addresses 608 John Jason Brzozowski 609 Comcast Cable 610 1701 John F. Kennedy Blvd. 611 Philadelphia, PA 612 USA 614 Email: john_brzozowski@cable.comcast.com 616 Gunter Van De Velde 617 Alcatel-Lucent 618 Antwerp 619 Belgium 621 Email: gunter.van_de_velde@alcatel-lucent.com