draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt   draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt 
v6ops J. Brzozowski v6ops J. Brzozowski
Internet-Draft Comcast Cable Internet-Draft Comcast Cable
Intended status: Best Current Practice G. Van De Velde Intended status: Best Current Practice G. Van De Velde
Expires: February 1, 2018 Nokia Expires: March 17, 2018 Nokia
July 31, 2017 September 13, 2017
Unique IPv6 Prefix Per Host Unique IPv6 Prefix Per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
Abstract Abstract
In some IPv6 environments, the need has arisen for hosts to be able
to utilize a unique IPv6 prefix, even though the link or media may be
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 This document outlines an approach utilising 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 unique
IPv6 prefix over a unique IPv6 address from the service provider IPv6 prefix over a unique service provider IPv6 address include
include improved subscriber isolation and enhanced subscriber improved host isolation and enhanced subscriber management on shared
management. network segments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 1, 2018.
This Internet-Draft will expire on March 17, 2018.
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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4
5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6 5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The concepts in this document are originally developed as part of a The concepts in this document are 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 network service. In this document IPv6 support does managed shared access network service.
not preclude support for IPv4; however, the primary objectives for
this work was to make it so that user equipment (UE) were capable of A shared network service, is a service offering where a particular L2
an IPv6 only experience from a network operators perspective. In the access network (i.e. wifi) is shared and used by multiple visiting
context of this document, UE can be 'regular' end-user-equipment, as devices (i.e. subscribers). Many service providers offering shared
well as a server in a datacenter, assuming a shared network (wired or access network services, have legal requirements, or find it good
wireless). practice, to provide isolation between the connected visitor devices
to control potential abuse of the shared access network.
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. In the context of this document, UE
can be 'regular' end-user-equipment, as well as a server in a
datacenter, assuming a shared network (wired or wireless).
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, User Equipment (UE) IPv6 address
assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862]
and/or DHCP IA_NA RFC3315 [RFC3315]. During the time when this and/or DHCP IA_NA (Identity Association - Non-temporary Address)
approach was developed and subsequently deployed, it has been RFC3315 [RFC3315]. During the time when this approach was developed
observed that some operating systems do not support the use of DHCPv6 and subsequently deployed, it has been observed that some operating
for the acquisition of IA_NA per RFC7934 [RFC7934]. As such the use systems do not support the use of DHCPv6 for the acquisition of IA_NA
of IPv6 SLAAC based subscriber and address management for provider per RFC7934 [RFC7934]. To not exclude any known IPv6
managed shared network services is the recommended technology of implementations, IPv6 SLAAC based subscriber and address management
choice, as it does not exclude any known IPv6 implementation. In is the recommended technology to reach highest percentage of
addition an IA_NA-only network is not recommended per RFC 7934 connected IPv6 devices on a provider managed shared network service.
In addition an IA_NA-only network is not recommended per RFC 7934
RFC7934 [RFC7934] section 8. This document will detail the mechanics RFC7934 [RFC7934] section 8. This document will detail the mechanics
involved for IPv6 SLAAC based address and subscriber management involved for IPv6 SLAAC based address and subscriber management
coupled with stateless DHCPv6, where beneficial. coupled with stateless DHCPv6, where beneficial.
This document will focus upon the process for UEs to obtain a unique This document focuses upon the process for UEs to obtain a unique
IPv6 prefix. IPv6 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Motivation and Scope of Applicability 2. Motivation and Scope of Applicability
skipping to change at page 4, line 25 skipping to change at page 4, line 20
and to transport traffic between the directly connected devices and and to transport traffic between the directly connected devices and
between directly connected devices and remote devices. 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 neighbor discovery and
related IPv6 address management settings between the First Hop router related IPv6 address management settings between the First Hop router
and directly connected hosts/subscribers. The documented Best and directly connected hosts/subscribers. The documented Best
Current Practice helps a service provider to better manage the shared Current Practice helps a service provider to better manage the shared
provider managed network on behalf of the connected devices. provider managed network on behalf of the connected devices.
The Best Current Practice documented in this note is to provide a This document recommends providing a unique IPv6 prefix to devices
unique IPv6 prefix to hosts/subscribers devices connected to the connected to the managed shared network. Each unique IPv6 prefix can
provider managed shared network. Each unique IPv6 prefix can function as control-plane anchor point to make sure that each device
function as control-plane anchor point to make sure that each receives expected subscriber policy and service levels (throughput,
subscriber is receiving expected subscriber policy and service levels QoS, security, parental-control, subscriber mobility management,
(throughput, QoS, security, parental-control, subscriber mobility etc.).
management, etc.).
4. IPv6 Unique Prefix Assignment 4. IPv6 Unique Prefix Assignment
When a UE connects to the shared provider managed network and is When a UE connects to the shared provider managed network and is
attached, it will initiate IP configuration phase. During this phase attached, it will initiate IP configuration phase. During this phase
the UE will, from an IPv6 perspective, attempt to learn the default the UE will, from an IPv6 perspective, attempt to learn the default
IPv6 gateway, the IPv6 prefix information, the DNS information IPv6 gateway, the IPv6 prefix information, the DNS information
RFC8106 [RFC8106], and the remaining information required to RFC8106 [RFC8106], and the remaining information required to
establish globally routable IPv6 connectivity. For that purpose, the establish globally routable IPv6 connectivity. For that purpose, the
the UE/subscriber sends a RS (Router Solicitation) message. the subscriber sends a RS (Router Solicitation) message.
The First Hop Router receives this UE/subscriber RS message and The First Hop Router receives this subscriber RS message and starts
starts the process to compose the response to the UE/subscriber the process to compose the response to the subscriber originated RS
originated RS message. The First Hop Provider Router will answer message. The First Hop Provider Router will answer using a,
using a unicast RA (Router Advertisement) to the UE/subscriber. This preferably unicast, RA (Router Advertisement) RFC6085 [RFC6085] to
RA contains two important parameters for the EU/subscriber to the subscriber. This RA contains two important parameters for the
consume: a Unique IPv6 prefix (currently a /64 prefix) and some EU/subscriber to consume: a Unique IPv6 prefix (currently a /64
flags. The Unique IPv6 prefix can be derived from a locally managed prefix) and some flags. The Unique IPv6 prefix can be derived from a
pool or aggregate IPv6 block assigned to the First Hop Provider locally managed pool or aggregate IPv6 block assigned to the First
Router or from a centrally allocated pool. The flags indicate to the Hop Provider Router or from a centrally allocated pool. The flags
UE/subscriber to use SLAAC and/or DHCPv6 for address assignment; it indicate to the subscriber to use SLAAC and/or DHCPv6 for address
may indicate if the autoconfigured address is on/off-link and if assignment; it may indicate if the autoconfigured address is on/off-
'Other' information (e.g. DNS server address) needs to be requested. 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 The IPv6 RA flags used for best common practice in IPv6 SLAAC based
Provider managed shared networks are: Provider managed shared networks are:
o M-flag = 0 (UE/subscriber address is not managed through DHCPv6), 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 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 UE/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 UE/subscriber will NEVER assume destination addresses that the subscriber will never assume destination addresses that match
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 UE adds an additional level of The use of a unique IPv6 prefix per subscriber adds an additional
protection and efficiency as it relates to how IPv6 Neighbor level of protection and efficiency as it relates to how IPv6 Neighbor
Discovery and Router Discovery processing. Since the UE has a unique Discovery and Router Discovery processing. Since the UE has a unique
IPv6 prefix all traffic by default will be directed to the First Hop IPv6 prefix all traffic by default will be directed to the First Hop
provider router. Further, the flag combinations documented above router. Further, the flag combinations documented above maximise the
maximise the IPv6 configurations that are available by hosts IPv6 configurations that are available by hosts including the use of
including the use of privacy IPv6 addressing. privacy IPv6 addressing.
The architected result of designing the RA as documented above is The architected result of designing the RA as documented above is
that each UE/subscriber gets its own unique IPv6 prefix for which it that each subscriber gets its own unique IPv6 prefix. Each host can
can use SLAAC or any other method to select its /128 unique address. consequently use SLAAC or any other method of choice to select its
In addition it will use stateless DHCPv6 to get the IPv6 address of /128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or
the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive IPv6 Router Advertisement Options for DNS Configuration RFC8106
a service provider managed IPv6 address. If the UE/subscriber [RFC8106] can be used to get the IPv6 address of the DNS server. If
desires to send anything external including other UE/subscriber the subscriber desires to send anything external including other
devices (assuming device to device communications is enabled and subscriber devices (assuming device to device communications is
supported), then, due to the L-bit set, it SHOULD send this traffic enabled and supported), then, due to the L-bit being unset, it SHOULD
to the First Hop Provider Router. send this traffic to the First Hop Router.
After the UE/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 UE/subscriber device itself, it will need address is composed by the subscriber device itself, it will need to
to verify that the address is unique on the shared network. The UE/ 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 Duplicate Address Detection
algorithm. This will occur for each address the UE attempts to algorithm. This will occur for each address the UE attempts to
utilize on the shared provider managed network. utilize on the shared provider managed network.
5. IPv6 Neighbor Discovery Best Practices 5. IPv6 Neighbor Discovery Best Practices
An operational consideration when using IPv6 address assignment using An operational consideration when using IPv6 address assignment using
IPv6 SLAAC is that after the onboarding procedure, the UE/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 Provider Router extends these lifetimes by sending an First Hop Provider Router extends these lifetimes by sending an
unsolicited RA, the applicable MaxRtrAdvInterval on the first hop unsolicited RA, the applicable MaxRtrAdvInterval on the first hop
router MUST therefore be lower than the preferred lifetime. One router MUST therefore be lower than the preferred lifetime. One
consequence of this process is that the First Hop Router never knows consequence of this process is that the First Hop Router never knows
when a UE/subscriber stops using addresses from a prefix and when a subscriber stops using addresses from a prefix and additional
additional procedures are required to help the First Hop Router to procedures are required to help the First Hop Router to gain this
gain this information. When using stateful DHCPv6 IA_NA for IPv6 UE/ information. When using stateful DHCPv6 IA_NA for IPv6 subscriber
subscriber address assignment, this uncertainty on the First Hop address assignment, this uncertainty on the First Hop Router is not
Router is not of impact due to the stateful nature of DHCPv6 IA_NA of impact due to the stateful nature of DHCPv6 IA_NA address
address assignment. assignment.
Following is a reference table of the key IPv6 router discovery and Following is a reference table of the key IPv6 router discovery and
neighbor discovery timers for provider managed shared networks: neighbor discovery timers for provider managed shared networks:
o IPv6 Router Advertisement Interval = 300s o Maximum IPv6 Router Advertisement Interval = 300s (or 600s when
battery consumption is a concern according RFC7772 [RFC7772]).
o IPv6 Router LifeTime = 3600s o IPv6 Router LifeTime = 3600s
o Reachable time = 30s o Reachable time = 30s
o IPv6 Valid Lifetime = 3600s o IPv6 Valid Lifetime = 3600s
o IPv6 Preferred Lifetime = 1800s o IPv6 Preferred Lifetime = 1800s
o Retransmit timer = 0s o Retransmit timer = 0s
The stateless nature of the UE/subscriber IPv6 SLAAC connectivity The stateless nature of the subscriber IPv6 SLAAC connectivity model
model provides a consideration to make regarding resource consumption introduces non-optimal resource consumption (i.e. memory, neighbor
(i.e. memory, neighbor state) on the First Hop Router. To reduce state) on the First Hop Router. To reduce undesired resource
undesired resource consumption on the First Hop Router the desire is consumption, such as in the case of WiFi hotspots, is to remove
to remove UE/subscriber context in the case of non-permanent UE, such subscriber context as quickly as possible when a device or subscriber
as in the case of WiFi hotspots as quickly as possible. A possible becomes non-active. A possible solution is to use a subscriber or
solution is to use a subscriber inactivity timer which, after device inactivity timer, that after tracking a pre-defined (currently
tracking a pre-defined (currently unspecified) number of minutes, unspecified) number of minutes, deletes the subscriber context on the
deletes the subscriber context on the First Hop Router. First Hop Router.
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 RFC 4941 RFC4941 deployed operating systems will attempt to utilise RFC 4941 RFC4941
[RFC4941] temporary 'private' addresses. [RFC4941] temporary 'private' addresses.
Similarly, when using this technology in a datacenter, the UE server Similarly, when using this technology in a datacenter, 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, etc.
in the bridged virtual switch. This can lead to the consequence that in the bridged virtual switch. This can lead to the consequence that
a UE has multiple /128 addresses from the same IPv6 prefix. The 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 First Hop Provider Router MUST be able to handle the presence and use
of multiple globally routable IPv6 addresses. of multiple globally routable IPv6 addresses.
For accounting purposes, the First Hop Provider Router must be able For accounting purposes, the First Hop Provider Router must be able
to send usage statistics per UE/subscriber using Radius attributes. to send usage statistics per subscriber using Radius attributes.
6. IANA Considerations 6. IANA Considerations
No IANA considerations are defined at this time. No IANA considerations are defined at this time.
7. Security Considerations 7. Security Considerations
The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is
compatible with assignment of an Unique IPv6 Prefix per Host. The compatible with assignment of a unique IPv6 Prefix per Host.
combination of both IPv6 privacy extensions and operator based However, when combining both IPv6 privacy extensions and a unique
assignment of a Unique IPv6 Prefix per Host provides each IPv6 Prefix per Host a reduced privacy experience for the subscriber
implementing operator a tool to manage and provide subscriber is introduced, because a prefix may be associated with a subscriber,
services and hence reduces the experienced privacy within each even when the subscriber implemented IPv6 privacy extensions RFC4941
operator controlled domain. However, beyond the operator controlled [RFC4941].
domain, IPv6 privacy extensions provide the desired privacy as
documented in RFC4941 [RFC4941].
No other additional security considerations are made in this No other additional security considerations are made in this
document. document.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the following, in alphabetical order, The authors would like to thank the following, in alphabetical order,
for their contributions: for their contributions:
Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian Desmedt, Brad Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian
Hilgenfeld, Wim Henderickx, Erik Kline, Warren Kumari, Thomas Lynn, Desmedt, Brad Hilgenfeld, Wim Henderickx, Erik Kline, Suresh
Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson,
Vyncke, Sanjay Wadhwa Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay Wadhwa
9. Normative References 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,
<http://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, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, DOI 10.17487/RFC6085, January 2011,
<https://www.rfc-editor.org/info/rfc6085>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
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 USA
Email: john_brzozowski@cable.comcast.com Email: john_brzozowski@cable.comcast.com
 End of changes. 37 change blocks. 
120 lines changed or deleted 127 lines changed or added

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