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