--- 1/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt 2017-09-29 03:13:08.199773553 -0700 +++ 2/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt 2017-09-29 03:13:08.223774125 -0700 @@ -1,19 +1,19 @@ v6ops J. Brzozowski Internet-Draft Comcast Cable Intended status: Best Current Practice G. Van De Velde -Expires: April 1, 2018 Nokia - September 28, 2017 +Expires: April 2, 2018 Nokia + September 29, 2017 Unique IPv6 Prefix Per Host - draft-ietf-v6ops-unique-ipv6-prefix-per-host-11 + draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 Abstract 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 unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. @@ -25,21 +25,21 @@ 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 https://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 April 1, 2018. + This Internet-Draft will expire on April 2, 2018. Copyright Notice 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,21 +52,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 access network service. A shared network service, is a service offering where a particular L2 @@ -180,46 +180,45 @@ 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 RFC8106 [RFC8106], and the remaining information required to establish globally routable IPv6 connectivity. For that purpose, the the subscriber sends a RS (Router Solicitation) message. The First Hop Router receives this subscriber RS message and starts the process to compose the response to the subscriber originated RS - message. The First Hop Provider Router will answer using a solicited - RA (Router Advertisement) to the subscriber. + message. The First Hop Router will answer using a solicited RA + (Router Advertisement) to the subscriber. - When the First Hop Provider Router sends a solicited RA response, or + When the First Hop Router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the Unique IPv6 prefix contained in the RA. This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in RFC4861 [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link- layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link- layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent unicast to the link-local address of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. This solicited RA contains two important parameters for the subscriber to consume: a Unique IPv6 prefix (currently a /64 prefix) and some flags. The Unique IPv6 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 subscriber to use SLAAC and/or DHCPv6 for address - assignment; it may indicate if the autoconfigured address is on/off- - link and if 'Other' information (e.g. DNS server address) needs to - be requested. + managed pool or aggregate IPv6 block assigned to the First Hop Router + or from a centrally allocated pool. The flags indicate to the + subscriber to use SLAAC and/or DHCPv6 for address assignment; it may + indicate if the autoconfigured address is on/off-link and if 'Other' + information (e.g. DNS server address) needs to be requested. The IPv6 RA flags used for best common practice in IPv6 SLAAC based Provider managed shared networks are: o M-flag = 0 (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) @@ -258,92 +257,109 @@ verify that the address is unique on the shared network. The 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 Neighbor Discovery Best Practices An operational consideration when using IPv6 address assignment using IPv6 SLAAC is that after the onboarding procedure, the 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 first hop - router MUST therefore be lower than the preferred lifetime. One - consequence of this process is that the First Hop Router never knows - when a subscriber stops using addresses from a prefix and additional + First Hop Router extends these lifetimes by sending an unsolicited + RA, the applicable MaxRtrAdvInterval on the first hop router MUST + therefore be lower than the preferred lifetime. One consequence of + this process is that the First Hop Router never knows when a + 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 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 a reference table of the key IPv6 router discovery and neighbor discovery timers for provider managed shared networks: - o Maximum IPv6 Router Advertisement Interval = 300s (or when battery - consumption is a concern then a MinRtrAdvInterval of 514 seconds - (1/7 of an hour) is better according RFC7772 [RFC7772]). + o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = + 300s (or when battery consumption is a concern 686s, see Note + below) + + o IIPv6 Router LifeTime = 3600s (see Note below) - o IPv6 Router LifeTime = 3600s o Reachable time = 30s o IPv6 Valid Lifetime = 3600s - o IPv6 Preferred Lifetime = 1800s o Retransmit timer = 0s + Note: When servicing large numbers of battery powered devices, + RFC7772 [RFC7772] suggests a maximum of 7 RAs per hour and a 45-90 + minute IPv6 Router Lifetime. To achieve a maximum of 7 RAs per hour, + the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is + the important parameter, and MUST be greater than or equal to 514 + seconds (1/7 of an hour). Further as discussed in RFC4861 [RFC4861] + section 6.2.1, MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval, + therefore MaxRtrAdvInterval MUST additionally be greater than or + equal to 686 seconds. As for the recommended IPv6 Router Lifetime, + since this technique requires that RAs are sent using the link-layer + unicast address of the subscriber, the concerns over multicast + delivery discussed in RFC7772 [RFC7772] are already mitigated, + therefore the above suggestion of 3600 seconds (an hour) seems + sufficient for this use case. + IPv6 SLAAC requires the router to maintain neighbor state, which implies costs in terms of memory, power, message exchanges, and message processing. Stale entries can prove an unnecessary burden, especially on WiFi interfaces. It is RECOMMENDED that stale neighbor state be removed quickly. When employing stateless IPv6 address assignment, a number of widely - deployed operating systems will attempt to utilise RFC 4941 RFC4941 - [RFC4941] temporary 'private' addresses. + deployed operating systems will attempt to utilise RFC4941 [RFC4941] + temporary 'private' addresses. Similarly, when using this technology in a datacenter, the UE server may need to use several addresses from the same Unique IPv6 Prefix, 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. + First Hop Router MUST be able to handle the presence and use of + multiple globally routable IPv6 addresses. 6. IANA Considerations No IANA considerations are defined at this time. 7. Security Considerations The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is compatible with assignment of a unique IPv6 Prefix per Host. However, when combining both IPv6 privacy extensions and a unique IPv6 Prefix per Host a reduced privacy experience for the subscriber is introduced, because a prefix may be associated with a subscriber, even when the subscriber implemented IPv6 privacy extensions RFC4941 [RFC4941]. No other additional security considerations are made in this document. 8. Acknowledgements - The authors would like to thank the following, in alphabetical order, - for their contributions: + The authors would like to explicit thank David Farmer and Lorenzo + Colitti for their extended contributions and suggested text. - Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo - Colitti, Killian Desmedt, David Farmer, Brad Hilgenfeld, Wim - Henderickx, Erik Kline, Suresh Krishnan, Warren Kumari, Thomas Lynn, - Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric - Vyncke, Sanjay Wadhwa + In addition the authors would like to thank the following, in + alphabetical order, for their contributions: + + Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Killian + Desmedt, Brad Hilgenfeld, Wim Henderickx, Erik Kline, Suresh + Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson, + Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay Wadhwa 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol