idnits 2.17.1 draft-bhandari-dhc-class-based-prefix-04.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 : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 235 has weird spacing: '...16 bits maint...' -- The document date (February 18, 2013) is 4078 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 867, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 870, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-05 ** Downref: Normative reference to an Informational draft: draft-ietf-dhc-dhcpv4-over-ipv6 (ref. 'I-D.ietf-dhc-dhcpv4-over-ipv6') == Outdated reference: A later version (-04) exists of draft-jiang-v6ops-semantic-prefix-02 ** Downref: Normative reference to an Informational draft: draft-jiang-v6ops-semantic-prefix (ref. 'I-D.jiang-v6ops-semantic-prefix') == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-03 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** 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 normative reference: RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 2 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. Gundavelli 5 Expires: August 22, 2013 Cisco Systems 6 H. Deng 7 China Mobile 8 L. Thiebaut 9 Alcatel-Lucent 10 J. Korhonen 11 Renesas Mobile 12 February 18, 2013 14 DHCPv6 class based prefix 15 draft-bhandari-dhc-class-based-prefix-04 17 Abstract 19 This document introduces options to communicate property and 20 associate metadata with prefixes. It extends DHCPv6 prefix 21 delegation and address allocation using the metadata for selection of 22 prefixes and addresses. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 22, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1.1. Mobile networks . . . . . . . . . . . . . . . . . . . 4 61 1.1.2. Home networks . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Prefix Property and Class Options . . . . . . . . . . . . 5 66 2.2. Consideration for different DHCPv6 entities . . . . . . . 7 67 2.2.1. Requesting Router Behavior for IA_PD allocation . . . 7 68 2.2.2. Delegating Router Behavior for IA_PD allocation . . . 8 69 2.2.3. DHCPv6 Client Behavior for IA_NA allocation . . . . . 9 70 2.2.4. DHCPv6 Server Behavior for IA_NA allocation . . . . . 9 71 2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.3.1. Class based prefix and IA_NA allocation . . . . . . . 10 73 2.3.2. Class based prefix and IA_PD allocation . . . . . . . 10 74 2.3.3. Class based prefix and SLAAC . . . . . . . . . . . . . 10 75 2.3.4. Class based prefix and applications . . . . . . . . . 11 76 3. Example Application . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. Mobile gateway example . . . . . . . . . . . . . . . . . . 11 78 3.1.1. Class based prefix delegation . . . . . . . . . . . . 12 79 3.1.2. IPv6 address assignment from class based prefix . . . 13 80 3.2. Homenet Example . . . . . . . . . . . . . . . . . . . . . 14 81 3.2.1. Class based prefix delegation to the HGW . . . . . . . 15 82 3.2.2. IPv6 Assignment to Homenet hosts using stateful 83 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 85 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. OPTION_PREFIX_PROPERTY values . . . . . . . . . . . . . . 17 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8. Change History (to be removed prior to publication as an 90 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 In IPv6 a network interface can acquire multiple addresses from the 99 same scope. In such a multi-prefix network each of the multiple 100 prefixes can have a specific property and purpose associated with it. 101 Example: In a mobile network a mobile device can be assigned a prefix 102 from its home network and another from the visiting network that it 103 is attached to. Another example is a prefix may provide free 104 internet access without offering any quality of service guarantees 105 while another prefix may be charged along with providing quality of 106 service guarantees for network service access. A prefix can have 107 well defined properties that is universal and have a metadata 108 associated with it that communicates its local significance. The 109 properties and metadata of prefix will be relevant for prefix 110 delegation, source address selection as elaborated in the subsequent 111 sections. 113 This document defines OPTION_PREFIX_PROPERTY option that communicates 114 property of the prefix that is universally understood.This document 115 defines OPTION_PREFIX_CLASS option to communicate metadata of the 116 prefix that communicates the prefix's local significance. 118 This document discusses usage of OPTION_PREFIX_CLASS to request and 119 select prefixes with specific metadata via IA_PD and IA_NA as defined 120 in [RFC3633] and[RFC3315] respectively.This document defines the 121 behavior of the DHCPv6 server, the DHCPv6 prefix requesting router 122 and the DHCPv6 client to use OPTION_PREFIX_CLASS option for 123 requesting and selecting prefixes and addresses. 125 The network address can be configured via DHCPv6 as defined in 126 [RFC3315] or via Stateless Address Autoconfiguration (SLAAC) as 127 defined in [RFC4862], additional information of a prefix can be 128 provided via DHCPv6 or via IPv6 Router Advertisement (RA). The 129 information provided in the options defined in this document 130 OPTION_PREFIX_PROPERTY and OPTION_PREFIX_CLASS can be used for source 131 address selection. Communicated property and metadata information 132 about the prefix via IPv6 Router Advertisement (RA) will be dealt 133 with in separate document [I-D.korhonen-dmm-prefix-properties]. 135 1.1. Motivation 137 In this section motivation for class based prefix delegation that 138 qualifies the delegated prefix with additional class information is 139 described in the context of mobile networks and home networks. The 140 property information attached to a delegated prefix helps to 141 distinguish a delegated IPv6 prefix and selection of the prefix by 142 different applications using it. 144 1.1.1. Mobile networks 146 In the mobile network architecture, there is a mobile router which 147 functions as a IP network gateway and provides IP connectivity to 148 mobile nodes. Mobile router can be the requesting router requesting 149 delegated IPv6 prefix using DHCPv6. Mobile router can assume the 150 role of DHCPv6 server for mobile nodes(DHCPv6 clients) attached to 151 it. A mobile node in mobile network architecture can be associated 152 with multiple IPv6 prefixes belonging to different domains for e.g. 153 home address prefix, care of address prefix as specified in 154 [RFC3775]. 156 The delegated prefixes when seen from the mobile router perspective 157 appear to be like any other prefix, but each prefixes have different 158 metadata referred to as "Prefix Color" in the mobile networks. Some 159 delegated prefixes may be topologically local and some may be remote 160 prefixes anchored on a global anchor, but available to the local 161 anchor by means of tunnel setup in the network between the local and 162 global anchor. Some may be local with low latency characteristics 163 suitable for voice call break-out, some may have global mobility 164 support. So, the prefixes have different properties and it is 165 required for the application using the prefix to learn about this 166 property in order to use it intelligently. There is currently no 167 semantics in DHCPv6 prefix delegation that can carry this information 168 to specify properties of a delegated prefix. In this scenario, the 169 mobile router is unable to further delegate a longer prefix 170 intelligently based on properties of the prefix learnt. Neither is a 171 mobile device able to learn about the property of the prefix assigned 172 to influence source address selection. Example to determine if the 173 prefix is a home address or care of address. 175 1.1.2. Home networks 177 In a fixed network environment, the homenet CPE may also function as 178 both a DHCPv6 client (requesting the IA_PD(s)) and a DHCPv6 server 179 allocating prefixes from delegated prefix(es) to downstream home 180 network hosts. Some service providers may wish to delegate multiple 181 prefixes to the CPE for use by different services classes and traffic 182 types. 184 Motivations for this include: 186 o Using source prefix to identify the service class / traffic type 187 that is being transported. The source prefix may then reliably be 188 used as a parameter for differentiated services or other purposes. 189 E.g. [I-D.jiang-v6ops-semantic-prefix] 191 o Using the specific source prefix as a host identifier for other 192 services. E.g. as an input parameter to a DHCPv4 over IPv6 server 193 [I-D.ietf-dhc-dhcpv4-over-ipv6] 195 To meet these requirements, when the CPE (functioning as a DHCPv6 196 server) receives an IA_NA or IA_TA request from a homenet host, a 197 mechanism is required so that the correct prefix for requested 198 service class can be selected for allocation. Likewise for DHCPv6 199 clients located in the homenet, a mechanism is necessary so that the 200 intended service class for a requested prefix can be signalled to the 201 DHCPv6 server. 203 1.2. Terminology 205 This document uses the terminology defined in [RFC2460], [RFC3315] 206 and [RFC3633]. 208 1.3. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 2. Overview 216 This section defines prefix property and prefix class options in 217 IA_PD and IA_NA. This section defines the behavior of the delegating 218 router, the requesting router and the DHCPv6 client. It discusses 219 these options in the context of a DHCPv6 information request from a 220 DHCPv6 client to a DHCPv6 server. 222 2.1. Prefix Property and Class Options 223 The format of the DHCPv6 prefix property and prefix class options are 224 shown below. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | OPTION_PREFIX_PROPERTY | option-length(2) | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Properties | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 option-code: OPTION_PREFIX_PROPERTY (TBD1) 234 option-length: 2 235 Properties: 16 bits maintained as 236 OPTION_PREFIX_PROPERTY in 237 IANA registered namespace. 238 Each value in the registry represents a property. 239 Multiple properties can be represented by bitwise 240 ORing of the individual property values in this 241 field. 243 Prefix Property Option 245 The individual property are maintained in OPTION_PREFIX_PROPERTY 246 values enumeration explained in Section Section 6.1. 248 Along with the OPTION_PREFIX_PROPERTY a metadata associated with the 249 prefix that is of local relevance is communicated using 250 OPTION_PREFIX_CLASS defined below: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | OPTION_PREFIX_CLASS | option-length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Prefix Class | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 option-code: OPTION_PREFIX_CLASS (TBD2) 261 option-length: 2 262 Prefix Class: 16 bit integer with the integer value 263 of local significance. 265 Prefix Class Option 267 2.2. Consideration for different DHCPv6 entities 269 The model of operation of communicating prefixes to be used by a 270 DHCPv6 server is as follows. A requesting router requests prefix(es) 271 from the delegating router, as described in Section 2.2.1. A 272 delegating router is provided IPv6 prefixes to be delegated to the 273 requesting router. Examples of ways in which the delegating router 274 is provided these prefixes are: 276 o Configuration 278 o Prefix delegated via a DHCPv6 request to another DHCPv6 server 280 o Using a Authentication Authorization Accounting (AAA) protocol 281 like RADIUS [RFC2865] 283 The delegating router chooses prefix(es) for delegation, and responds 284 with prefix(es) to the requesting router along with additional 285 options in the allocated prefix as described in Section 2.2.2. The 286 requesting router is then responsible for the delegated prefix(es) 287 after the DHCPv6 REQUEST message exchange. For example, the 288 requesting router may create DHCPv6 server configuration pools from 289 the delegated prefix, and function as a DHCPv6 Server. When the 290 requesting router then receives a DHCPv6 IA_NA requests it can select 291 the address to be allocated based on the OPTION_PREFIX_CLASS option 292 received in IA_NA request or any of the other method as described in 293 Section 2.3.1. 295 2.2.1. Requesting Router Behavior for IA_PD allocation 297 DHCPv6 requesting router can request for prefixes in the following 298 ways: 300 o In the SOLICIT message within the IA_PD Prefix option, it MAY 301 include OPTION_PREFIX_CLASS requesting prefix delegation for the 302 specific class indicated in the OPTION_PREFIX_CLASS option. It 303 can include multiple IA_PD Prefix options to indicate it's 304 preference for more than one prefix class. The class of prefix it 305 requests is learnt via configuration or any other out of band 306 mechanism not defined in this document. 308 o In the SOLICIT message include an OPTION_ORO option with the 309 OPTION_PREFIX_CLASS option code to request prefixes from all the 310 classes that the DHCPv6 server can provide to this requesting 311 Router. 313 The requesting router parses the OPTION_PREFIX_CLASS option in the 314 OPTION_IAPREFIX option area of the corresponding IA_PD Prefix option 315 in the ADVERTISE message. The Requesting router MUST then include 316 all or subset of the received class based prefix(es) in the REQUEST 317 message so that it will be responsible for the prefixes selected. 319 The requesting router parses and stores OPTION_PREFIX_PROPERTY if 320 received with the prefix. 322 2.2.2. Delegating Router Behavior for IA_PD allocation 324 If the Delegating router supports class based prefix allocation by 325 supporting the OPTION_PREFIX_CLASS option and it is configured to 326 assign prefixes from different classes, it selects prefixes for class 327 based prefix allocation in the following way: 329 o If requesting router includes OPTION_PREFIX_CLASS within the IA_PD 330 Prefix option, it selects prefixes to be offered from that 331 specific class. 333 o If requesting router includes OPTION_PREFIX_CLASS within 334 OPTION_ORO, then based on its configuration and policy it MAY 335 offer prefixes from multiple classes available. 337 The delegating router responds with an ADVERTISE message after 338 populating the IP_PD option with prefixes from different classes. 339 Along with including the IA_PD prefix options in the IA_PD option, it 340 MAY include the OPTION_PREFIX_CLASS option in the OPTION_IAPREFIX 341 option area of the corresponding IA_PD prefix option with the class 342 information of the prefix. 344 If neither the OPTION_ORO nor the IA_PD option in the SOLICIT message 345 include the OPTION_PREFIX_CLASS option, then the delegating router 346 MAY allocate the prefix as specified in [RFC3633] without including 347 the class option in the IA_PD prefix option in the response. 349 If OPTION_ORO option in the Solicit message includes the 350 OPTION_PREFIX_CLASS option code but the delegating router does not 351 support the solution described in this specification, then the 352 delegating router acts as specified in [RFC3633]. The requesting 353 router MUST in this case also fall back to the behavior specified in 354 [RFC3633]. 356 If both delegating and requesting routers support class-based prefix 357 allocation, but the delegating router cannot offer prefixes for any 358 other reason, it MUST respond to requesting router with appropriate 359 status code as specified in [RFC3633]. For e.g., if no prefixes are 360 available in the specified class then the delegating router MUST 361 include the status code NoPrefixAvail in the response message. 363 In addition if the delegating router has additional property 364 associated with the prefix it will be provided in 365 OPTION_PREFIX_PROPERTY option. 367 2.2.3. DHCPv6 Client Behavior for IA_NA allocation 369 DHCPv6 client MAY request for an IA_NA address allocation from a 370 specific prefix class in the following way: 372 o In the SOLICIT message within the IA_NA option, it MAY include the 373 OPTION_PREFIX_CLASS requesting address to be allocated from a 374 specific class indicated in that option. The class information to 375 be requested can be learnt via configuration or any other out of 376 band mechanism not described in this document. 378 If DHCPv6 client receives OPTION_PREFIX_CLASS, OPTION_PREFIX_PROPERTY 379 options in the IAaddr-options area of the corresponding IA_NA but 380 does not support one or both of these options, it SHOULD ignore the 381 received option(s). 383 2.2.4. DHCPv6 Server Behavior for IA_NA allocation 385 The DHCPv6 server parses OPTION_PREFIX_CLASS option received and when 386 it supports allocation within the requested OPTION_PREFIX_CLASS 387 responds with an ADVERTISE message after populating the IA_NA option 388 with address information from the requested prefix class. Along with 389 including the IA Address options in the IA_NA option, it also 390 includes the OPTION_PREFIX_CLASS option in the corresponding IAaddr- 391 options area. 393 Even though the IA_NA option in the SOLICIT message does not include 394 the OPTION_PREFIX_CLASS option, based on local policies, the DHCP 395 server MAY select a default OPTION_PREFIX_CLASS value for the client 396 and then SHOULD include the OPTION_PREFIX_CLASS option in the IAaddr- 397 options area of the corresponding IA_NA it sends to the client. If 398 both DHCP client and server support class based address allocation, 399 but the DHCP server cannot offer addresses in the specified Usage 400 class then the DHCP server MUST include the status code NoAddrsAvail 401 (as defined in [RFC3315]) in the response message. If the DHCP 402 server cannot offer addresses for any other reason, it MUST respond 403 to client with appropriate status code as specified in [RFC3315]. In 404 addition if the server has additional property associated with the 405 prefix by means of configuration or learnt from DHCPv6 prefix 406 delegation or derived via any other means it MUST be sent as 407 OPTION_PREFIX_PROPERTY option. 409 2.3. Usage 411 Class based prefix delegation can be used by the requesting router to 412 configure itself as a DHCPv6 server to serve its DHCPv6 clients. It 413 can allocate longer prefixes from a delegated shorter prefix it 414 received, for serving IA_NA and IA_PD requests. Prefix property and 415 class can be used for source address selection by applications using 416 the prefix for communication. 418 2.3.1. Class based prefix and IA_NA allocation 420 The requesting router can use the delegated prefix(es) from different 421 classes (for example "video" (1), "guest"(2), "voice" (3) etc), for 422 assigning the IPv6 addresses to the end hosts through DHCPv6 IA_NA 423 based on a preconfigured mapping with OPTION_PREFIX_CLASS option, the 424 following conditions MAY be observed: 426 o It MAY have a pre-configured mapping between the prefix class and 427 OPTION_USER_CLASS option received in IA_NA. 429 o It MAY match the OPTION_PREFIX_CLASS if the IA_NA request received 430 contains OPTION_PREFIX_CLASS. 432 o It MAY have a pre-configured mapping between the prefix class and 433 the client DUID received in DHCPv6 message. 435 o It MAY have a pre-configured mapping between the prefix class and 436 its network interface on which the IA_NA request was received. 438 The requesting router playing the role of a DHCPv6 server can 439 ADVERTISE IA_NA from a class of prefix(es) thus selected. 441 2.3.2. Class based prefix and IA_PD allocation 443 If the requesting router, receives prefix(es) for different classes 444 (for example "video"(1), "guest"(2), "voice"(3) etc), it can use 445 these prefix(es) for assigning the longer IPv6 prefixes to requesting 446 routers it serves through DHCPv6 IA_PD by assuming the role of 447 delegating router, its behavior is explained in Section 2.2.2. 449 2.3.3. Class based prefix and SLAAC 451 DHCPv6 IA_NA and IPv6 Stateless Address Autoconfiguration (SLAAC as 452 defined in [RFC4862]) are two ways by IPv6 addresses can be 453 dynamically assigned to end hosts. Making SLAAC class aware is 454 outside the scope of this document, it is specified in 455 [I-D.korhonen-dmm-prefix-properties]. 457 2.3.4. Class based prefix and applications 459 Applications within a host can do source address selection based on 460 the class of the prefix learnt in OPTION_PREFIX_PROPERTY and 461 OPTION_PREFIX_CLASS using rules defined in [RFC6724]. 463 3. Example Application 465 3.1. Mobile gateway example 467 The following sub-sections provide examples of class based prefix 468 delegation and how it is used in a mobile network. Each of the 469 examples will refer to the below network: 471 The example network consists of : 473 Mobile Gateway It is network entity anchoring IP traffic in the 474 mobile core network. This entity allocates an IP address which is 475 topologically valid in the mobile network and may act as a mobility 476 anchor if handover between mobile and Wi-Fi is supported. 478 Mobile Nodes (MN) A host or router that changes its point of 479 attachment from one network or subnetwork to another. A mobile node 480 may change its location without changing its IP address; it may 481 continue to communicate with other Internet nodes at any location 482 using its (constant) IP address, assuming link-layer connectivity to 483 a point of attachment is available. 485 Access Point (AP) A wireless access point, identified by a MAC 486 address, providing service to the wired network for wireless nodes. 488 Access Router (AR) An IP router residing in an access network and 489 connected to one or more Acess Point(AP)s. An AR offers IP 490 connectivity to MNs. 492 WLAN controller (WLC) The entity that provides the centralized 493 forwarding, routing function for the user traffic. 495 _----_ _----_ _----_ 496 _( )_ _( )_ _( )_ 497 (Operator-1) (Operator-2) (Operator-3) 498 (_ _) (_ _) (_ _) 499 -+-- -+-- '-+--' 500 +--------+ +--------+ +--------+ 501 | Mobile | | Mobile | | Mobile | 502 |gateway | |gateway | |gateway | 503 +--------+ +--------+ +--------+ 504 | | | 505 +-------------. | .-------------+ 506 | | | 507 | | | 508 | | |P1:"global-anchor"(1) 509 | | | 510 +--------+ _----_ 511 +---+ | |P2:"local-breakout"(2)_( )_ 512 |AAA|. . . . . . . | Access |---------------------( Internet ) 513 +---+ | Aggreg |-----------+ (_ _) 514 | Gateway| P3:"guest"| '----' 515 +--------+ | 516 | | +----- Guest Access 517 | | Network 518 | +-------------+ 519 | | 520 | +-----+ 521 | | AR | 522 +-----+ +-----+ 523 | WLC | * ---------* 524 | | ( LAN ) 525 +-----+ * ---------* 526 / \ / \ 527 +----+ +----+ +----+ +----+ 528 |WiFi| |WiFi| |WiFi| |WiFi| 529 | AP | | AP | | AP | | AP | 530 +----+ +----+ +----+ +----+ 531 . . 532 / \ / \ 533 MN1 MN2 MN3 MN4(guest) 535 Figure 1: Example mobile network 537 3.1.1. Class based prefix delegation 539 The Access Aggregation Gateway requests for Prefix delegation from 540 Mobile gateway and associates the prefix received with class "global- 541 anchor"(1). The Access Aggregation Gateway is preconfigured to 542 provide prefixes from the following classes: "global-anchor" (1), 543 "local-breakout"(2), "guest"(3). It has a preconfigured policy to 544 advertise prefixes to requesting routers and mobile nodes based on 545 the service class supported by the service provider for the 546 requesting device. In the example mobile network, the Access 547 Router(AR) requests class based prefix allocation by sending a DHCPv6 548 SOLICIT message and include OPTION_PREFIX_CLASS in the OPTION_ORO. 550 The Access Router (AR) receives an advertise with following prefixes 551 in the IA_PD option: 553 1. P1: IA_PD Prefix option with a prefix 3001:1::/64 containing 554 OPTION_PREFIX_CLASS set to "global-anchor"(1) 556 2. P2: IA_PD Prefix option with a prefix 3001:2::/64 containing 557 OPTION_PREFIX_CLASS set to "local-breakout"(2) 559 3. P3: IA_PD Prefix option with a prefix 3001:3::/64 containing 560 OPTION_PREFIX_CLASS set to "guest"(3) 562 It sends a REQUEST message with all of above prefixes and receives a 563 REPLY message with prefixes allocated for each of the requested 564 class. 566 3.1.2. IPv6 address assignment from class based prefix 568 When the Access Router(AR) receives a DHCPv6 SOLICIT requesting IA_NA 569 from the mobile node that has mobility service enabled, it offers an 570 IPv6 address from the prefix class "global-anchor"(1). For MN3 it 571 advertises 3001:1::1 as the IPv6 address in OPTION_IAADDR in response 572 to the IA_NA request. 574 The Mobile Node(MN4) Figure 1 sends a DHCPv6 SOLICIT message 575 requesting IA_NA address assignment with OPTION_USER_CLASS option 576 containing the value "guest" towards the CPE. The Access Router(AR) 577 assumes the role of the DHCPv6 server and sends an ADVERTISE to the 578 MN with OPTION_IA_NA containing an IPv6 address in OPTION_IAADDR from 579 the "guest"(3) class. The IPv6 address in the OPTION_IAADDR is set 580 to 3001:3::1. The "guest" class can also be distinguished based on a 581 preconfigured interface or SSID advertised for MNs connecting to it. 583 When the Access Aggregation Gateway receives a DHCPv6 SOLICIT 584 requesting IA_NA from MNs through WLC and it has a preconfigured 585 profile to provide both local-breakout internet access and global- 586 anchor, it offers an IPv6 address from the class "local-breakout" (2) 587 and "global-anchor"(1). For MN1 it advertises 3001:2::1 and 588 3001:1::2 as the IPv6 address in OPTION_IAADDR in response to the 589 IA_NA request. Applications within MN1 can choose to use the 590 appropriate prefix based on the mobility enabled or local-breakout 591 property attached to the prefix based on source address selection 592 policy. 594 The prefixes that are globally anchored and hence have mobility can 595 be advertised with OPTION_PREFIX_PROPERTY set to 0x0002 to convey 596 that the prefix provides network based mobility as listed in 597 Section 6.1. If the prefix also provides security guarantees 598 OPTION_PREFIX_PROPERTY can be set to 0x0009 to indicated mobility and 599 security guarantees by bitwise ORing of both the properties. 601 3.2. Homenet Example 603 The following sub-section describes an example of class based prefix 604 delegation in a home network environment. The network consists of 605 the following elements: 607 o Home Gateway (HGW) device: a routing device located in the 608 customer's premises that provides connectivity between the 609 customer and the service provider. In this example, the HGW is 610 functioning as both a DHCP client towards the service provider's 611 DHCP infrastructure and a DHCP server towards hosts located in the 612 home network. 614 o IPv6 Set Top Box (STB): A dedicated, IPv6 attached, video on 615 demand device. 617 o IPv6 PC: An IPv6 attached personal computer. 619 o Delegating Router: The router in the ISPs network acting as a DHCP 620 server for the IA_PD request. 622 o Video On Demand (VOD) service: A server providing unicast based 623 streaming video content to subscribers. 625 _----+----_ 626 _( ) 627 ( Internet ) 628 (_ _) 629 '----+----' 630 | 631 _----+----_ +----------+ \ 632 _( )_ | Video on | \ 633 (Service Provider)--| Demand | \ 634 (_ Network _) | Service | | ISP 635 '----+----' +----------+ | Network 636 | | 637 +------+-----+ | 638 | Delegating | | 639 | Router | | 640 +------+-----+ | 641 | | 642 | Customer | 643 | Internet connection / 644 | / 645 | / 646 +------+--------+ ^ \ 647 | IPv6 | | DHCPv6 Client \ 648 | Home gateway | \ 649 | Device (CPE) | | DHCPv6 Server | 650 +------+--------+ v | Home 651 | | Network 652 Home Network | | 653 +-----+-------+ | 654 | | | 655 +----+-----+ +-----+----+ | 656 |IPv6 Host | |IPv6 Host | | 657 | (Set top | | (PC) | DHCPv6 Clients / 658 | box) | | | / 659 +----------+ +----------+ / 661 Simple home network with Data and Video devices 663 3.2.1. Class based prefix delegation to the HGW 665 In this example, two different services are being run on the same 666 network. The service provider wishes that traffic is sourced from 667 different prefixes by the home network clients 668 [I-D.jiang-v6ops-semantic-prefix]. The HGW (requesting router) has 669 been configured to request prefix delegation from the ISPs delegating 670 router with the usage classes "video" (1) and "internet"(2) the 671 meaning of these being of relevance to the ISP operating this and 672 application that are configured out of band to utilize it. 674 The delegating router is preconfigured to advertise prefixes with 675 these service classes. The HGW sends two IA_PD options within the 676 SOLICIT message, one with OPTION_PREFIX_CLASS "video" (1) and the 677 second with "internet" (2). The HGW receives an advertise with the 678 following prefixes in the IA_PD option: 680 1. P1: IA_PD Prefix option with a prefix 3001:5::/56 containing 681 OPTION_PREFIX_CLASS set to "video" (1) 683 2. P2: IP_PD Prefix option with a prefix 3001:6::/56 containing 684 OPTION_PREFIX_CLASS set to "internet" (2) 686 It sends a REQUEST message with all of the above prefixes and 687 receives a REPLY message with prefixes allocated for each of the 688 requested classes. The HGW then configures a /64 prefix from each of 689 the delegated prefixes on its LAN interface [RFC6204] and sends out 690 router advertisements (RAs) with the "M" and "O" bits set. 692 3.2.2. IPv6 Assignment to Homenet hosts using stateful DHCPv6 694 STB sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS 695 option set to "video" (1) within the IA_NA. The HGW checks the 696 requested prefix class against the available prefixes it has been 697 delegated and advertises 3001:5::1 to the STB. The STB then 698 configures this address on its LAN interface and uses it for sourcing 699 requests to the VOD service. 701 The PC sends a DHCPv6 SOLICIT message with the OPTION_PREFIX_CLASS 702 option set to "internet" within the IA_NA or without 703 OPTION_PREFIX_PROPERTY. The HGW checks the requested prefix class 704 against the available prefixes it has been delegated and advertises 705 3001:6::1 to the PC or in absence of OPTION_PREFIX_CLASS in the 706 solicit HGW is preconfigured to assign from the "internet"(2) class 707 as the default. The PC then configures this address on its LAN 708 interface and uses it for sourcing requests to the Internet. 710 4. Acknowledgements 712 The authors would like to acknowledge review and guidance received 713 from Frank Brockners, Wojciech Dec, Richard Johnson, Erik Nordmark, 714 Hemant Singh, Mark Townsley, Ole Troan, Bernie Volz 716 5. Contributors 718 Authors would like to thank contributions to use cases and text for 719 various sections received from Ian Farrer and Sindhura Bandi. 721 6. IANA Considerations 723 IANA is requested to assign an option code to OPTION_PREFIX_PROPERTY 724 (TBD1) and OPTION_PREFIX_CLASS (TBD2) from the "DHCPv6 and DHCPv6 725 options" registry (http://www.iana.org/assignments/dhcpv6-parameters/ 726 dhcpv6-parameters.xml). 728 6.1. OPTION_PREFIX_PROPERTY values 730 IANA is requested to reserve and maintain registry of 731 OPTION_PREFIX_PROPERTY values and manage allocation of values as per 732 as per policy defined in [RFC5226] with IETF assigned values 733 requiring IETF consensus, RFC Required policy, any other values other 734 than the ones listed below are not valid. 736 1. 0x0001 The prefix cannot be used to reach the Internet 738 2. 0x0002 The prefix provides network based mobility 740 3. 0x0004 The prefix requires authentication 742 4. 0x0008 The prefix is assigned on an interface that provides 743 security guarantees 745 5. 0x0010 Usage is charged 747 6. 0x0020 Unassigned 749 7. 0x0040 Unassigned 751 8. 0x0080 Unassigned 753 9. 0x0100 Unassigned 755 10. 0x0200 Unassigned 757 11. 0x0400 Unassigned 759 12. 0x0800 Unassigned 761 13. 0x1000 Unassigned 762 14. 0x2000 Unassigned 764 15. 0x4000 Unassigned 766 16. 0x8000 Unassigned 768 7. Security Considerations 770 Security issues related to DHCPv6 which are described in section 23 771 of [RFC3315] and [RFC3633] apply for scenarios mentioned in this 772 draft as well. 774 8. Change History (to be removed prior to publication as an RFC) 776 Changes from -00 to -01 778 a. Modified motivation section to focus on mobile networks 780 b. Modified example with a mobile network and class based prefix 781 delegation in it 783 Changes from -01 to -02 785 a. Modified option format to be enumerated values 787 b. Added IANA section to request managing of registry for the 788 enumerated values 790 c. Added initial values for the class 792 d. Added section for applications to select address with a specific 793 property 795 Changes from -02 to -03 797 a. Added server behaviour for IA_NA and IA_PD allocation 799 b. Added Class based Information-Request usage 801 Changes from -03 to -04 803 a. Added homenet use case 805 b. Split usage class into a fixed IANA maintained properties 806 registry and a prefix class 808 9. References 810 9.1. Normative References 812 [I-D.ietf-dhc-dhcpv4-over-ipv6] 813 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 814 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in 815 progress), September 2012. 817 [I-D.jiang-v6ops-semantic-prefix] 818 Jiang, S., Sun, Q., and I. Farrer, "A Framework for 819 Semantic IPv6 Prefix and Gap Analysis", 820 draft-jiang-v6ops-semantic-prefix-02 (work in progress), 821 January 2013. 823 [I-D.korhonen-dmm-prefix-properties] 824 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 825 Liu, "IPv6 Prefix Mobility Management Properties", 826 draft-korhonen-dmm-prefix-properties-03 (work in 827 progress), October 2012. 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 833 (IPv6) Specification", RFC 2460, December 1998. 835 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 836 "Remote Authentication Dial In User Service (RADIUS)", 837 RFC 2865, June 2000. 839 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 840 and M. Carney, "Dynamic Host Configuration Protocol for 841 IPv6 (DHCPv6)", RFC 3315, July 2003. 843 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 844 Host Configuration Protocol (DHCP) version 6", RFC 3633, 845 December 2003. 847 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 848 in IPv6", RFC 3775, June 2004. 850 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 851 Address Autoconfiguration", RFC 4862, September 2007. 853 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 854 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 855 May 2008. 857 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 858 Troan, "Basic Requirements for IPv6 Customer Edge 859 Routers", RFC 6204, April 2011. 861 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 862 "Default Address Selection for Internet Protocol Version 6 863 (IPv6)", RFC 6724, September 2012. 865 9.2. Informative References 867 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 868 June 1999. 870 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 871 Text on Security Considerations", BCP 72, RFC 3552, 872 July 2003. 874 Authors' Addresses 876 Shwetha Bhandari 877 Cisco Systems 878 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 879 Bangalore, KARNATAKA 560 087 880 India 882 Phone: 883 Email: shwethab@cisco.com 885 Gaurav Halwasia 886 Cisco Systems 887 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 888 Bangalore, KARNATAKA 560 087 889 India 891 Phone: +91 80 4426 1321 892 Email: ghalwasi@cisco.com 894 Sri Gundavelli 895 Cisco Systems 896 170 West Tasman Drive 897 San Jose, CA 95134 898 USA 900 Email: sgundave@cisco.com 901 Hui Deng 902 China Mobile 903 53A, Xibianmennei Ave., Xuanwu District 904 Beijing 100053 905 China 907 Email: denghui02@gmail.com 909 Laurent Thiebaut 910 Alcatel-Lucent 911 France 913 Email: laurent.thiebaut@alcatel-lucent.com 915 Jouni Korhonen 916 Renesas Mobile 917 Linnoitustie 6 918 FIN-02600 Espoo, 919 Finland 921 Phone: 922 Email: jouni.nospam@gmail.com