| 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
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.
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 (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 (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.
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.
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.
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. 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.
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 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) | | | /
+----------+ +----------+
This document uses the terminology defined in [RFC2460], [RFC3315] and [RFC3633].
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].
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.
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).
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:
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.
DHCPv6 requesting router can request for prefixes in the following ways:
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.
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:
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.
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.
DHCPv6 client MAY request for an IA_NA address allocation from a specific prefix class in the following way:
The DHCPv6 server parses OPTION_PREFIX_CLASS option received and includes it in option area of corresponding OPTION_IA_NA in ADVERTISE message.
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.
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:
The requesting router playing the role of a DHCPv6 server can ADVERTISE IA_NA from a class of prefix(es) thus selected.
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.
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.
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.
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 | /
+----------+ +-----+----+ /
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.
The CPE receives an advertise with following prefixes in the IA_PD option :
It sends a REQUEST message with all of above prefixes and receives a REPLY message.
The video endpoint in Network A inFigure 3 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.
The IPv6 Smart Grid router in Figure 3 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.
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
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).
Security issues related to DHCPv6 which are described in section 23 of [RFC3315] and [RFC3633] apply for scenarios mentioned in this draft as well.
| [RFC2629] | Rose, M.T., "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. |