One document matched: draft-bhandari-dhc-class-based-prefix-00.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 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 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-00"
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>sinb@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="21" month="October" year="2011" />
<!-- 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 prefix 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
prefix 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_PREFIX_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>
<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 homenet. 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>
<section title="Mobile network">
<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 beloging to different domains
for e.g. home address prefix, care of address prefix as specified in
<xref target="RFC3775"></xref>. The delegated prefixes when seen
from the mobile router perspective appear to be like any other
prefix, but each prefixes have different properties. 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 tunneling 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="Homenet">
<t>With the introduction of IPv6 and possible absence of Network
Address Translation(NAT) in home networks, the IPv6 source address
of the hosts can be used as a parameter for route decision and
providing differentiated service for different classes of devices
within a home network. <xref
target="I-D.baker-fun-routing-class"></xref> and <xref
target="I-D.baker-fun-multi-router"></xref> introduce use-cases and
requirements for source based routing. The home network architecture
and associated requirements are specified in <xref
target="I-D.chown-homenet-arch"></xref>. To support source based
routing it is necessary to have a mechanism to assign the source
address or prefix based on parameters that identify the class of
device or network.</t>
<t><xref target="RFC3315"></xref> defines OPTION_USER_CLASS option
in the IA_NA/IA_TA assignment, which influences the address
allocated based on the user class of the device requesting IA_NA or
IA_TA. A typical deployment in a home network is the Customer
Premise Equipment (CPE) to be a DHCPv6 client requesting a prefix as
defined in [RFC3633] from upstream the DHCPv6 server and playing the
role of a DHCPv6 server for devices in the Local Area Network (LAN).
The CPE can get a shorter prefix from a DHCPv6 server in Wide Area
Network(WAN) and allocate longer prefixes to its DHCPv6 clients.
Today the CPE has to be manually configured to associate a prefix
acquired from the WAN to devices in the LAN. A means of classifying
and associating an acquired prefix via DHCPv6 for further delegation
either via IA_NA/IA_TA or IA_PD requests is missing.</t>
<t>For e.g. as shown in <xref target="fig-homenetwork"></xref> the
CPE in a home network may request prefixes from the DHCPv6 server of
the service provider and assume the role of a DHCPv6 server for
devices within the home network. Residential and
Small-Office/Home-Office (SOHO) networks may have separate domains
for their “data network” and “home video
network”. Devices in these different domains are to be
assigned addresses from different prefix ranges. The CPE router will
need a way to assign prefixes to the home video network from a
prefix that is meant for home video devices to provide
differentiated service for such devices in the provider network that
has source address based routing policy configured. </t>
<figure align="center" anchor="fig-homenetwork">
<preamble>Simple home network with Data and Video
devices</preamble>
<artwork align="left"><![CDATA[ +-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection (WAN) /
| /
|DHCPv6 Client \
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router (CPE) | /
+------+--------+ /
|DHCPv6 Server | End-User
Local Network | | network(s)
---+-----+-------+--- \
| | \
+----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | /
| (video | | (PC) | /
| device) | | | /
+----------+ +----------+
]]></artwork>
<postamble></postamble>
</figure>
<t></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 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="Prefix Class Option in IA_PD">
<t><figure>
<preamble>The format of the DHCPv6 Prefix 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_PREFIX_CLASS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-class |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PREFIX_CLASS (TBD)
option-length: length of prefix-class
prefix-class: Prefix class (binary string).]]></artwork>
<postamble></postamble>
</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_USER_CLASS or
OPTION_PREFIX_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_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.</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 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_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
prefix classes. Along with including the IA_PD prefix options in the
IA_PD option, it also includes the OPTION_PREFIX_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_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>
</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 prefix class indicated in that
option.</t>
</list>The DHCPv6 server parses OPTION_PREFIX_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 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_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 map OPTION_PREFIX_CLASS option to the
OPTION_USER_CLASS option by string matching of both these option
values.</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", "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.</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 home network. Each of the examples
will refer to the below network:</t>
<t>The example network consists of an IPv6 video endpoint, IPv6 hosts,
and a Smart grid network consisting of IPv6 sensors and a router that
supports Smart Grid Energy Services Interface (ESI) to which sensors are
connected. The customer edge router acts as a home gateway router for
all the devices and networks within the home.</t>
<figure anchor="fig_Example_homenetwork">
<preamble>Example home network</preamble>
<artwork><![CDATA[
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection
|
+------+--------+ \
| IPv6 | Network D (guest) \
| Customer Edge +------------+ \
| Router(CPE) | | |
+----+-+---+--+-+ | |
Network A | | |Network B | |
+----+ | | | |
| | +---+ | |
+-----+----+ | +----+-----+ +-----+----+ |
|IPv6 Video| | | IPv6 Host| |IPv6 Host | |
|endpoint | | | A | | B | |
+-----+----+ | +----------+ +----------+ |
| |
| |
| |
+------+--------+ | End-User
| IPv6 | | networks
| Smart grid + |
| Router | |
+--------+------+ |
Network C | |
+----+-------------+---+ |
| | |
+----+-----+ +-----+----+ |
| IPv6 | | IPv6 | |
| Sensor | | Sensor | /
+----------+ +-----+----+ /]]></artwork>
</figure>
<section title="Class based prefix delegation">
<t>The Service Provider Router is preconfigured to provide prefixes
from the following classes: "video", "default", "guest", and
"smart-grid". It has a preconfigured policy to advertise prefixes to
requesting routers based on the services supported by the service
provider for a given home. In the example home network, the CPE
requests class based prefix allocation by sending a DHCPv6 SOLICIT
message and include OPTION_PREFIX_CLASS in the OPTION_ORO. </t>
<t>The CPE receives an advertise with following prefixes in the IA_PD
option :</t>
<t><list style="numbers">
<t>IA_PD Prefix option with a prefix 3001::1::/64 containing
OPTION_PREFIX_CLASS set to "video"</t>
<t>IA_PD Prefix option with a prefix 3001::2::/64 containing
OPTION_PREFIX_CLASS set to "guest"</t>
<t>IA_PD Prefix option with a prefix 3001::3::/64 containing
OPTION_PREFIX_CLASS set to "smart-grid"</t>
<t>IA_PD Prefix option with a prefix 3001::4::/64 containing
OPTION_PREFIX_CLASS set to "default"</t>
</list>It sends a REQUEST message with all of above prefixes and
receives a REPLY message. </t>
</section>
<section title="IPv6 address assignment from class based prefix">
<t>The video endpoint in Network A in<xref
target="fig_Example_homenetwork"></xref> sends a DHCPv6 SOLICIT
message requesting IA_NA address assignment with OPTION_USER_CLASS
option containing the value "video" towards the CPE. The CPE assumes
the role of the DHCPv6 server and sends an ADVERTISE to the video
endpoint with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR
from the "video" prefix class. The IPv6 address in the OPTION_IAADDR
is set to 3001::1::1. </t>
<t>When the CPE receives a DHCPv6 SOLICIT requesting IA_NA for the
IPv6 host from Network B, it offers an IPv6 address from the prefix
class "default". For IPv6 host A it advertises 3001::4::1 as the IPv6
address in OPTION_IAADDR in response to the IA_NA request. </t>
<t>When the CPE receives a DHCPv6 SOLICIT requesting IA_NA for the
IPv6 host from Network D (guest network), it offers an IPv6 address
from the prefix class "guest". For IPv6 host B it advertises
3001::2::1 as the IPv6 address in OPTION_IAADDR in response to the
IA_NA request. The Network D can be distinguished based on a
preconfigured interface or SSID advertised by this CPE for guest hosts
connecting to it. </t>
</section>
<section title="IPv6 prefix delegation from class based prefix">
<t>The IPv6 Smart Grid router in <xref
target="fig_Example_homenetwork"></xref> sends a SOLICIT towards the
CPE requesting prefix delegation in the "smart-grid" class by
including the IA_PD option with the OPTION_PREFIX_CLASS containing
"smart-grid". The CPE selects a longer prefix from "smart-grid" prefix
previously obtained from Service Provider Router. It sends a DHCPv6
ADVERTISE message with IA_PD option containing the IPv6 prefix 3001::
3:1::/96 and OPTION_PREFIX_CLASS set to "smart-grid". The Smart Grid
router MAY then advertise that prefix in IPv6 Router Advertisement
(RA) messages towards IPv6 sensors connected to it. IPv6 sensors can
do SLAAC (<xref target="RFC4862">as defined in</xref>) to configure
IPv6 address from the received RA message.</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_PREFIX_CLASS
from the "DHCPv6 and DHCPv6 options" registry
(http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml).</t>
</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>
</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;
&I-D.baker-fun-multi-router;
&I-D.chown-homenet-arch;
&I-D.baker-fun-routing-class;
&RFC2865;
&RFC4862;
&RFC3775;
</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:25:16 |