One document matched: draft-bhandari-dhc-class-based-prefix-02.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 RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.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 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.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-02"
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="Sindhura Bandi" initials="S." surname="Bandi">
<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 2347</phone>
<email>sinb@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>
<date day="16" month="July" year="2012" />
<!-- 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>DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6
addresses. This document extends DHCPv6 prefix delegation with class
based prefix allocation. It defines a new usage class option to classify
a prefix. It defines the behavior of a DHCPv6 client 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DHCPv6 based prefix delegation as defined in <xref
target="RFC3633"></xref> is a mechanism for the delegation of IPv6
prefixes using DHCPv6 options. Through these options, a delegating
router can delegate prefixes to authorized requesting routers. If the
requesting router has to function as a DHCPv6 server there needs to be
additional information in the delegated prefix that helps the requesting
router to select the address allocation for the DHCPv6 client it serves,
from one of the available delegated prefixes.</t>
<t>One way to select an address or longer prefix (from a delegated
prefix) to be allocated by a requesting router playing the role of a
DHCPv6 server is by introducing additional options in IA_PD to be
matched with options for address selection in the DHCPv6 SOLICIT
message. <xref target="RFC3315"></xref> defines the OPTION_USER_CLASS
option which is used for selecting address for assignment. This document
introduces OPTION_USAGE_CLASS option in IA_PD option for the purpose of
selecting a prefix for further delegation either via IA_NA or IA_PD
DHCPv6 request. It defines the behavior of the DHCPv6 server, the DHCPv6
prefix requesting router and the DHCPv6 client to use this option.</t>
<t>In IPv6 a network interface can acquire multiple addresses from the
same scope. In this case application need to have additional information
about the prefix configured on the interface for source address
selection. Since 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).</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. The class information
attached to a delegated prefix helps to distinguish property of a
delegated IPv6 prefix and selection of the prefix by different
applications using it.</t>
<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
properties 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.</t>
</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 usage class option in IA_PD and IA_NA to aid
class based prefix delegation and address assignment. This section
defines the behavior of the delegating router, the requesting router and
the DHCPv6 client.</t>
<section title="Usage Class Option">
<t><figure>
<preamble>The format of the DHCPv6 usage class option is 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_USAGE_CLASS | option-length(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~
~ Vendor Class Data (Optional,variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | Enterprise ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise ID(4) | Vendor Class length(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Vendor Class Data (Variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Enterprise ID: The vendor's 32-bit Enterprise Number as
registered with IANA [IANAEnterprise]
Vendor Class Length: 2, length of vendor class data that follows
Vendor Class Data: Binary data as defined by the vendor.
For e.g. 3gpp can specify this data to be
Application providers network domain string
]]></artwork>
<postamble></postamble>
</figure>The class values are maintained in OPTION_USAGE_CLASS
values enumeration explained in Section <xref
target="class_values"></xref>.</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_USER_CLASS or
OPTION_USAGE_CLASS options received in IA_NA request or any of the
other methods as described in Section 2.3.1.</t>
<section title="Requesting Router Behavior ">
<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_USAGE_CLASS requesting prefix delegation for the
specific class indicated in the OPTION_USAGE_CLASS option. It
can include multiple IA_PD Prefix options to indicate it's
preference for more than one usage class.</t>
<t>In the SOLICIT message include an OPTION_ORO option with the
OPTION_USAGE_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_USAGE_CLASS option
in theOPTION_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>
</section>
<section title="Delegating Router Behavior">
<t>If the Delegating router supports class based prefix allocation
by supporting the OPTION_USAGE_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_USAGE_CLASS within the
IA_PD Prefix option, it selects prefixes to be offered from that
specific class.</t>
<t>If requesting router includes OPTION_USAGE_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 usage
classes. Along with including the IA_PD prefix options in the IA_PD
option, it also includes the OPTION_USAGE_CLASS option in the
OPTION_IAPREFIX option area of the corresponding IA_PD prefix
option.</t>
<t>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 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_USAGE_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>
</section>
<section title="DHCPv6 Client Behavior for IA_NA allocation">
<t>DHCPv6 client MAY request for an IA_NA address allocation from a
specific usage 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_USAGE_CLASS requesting address to be
allocated from a specific usage class indicated in that
option.</t>
</list>The DHCPv6 server parses OPTION_USAGE_CLASS option received
and includes it in option area of corresponding OPTION_IA_NA in
ADVERTISE message.</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.</t>
<section anchor="class_values" title="OPTION_USAGE_CLASS Values">
<t>Following values will be allocated from the IANA maintained
OPTION_USAGE_CLASS registry:<list style="symbols">
<t>global-anchor(1) - Prefix is globally anchored and hence
would allow mobility.</t>
<t>local-breakout(2) - Prefix is managed in a local-breakout
domain and hence has limited mobility.</t>
<t>Vendor-specfied-class(3) - Prefix class is specified by the
vendor, Vendor class data in the option that follows will
provide more information.</t>
</list>New values of OPTION_USAGE_CLASS can be assigned and
registered with IANA as per policy detailed in section <xref
target="IANA_CLASS_VALUES"></xref>.</t>
</section>
<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", "guest", "voice" etc), for
assigning the IPv6 addresses to the end hosts through DHCPv6 IA_NA
based on a preconfigured mapping with OPTION_USAGE_CLASS option, the
following conditions MAY be observed: <list style="symbols">
<t>It MAY have a pre-configured mapping between the usage class
and OPTION_USER_CLASS option received in IA_NA.</t>
<t>It MAY match the OPTION_USAGE_CLASS if the IA_NA request
received contains OPTION_USAGE_CLASS.</t>
<t>It MAY have a pre-configured mapping between the usage class
and the client DUID received in DHCPv6 message.</t>
<t>It MAY have a pre-configured mapping between the usage 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", "guest", "voice" 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-dmm-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_USAGE_CLASS using rules
defined in <xref target="RFC3484"></xref>.</t>
</section>
</section>
</section>
<section anchor="example" title="Example Application ">
<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 Acess 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">
<preamble>Example mobile network</preamble>
<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 usage class
"global-anchor"(1). The Access Aggregation Gateway is preconfigured to
provide prefixes from the following classes: "global-anchor" (1),
"local-breakout"(2), "guest"(x). 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_USAGE_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_USAGE_CLASS set to "global-anchor"(1)</t>
<t>P2: IA_PD Prefix option with a prefix 3001::2::/64 containing
OPTION_USAGE_CLASS set to "local-breakout"(2)</t>
<t>P3: IA_PD Prefix option with a prefix 3001::3::/64 containing
OPTION_USAGE_CLASS set to "guest"(x)</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 usage 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" usage 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 usage 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>
</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</t>
</section>
<!---->
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign an option code to OPTION_USAGE_CLASS from
the "DHCPv6 and DHCPv6 options" registry
(http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).</t>
<section anchor="IANA_CLASS_VALUES" title="OPTION_USAGE_CLASS values">
<t>IANA is requested to reserve and maintain registry of
OPTION_USAGE_CLASS values and manage allocation of values in the
following way as per as per policy defined in <xref
target="RFC5226"></xref>: <list style="numbers">
<t>Values 1 to 8191 ( 0x0001 - 0x1FFF) - IETF assigned class with
IETF consensus, RFC Required policy</t>
<t>Values 8192 to 16368 (0x2000 – 0x3ff0) - Vendor defined
class assigned on a First Come First Served allocation policy</t>
<t>Values 16369 to 16383 (0x3ff1 - 0x3fff) - Experimental usage
reserved for Private Use</t>
</list></t>
<t>Following values will be allocated from this registry as explained
in section <xref target="class_values"></xref>:</t>
<t><list style="symbols">
<t>global-anchor(1) - Prefix is globally anchored and hence would
allow mobility.</t>
<t>local-breakout(2) - Prefix is managed in a local-breakout
domain and hence has limited mobility.</t>
<t>Vendor-specfied-class(3) - Prefix class is vendor
specified.</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 -00 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></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"?-->
&RFC2119;
&RFC2460;
&RFC3315;
&RFC3633;
&RFC2865;
&RFC4862;
&RFC3775;
&RFC5226;
&RFC3484;
&I-D.korhonen-dmm-prefix-properties;
<reference anchor="IANAEnterprise">
<front>
<title>Private Enterprise Numbers,
http://www.iana.org/assignments/enterprise-numbers</title>
<author fullname="IANA" surname="IANA">
<organization></organization>
</author>
<date month="" year="" />
</front>
</reference>
</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-24 05:24:52 |