One document matched: draft-bhandari-dhc-class-based-prefix-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml">
<!ENTITY RFC6724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6204 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml">
<!ENTITY I-D.korhonen-6man-prefix-properties SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-6man-prefix-properties.xml">
<!ENTITY I-D.korhonen-dmm-prefix-properties SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-dmm-prefix-properties.xml">
<!ENTITY I-D.baker-fun-multi-router SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-fun-multi-router.xml">
<!ENTITY I-D.chown-homenet-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chown-homenet-arch.xml">
<!ENTITY I-D.baker-fun-routing-class SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-fun-routing-class.xml">
<!ENTITY I-D.jiang-v6ops-semantic-prefix SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jiang-v6ops-semantic-prefix.xml">
<!ENTITY I-D.ietf-dhc-dhcpv4-over-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv4-over-ipv6.xml">
<!ENTITY I-D.ietf-v6ops-ipv6-cpe-router-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-cpe-router-bis.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-bhandari-dhc-class-based-prefix-05"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DHCPv6 class based prefix">DHCPv6 class based
prefix</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Sarjapura Marathalli Outer Ring
Road</street>
<city>Bangalore</city>
<region>KARNATAKA</region>
<code>560 087</code>
<country>India</country>
</postal>
<phone></phone>
<email>shwethab@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Gaurav Halwasia" initials="G." surname="Halwasia">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Sarjapura Marathalli Outer Ring
Road</street>
<city>Bangalore</city>
<region>KARNATAKA</region>
<code>560 087</code>
<country>India</country>
</postal>
<phone>+91 80 4426 1321</phone>
<email>ghalwasi@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Hui Deng" initials="H." surname="Deng">
<organization>China Mobile</organization>
<address>
<postal>
<street>53A, Xibianmennei Ave., Xuanwu District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>denghui02@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Laurent Thiébaut" initials="L."
surname="Thiébaut">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<country>France</country>
</postal>
<email>laurent.thiebaut@alcatel-lucent.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jouni Korhonen " initials="J." surname="Korhonen">
<organization>Renesas Mobile</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>FIN-02600 Espoo</city>
<region></region>
<code></code>
<country>Finland</country>
</postal>
<phone></phone>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author fullname="Ian Farrer " initials="I" surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>GTN-FM4, Landgrabenweg 151</street>
<city>Bonn 53227</city>
<region></region>
<code></code>
<country>Bonn 53227</country>
</postal>
<phone></phone>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<date day="14" month="July" year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document introduces options to communicate property and
associate meta data with prefixes. It extends DHCPv6 prefix delegation
and address allocation using the meta data for selection of prefixes and
addresses.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In IPv6 a network interface can acquire multiple addresses from the
same scope. In such a multi-prefix network each of the multiple prefixes
can have a specific property and purpose associated with it. Example: In
a mobile network a mobile device can be assigned a prefix from its home
network and another from the visiting network that it is attached to.
Another example is a prefix may provide free Internet access without
offering any quality of service guarantees 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 meta data associated with it that communicates its
local significance. The properties and meta data of prefix will be
relevant for prefix delegation, source address selection as elaborated
in the subsequent sections.</t>
<t>This document defines OPTION_PREFIX_PROPERTY option that communicates
property of the prefix that is universally understood. This document
defines OPTION_PREFIX_CLASS option to communicate meta data of the
prefix that communicates the prefix's local significance.</t>
<t>This document discusses usage of OPTION_PREFIX_CLASS to request and
select prefixes with specific meta data via IA_PD and IA_NA as defined
in <xref target="RFC3633"></xref> and<xref target="RFC3315"></xref>
respectively. This document defines the behavior of the DHCPv6 server,
the DHCPv6 prefix requesting router and the DHCPv6 client to use
OPTION_PREFIX_CLASS option for requesting and selecting prefixes and
addresses.</t>
<t>The network address can be configured via DHCPv6 as defined in <xref
target="RFC3315"></xref> or via Stateless Address Autoconfiguration
(SLAAC) as defined in <xref target="RFC4862"></xref>, additional
information of a prefix can be provided via DHCPv6 or via IPv6 Router
Advertisement (RA). The information provided in the options defined in
this document OPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS can be used
for source address selection. Communicated property and meta data
information about the prefix via IPv6 Router Advertisement (RA) will be
dealt with in separate document <xref
target="I-D.korhonen-6man-prefix-properties"></xref>.</t>
<section title="Motivation">
<t>In this section motivation for class based prefix delegation that
qualifies the delegated prefix with additional class information is
described in the context of mobile networks and home networks. The
property information attached to a delegated prefix helps to
distinguish a delegated IPv6 prefix and selection of the prefix by
different applications using it.</t>
<section title="Mobile networks">
<t>In the mobile network architecture, there is a mobile router
which functions as a IP network gateway and provides IP connectivity
to mobile nodes. Mobile router can be the requesting router
requesting delegated IPv6 prefix using DHCPv6. Mobile router can
assume the role of DHCPv6 server for mobile nodes(DHCPv6 clients)
attached to it. A mobile node in mobile network architecture can be
associated with multiple IPv6 prefixes belonging to different
domains for e.g. home address prefix, care of address prefix as
specified in <xref target="RFC3775"></xref>.</t>
<t>The delegated prefixes when seen from the mobile router
perspective appear to be like any other prefix, but each prefixes
have different meta data referred to as "Prefix Color" in the mobile
networks. Some delegated prefixes may be topologically local and
some may be remote prefixes anchored on a global anchor, but
available to the local anchor by means of tunnel setup in the
network between the local and global anchor. Some may be local with
low latency characteristics suitable for voice call break-out, some
may have global mobility support. So, the prefixes have different
properties and it is required for the application using the prefix
to learn about this property in order to use it intelligently. There
is currently no semantics in DHCPv6 prefix delegation that can carry
this information to specify properties of a delegated prefix. In
this scenario, the mobile router is unable to further delegate a
longer prefix 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.</t>
</section>
<section title="Home networks">
<t>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.</t>
<t>Motivations for this include: <list style="symbols">
<t>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. <xref
target="I-D.jiang-v6ops-semantic-prefix"></xref></t>
<t>Using the specific source prefix as a host identifier for
other services. E.g. as an input parameter to a DHCPv4 over IPv6
server <xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"></xref></t>
</list></t>
<t>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.</t>
</section>
</section>
<section title="Terminology">
<t>This document uses the terminology defined in <xref
target="RFC2460"></xref>, <xref target="RFC3315"></xref> and <xref
target="RFC3633"></xref>.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Overview">
<t>This section defines prefix property and prefix class options in
IA_PD and IA_NA. This section defines the behavior of the delegating
router, the requesting router and the DHCPv6 client. It discusses these
options in the context of a DHCPv6 information request from a DHCPv6
client to a DHCPv6 server.</t>
<section title="Prefix Property and Class Options">
<t><figure title="Prefix Property Option">
<preamble>The format of the DHCPv6 prefix property and prefix
class options are shown below.</preamble>
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_PROPERTY (TBD1)
option-length: 2
Properties: 16 bits maintained as
OPTION_PREFIX_PROPERTY in
IANA registered namespace.
Each value in the registry represents a property.
Multiple properties can be represented by bitwise
ORing of the individual property values in this
field.
]]></artwork>
<postamble></postamble>
</figure>The individual property are maintained in
OPTION_PREFIX_PROPERTY values enumeration explained in Section <xref
target="IANA_PREFIX_PROPERTIES"></xref>.</t>
<t>Along with the OPTION_PREFIX_PROPERTY a meta data associated with
the prefix that is of local relevance is communicated using
OPTION_PREFIX_CLASS defined below:</t>
<t><figure title="Prefix Class Option">
<artwork><![CDATA[
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_CLASS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_CLASS (TBD2)
option-length: 2
Prefix Class: 16 bit integer with the integer value
of local significance.
]]></artwork>
</figure></t>
</section>
<section anchor="sec_prefix_delegation"
title="Consideration for different DHCPv6 entities">
<t>The model of operation of communicating prefixes to be used by a
DHCPv6 server is as follows. A requesting router requests prefix(es)
from the delegating router, as described in Section 2.2.1. A
delegating router is provided IPv6 prefixes to be delegated to the
requesting router. Examples of ways in which the delegating router is
provided these prefixes are:</t>
<t><list style="symbols">
<t>Configuration</t>
<t>Prefix delegated via a DHCPv6 request to another DHCPv6
server</t>
<t>Using a Authentication Authorization Accounting (AAA) protocol
like RADIUS <xref target="RFC2865"></xref></t>
</list>The delegating router chooses prefix(es) for delegation, and
responds with prefix(es) to the requesting router along with
additional options in the allocated prefix as described in Section
2.2.2. The requesting router is then responsible for the delegated
prefix(es) after the DHCPv6 REQUEST message exchange. For example, the
requesting router may create DHCPv6 server configuration pools from
the delegated prefix, and function as a DHCPv6 Server. When the
requesting router then receives a DHCPv6 IA_NA requests it can select
the address to be allocated based on the OPTION_PREFIX_CLASS option
received in IA_NA request or any of the other method as described in
Section 2.3.1.</t>
<section title="Requesting Router Behavior for IA_PD allocation">
<t>DHCPv6 requesting router can request for prefixes in the
following ways:</t>
<t><list style="symbols">
<t>In the SOLICIT message within the IA_PD Prefix option, it MAY
include OPTION_PREFIX_CLASS requesting prefix delegation for the
specific class indicated in the OPTION_PREFIX_CLASS option. It
can include multiple IA_PD Prefix options to indicate it's
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.</t>
<t>In the SOLICIT message include an OPTION_ORO option with the
OPTION_PREFIX_CLASS option code to request prefixes from all the
classes that the DHCPv6 server can provide to this requesting
Router.</t>
</list>The requesting router parses the OPTION_PREFIX_CLASS option
in the OPTION_IAPREFIX option area of the corresponding IA_PD Prefix
option in the ADVERTISE message. The Requesting router MUST then
include all or subset of the received class based prefix(es) in the
REQUEST message so that it will be responsible for the prefixes
selected.</t>
<t>The requesting router parses and stores OPTION_PREFIX_PROPERTY if
received with the prefix.</t>
</section>
<section title="Delegating Router Behavior for IA_PD allocation">
<t>If the Delegating router supports class based prefix allocation
by supporting the OPTION_PREFIX_CLASS option and it is configured to
assign prefixes from different classes, it selects prefixes for
class based prefix allocation in the following way:</t>
<t><list style="symbols">
<t>If requesting router includes OPTION_PREFIX_CLASS within the
IA_PD Prefix option, it selects prefixes to be offered from that
specific class.</t>
<t>If requesting router includes OPTION_PREFIX_CLASS within
OPTION_ORO, then based on its configuration and policy it MAY
offer prefixes from multiple classes available.</t>
</list>The delegating router responds with an ADVERTISE message
after populating the IP_PD option with prefixes from different
classes. Along with including the IA_PD prefix options in the IA_PD
option, it MAY include the OPTION_PREFIX_CLASS option in the
OPTION_IAPREFIX option area of the corresponding IA_PD prefix option
with the class information of the prefix.</t>
<t>If neither the OPTION_ORO nor the IA_PD option in the SOLICIT
message include the OPTION_PREFIX_CLASS option, then the delegating
router MAY allocate the prefix as specified in <xref
target="RFC3633"></xref> without including the class option in the
IA_PD prefix option in the response.</t>
<t>If OPTION_ORO option in the Solicit message includes the
OPTION_PREFIX_CLASS option code but the delegating router does not
support the solution described in this specification, then the
delegating router acts as specified in [RFC3633]. The requesting
router MUST in this case also fall back to the behavior specified in
<xref target="RFC3633"></xref>.</t>
<t>If both delegating and requesting routers support class-based
prefix allocation, but the delegating router cannot offer prefixes
for any other reason, it MUST respond to requesting router with
appropriate status code as specified in <xref
target="RFC3633"></xref>. For e.g., if no prefixes are available in
the specified class then the delegating router MUST include the
status code NoPrefixAvail in the response message.</t>
<t>In addition if the delegating router has additional property
associated with the prefix it will be provided in
OPTION_PREFIX_PROPERTY option.</t>
</section>
<section title="DHCPv6 Client Behavior for IA_NA allocation">
<t>DHCPv6 client MAY request for an IA_NA address allocation from a
specific prefix class in the following way:</t>
<t><list style="symbols">
<t>In the SOLICIT message within the IA_NA option, it MAY
include the OPTION_PREFIX_CLASS requesting address to be
allocated from a 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.</t>
</list>If DHCPv6 client receives OPTION_PREFIX_CLASS,
OPTION_PREFIX_PROPERTY options in the IAaddr-options area of the
corresponding IA_NA but does not support one or both of these
options, it SHOULD ignore the received option(s).</t>
</section>
<section title="DHCPv6 Server Behavior for IA_NA allocation">
<t>The DHCPv6 server parses OPTION_PREFIX_CLASS option received and
when it supports allocation within the requested OPTION_PREFIX_CLASS
responds with an ADVERTISE message after populating the IA_NA option
with address information from the requested prefix class. Along with
including the IA Address options in the IA_NA option, it also
includes the OPTION_PREFIX_CLASS option in the corresponding
IAaddr-options area.</t>
<t>Even though the IA_NA option in the SOLICIT message does not
include the OPTION_PREFIX_CLASS option, based on local policies, the
DHCP server MAY select a default OPTION_PREFIX_CLASS value for the
client 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 both DHCP client and server support class based address
allocation, but the DHCP server cannot offer addresses in the
specified Usage class then the DHCP server MUST include the status
code NoAddrsAvail (as defined in <xref target="RFC3315"></xref>) in
the response message. If the DHCP server cannot offer addresses for
any other reason, it MUST respond to client with appropriate status
code as specified in <xref target="RFC3315"></xref>. In 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.</t>
</section>
</section>
<section anchor="usage" title="Usage ">
<t>Class based prefix delegation can be used by the requesting router
to configure itself as a DHCPv6 server to serve its DHCPv6 clients. It
can allocate longer prefixes from a delegated shorter prefix it
received, for serving IA_NA and IA_PD requests. Prefix property and
class can be used for source address selection by applications using
the prefix for communication.</t>
<section title="Class based prefix and IA_NA allocation">
<t>The requesting router can use the delegated prefix(es) from
different classes (for example "video" (1), "guest"(2), "voice" (3)
etc), for assigning the IPv6 addresses to the end hosts through
DHCPv6 IA_NA based on a preconfigured mapping with
OPTION_PREFIX_CLASS option, the following conditions MAY be
observed: <list style="symbols">
<t>It MAY have a pre-configured mapping between the prefix class
and OPTION_USER_CLASS option received in IA_NA.</t>
<t>It MAY match the OPTION_PREFIX_CLASS if the IA_NA request
received contains OPTION_PREFIX_CLASS.</t>
<t>It MAY have a pre-configured mapping between the prefix class
and the client DUID received in DHCPv6 message.</t>
<t>It MAY have a pre-configured mapping between the prefix class
and its network interface on which the IA_NA request was
received.</t>
</list>The requesting router playing the role of a DHCPv6 server
can ADVERTISE IA_NA from a class of prefix(es) thus selected.</t>
</section>
<section title="Class based prefix and IA_PD allocation">
<t>If the requesting router, receives prefix(es) for different
classes (for example "video"(1), "guest"(2), "voice"(3) etc), it can
use these prefix(es) for assigning the longer IPv6 prefixes to
requesting routers it serves through DHCPv6 IA_PD by assuming the
role of delegating router, its behavior is explained in Section
2.2.2.</t>
</section>
<section title="Class based prefix and SLAAC">
<t>DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC
as defined in <xref target="RFC4862"></xref>) are two ways by IPv6
addresses can be dynamically assigned to end hosts. Making SLAAC
class aware is outside the scope of this document, it is specified
in <xref target="I-D.korhonen-6man-prefix-properties"></xref>.</t>
</section>
<section title="Class based prefix and applications">
<t>Applications within a host can do source address selection based
on the class of the prefix learnt in OPTION_PREFIX_PROPERTY and
OPTION_PREFIX_CLASS using rules defined in <xref
target="RFC6724"></xref>. The internal data structure and interface
for source address selection used by application to choose source
prefix with specific property and class in a host is beyond the
scope of this document.</t>
</section>
</section>
</section>
<section title="Example Application">
<t></t>
<section anchor="example" title="Mobile gateway example ">
<t>The following sub-sections provide examples of class based prefix
delegation and how it is used in a mobile network. Each of the
examples will refer to the below network:</t>
<t>The example network consists of :</t>
<t>Mobile Gateway It is network entity anchoring IP traffic in the
mobile core network. This entity allocates an IP address which is
topologically valid in the mobile network and may act as a mobility
anchor if handover between mobile and Wi-Fi is supported.</t>
<t>Mobile Nodes (MN) A host or router that changes its point of
attachment from one network or subnetwork to another. A mobile node
may change its location without changing its IP address; it may
continue to communicate with other Internet nodes at any location
using its (constant) IP address, assuming link-layer connectivity to a
point of attachment is available.</t>
<t>Access Point (AP) A wireless access point, identified by a MAC
address, providing service to the wired network for wireless
nodes.</t>
<t>Access Router (AR) An IP router residing in an access network and
connected to one or more Access Point(AP)s. An AR offers IP
connectivity to MNs.</t>
<t>WLAN controller (WLC) The entity that provides the centralized
forwarding, routing function for the user traffic.</t>
<figure anchor="fig_Example_mobilenetwork"
title="Example mobile network">
<artwork><![CDATA[ _----_ _----_ _----_
_( )_ _( )_ _( )_
(Operator-1) (Operator-2) (Operator-3)
(_ _) (_ _) (_ _)
-+-- -+-- '-+--'
+--------+ +--------+ +--------+
| Mobile | | Mobile | | Mobile |
|gateway | |gateway | |gateway |
+--------+ +--------+ +--------+
| | |
+-------------. | .-------------+
| | |
| | |
| | |P1:"global-anchor"(1)
| | |
+--------+ _----_
+---+ | |P2:"local-breakout"(2)_( )_
|AAA|. . . . . . . | Access |---------------------( Internet )
+---+ | Aggreg |-----------+ (_ _)
| Gateway| P3:"guest"| '----'
+--------+ |
| | +----- Guest Access
| | Network
| +-------------+
| |
| +-----+
| | AR |
+-----+ +-----+
| WLC | * ---------*
| | ( LAN )
+-----+ * ---------*
/ \ / \
+----+ +----+ +----+ +----+
|WiFi| |WiFi| |WiFi| |WiFi|
| AP | | AP | | AP | | AP |
+----+ +----+ +----+ +----+
. .
/ \ / \
MN1 MN2 MN3 MN4(guest)
]]></artwork>
</figure>
<section title="Class based prefix delegation">
<t>The Access Aggregation Gateway requests for Prefix delegation
from Mobile gateway and associates the prefix received with class
"global-anchor"(1). The Access Aggregation Gateway is preconfigured
to provide prefixes from the following classes: "global-anchor" (1),
"local-breakout"(2), "guest"(3). It has a preconfigured policy to
advertise prefixes to requesting routers and mobile nodes based on
the service class supported by the service provider for the
requesting device. In the example mobile network, the Access
Router(AR) requests class based prefix allocation by sending a
DHCPv6 SOLICIT message and include OPTION_PREFIX_CLASS in the
OPTION_ORO.</t>
<t>The Access Router (AR) receives an advertise with following
prefixes in the IA_PD option:</t>
<t><list style="numbers">
<t>P1: IA_PD Prefix option with a prefix 3001:1::/64 containing
OPTION_PREFIX_CLASS set to "global-anchor"(1)</t>
<t>P2: IA_PD Prefix option with a prefix 3001:2::/64 containing
OPTION_PREFIX_CLASS set to "local-breakout"(2)</t>
<t>P3: IA_PD Prefix option with a prefix 3001:3::/64 containing
OPTION_PREFIX_CLASS set to "guest"(3)</t>
</list>It sends a REQUEST message with all of above prefixes and
receives a REPLY message with prefixes allocated for each of the
requested class.</t>
</section>
<section title="IPv6 address assignment from class based prefix">
<t>When the Access Router(AR) receives a DHCPv6 SOLICIT requesting
IA_NA from the mobile node that has mobility service enabled, it
offers an IPv6 address from the prefix class "global-anchor"(1). For
MN3 it advertises 3001:1::1 as the IPv6 address in OPTION_IAADDR in
response to the IA_NA request.</t>
<t>The Mobile Node(MN4) <xref target="fig_Example_mobilenetwork">
</xref> sends a DHCPv6 SOLICIT message requesting IA_NA address
assignment with OPTION_USER_CLASS option containing the value
"guest" towards the CPE. The Access Router(AR) 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 the "guest"(3)
class. The IPv6 address in the OPTION_IAADDR is set to 3001:3::1.
The "guest" class can also be distinguished based on a preconfigured
interface or SSID advertised for MNs connecting to it.</t>
<t>When the Access Aggregation Gateway receives a DHCPv6 SOLICIT
requesting IA_NA from MNs through WLC and it has a preconfigured
profile to provide both local-breakout Internet access and
global-anchor, it offers an IPv6 address from the class
"local-breakout" (2) and "global-anchor"(1). For MN1 it advertises
3001:2::1 and 3001:1::2 as the IPv6 address in OPTION_IAADDR in
response to the IA_NA request. Applications within MN1 can choose to
use the appropriate prefix based on the mobility enabled or
local-breakout property attached to the prefix based on source
address selection policy.</t>
<t>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
<xref target="IANA_PREFIX_PROPERTIES"></xref>. If the prefix also
provides security guarantees OPTION_PREFIX_PROPERTY can be set to
0x000A to indicate mobility and security guarantees by bitwise ORing
of both the properties.</t>
</section>
</section>
<section title="Homenet Example">
<t>The following sub-section describes an example of class based
prefix delegation in a home network environment. The network consists
of the following elements:</t>
<t><list style="symbols">
<t>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.</t>
<t>IPv6 Set Top Box (STB): A dedicated, IPv6 attached, video on
demand device.</t>
<t>IPv6 PC: An IPv6 attached personal computer</t>
<t>Delegating Router: The router in the ISPs network acting as a
DHCP server for the IA_PD request.</t>
<t>ISP Video On Demand (ISP-VOD) service: An ISP provided service
offering unicast based streaming video content to subscribers.</t>
<t>Video On Demand (VOD) service: A server providing unicast based
streaming video content to subscribers</t>
<t>On demand Video Application: Application hosted on the IPv6
PC</t>
<t>Application Central: Application server hosted in the Internet
that the On demand Video Application communicates with to access
VOD service</t>
</list></t>
<t><figure title="Simple home network with Data and Video devices">
<artwork><![CDATA[ +-----------+ _----+----_ +----------+
|Application| _( )_ | Video on |
|central |-( Internet )---| Demand |
| | (_ _) | Service |
+-----------+ '----+----' +----------+
|
_----+----_ +----------+ \
_( )_ |ISP Video | \
(Service Provider)--| on 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) | | | /
+----------+ +----------+ /
]]></artwork>
</figure></t>
<section title="Class based prefix delegation to the HGW">
<t>In this example, three 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 <xref
target="I-D.jiang-v6ops-semantic-prefix"></xref>. 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) and "video-app" (3) the meaning of these being of
relevance to the ISP operating this and application that are
configured out of band to utilize it.</t>
<t>The delegating router is preconfigured to advertise prefixes with
these service classes. The HGW sends three IA_PD options within the
SOLICIT message, one with OPTION_PREFIX_CLASS "video" (1), the
second with "internet" (2) and a third with "video-app" (3). The HGW
receives an advertise with the following prefixes in the IA_PD
option:</t>
<t>1. P1: IA_PD Prefix option with a prefix 3001:5::/56 containing
OPTION_PREFIX_CLASS set to "video" (1) with OPTION_PREFIX_PROPERTY
set to 0x0001 indicating there is no internet reach</t>
<t>2. P2: IP_PD Prefix option with a prefix 3001:6::/56 containing
OPTION_PREFIX_CLASS set to "internet" (2)</t>
<t>3. P3: IP_PD Prefix option with a prefix 3001:7::/56 containing
OPTION_PREFIX_CLASS set to "video-app" (3) with property set to
0x0040 indicating the prefix provides Internet service SLA</t>
<t>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 <xref
target="RFC6204"></xref> and sends out router advertisements (RAs)
with the "M" and "O" bits set.</t>
</section>
<section title="IPv6 Assignment to Homenet hosts using stateful DHCPv6">
<t><list style="numbers">
<t>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.</t>
<t>The PC sends a DHCPv6 SOLICIT message requesting for IA_NA
with the OPTION_PREFIX_CLASS option in ORO indicating support
for prefix class. The HGW checks the available prefixes it has
been delegated and advertises IA_NA from P1 (3001:5:2 with
property set to 0x0001) , P2 (3001;6::1) and P3 (3001:7::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 these addresses on its LAN
interface and uses it for sourcing requests to the Internet.</t>
<t>The On demand Video Application on the PC communicates with
its well known Application Central using the "internet" prefix
and is directed to use "video-app" prefix if available based on
agreement between service provider and on demand video
application service provider. The On demand Video Application
then connects using the address assigned from P3 that will offer
better experience based on the SLA between the providers.</t>
<t>If the homenet hosts use SLAAC prefix delegation with the
class will use the options and procedure defined in <xref
target="I-D.korhonen-6man-prefix-properties"></xref></t>
</list></t>
</section>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge review and guidance received
from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark,
Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz, Maciek
Konstantynowicz</t>
</section>
<section title="Contributors">
<t>Authors would like to thank contributions to use cases and text for
various sections received from Sindhura Bandi.</t>
</section>
<!---->
<section anchor="IANA" title="IANA Considerations">
<t>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).</t>
<section anchor="IANA_PREFIX_PROPERTIES"
title="OPTION_PREFIX_PROPERTY values">
<t>IANA is requested to reserve and maintain registry of
OPTION_PREFIX_PROPERTY values and manage allocation of values as per
as per policy defined in <xref target="RFC5226"></xref> with IETF
assigned values requiring IETF consensus, RFC Required policy, any
other values other than the ones listed below are not valid.<list
style="numbers">
<t>0x0001 The prefix cannot be used to reach the Internet</t>
<t>0x0002 The prefix provides network based mobility</t>
<t>0x0004 The prefix requires authentication</t>
<t>0x0008 The prefix is assigned on an interface that provides
security guarantees</t>
<t>0x0010 Usage is charged</t>
<t>0x0020 The prefix provides multi-homed redundancy</t>
<t>0x0040 The prefix provides Internet service SLA, based on
associated OPTION_PREFIX_CLASS</t>
<t>0x0080 Unassigned</t>
<t>0x0100 Unassigned</t>
<t>0x0200 Unassigned</t>
<t>0x0400 Unassigned</t>
<t>0x0800 Unassigned</t>
<t>0x1000 Unassigned</t>
<t>0x2000 Unassigned</t>
<t>0x4000 Unassigned</t>
<t>0x8000 Unassigned</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security issues related to DHCPv6 which are described in section 23
of <xref target="RFC3315"></xref> and <xref target="RFC3633"></xref>
apply for scenarios mentioned in this draft as well.</t>
</section>
<section title="Change History (to be removed prior to publication as an RFC) ">
<t>Changes from -00 to -01</t>
<t><list style="letters">
<t>Modified motivation section to focus on mobile networks</t>
<t>Modified example with a mobile network and class based prefix
delegation in it</t>
</list>Changes from -01 to -02<list style="letters">
<t>Modified option format to be enumerated values</t>
<t>Added IANA section to request managing of registry for the
enumerated values</t>
<t>Added initial values for the class</t>
<t>Added section for applications to select address with a specific
property</t>
</list>Changes from -02 to -03<list style="letters">
<t>Added server behaviour for IA_NA and IA_PD allocation</t>
<t>Added Class based Information-Request usage</t>
</list>Changes from -03 to -04<list style="letters">
<t>Added homenet use case</t>
<t>Split usage class into a fixed IANA maintained properties
registry and a prefix class</t>
</list>Changes from -04 to -05<list style="letters">
<t>Added on demand video application use case and modified the
example section</t>
<t>Added additional properties and reference for SLAAC/ND
procedure</t>
</list></t>
<t></t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<!--&I-D.lepape-6man-prefix-metadata;-->
&RFC2119;
&RFC2460;
&RFC3315;
&RFC3633;
&RFC2865;
&RFC4862;
&RFC3775;
&RFC5226;
&RFC6724;
&RFC6204;
&I-D.korhonen-6man-prefix-properties;
&I-D.ietf-dhc-dhcpv4-over-ipv6;
&I-D.jiang-v6ops-semantic-prefix;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
<!-- A reference written by by an organization not a person. -->
</references>
<!-- Change Log
v00 2011-09-10 EBD Initial version -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:18:50 |