--- 1/draft-ietf-v6ops-unique-ipv6-prefix-per-host-01.txt 2017-03-12 21:13:09.091371268 -0700 +++ 2/draft-ietf-v6ops-unique-ipv6-prefix-per-host-02.txt 2017-03-12 21:13:09.111371747 -0700 @@ -1,111 +1,117 @@ v6ops J. Brzozowski Internet-Draft Comcast Cable Intended status: Best Current Practice G. Van De Velde -Expires: November 11, 2016 Nokia - May 10, 2016 +Expires: September 14, 2017 Nokia + March 13, 2017 Unique IPv6 Prefix Per Host - draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 + draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 Abstract In some IPv6 environments the need has arisen for hosts to be able to utilise a unique IPv6 prefix even though the link or media may be - shared. Typically hosts (subscribers) on a shared network, like Wi- - Fi or Ethernet, will acquire unique IPv6 addresses from a common IPv6 - prefix that is allocated or assigned for use on a specific link. - Benefits of a unique IPv6 prefix compared to a unique IPv6 address - from the service provider are going from enhanced subscriber - management to improved isolation between subscribers. + shared. Typically hosts (subscribers) on a shared network, either + wired or wireless, such as Ethernet, WiFi, etc., will acquire unique + IPv6 addresses from a common IPv6 prefix that is allocated or + assigned for use on a specific link. In most deployments today IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 - router and neighbor discovery. This document outlines an approach - utilising existing IPv6 protocols to allow hosts to be assigned a - unique IPv6 prefix (instead of a unique IPv6 address from a shared - IPv6 prefix). + router and neighbor discovery. + + This document outlines an approach utilising existing IPv6 protocols + to allow hosts to be assigned a unique IPv6 prefix (instead of a + unique IPv6 address from a shared IPv6 prefix). Benefits of a unique + IPv6 prefix compared to a unique IPv6 address from the service + provider are going from improved subscriber isolation to enhanced + subscriber management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on November 11, 2016. + This Internet-Draft will expire on September 14, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 - 3. Design Princinples . . . . . . . . . . . . . . . . . . . . . 3 + 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 5. IPv6 Neighbourship Discovery Best Practices . . . . . . . . . 5 - 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 10.2. Informative References . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The concepts in this document are originally developed as part of a large scale, production deployment of IPv6 support for a provider managed shared network service. In this document IPv6 support does not preclude support for IPv4, however, the primary objectives for this work was to make it so that user equipment (UE) were capable of - an IPv6 only experience from a network operators perspective. + an IPv6 only experience from a network operators perspective. In the + context of this document, UE can be a 'regular' end-user-equipment, + as well as a server in a datacentre, assuming a shared network (wired + or wireless). + Details of IPv4 support are out of scope for this document. This document will also, in general, outline the requirements that must be satified by UE to allow for an IPv6 only experience. In most deployments today User Equipment (UE) IPv6 address assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] and/or - DHCP IA_NA RFC3315 [RFC3315]. However, at current time there is a - non-trivial UE/subscriber base not supporting DHCPv6 IA_NA, making - IPv6 SLAAC based subscriber and address management for provider - managed shared network services the technology of choice as it does - not exclude any known IPv6 implementation. This document will detail - the mechanics involved for IPv6 SLAAC based address and subscriber - management coupled with stateless DHCPv6, where beneficial. + DHCP IA_NA RFC3315 [RFC3315]. During the time when this approach was + developed and subsequently deployed it has been observed that some + operating systems do not support the use of DHCPv6 for the + acquisition of IA_NA per RFC7934 [RFC7934]. As such the use of IPv6 + SLAAC based subscriber and address management for provider managed + shared network services is the recommended technology of choice as it + does not exclude any known IPv6 implementation. In addition an + IA_NA-only network is not recommended per RFC 7934 RFC7934 [RFC7934] + section 8. This document will detail the mechanics involved for IPv6 + SLAAC based address and subscriber management coupled with stateless + DHCPv6, where beneficial. This document will focus upon the process for UEs to obtain a unique IPv6 prefix. 2. Motivation and Scope of Applicability The motivation for this work falls into the following categories: o Deployment advice for IPv6 that will allow stable and secure IPv6 only experience, even if IPv4 support is present @@ -125,21 +131,21 @@ management o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router o Provide guidelines regarding best common practices around IPv6 neighborship discovery and IPv6 address managent settings between the First Hop router and directly connected hosts/subscribers. -3. Design Princinples +3. Design Principles The First Hop router discussed in this document is the L3-Edge router responsible for the communication with the devices (hosts and subscribers) directly connected to a provider managed shared network, and to transport traffic between the directly connected devices and between directy connected devices and remote devices. The work detailed in this document is focussed to provide details regarding best common practices of the IPv6 neighborship discovery and related IPv6 address management settings between the First Hop @@ -153,24 +159,24 @@ control-plane anchor point to make sure that each subscriber is receiving the expected subscriber policy and service levels (throughput, QoS, security, parental-control, subscriber mobility management, etc.). 4. IPv6 Unique Prefix Assignment When a UE connects to the shared provider managed network and is attached it will initiate IP configuration phase. During this phase the UE will from an IPv6 perspective attempt to learn the default - IPv6 gateway, the IPv6 prefix information, the DNS information, and - the remaining information required to establish globally routable - IPv6 connectivity. For that purpose the the UE/subscriber sends a RS - (Router Solicitation) message. + IPv6 gateway, the IPv6 prefix information, the DNS information + RFC6106 [RFC6106], and the remaining information required to + establish globally routable IPv6 connectivity. For that purpose the + the UE/subscriber sends a RS (Router Solicitation) message. The First Hop Router receives this UE/subscriber RS message and starts the process to compose the response to the UE/subscriber originated RS message. The First Hop Provider Router will answer using a unicast RA (Router Advertisement) to the UE/subscriber. This RA contains a few important parameters for the EU/subscriber to consume: (1) a /64 prefix and (2) flags. The /64 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the First Hop Provider Router or from a centrally allocated pool. The flags indicate to the UE/subscriber to use SLAAC and/or DHCPv6 @@ -182,22 +188,23 @@ Provider managed shared networks are: o M-flag = 0 (UE/subscriber address is not managed through DHCPv6), this flag may be set to 1 in the future if/when DHCPv6 prefix delegation support is desired) o O-flag = 1 (DHCPv6 is used to request configuration information i.e. DNS, NTP information, not for IPv6 addressing) o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) + o L-flag = 0 (The UE/subscriber is off-link, which means that the - UE/subscriber will send packets ALWAYS to his default gateway, + UE/subscriber will ALWAYS send packets to its default gateway, even if the destination is within the range of the /64 prefix) The use of a unique IPv6 prefix per UE adds an additional level of protection and efficiency as it relates to how IPv6 Neighbor Discovery and Router Discovery processing. Since the UE has a unique IPv6 prefix all traffic by default will be directed to the First Hop provider router. Further, the flag combinations documented above maximize the IPv6 configurations that are available by hosts including the use of privacy IPv6 addressing. @@ -219,86 +226,86 @@ subscriber will for that purpose perform Duplicate Address Detection algorithm. This will occur for each address the UE attempts to utilize on the shared provider managed network. 5. IPv6 Neighbourship Discovery Best Practices An operational consideration when using IPv6 address assignment using IPv6 SLAAC is that after the onboarding procedure the UE/subscriber will have a prefix with certain preferred and valid lifetimes. The First Hop Provider Router extends these lifetimes by sending an - unsolicited RA, the applicable MaxRtrAdvInterval on the WLAN-GW MUST - therefore be lower than the preferred lifetime. As a consequence of - this process is that the First Hop Router never knows when a UE/ - subscriber stops using addresses from a prefix and additional - procedures are required to help the First Hop Router to gain this - information. When using stateful DHCPv6 IA_NA for IPv6 UE/subscriber - address assignment this uncertainty on the First Hop Router is not of - impact due to the stateful nature of DHCPv6 IA_NA address assignment. + unsolicited RA, the applicable MaxRtrAdvInterval on the first hop + router MUST therefore be lower than the preferred lifetime. As a + consequence of this process is that the First Hop Router never knows + when a UE/subscriber stops using addresses from a prefix and + additional procedures are required to help the First Hop Router to + gain this information. When using stateful DHCPv6 IA_NA for IPv6 UE/ + subscriber address assignment this uncertainty on the First Hop + Router is not of impact due to the stateful nature of DHCPv6 IA_NA + address assignment. Following is reference table of the key IPv6 router discovery and neighbor discovery timers for provider managed shared networks: o IPv6 Router Advertisement Interval = 300s o IPv6 Router LifeTime = 3600s o Reachable time = 30s o IPv6 Valid Lifetime = 3600s o IPv6 Preferred Lifetime = 1800s o Retransmit timer = 0s The stateless nature of the UE/subscriber IPv6 SLAAC connectivity model provides value to make sure that the UE/subscriber context is timely removed from the First Hop Router to avoid ongoing resource - depletion. A possible solution is to use a subscriber inactivity + depletion in the case of non-permanent UE, such as in the case of + WiFi hotspots. A possible solution is to use a subscriber inactivity timer which after tracking a pre-defined (currently unspecified) # of minutes deletes the subscriber context on the First Hop Router. When employing stateless IPv6 address assignment a number of widely deployed operating systems will attempt to utilize RFC 4941 RFC4941 - [RFC4941] temporary 'private' addresses. This can lead to the - consequence that a UE has multiple /128 addresses from the same IPv6 - prefix. The First Hop Provder Router MUST be able to handle the - presence and use of multiple globally routable IPv6 addresses. + [RFC4941] temporary 'private' addresses. + + Similarly, when using this technology in a datacentre, the UE server + may need to use several addresses from the same /64, for example + because is using multiple virtual hosts, containers, etc. in the + bridged virtual switch. This can lead to the consequence that a UE + has multiple /128 addresses from the same IPv6 prefix. The First Hop + Provider Router MUST be able to handle the presence and use of + multiple globally routable IPv6 addresses. For accounting purposes the First Hop Provider Router must be able to send usage statistics per UE/subscriber using Radius attributes. -6. Future work - - o Informational draft regarding WLAN IPv6 Deployment technology - experiences roll-out - -7. IANA Considerations +6. IANA Considerations No IANA considerations are defined at this time. -8. Security Considerations +7. Security Considerations - No Additional Security Considerations are made in this document. + No additional security considerations are made in this document. -9. Acknowledgements +8. Acknowledgements The authors would like to thank the following, in alphabetical order, for their contributions: - Lorenzo Colitti, Killian Desmedt, Brad Hilgenfeld, Wim Henderickx, - Erik Kline, Thomas Lynn, Phil Sanderson, Colleen Szymanik, Sanjay - Wadhwa - -10. References + Tim Chown, Lorenzo Colitti, Killian Desmedt, Brad Hilgenfeld, Wim + Henderickx, Erik Kline, Thomas Lynn, Jordi Palet, Phil Sanderson, + Colleen Szymanik, Eric Vyncke, Sanjay Wadhwa -10.1. Normative References +9. Normative References [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . @@ -306,35 +313,24 @@ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, . - [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 - Transition Mechanisms during IPv6 Deployment", RFC 6180, - DOI 10.17487/RFC6180, May 2011, - . - -10.2. Informative References - - [I-D.ietf-v6ops-v4v6tran-framework] - Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for - IP Version Transition Scenarios", draft-ietf-v6ops- - v4v6tran-framework-02 (work in progress), July 2011. - - [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", - RFC 6343, DOI 10.17487/RFC6343, August 2011, - . + [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, + "Host Address Availability Recommendations", BCP 204, + RFC 7934, DOI 10.17487/RFC7934, July 2016, + . Authors' Addresses John Jason Brzozowski Comcast Cable 1701 John F. Kennedy Blvd. Philadelphia, PA USA Email: john_brzozowski@cable.comcast.com