draft-ietf-v6ops-unique-ipv6-prefix-per-host-13.txt   rfc8273.txt 
v6ops J. Brzozowski Internet Engineering Task Force (IETF) J. Brzozowski
Internet-Draft Comcast Cable Request for Comments: 8273 Comcast Cable
Intended status: Best Current Practice G. Van De Velde Category: Informational G. Van de Velde
Expires: April 19, 2018 Nokia ISSN: 2070-1721 Nokia
October 16, 2017 December 2017
Unique IPv6 Prefix Per Host Unique IPv6 Prefix per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-13
Abstract Abstract
This document outlines an approach utilising existing IPv6 protocols This document outlines an approach utilizing existing IPv6 protocols
to allow hosts to be assigned a unique IPv6 prefix (instead of a to allow hosts to be assigned a unique IPv6 prefix (instead of a
unique IPv6 address from a shared IPv6 prefix). Benefits of unique unique IPv6 address from a shared IPv6 prefix). Benefits of using a
IPv6 prefix over a unique service provider IPv6 address include unique IPv6 prefix over a unique service-provider IPv6 address
improved host isolation and enhanced subscriber management on shared include improved host isolation and enhanced subscriber management on
network segments. shared network segments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on April 19, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8273.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 4. Assignment of IPv6 Unique Prefixes . . . . . . . . . . . . . 4
5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6 5. Best Practices for IPv6 Neighbor Discovery . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The concepts in this document are originally developed as part of a The concepts in this document were originally developed as part of a
large scale, production deployment of IPv6 support for a provider large-scale production deployment of IPv6 support for a provider-
managed shared access network service. managed shared-access network service.
A shared network service, is a service offering where a particular L2 A shared-access network service is a service offering in which a
access network (e.g. wifi) is shared and used by multiple visiting particular Layer 2 (L2) access network (e.g., Wi-Fi) is shared and
devices (i.e. subscribers). Many service providers offering shared used by multiple visiting devices (i.e., subscribers). Many service
access network services, have legal requirements, or find it good providers offering shared-access network services have legal
practice, to provide isolation between the connected visitor devices requirements, or find it good practice, to provide isolation between
to control potential abuse of the shared access network. the connected visitor devices to control potential abuse of the
shared-access network.
A network implementing a unique IPv6 prefix per host, can simply A network implementing a unique IPv6 prefix per host can simply
ensure that devices cannot send packets to each other except through ensure that devices cannot send packets to each other except through
the first-hop router. This will automatically provide robust the first-hop router. This will automatically provide robust
protection against attacks between devices that rely on link-local protection against attacks between devices that rely on link-local
ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, ICMPv6 packets, such as Duplicate Address Detection (DAD) reply
malicious redirects, and rogue RAs. This form of protection is much spoofing, Neighbor Discovery (ND) cache exhaustion, malicious
more scalable and robust than alternative mechanisms such as DAD redirects, and rogue Router Advertisements (RAs). This form of
proxying, forced forwarding, or ND snooping. protection is much more scalable and robust than alternative
mechanisms such as DAD proxying, forced forwarding, or ND snooping.
In this document IPv6 support does not preclude support for IPv4; In this document IPv6 support does not preclude support for IPv4;
however, the primary objectives for this work was to make it so that however, the primary objective for this work was to make it so that
user equipment (UE) were capable of an IPv6 only experience from a user equipment (UE) were capable of an IPv6-only experience from a
network operators perspective. In the context of this document, UE network operator's perspective. In the context of this document, UE
can be 'regular' end-user-equipment, as well as a server in a can be 'regular' end-user equipment as well as a server in a data
datacenter, assuming a shared network (wired or wireless). center, assuming a shared network (wired or wireless) exists.
Details of IPv4 support are out of scope for this document. This Details of IPv4 support are out of scope for this document. This
document will also, in general, outline the requirements that must be document will also, in general, outline the requirements that must be
satisfied by UE to allow for an IPv6 only experience. satisfied by UE to allow for an IPv6-only experience.
In most current deployments, User Equipment (UE) IPv6 address In most current deployments, assignment of UE IPv6 addresses is
assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] commonly done using IPv6 Stateless Address Autoconfiguration (SLAAC)
and/or DHCP IA_NA (Identity Association - Non-temporary Address) [RFC4862] and/or DHCP IA_NA (Identity Association - Non-temporary
RFC3315 [RFC3315]. During the time when this approach was developed Address) [RFC3315]. During the time when this approach was developed
and subsequently deployed, it has been observed that some operating and subsequently deployed, it was observed that some operating
systems do not support the use of DHCPv6 for the acquisition of IA_NA systems did not support the use of DHCPv6 for the acquisition of
per RFC7934 [RFC7934]. To not exclude any known IPv6 IA_NA per [RFC7934]. To not exclude any known IPv6 implementations,
implementations, IPv6 SLAAC based subscriber and address management IPv6-SLAAC-based subscriber and address management is the recommended
is the recommended technology to reach highest percentage of technology to reach the highest percentage of connected IPv6 devices
connected IPv6 devices on a provider managed shared network service. on a provider-managed shared-access network service. In addition, an
In addition an IA_NA-only network is not recommended per RFC 7934 IA_NA-only network is not recommended per Section 8 of [RFC7934].
RFC7934 [RFC7934] section 8. This document will detail the mechanics This document will detail the mechanics involved for IPv6-SLAAC-based
involved for IPv6 SLAAC based address and subscriber management address and subscriber management coupled with stateless DHCPv6,
coupled with stateless DHCPv6, where beneficial. where beneficial.
This document focuses upon the process for UEs to obtain a unique This document focuses upon the process for UE to obtain a unique IPv6
IPv6 prefix. prefix.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Motivation and Scope of Applicability 2. Motivation and Scope of Applicability
The motivation for this work falls into the following categories: The motivation for this work falls into the following categories:
o Deployment advice for IPv6 that will allow stable and secure IPv6 o Give deployment advice for IPv6 that will allow a stable and
only experience, even if IPv4 support is present secure IPv6-only experience, even if IPv4 support is present
o Ensure support for IPv6 is efficient and does not impact the o Ensure support for IPv6 is efficient and does not impact the
performance of the underlying network and in turn the customer performance of the underlying network and, in turn, the customer
experience experience
o Allow for the greatest flexibility across host implementation to o Allow for the greatest flexibility across host implementations to
allow for the widest range of addressing and configuration allow for the widest range of addressing and configuration
mechanisms to be employed. The goal here is to ensure that the mechanisms to be employed. Ensure that the widest population of
widest population of UE implementations can leverage the UE implementations can leverage the availability of IPv6
availability of IPv6
o Lay the technological foundation for future work related to the o Lay the technological foundation for future work related to the
use of IPv6 over shared media requiring optimized subscriber use of IPv6 over shared media, requiring optimized subscriber
management management
o Two devices (subscriber/hosts), both attached to the same provider o Ensure that two devices (subscriber/hosts), both attached to the
managed shared network should only be able to communicate through same provider-managed shared-access network, should only be able
the provider managed First Hop Router. Often service providers to communicate through the provider-managed first-hop router.
have legal requirements, or find it good practice, to provide Often, service providers have legal requirements, or find it good
isolation between the connected visitor devices to control practice, to provide isolation between the connected visitor
potential abuse of the shared access network. devices in order to control potential abuse of the shared-access
network.
o Provide guidelines regarding best common practices around IPv6 o Provide guidelines regarding best common practices around IPv6 ND
neighborship discovery RFC4861 [RFC4861] and IPv6 address [RFC4861] and IPv6-address-management settings between the first-
management settings between the First Hop router and directly hop router and directly connected hosts/subscribers.
connected hosts/subscribers.
3. Design Principles 3. Design Principles
The First Hop router discussed in this document is the L3-Edge router The first-hop router discussed in this document is the L3 Edge router
responsible for the communication with the devices (hosts and responsible for the communication with the devices (hosts and
subscribers) directly connected to a provider managed shared network, subscribers) directly connected to a provider-managed shared-access
and to transport traffic between the directly connected devices and network; it is also responsible for transporting traffic between the
between directly connected devices and remote devices. directly connected devices and between directly connected devices and
remote devices.
The work detailed in this document is focused on providing details The work detailed in this document is focused on providing details
regarding best common practices of the IPv6 neighbor discovery and regarding best common practices of the IPv6 ND and related IPv6-
related IPv6 address management settings between the First Hop router address-management settings between the first-hop router and directly
and directly connected hosts/subscribers. The documented Best connected hosts/subscribers. The documented best current practice
Current Practice helps a service provider to better manage the shared helps a service provider to better manage the provider-managed
provider managed network on behalf of the connected devices. shared-access network on behalf of the connected devices.
This document recommends providing a unique IPv6 prefix to devices This document recommends providing a unique IPv6 prefix to devices
connected to the managed shared network. Each unique IPv6 prefix can connected to the provider-managed shared-access network. Each unique
function as control-plane anchor point to make sure that each device IPv6 prefix can function as a control-plane anchor point to make sure
receives expected subscriber policy and service levels (throughput, that each device receives expected subscriber policy and service
QoS, security, parental-control, subscriber mobility management, levels (throughput, QoS, security, parental control, subscriber-
etc.). mobility management, etc.).
4. IPv6 Unique Prefix Assignment 4. Assignment of IPv6 Unique Prefixes
When a UE connects to the shared provider managed network and is When a UE connects to the provider-managed shared-access network, it
attached, it will initiate IP configuration phase. During this phase will initiate the IP configuration phase. During this phase, the UE
the UE will, from an IPv6 perspective, attempt to learn the default will, from an IPv6 perspective, attempt to learn the default IPv6
IPv6 gateway, the IPv6 prefix information, the DNS information gateway, the IPv6 prefix information, the DNS information [RFC8106],
RFC8106 [RFC8106], and the remaining information required to and the remaining information required to establish globally routable
establish globally routable IPv6 connectivity. For that purpose, the IPv6 connectivity. For that purpose, the subscriber sends an RS
the subscriber sends a RS (Router Solicitation) message. (Router Solicitation) message.
The First Hop Router receives this subscriber RS message and starts The first-hop router receives this subscriber RS message and starts
the process to compose the response to the subscriber originated RS the process of composing the response to the subscriber-originated RS
message. The First Hop Router will answer using a solicited RA message. The first-hop router will answer using a solicited RA to
(Router Advertisement) to the subscriber. the subscriber.
When the First Hop 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 periodically sends unsolicited RAs, the RA MUST be sent only to the
subscriber that has been assigned the Unique IPv6 prefix contained in subscriber that has been assigned the unique IPv6 prefix contained in
the RA. This is achieved by sending a solicited RA response or the RA. This is achieved by sending a solicited RA response or
unsolicited RAs to the all-nodes group, as detailed in RFC4861 unsolicited RAs to the all-nodes group, as detailed in Sections 6.2.4
[RFC4861] section 6.2.4 and 6.2.6, but instead of using the link- and 6.2.6 of [RFC4861]; but, instead of using the link-layer
layer multicast address associated with the all-nodes group, the multicast address associated with the all-nodes group, the link-layer
link-layer unicast address of the subscriber that has been assigned unicast address of the subscriber that has been assigned the unique
the Unique IPv6 prefix contained in the RA MUST be used as the link- IPv6 prefix contained in the RA MUST be used as the link-layer
layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a destination [RFC6085]. Or, optionally in some cases, a solicited RA
solicited RA response could be sent unicast to the link-local address response could be sent (unicast) to the link-local address of the
of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6, subscriber as detailed in Section 6.2.6 of [RFC4861]; nevertheless,
nevertheless unsolicited RAs are always sent to the all-nodes group. unsolicited RAs are always sent to the all-nodes group.
This solicited RA contains two important parameters for the This solicited RA contains two important parameters for the
subscriber to consume: a Unique IPv6 prefix (currently a /64 prefix) subscriber to consume: a unique IPv6 prefix (currently a /64 prefix)
and some flags. The Unique IPv6 prefix can be derived from a locally and some flags. The unique IPv6 prefix can be derived from a locally
managed pool or aggregate IPv6 block assigned to the First Hop Router managed pool or aggregate IPv6 block assigned to the first-hop router
or from a centrally allocated pool. The flags indicate to the or from a centrally allocated pool. The flags indicate that the
subscriber to use SLAAC and/or DHCPv6 for address assignment; it may subscriber should use SLAAC and/or DHCPv6 for address assignment; it
indicate if the autoconfigured address is on/off-link and if 'Other' may indicate whether the autoconfigured address is on/off-link and if
information (e.g. DNS server address) needs to be requested. 'Other' information (e.g., DNS server address) needs to be requested.
The IPv6 RA flags used for best common practice in IPv6 SLAAC based The IPv6 RA flags used for best common practice in IPv6-SLAAC-based
Provider managed shared networks are: provider-managed shared-access networks are:
o M-flag = 0 (subscriber address is not managed through DHCPv6), o M-flag = 0 (The subscriber address is not managed through DHCPv6);
this flag may be set to 1 in the future if/when DHCPv6 prefix this flag may be set to 1 in the future if/when DHCPv6-prefix-
delegation support is desired) delegation support is desired.)
o O-flag = 1 (DHCPv6 is used to request configuration information o O-flag = 1 (DHCPv6 is used to request configuration information,
i.e. DNS, NTP information, not for IPv6 addressing) i.e., DNS, NTP information, not for IPv6 addressing.)
o A-flag = 1 (The subscriber can configure itself using SLAAC) o A-flag = 1 (The subscriber can configure itself using SLAAC.)
o L-flag = 0 (the prefix is not an on-link prefix, which means that o L-flag = 0 (The prefix is not an on-link prefix, which means that
the subscriber will never assume destination addresses that match the subscriber will never assume destination addresses that match
the prefix are on-link and will always send packets to those the prefix are on-link and will always send packets to those
addresses to the appropriate gateway according to route selection addresses to the appropriate gateway according to route selection
rules.) rules.)
The use of a unique IPv6 prefix per subscriber adds an additional The use of a unique IPv6 prefix per subscriber adds an additional
level of protection and efficiency. The protection is driven because level of protection and efficiency. The protection exists because
all external communication of a connected device is directed to the all external communication of a connected device is directed to the
first hop router as required by RFC4861 [RFC4861]. Best efficiency first-hop router as required by [RFC4861]. Best efficiency is
is achieved because the recommended RA flags allow broadest support achieved because the recommended RA flags allow the broadest support
on connected devices to receive a valid IPv6 address (i.e. privacy on connected devices to receive a valid IPv6 address (i.e., privacy
addresses RFC4941 [RFC4941] or SLAAC RFC4862 [RFC4862]). addresses [RFC4941] or SLAAC [RFC4862]).
The architected result of designing the RA as documented above is The architected result of designing the RA as documented above is
that each subscriber gets its own unique IPv6 prefix. Each host can that each subscriber gets its own unique IPv6 prefix. Each host can
consequently use SLAAC or any other method of choice to select its consequently use SLAAC or any other method of choice to select its
/128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or /128 unique address. Either stateless DHCPv6 [RFC3736] or IPv6
IPv6 Router Advertisement Options for DNS Configuration RFC8106 Router Advertisement Options for DNS Configuration [RFC8106] can be
[RFC8106] can be used to get the IPv6 address of the DNS server. If used to get the IPv6 address of the DNS server. If the subscriber
the subscriber desires to send anything external including towards desires to send anything external, including towards other subscriber
other subscriber devices (assuming device to device communications is devices (assuming device-to-device communications is enabled and
enabled and supported), then, due to the L-bit being unset, then supported), then, due to the L-bit being unset, [RFC4861] requires
RFC4861 [RFC4861] requires that this traffic is sent to the First Hop that this traffic be sent to the first-hop router.
Router.
After the subscriber received the RA, and the associated flags, it After the subscriber received the RA and the associated flags, it
will assign itself a 128 bit IPv6 address using SLAAC. Since the will assign itself a 128-bit IPv6 address using SLAAC. Since the
address is composed by the subscriber device itself, it will need to address is composed by the subscriber device itself, it will need to
verify that the address is unique on the shared network. The verify that the address is unique on the shared network. The
subscriber will for that purpose, perform Duplicate Address Detection subscriber will, for that purpose, perform the DAD algorithm. This
algorithm. This will occur for each address the UE attempts to will occur for each address the UE attempts to utilize on the
utilize on the shared provider managed network. provider-managed shared-access network.
5. IPv6 Neighbor Discovery Best Practices 5. Best Practices for IPv6 Neighbor Discovery
An operational consideration when using IPv6 address assignment using An operational consideration when using IPv6-address assignment with
IPv6 SLAAC is that after the onboarding procedure, the subscriber IPv6 SLAAC is that after the onboarding procedure, the subscriber
will have a prefix with certain preferred and valid lifetimes. The will have a prefix with certain preferred and valid lifetimes. The
First Hop Router extends these lifetimes by sending an unsolicited first-hop router extends these lifetimes by sending an unsolicited
RA, the applicable MaxRtrAdvInterval on the first hop router MUST RA, the applicable MaxRtrAdvInterval on the first-hop router MUST,
therefore be lower than the preferred lifetime. One consequence of therefore, be lower than the preferred lifetime. One consequence of
this process is that the First Hop Router never knows when a this process is that the first-hop router never knows when a
subscriber stops using addresses from a prefix and additional subscriber stops using addresses from a prefix, and additional
procedures are required to help the First Hop Router to gain this procedures are required to help the first-hop router to gain this
information. When using stateful DHCPv6 IA_NA for IPv6 subscriber information. When using stateful DHCPv6 IA_NA for IPv6-subscriber-
address assignment, this uncertainty on the First Hop Router is not address assignment, this uncertainty on the first-hop router does not
of impact due to the stateful nature of DHCPv6 IA_NA address have an impact due to the stateful nature of the assignment of DHCPv6
assignment. IA_NA addresses.
Following is a reference table of the key IPv6 router discovery and The following is a reference table of the key IPv6 router and
neighbor discovery timers for provider managed shared networks: neighbor discovery timers for provider-managed shared-access
networks:
o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) =
300s (or when battery consumption is a concern 686s, see Note 300 s (or when battery consumption is a concern 686 s, see note
below) below)
o IIPv6 Router LifeTime = 3600s (see Note below) o IPv6 Router Lifetime = 3600 s (see note below)
o Reachable time = 30s o Reachable time = 30 s
o IPv6 Valid Lifetime = 3600s o IPv6 Valid Lifetime = 3600 s
o IPv6 Preferred Lifetime = 1800s
o Retransmit timer = 0s o IPv6 Preferred Lifetime = 1800 s
o Retransmit timer = 0 s
Note: When servicing large numbers of battery powered devices, Note: When servicing large numbers of battery powered devices,
RFC7772 [RFC7772] suggests a maximum of 7 RAs per hour and a 45-90 [RFC7772] suggests a maximum of seven RAs per hour and a 45-90 minute
minute IPv6 Router Lifetime. To achieve a maximum of 7 RAs per hour, IPv6 Router Lifetime. To achieve a maximum of seven RAs per hour,
the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is
the important parameter, and MUST be greater than or equal to 514 the important parameter, and it MUST be greater than or equal to 514
seconds (1/7 of an hour). Further as discussed in RFC4861 [RFC4861] seconds (1/7 of an hour). Further, as discussed in Section 6.2.1. of
section 6.2.1, MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval, [RFC4861], MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval; therefore,
therefore MaxRtrAdvInterval MUST additionally be greater than or MaxRtrAdvInterval MUST additionally be greater than or equal to 686
equal to 686 seconds. As for the recommended IPv6 Router Lifetime, seconds. As for the recommended IPv6 Router Lifetime, since this
since this technique requires that RAs are sent using the link-layer technique requires that RAs be sent using the link-layer unicast
unicast address of the subscriber, the concerns over multicast address of the subscriber, the concerns over multicast delivery
delivery discussed in RFC7772 [RFC7772] are already mitigated, discussed in [RFC7772] are already mitigated; therefore, the above
therefore the above suggestion of 3600 seconds (an hour) seems suggestion of 3600 seconds (an hour) seems sufficient for this use
sufficient for this use case. case.
IPv6 SLAAC requires the router to maintain neighbor state, which IPv6 SLAAC requires the router to maintain neighbor state, which
implies costs in terms of memory, power, message exchanges, and implies costs in terms of memory, power, message exchanges, and
message processing. Stale entries can prove an unnecessary burden, message processing. Stale entries can prove an unnecessary burden,
especially on WiFi interfaces. It is RECOMMENDED that stale neighbor especially on Wi-Fi interfaces. It is RECOMMENDED that stale
state be removed quickly. neighbor state be removed quickly.
When employing stateless IPv6 address assignment, a number of widely When employing stateless IPv6 address assignment, a number of widely
deployed operating systems will attempt to utilise RFC4941 [RFC4941] deployed operating systems will attempt to utilize [RFC4941]
temporary 'private' addresses. temporary 'private' addresses.
Similarly, when using this technology in a datacenter, the UE server Similarly, when using this technology in a data center, the UE server
may need to use several addresses from the same Unique IPv6 Prefix, may need to use several addresses from the same unique IPv6 prefix,
for example because is using multiple virtual hosts, containers, etc. for example, because is using multiple virtual hosts, containers,
in the bridged virtual switch. This can lead to the consequence that etc., in the bridged-virtual switch. This can lead to the
a UE has multiple /128 addresses from the same IPv6 prefix. The consequence that a UE has multiple /128 addresses from the same IPv6
First Hop Router MUST be able to handle the presence and use of prefix. The first-hop router MUST be able to handle the presence and
multiple globally routable IPv6 addresses. use of multiple globally routable IPv6 addresses.
6. IANA Considerations 6. IANA Considerations
No IANA considerations are defined at this time. This document does not require any IANA actions.
7. Security Considerations 7. Security Considerations
The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is The mechanics of IPv6 privacy extensions [RFC4941] are compatible
compatible with assignment of a unique IPv6 Prefix per Host. with assignment of a unique IPv6 prefix per host. However, when
However, when combining both IPv6 privacy extensions and a unique combining both IPv6 privacy extensions and a unique IPv6 prefix per
IPv6 Prefix per Host a reduced privacy experience for the subscriber host, a reduced privacy experience for the subscriber is introduced.
is introduced, because a prefix may be associated with a subscriber, This is because a prefix may be associated with a subscriber, even
even when the subscriber implemented IPv6 privacy extensions RFC4941 when the subscriber has implemented IPv6 privacy extensions
[RFC4941]. If the operator assigns the same unique prefix to the [RFC4941]. If the operator assigns the same unique prefix to the
same link-layer address every time a host connects, any remote party same link-layer address every time a host connects, any remote party
who is aware of this fact can easily track a host simply by tracking who is aware of this fact can easily track a host simply by tracking
its assigned prefix. This nullifies the benefit provided by privacy its assigned prefix. This nullifies the benefit provided by privacy
addresses RFC4941 [RFC4941]. If a host wishes to maintain privacy on addresses [RFC4941]. If a host wishes to maintain privacy on such
such networks, it SHOULD ensure that its link-layer address is networks, it SHOULD ensure that its link-layer address is
periodically changed or randomized. periodically changed or randomized.
No other additional security considerations are made in this No other additional security considerations are made in this
document. document.
8. Acknowledgements 8. Normative References
The authors would like to explicit thank David Farmer and Lorenzo
Colitti for their extended contributions and suggested text.
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
The authors would like to explicitly thank David Farmer and Lorenzo
Colitti for their extended contributions and suggested text.
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, Wim Henderickx, Brad Hilgenfeld, Erik Kline, Suresh
Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson,
Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, and Sanjay Wadhwa
Authors' Addresses Authors' Addresses
John Jason Brzozowski John Jason Brzozowski
Comcast Cable Comcast Cable
1701 John F. Kennedy Blvd. 1701 John F. Kennedy Blvd.
Philadelphia, PA Philadelphia, PA
USA United States of America
Email: john_brzozowski@cable.comcast.com Email: john_brzozowski@cable.comcast.com
Gunter Van De Velde Gunter Van de Velde
Nokia Nokia
Antwerp Antwerp
Belgium Belgium
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
 End of changes. 66 change blocks. 
225 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/