Internet Engineering Task Force S. Bhandari Internet-Draft G. Halwasia Intended status: Standards Track S.BandiGundavelli Expires:January 17,August 22, 2013S. GundavelliCisco Systems H. Deng China Mobile L. Thiebaut Alcatel-LucentJuly 16, 2012J. Korhonen Renesas Mobile February 18, 2013 DHCPv6 class based prefixdraft-bhandari-dhc-class-based-prefix-03draft-bhandari-dhc-class-based-prefix-04 AbstractDHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 addresses.This documentextends DHCPv6 prefix delegation with class based prefix allocation. It defines a new usage class optionintroduces options toclassify a prefix.communicate property and associate metadata with prefixes. Itdefines the behavior of aextends DHCPv6client requesting a prefix to include the class of theprefixto be allocateddelegation and address allocation using theDHCPv6 server behavior to select and offer a prefix from a given class. It discusses how IA_NA can be requestedmetadata for selection of prefixes andassigned from a specific usage class.addresses. 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 onJanuary 17,August 22, 2013. Copyright Notice Copyright (c)20122013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Terminology1.1.1. Mobile networks . . . . . . . . . . . . . . . . . . . 4 1.1.2. Home networks . . . . . . . . . . . . . . . . . . . . 41.3. Requirements Language1.2. Terminology . . . . . . . . . . . . . . . . . . . . .4 2. Overview. . 5 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . .4 2.1. Usage Class Option. . . . . . . . . . . . . . . . . . . . 5 2.1. Prefix Property and Class Options . . . . . . . . . . . . 5 2.2. Consideration for different DHCPv6 entities . . . . . . .67 2.2.1. Requesting Router Behavior for IA_PD allocation . . .67 2.2.2. Delegating Router Behavior for IA_PD allocation . . .78 2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . .79 2.2.4. DHCPv6 Server Behavior for IA_NA allocation . . . . .89 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . .810 2.3.1.OPTION_USAGE_CLASS Values . . . . . . .Class based prefix and IA_NA allocation . . . . . . .810 2.3.2. Class based prefix andIA_NAIA_PD allocation . . . . . . .910 2.3.3. Class based prefix andIA_PD allocationSLAAC . . . . . . .9. . . . . . 10 2.3.4. Class based prefix andSLAACapplications . . . . . . . . . 11 3. Example Application . . . .9 2.3.5. Class based Information-Request. . . . . . . . . . .10 2.3.6.. . . . . . 11 3.1. Mobile gateway example . . . . . . . . . . . . . . . . . . 11 3.1.1. Class based prefixand applicationsdelegation . . . . . . . . .10 3.. . . 12 3.1.2. IPv6 address assignment from class based prefix . . . 13 3.2. Homenet ExampleApplication. . . . . . . . . . . . . . . . . . . . .10 3.1.14 3.2.1. Class based prefix delegation to the HGW . . . . . . . 15 3.2.2. IPv6 Assignment to Homenet hosts using stateful DHCPv6 . . . . . . .12 3.2. IPv6 address assignment from class based prefix. . . . .12. . . . . . . . . . . . 16 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .1316 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .13 5.1. OPTION_USAGE_CLASS17 6.1. OPTION_PREFIX_PROPERTY values . . . . . . . . . . . . . .. . 13 6.17 7. Security Considerations . . . . . . . . . . . . . . . . . . .14 7.18 8. Change History (to be removed prior to publication as an RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 8.18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . .14 8.1.19 9.1. Normative References . . . . . . . . . . . . . . . . . . .14 8.2.19 9.2. Informative References . . . . . . . . . . . . . . . . . .1520 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1520 1. IntroductionDHCPv6 based prefix delegation as defined in [RFC3633] isIn IPv6 amechanism fornetwork interface can acquire multiple addresses from thedelegationsame scope. In such a multi-prefix network each ofIPv6the multiple prefixesusing DHCPv6 options. Through these options, a delegating routercandelegate prefixes to authorized requesting routers. If the requesting router has to function ashave aDHCPv6 server there needs tospecific property and purpose associated with it. Example: In a mobile network a mobile device can beadditional information in the delegatedassigned a prefixthat helps the requesting router to select the address allocation forfrom its home network and another from theDHCPv6 clientvisiting network that itserves, from oneis attached to. Another example is a prefix may provide free internet access without offering any quality ofthe available delegated prefixes. One way to select an address or longerservice guarantees while another prefix(from a delegated prefix) tomay beallocated by a requesting router playing the rolecharged along with providing quality ofa DHCPv6 serverservice guarantees for network service access. A prefix can have well defined properties that isby introducing additional options in IA_PD to be matcheduniversal and have a metadata associated withoptionsit that communicates its local significance. The properties and metadata of prefix will be relevant for prefix delegation, source address selection as elaborated in theDHCPv6 SOLICIT message. [RFC3315]subsequent sections. This document definesthe OPTION_USER_CLASSOPTION_PREFIX_PROPERTY optionwhich is used for selecting address for assignment. Butthat communicates property of theOPTION_USER_CLASS optionprefix that isonly loosely defined and it can hardly be used in mobile environment where a DHCPv6 client,universally understood.This document defines OPTION_PREFIX_CLASS option to communicate metadata of theDHCPv6 server or requesting router andprefix that communicates thedelegating Router may belong to different organizations.prefix's local significance. This documentintroduces OPTION_USAGE_CLASS option in IA_PD option for the purposediscusses usage ofselecting a prefix for further delegation eitherOPTION_PREFIX_CLASS to request and select prefixes with specific metadata viaIA_NA orIA_PDDHCPv6 request. Itand IA_NA as defined in [RFC3633] and[RFC3315] respectively.This document defines the behavior of the DHCPv6 server, the DHCPv6 prefix requesting router and the DHCPv6 client to usethis option. 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 interfaceOPTION_PREFIX_CLASS option forsource address selection. Since therequesting and selecting prefixes and addresses. The network address can be configured via DHCPv6 as defined in [RFC3315] or via Stateless Address Autoconfiguration (SLAAC) as defined in [RFC4862], additional information of a prefix can be provided via DHCPv6 or via IPv6 Router Advertisement (RA). The information provided in the options defined in this document OPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS can be used for source address selection. Communicated property and metadata information about the prefix via IPv6 Router Advertisement (RA) will be dealt with in separate document [I-D.korhonen-dmm-prefix-properties]. 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 home networks. Theclassproperty information attached to a delegated prefix helps to distinguishproperty ofa delegated IPv6 prefix and selection of the prefix by different applications using it. 1.1.1. Mobile networks 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 [RFC3775]. The delegated prefixes when seen from the mobile router perspective appear to be like any other prefix, but each prefixes have differentpropertiesmetadata referred to as "Prefix Color" in the mobile networks. Some delegated prefixes may be topologically local and some may be remote prefixes anchored on a global anchor, but available to the local anchor by means of tunnel setup in the network between the local and global anchor. Some may be local with low latency characteristics suitable for voice call break-out, some may have global mobility support. So, the prefixes have different properties and it is required for the application using the prefix to learn about this property in order to use it intelligently. There is currently no semantics in DHCPv6 prefix delegation that can carry this information to specify properties of a delegated prefix. In this scenario, the mobile router is unable to further delegate a longer prefix intelligently based on properties of the prefix learnt. Neither is a mobile device able to learn about the property of the prefix assigned to influence source address selection. Example to determine if the prefix is a home address or care of address. 1.1.2. Home networks In a fixed network environment, the homenet CPE may also function as both a DHCPv6 client (requesting the IA_PD(s)) and a DHCPv6 server allocating prefixes from delegated prefix(es) to downstream home network hosts. Some service providers may wish to delegate multiple prefixes to the CPE for use by different services classes and traffic types. Motivations for this include: o Using source prefix to identify the service class / traffic type that is being transported. The source prefix may then reliably be used as a parameter for differentiated services or other purposes. E.g. [I-D.jiang-v6ops-semantic-prefix] o Using the specific source prefix as a host identifier for other services. E.g. as an input parameter to a DHCPv4 over IPv6 server [I-D.ietf-dhc-dhcpv4-over-ipv6] To meet these requirements, when the CPE (functioning as a DHCPv6 server) receives an IA_NA or IA_TA request from a homenet host, a mechanism is required so that the correct prefix for requested service class can be selected for allocation. Likewise for DHCPv6 clients located in the homenet, a mechanism is necessary so that the intended service class for a requested prefix can be signalled to the DHCPv6 server. 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 definesusageprefix property and prefix classoptionoptions in IA_PD andIA_NA to aid class based prefix delegation and address assignment.IA_NA. This section defines the behavior of the delegating router, the requesting router and the DHCPv6 client. Itdefines also usage class optiondiscusses these options in the context of aDHCPDHCPv6 information request from aDHCPDHCPv6 client to aDHCPDHCPv6 server. 2.1.UsagePrefix Property and ClassOptionOptions The format of the DHCPv6usageprefix property and prefix classoption isoptions are 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_USAGE_CLASSOPTION_PREFIX_PROPERTY | option-length(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ClassProperties |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ ~ Vendor Class Data (Optional,variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code:OPTION_USAGE_CLASS (TBD)OPTION_PREFIX_PROPERTY (TBD1) option-length: 2+ Length of Vendor class information if present Class:Properties: 16bit numeric valuebits maintained asOPTION_USAGE_CLASS enumerationOPTION_PREFIX_PROPERTY in IANA registerednamespace Vendor Class Data: If thenamespace. Each valueof Class (3) indicates it is vendor specified additional vendor specified data of variable length willin the registry represents a property. Multiple properties can beattachedrepresented by bitwise ORing of the individual property values in this field. Prefix Property Option The individual property are maintained in OPTION_PREFIX_PROPERTY values enumeration explained in Section Section 6.1. Along with theform specifiedOPTION_PREFIX_PROPERTY a metadata associated with the prefix that is of local relevance is communicated using OPTION_PREFIX_CLASS defined 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_CLASSOPTION_PREFIX_CLASS |option-length(2)option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_PREFIX_CLASS (TBD2) option-length: 2 Prefix Class: 16 bit integer withIANA [IANAEnterprise] Vendor Class Length: 2, lengththe integer value ofvendor class data that follows Vendorlocal significance. Prefix ClassData: Binary data as defined by the vendor. For e.g. 3gpp can specify this data to be Application providers network domain string The class values are maintained in OPTION_USAGE_CLASS values enumeration explained in Section Section 2.3.1.Option 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 theOPTION_USER_CLASS or OPTION_USAGE_CLASS optionsOPTION_PREFIX_CLASS option received in IA_NA request or any of the othermethodsmethod as described in Section 2.3.1. 2.2.1. Requesting Router Behavior for IA_PD allocation DHCPv6 requesting router can request for prefixes in the following ways: o In the SOLICIT message within the IA_PD Prefix option, it MAY includeOPTION_USAGE_CLASSOPTION_PREFIX_CLASS requesting prefix delegation for the specific class indicated in theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option. It can include multiple IA_PD Prefix options to indicate it's preference for more than oneusageprefix class. The class of prefix it requests is learnt via configuration or any other out of band mechanism not defined in this document. o In the SOLICIT message include an OPTION_ORO option with theOPTION_USAGE_CLASSOPTION_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 theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option intheOPTION_IAPREFIXthe OPTION_IAPREFIX option area of the corresponding IA_PD Prefix option in the ADVERTISE message. The Requesting router MUST then include all or subset of the received class based prefix(es) in the REQUEST message so that it will be responsible for the prefixes selected. The requesting router parses and stores OPTION_PREFIX_PROPERTY if received with the prefix. 2.2.2. Delegating Router Behavior for IA_PD allocation If the Delegating router supports class based prefix allocation by supporting theOPTION_USAGE_CLASSOPTION_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 includesOPTION_USAGE_CLASSOPTION_PREFIX_CLASS within the IA_PD Prefix option, it selects prefixes to be offered from that specific class. o If requesting router includesOPTION_USAGE_CLASSOPTION_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 differentusageclasses. Along with including the IA_PD prefix options in the IA_PD option, italso includesMAY include theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option in the OPTION_IAPREFIX option area of the corresponding IA_PD prefixoption.option with the class information of the prefix. If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message include theOPTION_USAGE_CLASSOPTION_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 theOPTION_USAGE_CLASSOPTION_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. In addition if the delegating router has additional property associated with the prefix it will be provided in OPTION_PREFIX_PROPERTY option. 2.2.3. DHCPv6 Client Behavior for IA_NA allocation DHCPv6 client MAY request for an IA_NA address allocation from a specificusageprefix class in the following way: o In the SOLICIT message within the IA_NA option, it MAY include theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS requesting address to be allocated from a specificusageclass indicated in that option. The class information to be requested can be learnt via configuration or any other out of band mechanism not described in this document. If DHCPv6 client receivesOPTION_USAGE_CLASS optionOPTION_PREFIX_CLASS, OPTION_PREFIX_PROPERTY options in theIAaddr- optionsIAaddr-options area of the corresponding IA_NA but does not supportthis option,one or both of these options, it SHOULD ignore the receivedoption.option(s). 2.2.4. DHCPv6 Server Behavior for IA_NA allocation The DHCPv6 server parsesOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option received and when it supports allocation within the requestedOPTION_USAGE_CLASSOPTION_PREFIX_CLASS responds with an ADVERTISE message after populating the IA_NA option with address information from the requestedUsageprefix class. Along with including the IA Address options in the IA_NA option, it also includes theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option in the corresponding IAaddr- options area. Even though the IA_NA option in the SOLICIT message does not include theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option, based on local policies, the DHCP server MAY select a defaultOPTION_USAGE_CLASSOPTION_PREFIX_CLASS value for the client and then SHOULD include theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option in the IAaddr- options area of the corresponding IA_NA it sends to the client. If both DHCP client and server supportUsage-class-basedclass based address allocation, but the DHCP server cannot offer addresses in the specified Usage class then the DHCP server MUST include the status code NoAddrsAvail (as defined in [RFC3315]) in the response message. If the DHCP server cannot offer addresses for any other reason, it MUST respond torequesting routerclient with appropriate status code as specified in [RFC3315]. In addition if the server has additional property associated with the prefix by means of configuration or learnt from DHCPv6 prefix delegation or derived via any other means it MUST be sent as OPTION_PREFIX_PROPERTY option. 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. OPTION_USAGE_CLASS Values Following values will be allocated from the IANA maintained OPTION_USAGE_CLASS registry: o global-anchor(1) - Prefix is globally anchored and hence would allow mobility. o local-breakout(2) -Prefixis managed in a local-breakout domainproperty andhence has limited mobility. o Vendor-specfied-class(3) - Prefixclassis specified by the vendor, Vendor class data in the option that follows will provide more information. New values of OPTION_USAGE_CLASScan beassigned and registered with IANA as per policy detailed in section Section 5.1. 2.3.2.used for source address selection by applications using the prefix for communication. 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","video" (1), "guest"(2), "voice" (3) etc), for assigning the IPv6 addresses to the end hosts through DHCPv6 IA_NA based on a preconfigured mapping withOPTION_USAGE_CLASSOPTION_PREFIX_CLASS option, the following conditions MAY be observed: o It MAY have a pre-configured mapping between theusageprefix class and OPTION_USER_CLASS option received in IA_NA. o It MAY match theOPTION_USAGE_CLASSOPTION_PREFIX_CLASS if the IA_NA request received containsOPTION_USAGE_CLASS.OPTION_PREFIX_CLASS. o It MAY have a pre-configured mapping between theusageprefix class and the client DUID received in DHCPv6 message. o It MAY have a pre-configured mapping between theusageprefix 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.3.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""video"(1), "guest"(2), "voice"(3) etc), it can use these prefix(es) for assigning the longer IPv6 prefixes to requesting routers it serves through DHCPv6 IA_PD by assuming the role of delegating router, its behavior is explained in Section 2.2.2.2.3.4.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, it is specified in [I-D.korhonen-dmm-prefix-properties].2.3.5. Class based Information-Request A DHCP client MAY include OPTION_USAGE_CLASS in the Information request message to indicate that the requested configuration information (such as a list of available DNS servers) may be associated with a specific Usage Class.The server responds to the client with the requested Options whose values are determined based on the received OPTION_USAGE_CLASS. Even though the Information request message does not include the OPTION_USAGE_CLASS option, based on local policies, the DHCP server MAY select a default OPTION_USAGE_CLASS value for the client and then SHOULD include the OPTION_USAGE_CLASS option Information Response it sends to the client. 2.3.6.2.3.4. Class based prefix and applications Applications within a host can do source address selection based on the class of the prefix learnt inOPTION_USAGE_CLASSOPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS using rules defined in[RFC3484].[RFC6724]. 3. Example Application 3.1. Mobile gateway example 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: The example network consists of : 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. 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. Access Point (AP) A wireless access point, identified by a MAC address, providing service to the wired network for wireless nodes. 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. WLAN controller (WLC) The entity that provides the centralized forwarding, routing function for the user traffic.Example mobile network_----_ _----_ _----_ _( )_ _( )_ _( )_ (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) Figure1 3.1.1: Example mobile network 3.1.1. Class based prefix delegation The Access Aggregation Gateway requests for Prefix delegation from Mobile gateway and associates the prefix received withusageclass"global-anchor"(1)."global- anchor"(1). The Access Aggregation Gateway is preconfigured to provide prefixes from the following classes: "global-anchor" (1), "local-breakout"(2),"guest"(x)."guest"(3). It has a preconfigured policy to advertise prefixes to requesting routers and mobile nodes based on the service class supported by the service provider for the requesting device. In the example mobile network, the Access Router(AR) requests class based prefix allocation by sending a DHCPv6 SOLICIT message and includeOPTION_USAGE_CLASSOPTION_PREFIX_CLASS in the OPTION_ORO. The Access Router (AR) receives an advertise with following prefixes in the IA_PD option: 1. P1: IA_PD Prefix option with a prefix3001::1::/643001:1::/64 containingOPTION_USAGE_CLASSOPTION_PREFIX_CLASS set to "global-anchor"(1) 2. P2: IA_PD Prefix option with a prefix3001::2::/643001:2::/64 containingOPTION_USAGE_CLASSOPTION_PREFIX_CLASS set to "local-breakout"(2) 3. P3: IA_PD Prefix option with a prefix3001::3::/643001:3::/64 containingOPTION_USAGE_CLASSOPTION_PREFIX_CLASS set to"guest"(x)"guest"(3) It sends a REQUEST message with all of above prefixes and receives a REPLY message with prefixes allocated for each of the requested class.3.2.3.1.2. IPv6 address assignment from class based prefix 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 theusageprefix class "global-anchor"(1). For MN3 it advertises3001::1::13001:1::1 as the IPv6 address in OPTION_IAADDR in response to the IA_NA request. The Mobile Node(MN4) Figure 1 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"guest"(3) class. The IPv6 address in the OPTION_IAADDR is set to3001::3::1.3001:3::1. The "guest" class can also be distinguished based on a preconfigured interface or SSID advertised for MNs connecting to it. 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 theusageclass"local- breakout""local-breakout" (2) and "global-anchor"(1). For MN1 it advertises3001::2::13001:2::1 and3001::1::23001: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 orlocal- breakoutlocal-breakout property attached to the prefix based on source address selection policy. The prefixes that are globally anchored and hence have mobility can be advertised with OPTION_PREFIX_PROPERTY set to 0x0002 to convey that the prefix provides network based mobility as listed in Section 6.1. If the prefix also provides security guarantees OPTION_PREFIX_PROPERTY can be set to 0x0009 to indicated mobility and security guarantees by bitwise ORing of both the properties. 3.2. Homenet Example The following sub-section describes an example of class based prefix delegation in a home network environment. The network consists of the following elements: o Home Gateway (HGW) device: a routing device located in the customer's premises that provides connectivity between the customer and the service provider. In this example, the HGW is functioning as both a DHCP client towards the service provider's DHCP infrastructure and a DHCP server towards hosts located in the home network. o IPv6 Set Top Box (STB): A dedicated, IPv6 attached, video on demand device. o IPv6 PC: An IPv6 attached personal computer. o Delegating Router: The router in the ISPs network acting as a DHCP server for the IA_PD request. o Video On Demand (VOD) service: A server providing unicast based streaming video content to subscribers. _----+----_ _( ) ( Internet ) (_ _) '----+----' | _----+----_ +----------+ \ _( )_ | Video on | \ (Service Provider)--| Demand | \ (_ Network _) | Service | | ISP '----+----' +----------+ | Network | | +------+-----+ | | Delegating | | | Router | | +------+-----+ | | | | Customer | | Internet connection / | / | / +------+--------+ ^ \ | IPv6 | | DHCPv6 Client \ | Home gateway | \ | Device (CPE) | | DHCPv6 Server | +------+--------+ v | Home | | Network Home Network | | +-----+-------+ | | | | +----+-----+ +-----+----+ | |IPv6 Host | |IPv6 Host | | | (Set top | | (PC) | DHCPv6 Clients / | box) | | | / +----------+ +----------+ / Simple home network with Data and Video devices 3.2.1. Class based prefix delegation to the HGW In this example, two different services are being run on the same network. The service provider wishes that traffic is sourced from different prefixes by the home network clients [I-D.jiang-v6ops-semantic-prefix]. The HGW (requesting router) has been configured to request prefix delegation from the ISPs delegating router with the usage classes "video" (1) and "internet"(2) the meaning of these being of relevance to the ISP operating this and application that are configured out of band to utilize it. The delegating router is preconfigured to advertise prefixes with these service classes. The HGW sends two IA_PD options within the SOLICIT message, one with OPTION_PREFIX_CLASS "video" (1) and the second with "internet" (2). The HGW receives an advertise with the following prefixes in the IA_PD option: 1. P1: IA_PD Prefix option with a prefix 3001:5::/56 containing OPTION_PREFIX_CLASS set to "video" (1) 2. P2: IP_PD Prefix option with a prefix 3001:6::/56 containing OPTION_PREFIX_CLASS set to "internet" (2) It sends a REQUEST message with all of the above prefixes and receives a REPLY message with prefixes allocated for each of the requested classes. The HGW then configures a /64 prefix from each of the delegated prefixes on its LAN interface [RFC6204] and sends out router advertisements (RAs) with the "M" and "O" bits set. 3.2.2. IPv6 Assignment to Homenet hosts using stateful DHCPv6 STB sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS option set to "video" (1) within the IA_NA. The HGW checks the requested prefix class against the available prefixes it has been delegated and advertises 3001:5::1 to the STB. The STB then configures this address on its LAN interface and uses it for sourcing requests to the VOD service. The PC sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS option set to "internet" within the IA_NA or without OPTION_PREFIX_PROPERTY. The HGW checks the requested prefix class against the available prefixes it has been delegated and advertises 3001:6::1 to the PC or in absence of OPTION_PREFIX_CLASS in the solicit HGW is preconfigured to assign from the "internet"(2) class as the default. The PC then configures this address on its LAN interface and uses it for sourcing requests to the Internet. 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. Contributors Authors would like to thank contributions to use cases and text for various sections received from Ian Farrer and Sindhura Bandi. 6. IANA Considerations IANA is requested to assign an option code toOPTION_USAGE_CLASSOPTION_PREFIX_PROPERTY (TBD1) and OPTION_PREFIX_CLASS (TBD2) from the "DHCPv6 and DHCPv6 options" registry(http://www.iana.org/ assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 5.1. OPTION_USAGE_CLASS(http://www.iana.org/assignments/dhcpv6-parameters/ dhcpv6-parameters.xml). 6.1. OPTION_PREFIX_PROPERTY values IANA is requested to reserve and maintain registry ofOPTION_USAGE_CLASSOPTION_PREFIX_PROPERTY values and manage allocation of valuesin the following wayas per as per policy defined in[RFC5226]: 1. Values 1 to 8191 ( 0x0001 - 0x1FFF) -[RFC5226] with IETF assignedclass withvalues requiring IETF consensus, RFC Requiredpolicy 2. Values 8192 to 16368 (0x2000 - 0x3ff0) - Vendor defined class assigned on a First Come First Served allocation policy 3. Values 16369 to 16383 (0x3ff1 - 0x3fff) - Experimental usage reserved for Private Use Followingpolicy, any other valueswillother than the ones listed below are not valid. 1. 0x0001 The prefix cannot beallocated from this registry as explained in section Section 2.3.1: o global-anchor(1) - Prefix is globally anchored and hence would allow mobility. o local-breakout(2) - Prefixused to reach the Internet 2. 0x0002 The prefix provides network based mobility 3. 0x0004 The prefix requires authentication 4. 0x0008 The prefix ismanaged in a local-breakout domain and hence has limited mobility. o Vendor-specfied-class(3) - Prefix classassigned on an interface that provides security guarantees 5. 0x0010 Usage isvendor specified.charged 6. 0x0020 Unassigned 7. 0x0040 Unassigned 8. 0x0080 Unassigned 9. 0x0100 Unassigned 10. 0x0200 Unassigned 11. 0x0400 Unassigned 12. 0x0800 Unassigned 13. 0x1000 Unassigned 14. 0x2000 Unassigned 15. 0x4000 Unassigned 16. 0x8000 Unassigned 7. 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.8. Change History (to be removed prior to publication as an RFC) Changes from -00 to -01 a. Modified motivation section to focus on mobile networks b. Modified example with a mobile network and class based prefix delegation in it Changes from-00-01 to -02 a. Modified option format to be enumerated values b. Added IANA section to request managing of registry for the enumerated values c. Added initial values for the class d. Added section for applications to select address with a specific property8.Changes from -02 to -03 a. Added server behaviour for IA_NA and IA_PD allocation b. Added Class based Information-Request usage Changes from -03 to -04 a. Added homenet use case b. Split usage class into a fixed IANA maintained properties registry and a prefix class 9. References8.1.9.1. Normative References [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in progress), September 2012. [I-D.jiang-v6ops-semantic-prefix] Jiang, S., Sun, Q., and I. Farrer, "A Framework for Semantic IPv6 Prefix and Gap Analysis", draft-jiang-v6ops-semantic-prefix-02 (work in progress), January 2013. [I-D.korhonen-dmm-prefix-properties] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Mobility Management Properties",draft-korhonen-dmm-prefix-properties-02draft-korhonen-dmm-prefix-properties-03 (work in progress),JulyOctober 2012.[IANAEnterprise] IANA, "Private Enterprise Numbers, http://www.iana.org/assignments/enterprise-numbers".[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.[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.8.2.[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. 9.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. 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.comSindhura Bandi Cisco Systems Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Phone: +91 80 4426 2347 Email: sinb@cisco.comSri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Hui Deng China Mobile 53A, Xibianmennei Ave., Xuanwu District Beijing 100053 China Email: denghui02@gmail.com Laurent Thiebaut Alcatel-Lucent France Email: laurent.thiebaut@alcatel-lucent.com Jouni Korhonen Renesas Mobile Linnoitustie 6 FIN-02600 Espoo, Finland Phone: Email: jouni.nospam@gmail.com