Unique IPv6 Prefix Per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-02
The information below is for an old version of the document |
Document |
Type |
|
Active Internet-Draft (v6ops WG)
|
|
Authors |
|
John Brzozowski
,
Gunter Van de Velde
|
|
Last updated |
|
2017-05-09
(latest revision 2017-03-12)
|
|
Replaces |
|
draft-jjmb-v6ops-unique-ipv6-prefix-per-host
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
Best Current Practice
|
|
Formats |
|
pdf
htmlized (tools)
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Ron Bonica
|
|
Shepherd write-up |
|
Show
(last changed 2017-05-09)
|
IESG |
IESG state |
|
Publication Requested
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Warren Kumari
|
|
Send notices to |
|
draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, Ron Bonica <rbonica@juniper.net>
|
v6ops J. Brzozowski
Internet-Draft Comcast Cable
Intended status: Best Current Practice G. Van De Velde
Expires: September 14, 2017 Nokia
March 13, 2017
Unique IPv6 Prefix Per Host
draft-ietf-v6ops-unique-ipv6-prefix-per-host-02
Abstract
In some IPv6 environments the need has arisen for hosts to be able to
utilise 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
to allow hosts to be assigned a unique IPv6 prefix (instead of a
unique IPv6 address from a shared IPv6 prefix). Benefits of a unique
IPv6 prefix compared to a unique IPv6 address from the service
provider are going from improved subscriber isolation to enhanced
subscriber management.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Brzozowski & Van De VelExpires September 14, 2017 [Page 1]
Internet-Draft Unique IPv6 Prefix Per Host March 2017
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4
5. IPv6 Neighbourship Discovery Best Practices . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The concepts in this document are originally developed as part of a
large scale, production deployment of IPv6 support for a provider
managed shared network service. 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 a 'regular' end-user-equipment,
as well as a server in a datacentre, assuming a shared network (wired
or wireless).
Details of IPv4 support are out of scope for this document. This
document will also, in general, outline the requirements that must be
satified by UE to allow for an IPv6 only experience.
In most deployments today User Equipment (UE) IPv6 address assignment
is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] and/or
Brzozowski & Van De VelExpires September 14, 2017 [Page 2]
Show full document text