DHCPv6 class based prefix
draft-bhandari-dhc-class-based-prefix-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Shwetha Bhandari , Gaurav Halwasia , Sri Gundavelli , Sindhura Bandi | ||
| Last updated | 2011-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bhandari-dhc-class-based-prefix-00
Internet Engineering Task Force S. Bhandari
Internet-Draft G. Halwasia
Intended status: Standards Track S. Bandi
Expires: April 23, 2012 S. Gundavelli
Cisco Systems
H. Deng
China Mobile
October 21, 2011
DHCPv6 class based prefix
draft-bhandari-dhc-class-based-prefix-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Bhandari, et al. Expires April 23, 2012 [Page 1]
Internet-Draft DHCPv6 class based prefix October 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Mobile network . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Homenet . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Prefix Class Option in IA_PD . . . . . . . . . . . . . . . 6
2.2. Consideration for different DHCPv6 entities . . . . . . . 6
2.2.1. Requesting Router Behavior . . . . . . . . . . . . . . 7
2.2.2. Delegating Router Behavior . . . . . . . . . . . . . . 7
2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 8
2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Class based prefix and IA_NA allocation . . . . . . . 8
2.3.2. Class based prefix and IA_PD allocation . . . . . . . 9
2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 9
3. Example Application . . . . . . . . . . . . . . . . . . . . . 9
3.1. Class based prefix delegation . . . . . . . . . . . . . . 10
3.2. IPv6 address assignment from class based prefix . . . . . 11
3.3. IPv6 prefix delegation from class based prefix . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Bhandari, et al. Expires April 23, 2012 [Page 2]
Internet-Draft DHCPv6 class based prefix October 2011
1. Introduction
DHCPv6 based prefix delegation as defined in [RFC3633] 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.
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. [RFC3315] 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.
1.1. Motivation
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.
1.1.1. Mobile network
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
[RFC3775]. 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.
Bhandari, et al. Expires April 23, 2012 [Page 3]
Internet-Draft DHCPv6 class based prefix October 2011
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.
1.1.2. Homenet
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. [I-D.baker-fun-routing-class] and
[I-D.baker-fun-multi-router] introduce use-cases and requirements for
source based routing. The home network architecture and associated
requirements are specified in [I-D.chown-homenet-arch]. 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.
[RFC3315] 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.
For e.g. as shown in Figure 1 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
Bhandari, et al. Expires April 23, 2012 [Page 4]
Internet-Draft DHCPv6 class based prefix October 2011
configured.
Simple home network with Data and Video devices
+-------+-------+ \
| 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) | | | /
+----------+ +----------+
Figure 1
1.2. Terminology
This document uses the terminology defined in [RFC2460], [RFC3315]
and [RFC3633].
1.3. Requirements Language
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 RFC 2119 [RFC2119].
2. Overview
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.
Bhandari, et al. Expires April 23, 2012 [Page 5]
Internet-Draft DHCPv6 class based prefix October 2011
2.1. Prefix Class Option in IA_PD
The format of the DHCPv6 Prefix Class option is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFIX_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).
2.2. Consideration for different DHCPv6 entities
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:
o Configuration
o Prefix delegated via a DHCPv6 request to another DHCPv6 server
o Using a Authentication Authorization Accounting (AAA) protocol
like RADIUS [RFC2865]
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.
Bhandari, et al. Expires April 23, 2012 [Page 6]
Internet-Draft DHCPv6 class based prefix October 2011
2.2.1. Requesting Router Behavior
DHCPv6 requesting router can request for prefixes in the following
ways:
o 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.
o 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.
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.
2.2.2. Delegating Router Behavior
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:
o If requesting router includes OPTION_PREFIX_CLASS within the IA_PD
Prefix option, it selects prefixes to be offered from that
specific class.
o 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.
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.
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 [RFC3633] without including
the class option in the IA_PD prefix option in the response.
Bhandari, et al. Expires April 23, 2012 [Page 7]
Internet-Draft DHCPv6 class based prefix October 2011
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
[RFC3633].
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 [RFC3633]. 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.
2.2.3. DHCPv6 Client Behavior for IA_NA allocation
DHCPv6 client MAY request for an IA_NA address allocation from a
specific prefix class in the following way:
o 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.
The DHCPv6 server parses OPTION_PREFIX_CLASS option received and
includes it in option area of corresponding OPTION_IA_NA in ADVERTISE
message.
2.3. Usage
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.
2.3.1. Class based prefix and IA_NA allocation
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:
o It MAY have a pre-configured mapping between the prefix class and
OPTION_USER_CLASS option received in IA_NA.
o It MAY match the OPTION_PREFIX_CLASS if the IA_NA request received
contains OPTION_PREFIX_CLASS.
Bhandari, et al. Expires April 23, 2012 [Page 8]
Internet-Draft DHCPv6 class based prefix October 2011
o It MAY map OPTION_PREFIX_CLASS option to the OPTION_USER_CLASS
option by string matching of both these option values.
o It MAY have a pre-configured mapping between the prefix class and
the client DUID received in DHCPv6 message.
o It MAY have a pre-configured mapping between the prefix class and
its network interface on which the IA_NA request was received.
The requesting router playing the role of a DHCPv6 server can
ADVERTISE IA_NA from a class of prefix(es) thus selected.
2.3.2. Class based prefix and IA_PD allocation
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.
2.3.3. Class based prefix and SLAAC
DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as
defined in [RFC4862]) are two ways by IPv6 addresses can be
dynamically assigned to end hosts. Making SLAAC class aware is
outside the scope of this document.
3. Example Application
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:
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.
Bhandari, et al. Expires April 23, 2012 [Page 9]
Internet-Draft DHCPv6 class based prefix October 2011
Example home network
+-------+-------+ \
| 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 | /
+----------+ +-----+----+ /
Figure 2
3.1. Class based prefix delegation
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
Bhandari, et al. Expires April 23, 2012 [Page 10]
Internet-Draft DHCPv6 class based prefix October 2011
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.
The CPE receives an advertise with following prefixes in the IA_PD
option :
1. IA_PD Prefix option with a prefix 3001::1::/64 containing
OPTION_PREFIX_CLASS set to "video"
2. IA_PD Prefix option with a prefix 3001::2::/64 containing
OPTION_PREFIX_CLASS set to "guest"
3. IA_PD Prefix option with a prefix 3001::3::/64 containing
OPTION_PREFIX_CLASS set to "smart-grid"
4. IA_PD Prefix option with a prefix 3001::4::/64 containing
OPTION_PREFIX_CLASS set to "default"
It sends a REQUEST message with all of above prefixes and receives a
REPLY message.
3.2. IPv6 address assignment from class based prefix
The video endpoint in Network A inFigure 2 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.
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.
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.
Bhandari, et al. Expires April 23, 2012 [Page 11]
Internet-Draft DHCPv6 class based prefix October 2011
3.3. IPv6 prefix delegation from class based prefix
The IPv6 Smart Grid router in Figure 2 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 (as defined in [RFC4862]) to configure IPv6
address from the received RA message.
4. Acknowledgements
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
5. IANA Considerations
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).
6. Security Considerations
Security issues related to DHCPv6 which are described in section 23
of [RFC3315] and [RFC3633] apply for scenarios mentioned in this
draft as well.
7. References
7.1. Normative References
[I-D.baker-fun-multi-router]
Baker, F., "Exploring the multi-router SOHO network",
draft-baker-fun-multi-router-00 (work in progress),
July 2011.
[I-D.baker-fun-routing-class]
Baker, F., "Routing a Traffic Class",
draft-baker-fun-routing-class-00 (work in progress),
Bhandari, et al. Expires April 23, 2012 [Page 12]
Internet-Draft DHCPv6 class based prefix October 2011
July 2011.
[I-D.chown-homenet-arch]
Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
Networking Architecture for IPv6",
draft-chown-homenet-arch-00 (work in progress),
September 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
Bhandari, et al. Expires April 23, 2012 [Page 13]
Internet-Draft DHCPv6 class based prefix October 2011
Authors' Addresses
Shwetha Bhandari
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone:
Email: shwethab@cisco.com
Gaurav Halwasia
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4426 1321
Email: ghalwasi@cisco.com
Sindhura Bandi
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4426 2347
Email: sinb@cisco.com
Sri Gundavelli
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Bhandari, et al. Expires April 23, 2012 [Page 14]
Internet-Draft DHCPv6 class based prefix October 2011
Hui Deng
China Mobile
53A, Xibianmennei Ave., Xuanwu District
Beijing 100053
China
Email: sinb@cisco.com
Bhandari, et al. Expires April 23, 2012 [Page 15]