< draft-bhandari-dhc-class-based-prefix-03.txt   draft-bhandari-dhc-class-based-prefix-04.txt >
Internet Engineering Task Force S. Bhandari Internet Engineering Task Force S. Bhandari
Internet-Draft G. Halwasia Internet-Draft G. Halwasia
Intended status: Standards Track S. Bandi Intended status: Standards Track S. Gundavelli
Expires: January 17, 2013 S. Gundavelli Expires: August 22, 2013 Cisco Systems
Cisco Systems
H. Deng H. Deng
China Mobile China Mobile
L. Thiebaut L. Thiebaut
Alcatel-Lucent Alcatel-Lucent
July 16, 2012 J. Korhonen
Renesas Mobile
February 18, 2013
DHCPv6 class based prefix DHCPv6 class based prefix
draft-bhandari-dhc-class-based-prefix-03 draft-bhandari-dhc-class-based-prefix-04
Abstract Abstract
DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 This document introduces options to communicate property and
addresses. This document extends DHCPv6 prefix delegation with class associate metadata with prefixes. It extends DHCPv6 prefix
based prefix allocation. It defines a new usage class option to delegation and address allocation using the metadata for selection of
classify a prefix. It defines the behavior of a DHCPv6 client prefixes and addresses.
requesting a prefix to include the class of the prefix to be
allocated and the DHCPv6 server behavior to select and offer a prefix
from a given class. It discusses how IA_NA can be requested and
assigned from a specific usage class.
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 http://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 January 17, 2013. This Internet-Draft will expire on August 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Mobile networks . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1.2. Home networks . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Usage Class Option . . . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Consideration for different DHCPv6 entities . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Requesting Router Behavior for IA_PD allocation . . . 6 2.1. Prefix Property and Class Options . . . . . . . . . . . . 5
2.2.2. Delegating Router Behavior for IA_PD allocation . . . 7 2.2. Consideration for different DHCPv6 entities . . . . . . . 7
2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 7 2.2.1. Requesting Router Behavior for IA_PD allocation . . . 7
2.2.4. DHCPv6 Server Behavior for IA_NA allocation . . . . . 8 2.2.2. Delegating Router Behavior for IA_PD allocation . . . 8
2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 9
2.3.1. OPTION_USAGE_CLASS Values . . . . . . . . . . . . . . 8 2.2.4. DHCPv6 Server Behavior for IA_NA allocation . . . . . 9
2.3.2. Class based prefix and IA_NA allocation . . . . . . . 9 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Class based prefix and IA_PD allocation . . . . . . . 9 2.3.1. Class based prefix and IA_NA allocation . . . . . . . 10
2.3.4. Class based prefix and SLAAC . . . . . . . . . . . . . 9 2.3.2. Class based prefix and IA_PD allocation . . . . . . . 10
2.3.5. Class based Information-Request . . . . . . . . . . . 10 2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 10
2.3.6. Class based prefix and applications . . . . . . . . . 10 2.3.4. Class based prefix and applications . . . . . . . . . 11
3. Example Application . . . . . . . . . . . . . . . . . . . . . 10 3. Example Application . . . . . . . . . . . . . . . . . . . . . 11
3.1. Class based prefix delegation . . . . . . . . . . . . . . 12 3.1. Mobile gateway example . . . . . . . . . . . . . . . . . . 11
3.2. IPv6 address assignment from class based prefix . . . . . 12 3.1.1. Class based prefix delegation . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. IPv6 address assignment from class based prefix . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.2. Homenet Example . . . . . . . . . . . . . . . . . . . . . 14
5.1. OPTION_USAGE_CLASS values . . . . . . . . . . . . . . . . 13 3.2.1. Class based prefix delegation to the HGW . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3.2.2. IPv6 Assignment to Homenet hosts using stateful
7. Change History (to be removed prior to publication as an DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 16
RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 6.1. OPTION_PREFIX_PROPERTY values . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Change History (to be removed prior to publication as an
RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism In IPv6 a network interface can acquire multiple addresses from the
for the delegation of IPv6 prefixes using DHCPv6 options. Through same scope. In such a multi-prefix network each of the multiple
these options, a delegating router can delegate prefixes to prefixes can have a specific property and purpose associated with it.
authorized requesting routers. If the requesting router has to Example: In a mobile network a mobile device can be assigned a prefix
function as a DHCPv6 server there needs to be additional information from its home network and another from the visiting network that it
in the delegated prefix that helps the requesting router to select is attached to. Another example is a prefix may provide free
the address allocation for the DHCPv6 client it serves, from one of internet access without offering any quality of service guarantees
the available delegated prefixes. while another prefix may be charged along with providing quality of
service guarantees for network service access. A prefix can have
well defined properties that is universal and have a metadata
associated with it that communicates its local significance. The
properties and metadata of prefix will be relevant for prefix
delegation, source address selection as elaborated in the subsequent
sections.
One way to select an address or longer prefix (from a delegated This document defines OPTION_PREFIX_PROPERTY option that communicates
prefix) to be allocated by a requesting router playing the role of a property of the prefix that is universally understood.This document
DHCPv6 server is by introducing additional options in IA_PD to be defines OPTION_PREFIX_CLASS option to communicate metadata of the
matched with options for address selection in the DHCPv6 SOLICIT prefix that communicates the prefix's local significance.
message. [RFC3315] defines the OPTION_USER_CLASS option which is
used for selecting address for assignment. But the OPTION_USER_CLASS
option is only loosely defined and it can hardly be used in mobile
environment where a DHCPv6 client, the DHCPv6 server or requesting
router and the delegating Router may belong to different
organizations.
This document introduces OPTION_USAGE_CLASS option in IA_PD option This document discusses usage of OPTION_PREFIX_CLASS to request and
for the purpose of selecting a prefix for further delegation either select prefixes with specific metadata via IA_PD and IA_NA as defined
via IA_NA or IA_PD DHCPv6 request. It defines the behavior of the in [RFC3633] and[RFC3315] respectively.This document defines the
DHCPv6 server, the DHCPv6 prefix requesting router and the DHCPv6 behavior of the DHCPv6 server, the DHCPv6 prefix requesting router
client to use this option. and the DHCPv6 client to use OPTION_PREFIX_CLASS option for
requesting and selecting prefixes and addresses.
In IPv6 a network interface can acquire multiple addresses from the The network address can be configured via DHCPv6 as defined in
same scope. In this case application need to have additional [RFC3315] or via Stateless Address Autoconfiguration (SLAAC) as
information about the prefix configured on the interface for source defined in [RFC4862], additional information of a prefix can be
address selection. Since the network address can be configured via provided via DHCPv6 or via IPv6 Router Advertisement (RA). The
DHCPv6 as defined in [RFC3315] or via Stateless Address information provided in the options defined in this document
Autoconfiguration (SLAAC) as defined in [RFC4862], additional OPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS can be used for source
information of a prefix can be provided via DHCPv6 or via IPv6 Router address selection. Communicated property and metadata information
Advertisement (RA). about the prefix via IPv6 Router Advertisement (RA) will be dealt
with in separate document [I-D.korhonen-dmm-prefix-properties].
1.1. Motivation 1.1. Motivation
In this section motivation for class based prefix delegation that In this section motivation for class based prefix delegation that
qualifies the delegated prefix with additional class information is qualifies the delegated prefix with additional class information is
described in the context of mobile networks. The class information described in the context of mobile networks and home networks. The
attached to a delegated prefix helps to distinguish property of a property information attached to a delegated prefix helps to
delegated IPv6 prefix and selection of the prefix by different distinguish a delegated IPv6 prefix and selection of the prefix by
applications using it. different applications using it.
1.1.1. Mobile networks
In the mobile network architecture, there is a mobile router which In the mobile network architecture, there is a mobile router which
functions as a IP network gateway and provides IP connectivity to functions as a IP network gateway and provides IP connectivity to
mobile nodes. Mobile router can be the requesting router requesting mobile nodes. Mobile router can be the requesting router requesting
delegated IPv6 prefix using DHCPv6. Mobile router can assume the delegated IPv6 prefix using DHCPv6. Mobile router can assume the
role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to
it. A mobile node in mobile network architecture can be associated it. A mobile node in mobile network architecture can be associated
with multiple IPv6 prefixes belonging to different domains for e.g. with multiple IPv6 prefixes belonging to different domains for e.g.
home address prefix, care of address prefix as specified in home address prefix, care of address prefix as specified in
[RFC3775]. [RFC3775].
The delegated prefixes when seen from the mobile router perspective The delegated prefixes when seen from the mobile router perspective
appear to be like any other prefix, but each prefixes have different appear to be like any other prefix, but each prefixes have different
properties referred to as "Prefix Color" in the mobile networks. metadata referred to as "Prefix Color" in the mobile networks. Some
Some delegated prefixes may be topologically local and some may be delegated prefixes may be topologically local and some may be remote
remote prefixes anchored on a global anchor, but available to the prefixes anchored on a global anchor, but available to the local
local anchor by means of tunnel setup in the network between the anchor by means of tunnel setup in the network between the local and
local and global anchor. Some may be local with low latency global anchor. Some may be local with low latency characteristics
characteristics suitable for voice call break-out, some may have suitable for voice call break-out, some may have global mobility
global mobility support. So, the prefixes have different properties support. So, the prefixes have different properties and it is
and it is required for the application using the prefix to learn required for the application using the prefix to learn about this
about this property in order to use it intelligently. There is property in order to use it intelligently. There is currently no
currently no semantics in DHCPv6 prefix delegation that can carry semantics in DHCPv6 prefix delegation that can carry this information
this information to specify properties of a delegated prefix. In to specify properties of a delegated prefix. In this scenario, the
this scenario, the mobile router is unable to further delegate a mobile router is unable to further delegate a longer prefix
longer prefix intelligently based on properties of the prefix learnt. intelligently based on properties of the prefix learnt. Neither is a
mobile device able to learn about the property of the prefix assigned
to influence source address selection. Example to determine if the
prefix is a home address or care of address.
1.1.2. Home networks
In a fixed network environment, the homenet CPE may also function as
both a DHCPv6 client (requesting the IA_PD(s)) and a DHCPv6 server
allocating prefixes from delegated prefix(es) to downstream home
network hosts. Some service providers may wish to delegate multiple
prefixes to the CPE for use by different services classes and traffic
types.
Motivations for this include:
o Using source prefix to identify the service class / traffic type
that is being transported. The source prefix may then reliably be
used as a parameter for differentiated services or other purposes.
E.g. [I-D.jiang-v6ops-semantic-prefix]
o Using the specific source prefix as a host identifier for other
services. E.g. as an input parameter to a DHCPv4 over IPv6 server
[I-D.ietf-dhc-dhcpv4-over-ipv6]
To meet these requirements, when the CPE (functioning as a DHCPv6
server) receives an IA_NA or IA_TA request from a homenet host, a
mechanism is required so that the correct prefix for requested
service class can be selected for allocation. Likewise for DHCPv6
clients located in the homenet, a mechanism is necessary so that the
intended service class for a requested prefix can be signalled to the
DHCPv6 server.
1.2. Terminology 1.2. Terminology
This document uses the terminology defined in [RFC2460], [RFC3315] This document uses the terminology defined in [RFC2460], [RFC3315]
and [RFC3633]. and [RFC3633].
1.3. Requirements Language 1.3. 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. Overview 2. Overview
This section defines usage class option in IA_PD and IA_NA to aid This section defines prefix property and prefix class options in
class based prefix delegation and address assignment. This section IA_PD and IA_NA. This section defines the behavior of the delegating
defines the behavior of the delegating router, the requesting router router, the requesting router and the DHCPv6 client. It discusses
and the DHCPv6 client. It defines also usage class option in the these options in the context of a DHCPv6 information request from a
context of a DHCP information request from a DHCP client to a DHCP DHCPv6 client to a DHCPv6 server.
server.
2.1. Usage Class Option 2.1. Prefix Property and Class Options
The format of the DHCPv6 prefix property and prefix class options are
shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFIX_PROPERTY | option-length(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Properties |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the DHCPv6 usage class option is shown below. option-code: OPTION_PREFIX_PROPERTY (TBD1)
0 1 2 3 option-length: 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Properties: 16 bits maintained as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OPTION_PREFIX_PROPERTY in
| OPTION_USAGE_CLASS | option-length(2) | IANA registered namespace.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each value in the registry represents a property.
| Class | ~ Multiple properties can be represented by bitwise
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ ORing of the individual property values in this
~ Vendor Class Data (Optional,variable length) ~ field.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Property Option
The individual property are maintained in OPTION_PREFIX_PROPERTY
values enumeration explained in Section Section 6.1.
Along with the OPTION_PREFIX_PROPERTY a metadata associated with the
prefix that is of local relevance is communicated using
OPTION_PREFIX_CLASS defined below:
option-code: OPTION_USAGE_CLASS (TBD)
option-length: 2 + Length of Vendor class information
if present
Class: 16 bit numeric value maintained as
OPTION_USAGE_CLASS enumeration in
IANA registered namespace
Vendor Class Data: If the value of Class (3) indicates it is
vendor specified additional vendor
specified data of variable length will be
attached in the form specified below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USAGE_CLASS | option-length(2) | | OPTION_PREFIX_CLASS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | Enterprise ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise ID(4) | Vendor Class length(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Vendor Class Data (Variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Enterprise ID: The vendor's 32-bit Enterprise Number as option-code: OPTION_PREFIX_CLASS (TBD2)
registered with IANA [IANAEnterprise] option-length: 2
Vendor Class Length: 2, length of vendor class data that follows Prefix Class: 16 bit integer with the integer value
Vendor Class Data: Binary data as defined by the vendor. of local significance.
For e.g. 3gpp can specify this data to be
Application providers network domain string
The class values are maintained in OPTION_USAGE_CLASS values Prefix Class Option
enumeration explained in Section Section 2.3.1.
2.2. Consideration for different DHCPv6 entities 2.2. Consideration for different DHCPv6 entities
The model of operation of communicating prefixes to be used by a The model of operation of communicating prefixes to be used by a
DHCPv6 server is as follows. A requesting router requests prefix(es) DHCPv6 server is as follows. A requesting router requests prefix(es)
from the delegating router, as described in Section 2.2.1. A from the delegating router, as described in Section 2.2.1. A
delegating router is provided IPv6 prefixes to be delegated to the delegating router is provided IPv6 prefixes to be delegated to the
requesting router. Examples of ways in which the delegating router requesting router. Examples of ways in which the delegating router
is provided these prefixes are: is provided these prefixes are:
skipping to change at page 6, line 29 skipping to change at page 7, line 29
like RADIUS [RFC2865] like RADIUS [RFC2865]
The delegating router chooses prefix(es) for delegation, and responds The delegating router chooses prefix(es) for delegation, and responds
with prefix(es) to the requesting router along with additional with prefix(es) to the requesting router along with additional
options in the allocated prefix as described in Section 2.2.2. The options in the allocated prefix as described in Section 2.2.2. The
requesting router is then responsible for the delegated prefix(es) requesting router is then responsible for the delegated prefix(es)
after the DHCPv6 REQUEST message exchange. For example, the after the DHCPv6 REQUEST message exchange. For example, the
requesting router may create DHCPv6 server configuration pools from requesting router may create DHCPv6 server configuration pools from
the delegated prefix, and function as a DHCPv6 Server. When the the delegated prefix, and function as a DHCPv6 Server. When the
requesting router then receives a DHCPv6 IA_NA requests it can select requesting router then receives a DHCPv6 IA_NA requests it can select
the address to be allocated based on the OPTION_USER_CLASS or the address to be allocated based on the OPTION_PREFIX_CLASS option
OPTION_USAGE_CLASS options received in IA_NA request or any of the received in IA_NA request or any of the other method as described in
other methods as described in Section 2.3.1. Section 2.3.1.
2.2.1. Requesting Router Behavior for IA_PD allocation 2.2.1. Requesting Router Behavior for IA_PD allocation
DHCPv6 requesting router can request for prefixes in the following DHCPv6 requesting router can request for prefixes in the following
ways: ways:
o In the SOLICIT message within the IA_PD Prefix option, it MAY o In the SOLICIT message within the IA_PD Prefix option, it MAY
include OPTION_USAGE_CLASS requesting prefix delegation for the include OPTION_PREFIX_CLASS requesting prefix delegation for the
specific class indicated in the OPTION_USAGE_CLASS option. It can specific class indicated in the OPTION_PREFIX_CLASS option. It
include multiple IA_PD Prefix options to indicate it's preference can include multiple IA_PD Prefix options to indicate it's
for more than one usage class. preference for more than one prefix class. The class of prefix it
requests is learnt via configuration or any other out of band
mechanism not defined in this document.
o In the SOLICIT message include an OPTION_ORO option with the o In the SOLICIT message include an OPTION_ORO option with the
OPTION_USAGE_CLASS option code to request prefixes from all the OPTION_PREFIX_CLASS option code to request prefixes from all the
classes that the DHCPv6 server can provide to this requesting classes that the DHCPv6 server can provide to this requesting
Router. Router.
The requesting router parses the OPTION_USAGE_CLASS option in The requesting router parses the OPTION_PREFIX_CLASS option in the
theOPTION_IAPREFIX option area of the corresponding IA_PD Prefix OPTION_IAPREFIX option area of the corresponding IA_PD Prefix option
option in the ADVERTISE message. The Requesting router MUST then in the ADVERTISE message. The Requesting router MUST then include
include all or subset of the received class based prefix(es) in the all or subset of the received class based prefix(es) in the REQUEST
REQUEST message so that it will be responsible for the prefixes message so that it will be responsible for the prefixes selected.
selected.
The requesting router parses and stores OPTION_PREFIX_PROPERTY if
received with the prefix.
2.2.2. Delegating Router Behavior for IA_PD allocation 2.2.2. Delegating Router Behavior for IA_PD allocation
If the Delegating router supports class based prefix allocation by If the Delegating router supports class based prefix allocation by
supporting the OPTION_USAGE_CLASS option and it is configured to supporting the OPTION_PREFIX_CLASS option and it is configured to
assign prefixes from different classes, it selects prefixes for class assign prefixes from different classes, it selects prefixes for class
based prefix allocation in the following way: based prefix allocation in the following way:
o If requesting router includes OPTION_USAGE_CLASS within the IA_PD o If requesting router includes OPTION_PREFIX_CLASS within the IA_PD
Prefix option, it selects prefixes to be offered from that Prefix option, it selects prefixes to be offered from that
specific class. specific class.
o If requesting router includes OPTION_USAGE_CLASS within o If requesting router includes OPTION_PREFIX_CLASS within
OPTION_ORO, then based on its configuration and policy it MAY OPTION_ORO, then based on its configuration and policy it MAY
offer prefixes from multiple classes available. offer prefixes from multiple classes available.
The delegating router responds with an ADVERTISE message after The delegating router responds with an ADVERTISE message after
populating the IP_PD option with prefixes from different usage populating the IP_PD option with prefixes from different classes.
classes. Along with including the IA_PD prefix options in the IA_PD Along with including the IA_PD prefix options in the IA_PD option, it
option, it also includes the OPTION_USAGE_CLASS option in the MAY include the OPTION_PREFIX_CLASS option in the OPTION_IAPREFIX
OPTION_IAPREFIX option area of the corresponding IA_PD prefix option. option area of the corresponding IA_PD prefix option with the class
information of the prefix.
If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message
include the OPTION_USAGE_CLASS option, then the delegating router MAY include the OPTION_PREFIX_CLASS option, then the delegating router
allocate the prefix as specified in [RFC3633] without including the MAY allocate the prefix as specified in [RFC3633] without including
class option in the IA_PD prefix option in the response. the class option in the IA_PD prefix option in the response.
If OPTION_ORO option in the Solicit message includes the If OPTION_ORO option in the Solicit message includes the
OPTION_USAGE_CLASS option code but the delegating router does not OPTION_PREFIX_CLASS option code but the delegating router does not
support the solution described in this specification, then the support the solution described in this specification, then the
delegating router acts as specified in [RFC3633]. The requesting delegating router acts as specified in [RFC3633]. The requesting
router MUST in this case also fall back to the behavior specified in router MUST in this case also fall back to the behavior specified in
[RFC3633]. [RFC3633].
If both delegating and requesting routers support class-based prefix If both delegating and requesting routers support class-based prefix
allocation, but the delegating router cannot offer prefixes for any allocation, but the delegating router cannot offer prefixes for any
other reason, it MUST respond to requesting router with appropriate other reason, it MUST respond to requesting router with appropriate
status code as specified in [RFC3633]. For e.g., if no prefixes are status code as specified in [RFC3633]. For e.g., if no prefixes are
available in the specified class then the delegating router MUST available in the specified class then the delegating router MUST
include the status code NoPrefixAvail in the response message. include the status code NoPrefixAvail in the response message.
In addition if the delegating router has additional property
associated with the prefix it will be provided in
OPTION_PREFIX_PROPERTY option.
2.2.3. DHCPv6 Client Behavior for IA_NA allocation 2.2.3. DHCPv6 Client Behavior for IA_NA allocation
DHCPv6 client MAY request for an IA_NA address allocation from a DHCPv6 client MAY request for an IA_NA address allocation from a
specific usage class in the following way: specific prefix class in the following way:
o In the SOLICIT message within the IA_NA option, it MAY include the o In the SOLICIT message within the IA_NA option, it MAY include the
OPTION_USAGE_CLASS requesting address to be allocated from a OPTION_PREFIX_CLASS requesting address to be allocated from a
specific usage class indicated in that option. specific class indicated in that option. The class information to
be requested can be learnt via configuration or any other out of
band mechanism not described in this document.
If DHCPv6 client receives OPTION_USAGE_CLASS option in the IAaddr- If DHCPv6 client receives OPTION_PREFIX_CLASS, OPTION_PREFIX_PROPERTY
options area of the corresponding IA_NA but does not support this options in the IAaddr-options area of the corresponding IA_NA but
option, it SHOULD ignore the received option. does not support one or both of these options, it SHOULD ignore the
received option(s).
2.2.4. DHCPv6 Server Behavior for IA_NA allocation 2.2.4. DHCPv6 Server Behavior for IA_NA allocation
The DHCPv6 server parses OPTION_USAGE_CLASS option received and when The DHCPv6 server parses OPTION_PREFIX_CLASS option received and when
it supports allocation within the requested OPTION_USAGE_CLASS it supports allocation within the requested OPTION_PREFIX_CLASS
responds with an ADVERTISE message after populating the IA_NA option responds with an ADVERTISE message after populating the IA_NA option
with address information from the requested Usage class. Along with with address information from the requested prefix class. Along with
including the IA Address options in the IA_NA option, it also including the IA Address options in the IA_NA option, it also
includes the OPTION_USAGE_CLASS option in the corresponding IAaddr- includes the OPTION_PREFIX_CLASS option in the corresponding IAaddr-
options area. options area.
Even though the IA_NA option in the SOLICIT message does not include Even though the IA_NA option in the SOLICIT message does not include
the OPTION_USAGE_CLASS option, based on local policies, the DHCP the OPTION_PREFIX_CLASS option, based on local policies, the DHCP
server MAY select a default OPTION_USAGE_CLASS value for the client server MAY select a default OPTION_PREFIX_CLASS value for the client
and then SHOULD include the OPTION_USAGE_CLASS option in the IAaddr- and then SHOULD include the OPTION_PREFIX_CLASS option in the IAaddr-
options area of the corresponding IA_NA it sends to the client. If options area of the corresponding IA_NA it sends to the client. If
both DHCP client and server support Usage-class-based address both DHCP client and server support class based address allocation,
allocation, but the DHCP server cannot offer addresses in the but the DHCP server cannot offer addresses in the specified Usage
specified Usage class then the DHCP server MUST include the status class then the DHCP server MUST include the status code NoAddrsAvail
code NoAddrsAvail (as defined in [RFC3315]) in the response message. (as defined in [RFC3315]) in the response message. If the DHCP
If the DHCP server cannot offer addresses for any other reason, it server cannot offer addresses for any other reason, it MUST respond
MUST respond to requesting router with appropriate status code as to client with appropriate status code as specified in [RFC3315]. In
specified in [RFC3315]. addition if the server has additional property associated with the
prefix by means of configuration or learnt from DHCPv6 prefix
delegation or derived via any other means it MUST be sent as
OPTION_PREFIX_PROPERTY option.
2.3. Usage 2.3. Usage
Class based prefix delegation can be used by the requesting router to Class based prefix delegation can be used by the requesting router to
configure itself as a DHCPv6 server to serve its DHCPv6 clients. It configure itself as a DHCPv6 server to serve its DHCPv6 clients. It
can allocate longer prefixes from a delegated shorter prefix it can allocate longer prefixes from a delegated shorter prefix it
received, for serving IA_NA and IA_PD requests. received, for serving IA_NA and IA_PD requests. Prefix property and
class can be used for source address selection by applications using
2.3.1. OPTION_USAGE_CLASS Values the prefix for communication.
Following values will be allocated from the IANA maintained
OPTION_USAGE_CLASS registry:
o global-anchor(1) - Prefix is globally anchored and hence would
allow mobility.
o local-breakout(2) - Prefix is managed in a local-breakout domain
and hence has limited mobility.
o Vendor-specfied-class(3) - Prefix class is specified by the
vendor, Vendor class data in the option that follows will provide
more information.
New values of OPTION_USAGE_CLASS can be assigned and registered with
IANA as per policy detailed in section Section 5.1.
2.3.2. Class based prefix and IA_NA allocation 2.3.1. Class based prefix and IA_NA allocation
The requesting router can use the delegated prefix(es) from different The requesting router can use the delegated prefix(es) from different
classes (for example "video", "guest", "voice" etc), for assigning classes (for example "video" (1), "guest"(2), "voice" (3) etc), for
the IPv6 addresses to the end hosts through DHCPv6 IA_NA based on a assigning the IPv6 addresses to the end hosts through DHCPv6 IA_NA
preconfigured mapping with OPTION_USAGE_CLASS option, the following based on a preconfigured mapping with OPTION_PREFIX_CLASS option, the
conditions MAY be observed: following conditions MAY be observed:
o It MAY have a pre-configured mapping between the usage class and o It MAY have a pre-configured mapping between the prefix class and
OPTION_USER_CLASS option received in IA_NA. OPTION_USER_CLASS option received in IA_NA.
o It MAY match the OPTION_USAGE_CLASS if the IA_NA request received o It MAY match the OPTION_PREFIX_CLASS if the IA_NA request received
contains OPTION_USAGE_CLASS. contains OPTION_PREFIX_CLASS.
o It MAY have a pre-configured mapping between the usage class and o It MAY have a pre-configured mapping between the prefix class and
the client DUID received in DHCPv6 message. the client DUID received in DHCPv6 message.
o It MAY have a pre-configured mapping between the usage class and o It MAY have a pre-configured mapping between the prefix class and
its network interface on which the IA_NA request was received. its network interface on which the IA_NA request was received.
The requesting router playing the role of a DHCPv6 server can The requesting router playing the role of a DHCPv6 server can
ADVERTISE IA_NA from a class of prefix(es) thus selected. ADVERTISE IA_NA from a class of prefix(es) thus selected.
2.3.3. Class based prefix and IA_PD allocation 2.3.2. Class based prefix and IA_PD allocation
If the requesting router, receives prefix(es) for different classes If the requesting router, receives prefix(es) for different classes
(for example "video", "guest", "voice" etc), it can use these (for example "video"(1), "guest"(2), "voice"(3) etc), it can use
prefix(es) for assigning the longer IPv6 prefixes to requesting these prefix(es) for assigning the longer IPv6 prefixes to requesting
routers it serves through DHCPv6 IA_PD by assuming the role of routers it serves through DHCPv6 IA_PD by assuming the role of
delegating router, its behavior is explained in Section 2.2.2. delegating router, its behavior is explained in Section 2.2.2.
2.3.4. Class based prefix and SLAAC 2.3.3. Class based prefix and SLAAC
DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as
defined in [RFC4862]) are two ways by IPv6 addresses can be defined in [RFC4862]) are two ways by IPv6 addresses can be
dynamically assigned to end hosts. Making SLAAC class aware is dynamically assigned to end hosts. Making SLAAC class aware is
outside the scope of this document, it is specified in outside the scope of this document, it is specified in
[I-D.korhonen-dmm-prefix-properties]. [I-D.korhonen-dmm-prefix-properties].
2.3.5. Class based Information-Request 2.3.4. Class based prefix and applications
A DHCP client MAY include OPTION_USAGE_CLASS in the Information
request message to indicate that the requested configuration
information (such as a list of available DNS servers) may be
associated with a specific Usage Class.The server responds to the
client with the requested Options whose values are determined based
on the received OPTION_USAGE_CLASS. Even though the Information
request message does not include the OPTION_USAGE_CLASS option, based
on local policies, the DHCP server MAY select a default
OPTION_USAGE_CLASS value for the client and then SHOULD include the
OPTION_USAGE_CLASS option Information Response it sends to the
client.
2.3.6. Class based prefix and applications
Applications within a host can do source address selection based on Applications within a host can do source address selection based on
the class of the prefix learnt in OPTION_USAGE_CLASS using rules the class of the prefix learnt in OPTION_PREFIX_PROPERTY and
defined in [RFC3484]. OPTION_PREFIX_CLASS using rules defined in [RFC6724].
3. Example Application 3. Example Application
3.1. Mobile gateway example
The following sub-sections provide examples of class based prefix The following sub-sections provide examples of class based prefix
delegation and how it is used in a mobile network. Each of the delegation and how it is used in a mobile network. Each of the
examples will refer to the below network: examples will refer to the below network:
The example network consists of : The example network consists of :
Mobile Gateway It is network entity anchoring IP traffic in the Mobile Gateway It is network entity anchoring IP traffic in the
mobile core network. This entity allocates an IP address which is mobile core network. This entity allocates an IP address which is
topologically valid in the mobile network and may act as a mobility topologically valid in the mobile network and may act as a mobility
anchor if handover between mobile and Wi-Fi is supported. anchor if handover between mobile and Wi-Fi is supported.
skipping to change at page 11, line 8 skipping to change at page 12, line 5
Access Point (AP) A wireless access point, identified by a MAC Access Point (AP) A wireless access point, identified by a MAC
address, providing service to the wired network for wireless nodes. address, providing service to the wired network for wireless nodes.
Access Router (AR) An IP router residing in an access network and Access Router (AR) An IP router residing in an access network and
connected to one or more Acess Point(AP)s. An AR offers IP connected to one or more Acess Point(AP)s. An AR offers IP
connectivity to MNs. connectivity to MNs.
WLAN controller (WLC) The entity that provides the centralized WLAN controller (WLC) The entity that provides the centralized
forwarding, routing function for the user traffic. forwarding, routing function for the user traffic.
Example mobile network
_----_ _----_ _----_ _----_ _----_ _----_
_( )_ _( )_ _( )_ _( )_ _( )_ _( )_
(Operator-1) (Operator-2) (Operator-3) (Operator-1) (Operator-2) (Operator-3)
(_ _) (_ _) (_ _) (_ _) (_ _) (_ _)
-+-- -+-- '-+--' -+-- -+-- '-+--'
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Mobile | | Mobile | | Mobile | | Mobile | | Mobile | | Mobile |
|gateway | |gateway | |gateway | |gateway | |gateway | |gateway |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
skipping to change at page 11, line 49 skipping to change at page 12, line 45
+-----+ * ---------* +-----+ * ---------*
/ \ / \ / \ / \
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
|WiFi| |WiFi| |WiFi| |WiFi| |WiFi| |WiFi| |WiFi| |WiFi|
| AP | | AP | | AP | | AP | | AP | | AP | | AP | | AP |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
. . . .
/ \ / \ / \ / \
MN1 MN2 MN3 MN4(guest) MN1 MN2 MN3 MN4(guest)
Figure 1 Figure 1: Example mobile network
3.1. Class based prefix delegation 3.1.1. Class based prefix delegation
The Access Aggregation Gateway requests for Prefix delegation from The Access Aggregation Gateway requests for Prefix delegation from
Mobile gateway and associates the prefix received with usage class Mobile gateway and associates the prefix received with class "global-
"global-anchor"(1). The Access Aggregation Gateway is preconfigured anchor"(1). The Access Aggregation Gateway is preconfigured to
to provide prefixes from the following classes: "global-anchor" (1), provide prefixes from the following classes: "global-anchor" (1),
"local-breakout"(2), "guest"(x). It has a preconfigured policy to "local-breakout"(2), "guest"(3). It has a preconfigured policy to
advertise prefixes to requesting routers and mobile nodes based on advertise prefixes to requesting routers and mobile nodes based on
the service class supported by the service provider for the the service class supported by the service provider for the
requesting device. In the example mobile network, the Access requesting device. In the example mobile network, the Access
Router(AR) requests class based prefix allocation by sending a DHCPv6 Router(AR) requests class based prefix allocation by sending a DHCPv6
SOLICIT message and include OPTION_USAGE_CLASS in the OPTION_ORO. SOLICIT message and include OPTION_PREFIX_CLASS in the OPTION_ORO.
The Access Router (AR) receives an advertise with following prefixes The Access Router (AR) receives an advertise with following prefixes
in the IA_PD option: in the IA_PD option:
1. P1: IA_PD Prefix option with a prefix 3001::1::/64 containing 1. P1: IA_PD Prefix option with a prefix 3001:1::/64 containing
OPTION_USAGE_CLASS set to "global-anchor"(1) OPTION_PREFIX_CLASS set to "global-anchor"(1)
2. P2: IA_PD Prefix option with a prefix 3001::2::/64 containing 2. P2: IA_PD Prefix option with a prefix 3001:2::/64 containing
OPTION_USAGE_CLASS set to "local-breakout"(2) OPTION_PREFIX_CLASS set to "local-breakout"(2)
3. P3: IA_PD Prefix option with a prefix 3001::3::/64 containing 3. P3: IA_PD Prefix option with a prefix 3001:3::/64 containing
OPTION_USAGE_CLASS set to "guest"(x) OPTION_PREFIX_CLASS set to "guest"(3)
It sends a REQUEST message with all of above prefixes and receives a It sends a REQUEST message with all of above prefixes and receives a
REPLY message with prefixes allocated for each of the requested REPLY message with prefixes allocated for each of the requested
class. class.
3.2. IPv6 address assignment from class based prefix 3.1.2. IPv6 address assignment from class based prefix
When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA
from the mobile node that has mobility service enabled, it offers an from the mobile node that has mobility service enabled, it offers an
IPv6 address from the usage class "global-anchor"(1). For MN3 it IPv6 address from the prefix class "global-anchor"(1). For MN3 it
advertises 3001::1::1 as the IPv6 address in OPTION_IAADDR in advertises 3001:1::1 as the IPv6 address in OPTION_IAADDR in response
response to the IA_NA request. to the IA_NA request.
The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message
requesting IA_NA address assignment with OPTION_USER_CLASS option requesting IA_NA address assignment with OPTION_USER_CLASS option
containing the value "guest" towards the CPE. The Access Router(AR) containing the value "guest" towards the CPE. The Access Router(AR)
assumes the role of the DHCPv6 server and sends an ADVERTISE to the assumes the role of the DHCPv6 server and sends an ADVERTISE to the
MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from
the "guest" usage class. The IPv6 address in the OPTION_IAADDR is the "guest"(3) class. The IPv6 address in the OPTION_IAADDR is set
set to 3001::3::1. The "guest" class can also be distinguished based to 3001:3::1. The "guest" class can also be distinguished based on a
on a preconfigured interface or SSID advertised for MNs connecting to preconfigured interface or SSID advertised for MNs connecting to it.
it.
When the Access Aggregation Gateway receives a DHCPv6 SOLICIT When the Access Aggregation Gateway receives a DHCPv6 SOLICIT
requesting IA_NA from MNs through WLC and it has a preconfigured requesting IA_NA from MNs through WLC and it has a preconfigured
profile to provide both local-breakout internet access and global- profile to provide both local-breakout internet access and global-
anchor, it offers an IPv6 address from the usage class "local- anchor, it offers an IPv6 address from the class "local-breakout" (2)
breakout" (2) and "global-anchor"(1). For MN1 it advertises and "global-anchor"(1). For MN1 it advertises 3001:2::1 and
3001::2::1 and 3001::1::2 as the IPv6 address in OPTION_IAADDR in 3001:1::2 as the IPv6 address in OPTION_IAADDR in response to the
response to the IA_NA request. Applications within MN1 can choose to IA_NA request. Applications within MN1 can choose to use the
use the appropriate prefix based on the mobility enabled or local- appropriate prefix based on the mobility enabled or local-breakout
breakout property attached to the prefix based on source address property attached to the prefix based on source address selection
selection policy. policy.
The prefixes that are globally anchored and hence have mobility can
be advertised with OPTION_PREFIX_PROPERTY set to 0x0002 to convey
that the prefix provides network based mobility as listed in
Section 6.1. If the prefix also provides security guarantees
OPTION_PREFIX_PROPERTY can be set to 0x0009 to indicated mobility and
security guarantees by bitwise ORing of both the properties.
3.2. Homenet Example
The following sub-section describes an example of class based prefix
delegation in a home network environment. The network consists of
the following elements:
o Home Gateway (HGW) device: a routing device located in the
customer's premises that provides connectivity between the
customer and the service provider. In this example, the HGW is
functioning as both a DHCP client towards the service provider's
DHCP infrastructure and a DHCP server towards hosts located in the
home network.
o IPv6 Set Top Box (STB): A dedicated, IPv6 attached, video on
demand device.
o IPv6 PC: An IPv6 attached personal computer.
o Delegating Router: The router in the ISPs network acting as a DHCP
server for the IA_PD request.
o Video On Demand (VOD) service: A server providing unicast based
streaming video content to subscribers.
_----+----_
_( )
( Internet )
(_ _)
'----+----'
|
_----+----_ +----------+ \
_( )_ | Video on | \
(Service Provider)--| Demand | \
(_ Network _) | Service | | ISP
'----+----' +----------+ | Network
| |
+------+-----+ |
| Delegating | |
| Router | |
+------+-----+ |
| |
| Customer |
| Internet connection /
| /
| /
+------+--------+ ^ \
| IPv6 | | DHCPv6 Client \
| Home gateway | \
| Device (CPE) | | DHCPv6 Server |
+------+--------+ v | Home
| | Network
Home Network | |
+-----+-------+ |
| | |
+----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | |
| (Set top | | (PC) | DHCPv6 Clients /
| box) | | | /
+----------+ +----------+ /
Simple home network with Data and Video devices
3.2.1. Class based prefix delegation to the HGW
In this example, two different services are being run on the same
network. The service provider wishes that traffic is sourced from
different prefixes by the home network clients
[I-D.jiang-v6ops-semantic-prefix]. The HGW (requesting router) has
been configured to request prefix delegation from the ISPs delegating
router with the usage classes "video" (1) and "internet"(2) the
meaning of these being of relevance to the ISP operating this and
application that are configured out of band to utilize it.
The delegating router is preconfigured to advertise prefixes with
these service classes. The HGW sends two IA_PD options within the
SOLICIT message, one with OPTION_PREFIX_CLASS "video" (1) and the
second with "internet" (2). The HGW receives an advertise with the
following prefixes in the IA_PD option:
1. P1: IA_PD Prefix option with a prefix 3001:5::/56 containing
OPTION_PREFIX_CLASS set to "video" (1)
2. P2: IP_PD Prefix option with a prefix 3001:6::/56 containing
OPTION_PREFIX_CLASS set to "internet" (2)
It sends a REQUEST message with all of the above prefixes and
receives a REPLY message with prefixes allocated for each of the
requested classes. The HGW then configures a /64 prefix from each of
the delegated prefixes on its LAN interface [RFC6204] and sends out
router advertisements (RAs) with the "M" and "O" bits set.
3.2.2. IPv6 Assignment to Homenet hosts using stateful DHCPv6
STB sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS
option set to "video" (1) within the IA_NA. The HGW checks the
requested prefix class against the available prefixes it has been
delegated and advertises 3001:5::1 to the STB. The STB then
configures this address on its LAN interface and uses it for sourcing
requests to the VOD service.
The PC sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS
option set to "internet" within the IA_NA or without
OPTION_PREFIX_PROPERTY. The HGW checks the requested prefix class
against the available prefixes it has been delegated and advertises
3001:6::1 to the PC or in absence of OPTION_PREFIX_CLASS in the
solicit HGW is preconfigured to assign from the "internet"(2) class
as the default. The PC then configures this address on its LAN
interface and uses it for sourcing requests to the Internet.
4. Acknowledgements 4. Acknowledgements
The authors would like to acknowledge review and guidance received The authors would like to acknowledge review and guidance received
from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark, from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark,
Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz
5. IANA Considerations 5. Contributors
IANA is requested to assign an option code to OPTION_USAGE_CLASS from Authors would like to thank contributions to use cases and text for
the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ various sections received from Ian Farrer and Sindhura Bandi.
assignments/dhcpv6-parameters/dhcpv6-parameters.xml).
5.1. OPTION_USAGE_CLASS values 6. IANA Considerations
IANA is requested to assign an option code to OPTION_PREFIX_PROPERTY
(TBD1) and OPTION_PREFIX_CLASS (TBD2) from the "DHCPv6 and DHCPv6
options" registry (http://www.iana.org/assignments/dhcpv6-parameters/
dhcpv6-parameters.xml).
6.1. OPTION_PREFIX_PROPERTY values
IANA is requested to reserve and maintain registry of IANA is requested to reserve and maintain registry of
OPTION_USAGE_CLASS values and manage allocation of values in the OPTION_PREFIX_PROPERTY values and manage allocation of values as per
following way as per as per policy defined in [RFC5226]: as per policy defined in [RFC5226] with IETF assigned values
requiring IETF consensus, RFC Required policy, any other values other
than the ones listed below are not valid.
1. Values 1 to 8191 ( 0x0001 - 0x1FFF) - IETF assigned class with 1. 0x0001 The prefix cannot be used to reach the Internet
IETF consensus, RFC Required policy
2. Values 8192 to 16368 (0x2000 - 0x3ff0) - Vendor defined class 2. 0x0002 The prefix provides network based mobility
assigned on a First Come First Served allocation policy
3. Values 16369 to 16383 (0x3ff1 - 0x3fff) - Experimental usage 3. 0x0004 The prefix requires authentication
reserved for Private Use
Following values will be allocated from this registry as explained in 4. 0x0008 The prefix is assigned on an interface that provides
section Section 2.3.1: security guarantees
o global-anchor(1) - Prefix is globally anchored and hence would 5. 0x0010 Usage is charged
allow mobility.
o local-breakout(2) - Prefix is managed in a local-breakout domain 6. 0x0020 Unassigned
and hence has limited mobility.
o Vendor-specfied-class(3) - Prefix class is vendor specified. 7. 0x0040 Unassigned
6. Security Considerations 8. 0x0080 Unassigned
9. 0x0100 Unassigned
10. 0x0200 Unassigned
11. 0x0400 Unassigned
12. 0x0800 Unassigned
13. 0x1000 Unassigned
14. 0x2000 Unassigned
15. 0x4000 Unassigned
16. 0x8000 Unassigned
7. Security Considerations
Security issues related to DHCPv6 which are described in section 23 Security issues related to DHCPv6 which are described in section 23
of [RFC3315] and [RFC3633] apply for scenarios mentioned in this of [RFC3315] and [RFC3633] apply for scenarios mentioned in this
draft as well. draft as well.
7. Change History (to be removed prior to publication as an RFC) 8. Change History (to be removed prior to publication as an RFC)
Changes from -00 to -01 Changes from -00 to -01
a. Modified motivation section to focus on mobile networks a. Modified motivation section to focus on mobile networks
b. Modified example with a mobile network and class based prefix b. Modified example with a mobile network and class based prefix
delegation in it delegation in it
Changes from -00 to -02 Changes from -01 to -02
a. Modified option format to be enumerated values a. Modified option format to be enumerated values
b. Added IANA section to request managing of registry for the b. Added IANA section to request managing of registry for the
enumerated values enumerated values
c. Added initial values for the class c. Added initial values for the class
d. Added section for applications to select address with a specific d. Added section for applications to select address with a specific
property property
8. References Changes from -02 to -03
8.1. Normative References a. Added server behaviour for IA_NA and IA_PD allocation
b. Added Class based Information-Request usage
Changes from -03 to -04
a. Added homenet use case
b. Split usage class into a fixed IANA maintained properties
registry and a prefix class
9. References
9.1. Normative References
[I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in
progress), September 2012.
[I-D.jiang-v6ops-semantic-prefix]
Jiang, S., Sun, Q., and I. Farrer, "A Framework for
Semantic IPv6 Prefix and Gap Analysis",
draft-jiang-v6ops-semantic-prefix-02 (work in progress),
January 2013.
[I-D.korhonen-dmm-prefix-properties] [I-D.korhonen-dmm-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Mobility Management Properties", Liu, "IPv6 Prefix Mobility Management Properties",
draft-korhonen-dmm-prefix-properties-02 (work in draft-korhonen-dmm-prefix-properties-03 (work in
progress), July 2012. progress), October 2012.
[IANAEnterprise]
IANA, "Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers".
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
8.2. Informative References [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
Authors' Addresses Authors' Addresses
skipping to change at page 16, line 25 skipping to change at page 20, line 42
Gaurav Halwasia Gaurav Halwasia
Cisco Systems Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087 Bangalore, KARNATAKA 560 087
India India
Phone: +91 80 4426 1321 Phone: +91 80 4426 1321
Email: ghalwasi@cisco.com Email: ghalwasi@cisco.com
Sindhura Bandi
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4426 2347
Email: sinb@cisco.com
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Hui Deng Hui Deng
China Mobile China Mobile
53A, Xibianmennei Ave., Xuanwu District 53A, Xibianmennei Ave., Xuanwu District
Beijing 100053 Beijing 100053
China China
Email: denghui02@gmail.com Email: denghui02@gmail.com
Laurent Thiebaut Laurent Thiebaut
Alcatel-Lucent Alcatel-Lucent
France France
Email: laurent.thiebaut@alcatel-lucent.com Email: laurent.thiebaut@alcatel-lucent.com
Jouni Korhonen
Renesas Mobile
Linnoitustie 6
FIN-02600 Espoo,
Finland
Phone:
Email: jouni.nospam@gmail.com
 End of changes. 86 change blocks. 
302 lines changed or deleted 476 lines changed or added

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