idnits 2.17.00 (12 Aug 2021) /tmp/idnits17863/draft-bhandari-dhc-class-based-prefix-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 3595 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAEnterprise' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Bhandari 3 Internet-Draft G. Halwasia 4 Intended status: Standards Track S. Bandi 5 Expires: January 17, 2013 S. Gundavelli 6 Cisco Systems 7 H. Deng 8 China Mobile 9 L. Thiebaut 10 Alcatel-Lucent 11 July 16, 2012 13 DHCPv6 class based prefix 14 draft-bhandari-dhc-class-based-prefix-03 16 Abstract 18 DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 19 addresses. This document extends DHCPv6 prefix delegation with class 20 based prefix allocation. It defines a new usage class option to 21 classify a prefix. It defines the behavior of a DHCPv6 client 22 requesting a prefix to include the class of the prefix to be 23 allocated and the DHCPv6 server behavior to select and offer a prefix 24 from a given class. It discusses how IA_NA can be requested and 25 assigned from a specific usage class. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 17, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Usage Class Option . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Consideration for different DHCPv6 entities . . . . . . . 6 68 2.2.1. Requesting Router Behavior for IA_PD allocation . . . 6 69 2.2.2. Delegating Router Behavior for IA_PD allocation . . . 7 70 2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 7 71 2.2.4. DHCPv6 Server Behavior for IA_NA allocation . . . . . 8 72 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.3.1. OPTION_USAGE_CLASS Values . . . . . . . . . . . . . . 8 74 2.3.2. Class based prefix and IA_NA allocation . . . . . . . 9 75 2.3.3. Class based prefix and IA_PD allocation . . . . . . . 9 76 2.3.4. Class based prefix and SLAAC . . . . . . . . . . . . . 9 77 2.3.5. Class based Information-Request . . . . . . . . . . . 10 78 2.3.6. Class based prefix and applications . . . . . . . . . 10 79 3. Example Application . . . . . . . . . . . . . . . . . . . . . 10 80 3.1. Class based prefix delegation . . . . . . . . . . . . . . 12 81 3.2. IPv6 address assignment from class based prefix . . . . . 12 82 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 5.1. OPTION_USAGE_CLASS values . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. Change History (to be removed prior to publication as an 87 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 DHCPv6 based prefix delegation as defined in [RFC3633] is a mechanism 96 for the delegation of IPv6 prefixes using DHCPv6 options. Through 97 these options, a delegating router can delegate prefixes to 98 authorized requesting routers. If the requesting router has to 99 function as a DHCPv6 server there needs to be additional information 100 in the delegated prefix that helps the requesting router to select 101 the address allocation for the DHCPv6 client it serves, from one of 102 the available delegated prefixes. 104 One way to select an address or longer prefix (from a delegated 105 prefix) to be allocated by a requesting router playing the role of a 106 DHCPv6 server is by introducing additional options in IA_PD to be 107 matched with options for address selection in the DHCPv6 SOLICIT 108 message. [RFC3315] defines the OPTION_USER_CLASS option which is 109 used for selecting address for assignment. But the OPTION_USER_CLASS 110 option is only loosely defined and it can hardly be used in mobile 111 environment where a DHCPv6 client, the DHCPv6 server or requesting 112 router and the delegating Router may belong to different 113 organizations. 115 This document introduces OPTION_USAGE_CLASS option in IA_PD option 116 for the purpose of selecting a prefix for further delegation either 117 via IA_NA or IA_PD DHCPv6 request. It defines the behavior of the 118 DHCPv6 server, the DHCPv6 prefix requesting router and the DHCPv6 119 client to use this option. 121 In IPv6 a network interface can acquire multiple addresses from the 122 same scope. In this case application need to have additional 123 information about the prefix configured on the interface for source 124 address selection. Since the network address can be configured via 125 DHCPv6 as defined in [RFC3315] or via Stateless Address 126 Autoconfiguration (SLAAC) as defined in [RFC4862], additional 127 information of a prefix can be provided via DHCPv6 or via IPv6 Router 128 Advertisement (RA). 130 1.1. Motivation 132 In this section motivation for class based prefix delegation that 133 qualifies the delegated prefix with additional class information is 134 described in the context of mobile networks. The class information 135 attached to a delegated prefix helps to distinguish property of a 136 delegated IPv6 prefix and selection of the prefix by different 137 applications using it. 139 In the mobile network architecture, there is a mobile router which 140 functions as a IP network gateway and provides IP connectivity to 141 mobile nodes. Mobile router can be the requesting router requesting 142 delegated IPv6 prefix using DHCPv6. Mobile router can assume the 143 role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to 144 it. A mobile node in mobile network architecture can be associated 145 with multiple IPv6 prefixes belonging to different domains for e.g. 146 home address prefix, care of address prefix as specified in 147 [RFC3775]. 149 The delegated prefixes when seen from the mobile router perspective 150 appear to be like any other prefix, but each prefixes have different 151 properties referred to as "Prefix Color" in the mobile networks. 152 Some delegated prefixes may be topologically local and some may be 153 remote prefixes anchored on a global anchor, but available to the 154 local anchor by means of tunnel setup in the network between the 155 local and global anchor. Some may be local with low latency 156 characteristics suitable for voice call break-out, some may have 157 global mobility support. So, the prefixes have different properties 158 and it is required for the application using the prefix to learn 159 about this property in order to use it intelligently. There is 160 currently no semantics in DHCPv6 prefix delegation that can carry 161 this information to specify properties of a delegated prefix. In 162 this scenario, the mobile router is unable to further delegate a 163 longer prefix intelligently based on properties of the prefix learnt. 165 1.2. Terminology 167 This document uses the terminology defined in [RFC2460], [RFC3315] 168 and [RFC3633]. 170 1.3. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 2. Overview 178 This section defines usage class option in IA_PD and IA_NA to aid 179 class based prefix delegation and address assignment. This section 180 defines the behavior of the delegating router, the requesting router 181 and the DHCPv6 client. It defines also usage class option in the 182 context of a DHCP information request from a DHCP client to a DHCP 183 server. 185 2.1. Usage Class Option 187 The format of the DHCPv6 usage class option is shown below. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | OPTION_USAGE_CLASS | option-length(2) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Class | ~ 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ 195 ~ Vendor Class Data (Optional,variable length) ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 option-code: OPTION_USAGE_CLASS (TBD) 199 option-length: 2 + Length of Vendor class information 200 if present 201 Class: 16 bit numeric value maintained as 202 OPTION_USAGE_CLASS enumeration in 203 IANA registered namespace 204 Vendor Class Data: If the value of Class (3) indicates it is 205 vendor specified additional vendor 206 specified data of variable length will be 207 attached in the form specified below: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | OPTION_USAGE_CLASS | option-length(2) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Class | Enterprise ID | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Enterprise ID(4) | Vendor Class length(2) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 ~ Vendor Class Data (Variable length) ~ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Enterprise ID: The vendor's 32-bit Enterprise Number as 221 registered with IANA [IANAEnterprise] 222 Vendor Class Length: 2, length of vendor class data that follows 223 Vendor Class Data: Binary data as defined by the vendor. 224 For e.g. 3gpp can specify this data to be 225 Application providers network domain string 227 The class values are maintained in OPTION_USAGE_CLASS values 228 enumeration explained in Section Section 2.3.1. 230 2.2. Consideration for different DHCPv6 entities 232 The model of operation of communicating prefixes to be used by a 233 DHCPv6 server is as follows. A requesting router requests prefix(es) 234 from the delegating router, as described in Section 2.2.1. A 235 delegating router is provided IPv6 prefixes to be delegated to the 236 requesting router. Examples of ways in which the delegating router 237 is provided these prefixes are: 239 o Configuration 241 o Prefix delegated via a DHCPv6 request to another DHCPv6 server 243 o Using a Authentication Authorization Accounting (AAA) protocol 244 like RADIUS [RFC2865] 246 The delegating router chooses prefix(es) for delegation, and responds 247 with prefix(es) to the requesting router along with additional 248 options in the allocated prefix as described in Section 2.2.2. The 249 requesting router is then responsible for the delegated prefix(es) 250 after the DHCPv6 REQUEST message exchange. For example, the 251 requesting router may create DHCPv6 server configuration pools from 252 the delegated prefix, and function as a DHCPv6 Server. When the 253 requesting router then receives a DHCPv6 IA_NA requests it can select 254 the address to be allocated based on the OPTION_USER_CLASS or 255 OPTION_USAGE_CLASS options received in IA_NA request or any of the 256 other methods as described in Section 2.3.1. 258 2.2.1. Requesting Router Behavior for IA_PD allocation 260 DHCPv6 requesting router can request for prefixes in the following 261 ways: 263 o In the SOLICIT message within the IA_PD Prefix option, it MAY 264 include OPTION_USAGE_CLASS requesting prefix delegation for the 265 specific class indicated in the OPTION_USAGE_CLASS option. It can 266 include multiple IA_PD Prefix options to indicate it's preference 267 for more than one usage class. 269 o In the SOLICIT message include an OPTION_ORO option with the 270 OPTION_USAGE_CLASS option code to request prefixes from all the 271 classes that the DHCPv6 server can provide to this requesting 272 Router. 274 The requesting router parses the OPTION_USAGE_CLASS option in 275 theOPTION_IAPREFIX option area of the corresponding IA_PD Prefix 276 option in the ADVERTISE message. The Requesting router MUST then 277 include all or subset of the received class based prefix(es) in the 278 REQUEST message so that it will be responsible for the prefixes 279 selected. 281 2.2.2. Delegating Router Behavior for IA_PD allocation 283 If the Delegating router supports class based prefix allocation by 284 supporting the OPTION_USAGE_CLASS option and it is configured to 285 assign prefixes from different classes, it selects prefixes for class 286 based prefix allocation in the following way: 288 o If requesting router includes OPTION_USAGE_CLASS within the IA_PD 289 Prefix option, it selects prefixes to be offered from that 290 specific class. 292 o If requesting router includes OPTION_USAGE_CLASS within 293 OPTION_ORO, then based on its configuration and policy it MAY 294 offer prefixes from multiple classes available. 296 The delegating router responds with an ADVERTISE message after 297 populating the IP_PD option with prefixes from different usage 298 classes. Along with including the IA_PD prefix options in the IA_PD 299 option, it also includes the OPTION_USAGE_CLASS option in the 300 OPTION_IAPREFIX option area of the corresponding IA_PD prefix option. 302 If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message 303 include the OPTION_USAGE_CLASS option, then the delegating router MAY 304 allocate the prefix as specified in [RFC3633] without including the 305 class option in the IA_PD prefix option in the response. 307 If OPTION_ORO option in the Solicit message includes the 308 OPTION_USAGE_CLASS option code but the delegating router does not 309 support the solution described in this specification, then the 310 delegating router acts as specified in [RFC3633]. The requesting 311 router MUST in this case also fall back to the behavior specified in 312 [RFC3633]. 314 If both delegating and requesting routers support class-based prefix 315 allocation, but the delegating router cannot offer prefixes for any 316 other reason, it MUST respond to requesting router with appropriate 317 status code as specified in [RFC3633]. For e.g., if no prefixes are 318 available in the specified class then the delegating router MUST 319 include the status code NoPrefixAvail in the response message. 321 2.2.3. DHCPv6 Client Behavior for IA_NA allocation 323 DHCPv6 client MAY request for an IA_NA address allocation from a 324 specific usage class in the following way: 326 o In the SOLICIT message within the IA_NA option, it MAY include the 327 OPTION_USAGE_CLASS requesting address to be allocated from a 328 specific usage class indicated in that option. 330 If DHCPv6 client receives OPTION_USAGE_CLASS option in the IAaddr- 331 options area of the corresponding IA_NA but does not support this 332 option, it SHOULD ignore the received option. 334 2.2.4. DHCPv6 Server Behavior for IA_NA allocation 336 The DHCPv6 server parses OPTION_USAGE_CLASS option received and when 337 it supports allocation within the requested OPTION_USAGE_CLASS 338 responds with an ADVERTISE message after populating the IA_NA option 339 with address information from the requested Usage class. Along with 340 including the IA Address options in the IA_NA option, it also 341 includes the OPTION_USAGE_CLASS option in the corresponding IAaddr- 342 options area. 344 Even though the IA_NA option in the SOLICIT message does not include 345 the OPTION_USAGE_CLASS option, based on local policies, the DHCP 346 server MAY select a default OPTION_USAGE_CLASS value for the client 347 and then SHOULD include the OPTION_USAGE_CLASS option in the IAaddr- 348 options area of the corresponding IA_NA it sends to the client. If 349 both DHCP client and server support Usage-class-based address 350 allocation, but the DHCP server cannot offer addresses in the 351 specified Usage class then the DHCP server MUST include the status 352 code NoAddrsAvail (as defined in [RFC3315]) in the response message. 353 If the DHCP server cannot offer addresses for any other reason, it 354 MUST respond to requesting router with appropriate status code as 355 specified in [RFC3315]. 357 2.3. Usage 359 Class based prefix delegation can be used by the requesting router to 360 configure itself as a DHCPv6 server to serve its DHCPv6 clients. It 361 can allocate longer prefixes from a delegated shorter prefix it 362 received, for serving IA_NA and IA_PD requests. 364 2.3.1. OPTION_USAGE_CLASS Values 366 Following values will be allocated from the IANA maintained 367 OPTION_USAGE_CLASS registry: 369 o global-anchor(1) - Prefix is globally anchored and hence would 370 allow mobility. 372 o local-breakout(2) - Prefix is managed in a local-breakout domain 373 and hence has limited mobility. 375 o Vendor-specfied-class(3) - Prefix class is specified by the 376 vendor, Vendor class data in the option that follows will provide 377 more information. 379 New values of OPTION_USAGE_CLASS can be assigned and registered with 380 IANA as per policy detailed in section Section 5.1. 382 2.3.2. Class based prefix and IA_NA allocation 384 The requesting router can use the delegated prefix(es) from different 385 classes (for example "video", "guest", "voice" etc), for assigning 386 the IPv6 addresses to the end hosts through DHCPv6 IA_NA based on a 387 preconfigured mapping with OPTION_USAGE_CLASS option, the following 388 conditions MAY be observed: 390 o It MAY have a pre-configured mapping between the usage class and 391 OPTION_USER_CLASS option received in IA_NA. 393 o It MAY match the OPTION_USAGE_CLASS if the IA_NA request received 394 contains OPTION_USAGE_CLASS. 396 o It MAY have a pre-configured mapping between the usage class and 397 the client DUID received in DHCPv6 message. 399 o It MAY have a pre-configured mapping between the usage class and 400 its network interface on which the IA_NA request was received. 402 The requesting router playing the role of a DHCPv6 server can 403 ADVERTISE IA_NA from a class of prefix(es) thus selected. 405 2.3.3. Class based prefix and IA_PD allocation 407 If the requesting router, receives prefix(es) for different classes 408 (for example "video", "guest", "voice" etc), it can use these 409 prefix(es) for assigning the longer IPv6 prefixes to requesting 410 routers it serves through DHCPv6 IA_PD by assuming the role of 411 delegating router, its behavior is explained in Section 2.2.2. 413 2.3.4. Class based prefix and SLAAC 415 DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as 416 defined in [RFC4862]) are two ways by IPv6 addresses can be 417 dynamically assigned to end hosts. Making SLAAC class aware is 418 outside the scope of this document, it is specified in 419 [I-D.korhonen-dmm-prefix-properties]. 421 2.3.5. Class based Information-Request 423 A DHCP client MAY include OPTION_USAGE_CLASS in the Information 424 request message to indicate that the requested configuration 425 information (such as a list of available DNS servers) may be 426 associated with a specific Usage Class.The server responds to the 427 client with the requested Options whose values are determined based 428 on the received OPTION_USAGE_CLASS. Even though the Information 429 request message does not include the OPTION_USAGE_CLASS option, based 430 on local policies, the DHCP server MAY select a default 431 OPTION_USAGE_CLASS value for the client and then SHOULD include the 432 OPTION_USAGE_CLASS option Information Response it sends to the 433 client. 435 2.3.6. Class based prefix and applications 437 Applications within a host can do source address selection based on 438 the class of the prefix learnt in OPTION_USAGE_CLASS using rules 439 defined in [RFC3484]. 441 3. Example Application 443 The following sub-sections provide examples of class based prefix 444 delegation and how it is used in a mobile network. Each of the 445 examples will refer to the below network: 447 The example network consists of : 449 Mobile Gateway It is network entity anchoring IP traffic in the 450 mobile core network. This entity allocates an IP address which is 451 topologically valid in the mobile network and may act as a mobility 452 anchor if handover between mobile and Wi-Fi is supported. 454 Mobile Nodes (MN) A host or router that changes its point of 455 attachment from one network or subnetwork to another. A mobile node 456 may change its location without changing its IP address; it may 457 continue to communicate with other Internet nodes at any location 458 using its (constant) IP address, assuming link-layer connectivity to 459 a point of attachment is available. 461 Access Point (AP) A wireless access point, identified by a MAC 462 address, providing service to the wired network for wireless nodes. 464 Access Router (AR) An IP router residing in an access network and 465 connected to one or more Acess Point(AP)s. An AR offers IP 466 connectivity to MNs. 468 WLAN controller (WLC) The entity that provides the centralized 469 forwarding, routing function for the user traffic. 471 Example mobile network 472 _----_ _----_ _----_ 473 _( )_ _( )_ _( )_ 474 (Operator-1) (Operator-2) (Operator-3) 475 (_ _) (_ _) (_ _) 476 -+-- -+-- '-+--' 477 +--------+ +--------+ +--------+ 478 | Mobile | | Mobile | | Mobile | 479 |gateway | |gateway | |gateway | 480 +--------+ +--------+ +--------+ 481 | | | 482 +-------------. | .-------------+ 483 | | | 484 | | | 485 | | |P1:"global-anchor"(1) 486 | | | 487 +--------+ _----_ 488 +---+ | |P2:"local-breakout"(2)_( )_ 489 |AAA|. . . . . . . | Access |---------------------( Internet ) 490 +---+ | Aggreg |-----------+ (_ _) 491 | Gateway| P3:"guest"| '----' 492 +--------+ | 493 | | +----- Guest Access 494 | | Network 495 | +-------------+ 496 | | 497 | +-----+ 498 | | AR | 499 +-----+ +-----+ 500 | WLC | * ---------* 501 | | ( LAN ) 502 +-----+ * ---------* 503 / \ / \ 504 +----+ +----+ +----+ +----+ 505 |WiFi| |WiFi| |WiFi| |WiFi| 506 | AP | | AP | | AP | | AP | 507 +----+ +----+ +----+ +----+ 508 . . 509 / \ / \ 510 MN1 MN2 MN3 MN4(guest) 512 Figure 1 514 3.1. Class based prefix delegation 516 The Access Aggregation Gateway requests for Prefix delegation from 517 Mobile gateway and associates the prefix received with usage class 518 "global-anchor"(1). The Access Aggregation Gateway is preconfigured 519 to provide prefixes from the following classes: "global-anchor" (1), 520 "local-breakout"(2), "guest"(x). It has a preconfigured policy to 521 advertise prefixes to requesting routers and mobile nodes based on 522 the service class supported by the service provider for the 523 requesting device. In the example mobile network, the Access 524 Router(AR) requests class based prefix allocation by sending a DHCPv6 525 SOLICIT message and include OPTION_USAGE_CLASS in the OPTION_ORO. 527 The Access Router (AR) receives an advertise with following prefixes 528 in the IA_PD option: 530 1. P1: IA_PD Prefix option with a prefix 3001::1::/64 containing 531 OPTION_USAGE_CLASS set to "global-anchor"(1) 533 2. P2: IA_PD Prefix option with a prefix 3001::2::/64 containing 534 OPTION_USAGE_CLASS set to "local-breakout"(2) 536 3. P3: IA_PD Prefix option with a prefix 3001::3::/64 containing 537 OPTION_USAGE_CLASS set to "guest"(x) 539 It sends a REQUEST message with all of above prefixes and receives a 540 REPLY message with prefixes allocated for each of the requested 541 class. 543 3.2. IPv6 address assignment from class based prefix 545 When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA 546 from the mobile node that has mobility service enabled, it offers an 547 IPv6 address from the usage class "global-anchor"(1). For MN3 it 548 advertises 3001::1::1 as the IPv6 address in OPTION_IAADDR in 549 response to the IA_NA request. 551 The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message 552 requesting IA_NA address assignment with OPTION_USER_CLASS option 553 containing the value "guest" towards the CPE. The Access Router(AR) 554 assumes the role of the DHCPv6 server and sends an ADVERTISE to the 555 MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from 556 the "guest" usage class. The IPv6 address in the OPTION_IAADDR is 557 set to 3001::3::1. The "guest" class can also be distinguished based 558 on a preconfigured interface or SSID advertised for MNs connecting to 559 it. 561 When the Access Aggregation Gateway receives a DHCPv6 SOLICIT 562 requesting IA_NA from MNs through WLC and it has a preconfigured 563 profile to provide both local-breakout internet access and global- 564 anchor, it offers an IPv6 address from the usage class "local- 565 breakout" (2) and "global-anchor"(1). For MN1 it advertises 566 3001::2::1 and 3001::1::2 as the IPv6 address in OPTION_IAADDR in 567 response to the IA_NA request. Applications within MN1 can choose to 568 use the appropriate prefix based on the mobility enabled or local- 569 breakout property attached to the prefix based on source address 570 selection policy. 572 4. Acknowledgements 574 The authors would like to acknowledge review and guidance received 575 from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark, 576 Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz 578 5. IANA Considerations 580 IANA is requested to assign an option code to OPTION_USAGE_CLASS from 581 the "DHCPv6 and DHCPv6 options" registry (http://www.iana.org/ 582 assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 584 5.1. OPTION_USAGE_CLASS values 586 IANA is requested to reserve and maintain registry of 587 OPTION_USAGE_CLASS values and manage allocation of values in the 588 following way as per as per policy defined in [RFC5226]: 590 1. Values 1 to 8191 ( 0x0001 - 0x1FFF) - IETF assigned class with 591 IETF consensus, RFC Required policy 593 2. Values 8192 to 16368 (0x2000 - 0x3ff0) - Vendor defined class 594 assigned on a First Come First Served allocation policy 596 3. Values 16369 to 16383 (0x3ff1 - 0x3fff) - Experimental usage 597 reserved for Private Use 599 Following values will be allocated from this registry as explained in 600 section Section 2.3.1: 602 o global-anchor(1) - Prefix is globally anchored and hence would 603 allow mobility. 605 o local-breakout(2) - Prefix is managed in a local-breakout domain 606 and hence has limited mobility. 608 o Vendor-specfied-class(3) - Prefix class is vendor specified. 610 6. Security Considerations 612 Security issues related to DHCPv6 which are described in section 23 613 of [RFC3315] and [RFC3633] apply for scenarios mentioned in this 614 draft as well. 616 7. Change History (to be removed prior to publication as an RFC) 618 Changes from -00 to -01 620 a. Modified motivation section to focus on mobile networks 622 b. Modified example with a mobile network and class based prefix 623 delegation in it 625 Changes from -00 to -02 627 a. Modified option format to be enumerated values 629 b. Added IANA section to request managing of registry for the 630 enumerated values 632 c. Added initial values for the class 634 d. Added section for applications to select address with a specific 635 property 637 8. References 639 8.1. Normative References 641 [I-D.korhonen-dmm-prefix-properties] 642 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 643 Liu, "IPv6 Prefix Mobility Management Properties", 644 draft-korhonen-dmm-prefix-properties-02 (work in 645 progress), July 2012. 647 [IANAEnterprise] 648 IANA, "Private Enterprise Numbers, 649 http://www.iana.org/assignments/enterprise-numbers". 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 655 (IPv6) Specification", RFC 2460, December 1998. 657 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 658 "Remote Authentication Dial In User Service (RADIUS)", 659 RFC 2865, June 2000. 661 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 662 and M. Carney, "Dynamic Host Configuration Protocol for 663 IPv6 (DHCPv6)", RFC 3315, July 2003. 665 [RFC3484] Draves, R., "Default Address Selection for Internet 666 Protocol version 6 (IPv6)", RFC 3484, February 2003. 668 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 669 Host Configuration Protocol (DHCP) version 6", RFC 3633, 670 December 2003. 672 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 673 in IPv6", RFC 3775, June 2004. 675 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 676 Address Autoconfiguration", RFC 4862, September 2007. 678 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 679 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 680 May 2008. 682 8.2. Informative References 684 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 685 June 1999. 687 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 688 Text on Security Considerations", BCP 72, RFC 3552, 689 July 2003. 691 Authors' Addresses 693 Shwetha Bhandari 694 Cisco Systems 695 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 696 Bangalore, KARNATAKA 560 087 697 India 699 Phone: 700 Email: shwethab@cisco.com 702 Gaurav Halwasia 703 Cisco Systems 704 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 705 Bangalore, KARNATAKA 560 087 706 India 708 Phone: +91 80 4426 1321 709 Email: ghalwasi@cisco.com 711 Sindhura Bandi 712 Cisco Systems 713 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 714 Bangalore, KARNATAKA 560 087 715 India 717 Phone: +91 80 4426 2347 718 Email: sinb@cisco.com 720 Sri Gundavelli 721 Cisco Systems 722 170 West Tasman Drive 723 San Jose, CA 95134 724 USA 726 Email: sgundave@cisco.com 727 Hui Deng 728 China Mobile 729 53A, Xibianmennei Ave., Xuanwu District 730 Beijing 100053 731 China 733 Email: denghui02@gmail.com 735 Laurent Thiebaut 736 Alcatel-Lucent 737 France 739 Email: laurent.thiebaut@alcatel-lucent.com