draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt   draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.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: April 1, 2018 Nokia Expires: April 2, 2018 Nokia
September 28, 2017 September 29, 2017
Unique IPv6 Prefix Per Host Unique IPv6 Prefix Per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-11 draft-ietf-v6ops-unique-ipv6-prefix-per-host-12
Abstract Abstract
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 service provider IPv6 address include IPv6 prefix over a unique service provider IPv6 address include
improved host isolation and enhanced subscriber management on shared improved host isolation and enhanced subscriber management on shared
network segments. network segments.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://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 April 1, 2018. This Internet-Draft will expire on April 2, 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
(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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 access network service. managed shared access network service.
A shared network service, is a service offering where a particular L2 A shared network service, is a service offering where a particular L2
skipping to change at page 4, line 51 skipping to change at page 4, line 51
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 subscriber sends a RS (Router Solicitation) message. the subscriber sends a RS (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 to compose the response to the subscriber originated RS
message. The First Hop Provider Router will answer using a solicited message. The First Hop Router will answer using a solicited RA
RA (Router Advertisement) to the subscriber. (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 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 RFC4861
[RFC4861] section 6.2.4 and 6.2.6, but instead of using the link- [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 layer multicast address associated with the all-nodes group, the
link-layer unicast address of the subscriber that has been assigned 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- the Unique IPv6 prefix contained in the RA MUST be used as the link-
layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a
solicited RA response could be sent unicast to the link-local address solicited RA response could be sent unicast to the link-local address
of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6, of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6,
nevertheless unsolicited RAs are always sent to the all-nodes group. nevertheless 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 managed pool or aggregate IPv6 block assigned to the First Hop Router
Provider Router or from a centrally allocated pool. The flags or from a centrally allocated pool. The flags indicate to the
indicate to the subscriber to use SLAAC and/or DHCPv6 for address subscriber to use SLAAC and/or DHCPv6 for address assignment; it may
assignment; it may indicate if the autoconfigured address is on/off- indicate if the autoconfigured address is on/off-link and if 'Other'
link and if 'Other' information (e.g. DNS server address) needs to information (e.g. DNS server address) needs to be requested.
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 (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)
skipping to change at page 6, line 32 skipping to change at page 6, line 30
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 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 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 Router extends these lifetimes by sending an unsolicited
unsolicited RA, the applicable MaxRtrAdvInterval on the first hop RA, the applicable MaxRtrAdvInterval on the first hop router MUST
router MUST therefore be lower than the preferred lifetime. One therefore be lower than the preferred lifetime. One consequence of
consequence of this process is that the First Hop Router never knows this process is that the First Hop Router never knows when a
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 is not
of impact due to the stateful nature of DHCPv6 IA_NA address of impact due to the stateful nature of DHCPv6 IA_NA 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 Maximum IPv6 Router Advertisement Interval = 300s (or when battery o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) =
consumption is a concern then a MinRtrAdvInterval of 514 seconds 300s (or when battery consumption is a concern 686s, see Note
(1/7 of an hour) is better according RFC7772 [RFC7772]). below)
o IIPv6 Router LifeTime = 3600s (see Note below)
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
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 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 WiFi interfaces. It is RECOMMENDED that stale neighbor
state be removed quickly. 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 RFC 4941 RFC4941 deployed operating systems will attempt to utilise RFC4941 [RFC4941]
[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 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 Router MUST be able to handle the presence and use of
of multiple globally routable IPv6 addresses. multiple globally routable IPv6 addresses.
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 a unique IPv6 Prefix per Host. compatible with assignment of a unique IPv6 Prefix per Host.
However, when combining both IPv6 privacy extensions and a unique However, when combining both IPv6 privacy extensions and a unique
IPv6 Prefix per Host a reduced privacy experience for the subscriber IPv6 Prefix per Host a reduced privacy experience for the subscriber
is introduced, because a prefix may be associated with a subscriber, is introduced, because a prefix may be associated with a subscriber,
even when the subscriber implemented IPv6 privacy extensions RFC4941 even when the subscriber implemented IPv6 privacy extensions RFC4941
[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 explicit thank David Farmer and Lorenzo
for their contributions: Colitti for their extended contributions and suggested text.
Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo In addition the authors would like to thank the following, in
Colitti, Killian Desmedt, David Farmer, Brad Hilgenfeld, Wim alphabetical order, for their contributions:
Henderickx, Erik Kline, Suresh Krishnan, Warren Kumari, Thomas Lynn,
Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Killian
Vyncke, Sanjay Wadhwa 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 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
 End of changes. 16 change blocks. 
35 lines changed or deleted 51 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/