draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt   draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.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: March 17, 2018 Nokia Expires: March 18, 2018 Nokia
September 13, 2017 September 14, 2017
Unique IPv6 Prefix Per Host Unique IPv6 Prefix Per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 draft-ietf-v6ops-unique-ipv6-prefix-per-host-09
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 March 17, 2018. This Internet-Draft will expire on March 18, 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 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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
access network (i.e. wifi) is shared and used by multiple visiting access network (e.g. wifi) is shared and used by multiple visiting
devices (i.e. subscribers). Many service providers offering shared devices (i.e. subscribers). Many service providers offering shared
access network services, have legal requirements, or find it good access network services, have legal requirements, or find it good
practice, to provide isolation between the connected visitor devices practice, to provide isolation between the connected visitor devices
to control potential abuse of the shared access network. to control potential abuse of the shared access network.
A network implementing a unique IPv6 prefix per host, can simply
ensure that devices cannot send packets to each other except through
the first-hop router. This will automatically provide robust
protection against attacks between devices that rely on link-local
ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion,
malicious redirects, and rogue RAs. This form of 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 objectives 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 operators 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
datacenter, assuming a shared network (wired or wireless). 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.
skipping to change at page 4, line 39 skipping to change at page 4, line 48
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, message. The First Hop Provider Router will answer using a solicited
preferably unicast, RA (Router Advertisement) RFC6085 [RFC6085] to RA (Router Advertisement) to the subscriber.
the subscriber. This RA contains two important parameters for the
EU/subscriber to consume: a Unique IPv6 prefix (currently a /64 When the First Hop Provider Router sends the solicited RA response,
prefix) and some flags. The Unique IPv6 prefix can be derived from a or a periodic unsolicited RA, the RA MUST be sent only to the UE/
locally managed pool or aggregate IPv6 block assigned to the First subscriber that has been assigned the Unique IPv6 prefix contained in
Hop Provider Router or from a centrally allocated pool. The flags the RA. This is achieved by sending a unicast RA response, as
detailed in [RFC4861] section 6.2.6, or by sending a multicast RA
response or unsolicited RA to the all-nodes group, as detailed in
[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 UE/subscriber that has been
assigned the Unique IPv6 prefix contained in the RA MUST be used as
the link-layer destination RFC6085 [RFC6085].
This solicited RA contains two important parameters for the EU/
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 indicate to the subscriber to use SLAAC and/or DHCPv6 for address
assignment; it may indicate if the autoconfigured address is on/off- assignment; it may indicate if the autoconfigured address is on/off-
link and if 'Other' information (e.g. DNS server address) needs to link and if 'Other' 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
skipping to change at page 7, line 31 skipping to change at page 8, line 6
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:
Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian
Desmedt, Brad Hilgenfeld, Wim Henderickx, Erik Kline, Suresh Desmedt, David Farmer, Brad Hilgenfeld, Wim Henderickx, Erik Kline,
Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson, Suresh Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil
Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay Wadhwa 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. 9 change blocks. 
18 lines changed or deleted 41 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/