idnits 2.17.1 draft-ietf-netext-pd-pmip-14.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 (December 18, 2013) is 3779 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG X. Zhou 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track J. Korhonen 5 Expires: June 21, 2014 Broadcom 6 C. Williams 7 Consultant 8 S. Gundavelli 9 Cisco 10 CJ. Bernardos 11 UC3M 12 December 18, 2013 14 Prefix Delegation Support for Proxy Mobile IPv6 15 draft-ietf-netext-pd-pmip-14 17 Abstract 19 This specification defines extensions to the Proxy Mobile IPv6 20 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain 21 to obtain IP prefixes for its attached mobile networks using DHCPv6 22 prefix delegation. Network-based mobility management support is 23 provided for those delegated IP prefixes just as it is provided for 24 the mobile node's home address. Even if the mobile router performs a 25 handoff and changes its network point of attachment, mobility support 26 is ensured for all the delegated IP prefixes and for all the IP nodes 27 in the mobile network that use IP address configuration from those 28 delegated IP prefixes. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 21, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Deployment Models . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. Delegating Router co-located with Mobile Access 69 Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2.2. Delegating Router co-located with Local Mobility 71 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2.3. Static Configuration of Delegated Mobile Network 73 Prefixes . . . . . . . . . . . . . . . . . . . . . . . 11 74 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.1. Delegated Mobile Network Prefix Option . . . . . . . . . . 12 76 4.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14 77 5. Operational Details . . . . . . . . . . . . . . . . . . . . . 14 78 5.1. MAG Considerations . . . . . . . . . . . . . . . . . . . . 14 79 5.1.1. Extension to Binding Update List Entry Data 80 Structure . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1.2. Signaling Considerations . . . . . . . . . . . . . . . 14 82 5.1.3. DHCP - MAG Interactions . . . . . . . . . . . . . . . 16 83 5.1.3.1. Delegating Router co-located with Mobile 84 Access Gateway . . . . . . . . . . . . . . . . . . 16 85 5.1.3.2. Delegating Router co-located with Local 86 Mobility Anchor . . . . . . . . . . . . . . . . . 18 87 5.1.4. Packet Forwarding . . . . . . . . . . . . . . . . . . 19 88 5.2. LMA Considerations . . . . . . . . . . . . . . . . . . . . 20 89 5.2.1. Extensions to Binding Cache Entry Data Structure . . . 20 90 5.2.2. Signaling Considerations . . . . . . . . . . . . . . . 20 91 5.2.3. Packet Forwarding . . . . . . . . . . . . . . . . . . 22 92 5.3. Security Policy Database (SPD) Example Entries . . . . . . 22 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 Proxy Mobile IPv6 [RFC5213] enables network-based mobility management 104 support for an IP host without requiring its participation in any IP 105 mobility signaling. In Proxy Mobile IPv6 (PMIPv6), the mobile access 106 gateway (MAG) performs the mobility management function on behalf of 107 the mobile node (MN). The local mobility anchor (LMA) is the home 108 agent for the MN and the topological anchor point. The mobility 109 elements (LMA and MAGs) in the network allow an IP host to obtain an 110 IPv4 address and/or a set of IPv6 addresses and be able to obtain IP 111 mobility support for those IP address(es) within the Proxy Mobile 112 IPv6 domain. In this context, the mobility management support is 113 enabled for an individual IP host, which is the mobile node. The 114 IPv4 home address, or the IPv6 home network prefixes are logically 115 bound to the link shared between the mobile access gateway and the 116 mobile node and only the mobile node can use those IP address(es) by 117 configuring them on the interface attached to that link. Currently, 118 there is no mobility support for the mobile networks attached to a 119 mobile router in a Proxy Mobile IPv6 domain. 121 This specification defines extensions to the Proxy Mobile IPv6 122 protocol (a new mobility option for carrying delegated prefix 123 information in proxy binding update and proxy binding acknowledgement 124 messages) for allowing mobility support to the mobile networks 125 attached to a mobile router. The mobile router can request the 126 mobility entities in the Proxy Mobile IPv6 domain for one or more 127 delegated IP prefixes using DHCP Prefix Delegation extensions 128 [RFC3633], or through other means such as static configuration, or 129 access technology specific mechanisms. The mobility entities in the 130 PMIPv6 network provide network-based mobility management support for 131 those delegated prefixes just as it is supported for a home address. 132 The delegated prefixes are hosted in the mobile network attached to 133 the mobile router. IP mobility is ensured for all the IP nodes in 134 the mobile network, even as the mobile router performs a handoff by 135 changing its point of network attachment within the Proxy Mobile IPv6 136 domain. The local mobility anchor in the Proxy Mobile IPv6 domain 137 will not track the individual IP sessions for all the IP nodes in the 138 mobile network, it only tracks a single mobile router session that is 139 hosting the mobile network and associates the delegated IP prefixes 140 with that session. Although the protocol solution defined in this 141 specification also allows signaling IPv4 subnets between the mobile 142 access gateway and the local mobility anchor, the delegation of IPv4 143 subnets to the mobile router is out of scope of this specification. 145 _----_ 146 +-------+ _( )_ 147 | |---( Internet ) 148 | LMA | (_ _) 149 | | '----' 150 +-------+ 151 | 152 === === === 153 == Proxy == 154 == Mobile IPv6 == 155 == Domain == 156 === === === 157 ___________|___________ 158 | | 159 +-------+ +-------+ 160 | MAG | | MAG | 161 +-------+ +-------+ 162 . 163 . 164 - - - - - - - - 165 | +------+ | 166 | | MR | | 167 | +------+ | 168 | | | 169 | ------- | 170 | | | | 171 | LFN LFN | 172 - - - - - - - - 174 Figure 1: Mobile Router in Proxy Mobile IPv6 Domain 176 Within the context of this document, the definition of a mobile 177 router extends that of a mobile node definition from [RFC5213], by 178 adding routing capability between the mobile network and the point of 179 attachment of the mobile router. The network of nodes part of the 180 mobile network are referred to as locally fixed nodes (LFN) and they 181 all move with the mobile router as a single cluster. As the mobile 182 router moves, the LFNs are not aware of the mobility of the MR to a 183 new point of attachment. Figure 1 illustrates a mobile router in a 184 Proxy Mobile IPv6 domain. 186 The rest of the document identifies the protocol extensions and the 187 operational details of the local mobility anchor and mobile access 188 gateway for supporting this specification. 190 2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 All the mobility related terms used in this document are to be 197 interpreted as defined in Proxy Mobile IPv6 specifications [RFC5213] 198 and [RFC5844]. All the DHCP related terms are to be interpreted as 199 defined in DHCPv6-PD for NEMO [RFC6276], DHCPv6-PD [RFC3633] and 200 Subnet Allocation Option for DHCPv4 [RFC6656]. This document also 201 provides a context-specific explanation to the following terms used 202 in this document, and originally defined in the Mobile Network 203 terminology document [RFC4885]. 205 Mobile Router (MR) 207 The term mobile router is used to refer to an IP router whose 208 mobility is managed by the network while being attached to a Proxy 209 Mobile IPv6 domain. The mobile router is a mobile node as defined 210 in [RFC5213], but with additional capabilities for supporting an 211 attached mobile network. The MR's interface used for attachment 212 to the mobile access gateway is referred to as the egress 213 interface. Any MR's interface used for attachment to the mobile 214 network is referred to as ingress interface. The mobility 215 entities in the Proxy Mobile IPv6 domain provide mobility for the 216 IPv4/IPv6 address(es) assigned to the mobile node's egress link 217 and also mobility support to the network prefixes hosted in the 218 network attached to the mobile router. 220 Mobile Network 222 It is an IP network attached to a mobile router. There can be 223 many IP nodes in this IP network. The mobile router is a gateway 224 for these IP nodes for reaching other IP networks or the Internet. 225 The mobile router and the attached IP networks move as a single 226 cluster. 228 Delegated Mobile Network Prefix (DMNP) 230 The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix 231 delegated to a mobile router and is hosted in the mobile network. 232 The IP nodes in the mobile network will be able to obtain IP 233 address configuration from the delegated mobile network prefix and 234 will have IP mobility support for that address configuration. The 235 DMNP is topologically anchored on the local mobility anchor and 236 the mobility elements in the Proxy Mobile IPv6 domain provide IP 237 mobility support for the prefix, by forwarding the mobile network 238 traffic to the mobile router. 240 Locally Fixed Node (LFN) 242 A Locally Fixed Node is an IP node in the mobile network. As the 243 mobile router performs a handoff and changes its network point of 244 attachment, the locally fixed node moves along with the mobile 245 router. 247 3. Solution Overview 249 This section provides an overview of the operation of this 250 specification, as well as lists the stated assumptions. This 251 specification references three different deployment scenarios and 252 explains the protocol operation. 254 3.1. Stated Assumptions 256 o The mobile router is a mobile node as defined in [RFC5213], but 257 with additional capabilities for routing IP packets between its 258 egress interface (interface used for attachment to the mobile 259 access gateway) and any of its ingress interfaces (interface used 260 for attachment to the mobile network). 262 o The specification assumes that a mobile router is an IPv4 and/or 263 IPv6 router without any capability for mobility management. 265 o The mobile router can obtain the delegated IP prefix(es) for its 266 attached mobile networks using DHCPv6 Prefix Delegation, Static 267 configuration, or through mechanisms specific to the access 268 technology. This document assumes DHCPv6 Prefix Delegation 269 [RFC3633] and in conjunction with the Prefix Exclude Option 270 [RFC6603] as the default mechanism for prefix assignment to the 271 mobile node. It defines an interworking between the mobility 272 entities and the DHCPv6 functional elements in a non-normative 273 way. The mechanism how to delegate IPv4 subnets to a mobile 274 router is out of scope of this specification. 276 o The mobile router obtains the IP address configuration for its 277 egress roaming interface as specified in [RFC5213] and [RFC5844]. 278 The mobile router along with its mobile networks will be able to 279 perform handoff and change its point of attachment in the network 280 and will be able to retain IP mobility support. 282 o When using DHCPv6 Prefix Delegation, this document assumes that 283 the mobile router uses its egress interface when making DHCPv6 284 requests. 286 3.2. Deployment Models 288 This section explains the protocol operation for supporting prefix 289 delegation support in Proxy Mobile IPv6 for the following three 290 deployment models: i) Delegating router co-located with mobile access 291 gateway, ii) Delegating router co-located with local mobility anchor, 292 and iii) Static configuration of delegated prefixes. High-level 293 message call flows between the mobile router, mobile access gateway 294 and the local mobility anchor are presented while explaining the 295 protocol operation. 297 3.2.1. Delegating Router co-located with Mobile Access Gateway 299 In this deployment scenario, the delegating router (DR) function, as 300 specified in [RFC3633], is co-located with the mobile access gateway, 301 and a requesting router (RR) function is enabled on the mobile 302 router. 304 Figure 2 shows the high-level message call flow for this case. The 305 mobile router attaches to the mobile access gateway, which triggers 306 the Proxy Mobile IPv6 signaling between the mobile access gateway and 307 the local mobility anchor, setting up the bi-directional tunnel 308 between them (regular Proxy Mobile IPv6 registration). After that, 309 the DHCPv6 requesting router function running on the mobile router 310 sends a Solicit message requesting a prefix. This message is 311 received by the the DHCPv6 delegating router function running on the 312 mobile access gateway. The mobile access gateway then sends a proxy 313 binding update message including a delegated mobile network prefix 314 (DMNP) option carrying the ALL_ZERO value [RFC5213]. This serves as 315 a request for the local mobility anchor to allocate a set of 316 delegated prefixes, conveyed back in one or more DMNP options in a 317 proxy binding acknowledgment message. The DHCPv6-PD signaling is 318 then completed as described in [RFC3633], finalizing with the 319 delegating router sending a Reply message conveying the delegated 320 prefixes. If the requesting router includes a Rapid Commit option in 321 its Solicit message, it is preferable that the MAG respond directly 322 with a Reply rather than with an Advertise message, as described in 323 [RFC3315], Section 17.2.3. 325 +-----+ +-----+ +-----+ 326 | MR | | MAG | | LMA | 327 |(RR) | | (DR)| | | 328 +-----+ +-----+ +-----+ 329 1) |-- MN Attach -----| | 330 | |--Proxy Binding Update----->| 331 | | | 332 | |<-------Proxy Binding Ack.--| 333 | | | 334 | |o==========================o| 335 2) | | PMIPv6 tunnel | 336 | |o==========================o| 337 3) |--Solicit for---->| | 338 | delegated prefix | | 339 4) | |--Proxy Binding Update----->| 340 | | | 341 5) | |<--Proxy Binding Ack.(DMNP)-| 342 | | | 343 - -<---+ | 344 6) |<------Advertise--| | | 345 | | | | 346 7) |--Request-------->| Optional | 347 | | | | 348 - -<---+ | 349 8) |<---Reply (DMNP)--| | 350 | | | 352 Figure 2: Delegating Router co-located with Mobile Access Gateway 354 From an operational point of view, this is the simplest deployment 355 option, as it keeps a single protocol interface between the mobile 356 access gateway and the local mobility anchor. 358 3.2.2. Delegating Router co-located with Local Mobility Anchor 360 In this deployment scenario, the delegating router (DR) function, as 361 specified in [RFC3633], is co-located with the local mobility anchor, 362 the requesting router (RR) function is enabled on the mobile router 363 and a DHCPv6 Relay Agent (DRA) function, is co-located on the mobile 364 access gateway. 366 Figure 3 shows the high-level message call flow for this case. The 367 mobile router attaches to the mobile access gateway, which triggers 368 the Proxy Mobile IPv6 signaling between the mobile access gateway and 369 the local mobility anchor, setting up the bi-directional tunnel 370 between them (regular Proxy Mobile IPv6 registration). After that, 371 the DHCPv6 requesting router function running on the mobile router 372 requests a prefix by sending a Solicit message. This message is 373 received by the DHCPv6 relay agent function running on the mobile 374 access gateway, which then completes the DHCPv6 signaling, according 375 to [RFC3315]. The relay agent function SHOULD include the relay 376 agent remote-id option [RFC4649] into Relay-forward messages with 377 appropriate identity information to enable correlation of mobile 378 router identities used over DHCPv6 and PMIPv6. 380 Once the mobile access gateway gets the set of delegated prefixes 381 from the delegating router function running on the local mobility 382 anchor, the MAG conveys the delegated prefixes in a proxy binding 383 update. This ensures that the local mobility anchor properly routes 384 the traffic addressed to the delegated prefixes via the PMIPv6 tunnel 385 established with the mobile access gateway, and that mobility is 386 provided to these prefixes while the mobile router roams within the 387 PMIPv6 domain. Note that the relay agent function in the mobile 388 access gateway has to queue the Reply message for the duration of the 389 PMIPv6 signaling (steps 10 and 11) before forwarding the Reply 390 message to the requesting router. While this does not change 391 anything from the DHCPv6-PD protocol point of view, implementations 392 will need to account for interactions between the timing of PMIPv6 393 signaling and the DHCPv6 timeout/retry logic. 395 +-----+ +-----+ +-----+ 396 | MR | | MAG | | LMA | 397 |(RR) | |(DRA)| |(DR) | 398 +-----+ +-----+ +-----+ 399 1) |-- MN Attach -----| | 400 | |--------- PBU ----------->| 401 | | | 402 | |<-------- PBA ------------| 403 | | | 404 | |o========================o| 405 2) | | PMIPv6 tunnel | 406 | |o========================o| 407 3) |-- Solicit for -->| | 408 | delegated prefix | | 409 4) | |--- Solicit ------------->| 410 - - - <---+ 411 5) | |<-- Advertise ------------| | 412 | | | | 413 6) |<- Advertise -----| | | 414 | | | Optional 415 7) |-- Request ------>| | | 416 | | | | 417 8) | |--- Request ------------->| | 418 - - - <---+ 419 9) | |<-- Reply (DMNP) ---------| 420 | | | 421 10) | |----------PBU (DMNP)----->| 422 | | | 423 11) | |<---------PBA (DMNP)------| 424 | | | 425 12) |<-- Reply (DMNP) -| | 426 | | | 428 Figure 3: Delegating Router co-located with Local Mobility Anchor 430 The DR function can also be on the located in other entities of the 431 home network different from the LMA. This deployment model requires 432 some interworking between the DR and the LMA and is out of scope for 433 this specification. Note that this additional interworking would 434 have no impact on the protocol between the LMA and MAG defined in 435 this document. 437 3.2.3. Static Configuration of Delegated Mobile Network Prefixes 439 In this deployment scenario, the delegated mobile network prefixes of 440 the mobile router are statically configured in the mobile node's 441 policy profile [RFC5213]. The delegated mobile network prefixes are 442 statically configured in the mobile network attached to the mobile 443 router. The mobile router is the default-router for the mobile 444 networks. 446 Figure 4 shows a high-level message call flow for this example. The 447 mobile access gateway obtains statically configured mobile network 448 prefixes from the policy profile and registers them with the local 449 mobility anchor using the extensions specified in this document, that 450 is, the use of the delegated mobile network prefix (DMNP) option in 451 the Proxy Mobile IPv6 signaling. There is no explicit trigger from 452 the mobile router for registering, or de-registering those prefixes. 453 As long as there is a mobility session for the mobile router's home 454 address, the local mobility anchor enables mobility support for the 455 mobile network prefixes. 457 +-----+ +-----+ +-----+ 458 | MR | | MAG | | LMA | 459 | | | | | | 460 +-----+ +-----+ +-----+ 461 1) |-- MN Attach -----| | 462 2) | - (Policy Profile) | 463 | | | 464 3) | |--------- PBU (DMNP) ---->| 465 | | | 466 4) | |<-------- PBA (DMNP) -----| 467 | | | 468 | |o========================o| 469 5) | | PMIPv6 tunnel | 470 | |o========================o| 471 | | | 473 Figure 4: Static Configuration of Delegated Mobile Network Prefixes 475 4. Message formats 477 This section defines extensions to Proxy Mobile IPv6 [RFC5213] 478 protocol messages. 480 4.1. Delegated Mobile Network Prefix Option 482 A new mobility header option, Delegated Mobile Network Prefix option 483 is defined for use with Proxy Binding Update and Proxy Binding 484 Acknowledgment messages exchanged between a local mobility anchor and 485 a mobile access gateway. This option is used for exchanging the 486 mobile router's IPv4/IPv6 delegated mobile network prefix. There can 487 be multiple instances of the Delegated Mobile Network Prefix option 488 present in a message. 490 The Delegated Mobile Network Prefix option has an alignment 491 requirement of 8n+2. Its format is as follows: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length |V| Reserved | Prefix Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 + + 500 | | 501 . . 502 + IPv4 or IPv6 Delegated Mobile Network Prefix + 503 | (DMNP) | 504 + + 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type 510 : To be assigned by IANA. 512 Length 514 8-bit unsigned integer indicating the length of the option in 515 octets, excluding the type and length fields. 517 IPv4 Prefix (V) 519 If the IPv4 Prefix (V) flag is set to a value of (1), then it 520 indicates that the prefix that is included in the DMNP field is an 521 IPv4 prefix. If the IPv4 Prefix (V) flag is set to a value of 522 (0), then it indicates that the prefix that is included in the 523 DMNP field is an IPv6 prefix. 525 Reserved 527 This field is unused for now. The value MUST be initialized to 0 528 by the sender and MUST be ignored by the receiver. 530 Prefix Length 532 8-bit unsigned integer indicating the prefix length of the prefix 533 contained in the option. 535 Delegated Mobile Network Prefix 536 Contains a mobile router's 4-byte IPv4 or a 16-byte IPv6 Delegated 537 Mobile Network Prefix. 539 4.2. Status Codes 541 This document defines the following new status code values for use in 542 the Proxy Binding Acknowledgement message. These values have been 543 allocated from the same number space as defined in Section 6.1.8 of 544 [RFC6275]. 546 NOT_AUTHORIZED_FOR_DELEGATED_MNP: 548 Not Authorized for delegated mobile network prefix 550 REQUESTED_DMNP_IN_USE: 552 Requested delegated mobile network prefix is in use 554 5. Operational Details 556 5.1. MAG Considerations 558 5.1.1. Extension to Binding Update List Entry Data Structure 560 In order to support this specification, the conceptual Binding Update 561 List Entry (BULE) data structure [RFC5213] needs to be extended to 562 include a delegated mobile network prefix (DMNP) list. Each entry in 563 the list is used for storing an IPv4/IPv6 mobile network prefix 564 delegated to the mobile router. 566 5.1.2. Signaling Considerations 568 During the mobile router's initial attachment procedure, the mobile 569 access gateway obtains the mobile router's policy profile, as per the 570 procedures defined in [RFC5213]. The mobile node's policy profile 571 defined in [RFC5213] is extended to include a parameter which 572 indicates Delegated Prefix support. If the policy profile indicates 573 that the mobile router is authorized for Delegated Prefix support, 574 then the considerations described next apply. 576 The mobile access gateway MUST include one or more Delegated Mobile 577 Network Prefix (DMNP) options in the Proxy Binding Update message in 578 order to request the local mobility anchor to allocate delegated 579 mobile network prefix(es) for the mobile router. 581 If the mobile access gateway requests the local mobility anchor to 582 perform the prefix assignment, then: 584 o There MUST be exactly one instance of the Delegated Mobile Network 585 Prefix option with ALL_ZERO value and with the (V) flag set to a 586 value of (0). This serves as a request to the local mobility 587 anchor to allocate a set of delegated IPv6 mobile network 588 prefixes. 590 o There MUST be exactly one instance of the Delegated Mobile Network 591 Prefix option with ALL_ZERO value and with the (V) flag set to a 592 value of (1). This serves as a request to the local mobility 593 anchor to allocate a set of delegated IPv4 mobile network 594 prefixes. 596 o If the received Proxy Binding Acknowledgement message has the 597 status field value set to NOT_AUTHORIZED_FOR_DELEGATED_MNP (Not 598 Authorized for delegated mobile network prefix), the mobile access 599 gateway MUST NOT enable mobility support for any of the prefixes 600 in the mobile network and prefix delegation support has to be 601 disabled. 603 o If the received Proxy Binding Acknowledgement message has the 604 status field value set to REQUESTED_DMNP_IN_USE (Requested 605 delegated mobile network prefix is in use), the mobile access 606 gateway MUST NOT enable mobility support for the requested 607 prefixes. The mobile access gateway MAY choose to send Proxy 608 Binding Update message requesting the local mobility anchor to 609 perform the prefix assignment. 611 If the mobile access gateway provides the local mobility anchor with 612 the prefix(es) that wants to get allocated, then: 614 o There MUST be exactly one instance of the Delegated Mobile Network 615 Prefix option with NON_ZERO prefix value [RFC5213] for each of the 616 mobile network prefixes that the mobile access gateway is 617 requesting the local mobility anchor to allocate. The prefix 618 value in the option is the prefix that is either statically 619 configured for that mobile router in the mobile node's policy 620 profile, or obtained via interactions with the DHCP PD functions. 621 This serves as a request to the local mobility anchor to allocate 622 the requested IPv4/IPv6 prefix. 624 If the received Proxy Binding Acknowledgement message has the status 625 field value set to 0 (Proxy Binding Update accepted), the mobile 626 access gateway has to apply the following considerations. 628 o The delegated mobile network prefix (DMNP) list in the mobile 629 router's Binding Update List entry has to be updated with the 630 allocated prefix(es). However, if the received message was in 631 response to a de-registration request with a lifetime value of 632 (0), then the delegated mobile network prefix list has to be 633 removed along with the Binding Update List entry. 635 o The mobile access gateway has to set up a policy-based route for 636 forwarding the IP packets received from the mobile network (with 637 the source IP address from any of the delegated IPv4/IPv6 mobile 638 network prefixes) through the bidirectional tunnel set up for that 639 mobile router. However, if the received message was in response 640 to a de-registration request with a lifetime value of (0), then 641 the created forwarding state has to be removed. 643 This specification assumes that all the mobile access gateways of a 644 PMIPv6 Domain support the same prefix delegation mechanism. If there 645 is any difference, it will result in delegated mobile network 646 prefix(es) getting de-registered and the mobile network loosing the 647 prefix(es). This would result in the attached local fixed nodes 648 loosing the assigned IP addresses. The mobile router MAY explicitly 649 deprecate these prefixes. Alternatively the lifetime of the 650 addresses may expire. 652 5.1.3. DHCP - MAG Interactions 654 This section describes the interactions between the DHCP and PMIPv6 655 logical entities running on the mobile access gateway. This section 656 is applicable only for deployments that use DHCPv6-based prefix 657 delegation (i.e., it does not apply if static configuration is used). 658 As described next, these interactions vary slightly depending on the 659 considered deployment model at the mobile access gateway (described 660 in Section 3.2). 662 The mobile router, acting as a "Requesting Router" as described in 663 [RFC3633], sends a Solicit message including one or more IA_PD 664 option(s) to the Delegating Router/DHCPv6 Relay Agent collocated on 665 the mobile access gateway. This message provides the needed trigger 666 for the mobile access gateway for requesting the local mobility 667 anchor to enable delegated mobile network prefix support for that 668 mobility session. We next describe the subsequent interactions 669 depending on the deployment model. 671 5.1.3.1. Delegating Router co-located with Mobile Access Gateway 673 The mobile access gateway applies the considerations in Section 5.1.2 674 for requesting the local mobility anchor to enable delegated prefix 675 support. For example, if the mobile router is soliciting an IPv4 676 prefix, the mobile access gateway includes in the Proxy Binding 677 Update signaling a Delegated Mobile Network Prefix option with 678 ALL_ZERO value and with the (V) flag set to a value of (1). 680 The mobile access gateway, upon successfully completing the Proxy 681 Binding Update signaling with the local mobility anchor (following 682 the considerations described in Section 5.1.2), adds the delegated 683 mobile network prefixes to the binding update list. Then, the mobile 684 access gateway provides the obtained prefixes to the DHCPv6 685 Delegating Router for prefix assignment. The way in which these 686 prefixes are passed to the DHCPv6 delegating router function is 687 beyond the scope of this document. 689 o In case the Proxy Binding Update signaling with the local mobility 690 anchor is not completed successfully, for example because the 691 local mobility anchor is not authorized for delegated mobile 692 network prefix or the requested prefix is in use, the DHCPv6 693 Delegating Router will send a Reply message to the Requesting 694 Router with no IA_PREFIX suboptions and with a Status Code option 695 as described in [RFC3633], section 11.2. 697 The standard DHCPv6 considerations will be applied with respect to 698 the interactions between the Delegating Router and the Requesting 699 Router. The Requesting Router is provided with the delegated 700 prefix(es), which can then be then advertised in the mobile network, 701 and therefore used by the locally fixed nodes to auto configure IP 702 addresses allowing to gain access to the Internet. 704 Any time, the Requesting Router releases the delegated prefixes, the 705 Delegating Router removes the assigned prefixes. To do so, the 706 mobile access gateway will send an Updated Proxy Binding Update 707 following the considerations described in Section 5.1.2 for de- 708 registering those prefixes. The way in which the DHCPv6 Delegating 709 Router triggers the mobile access gateway in order to de-register the 710 prefixes is beyond the scope of this document. 712 In case the mobile router performs a handover and attaches to a 713 different mobile access gateway, the following cases are possible: 715 o The new mobile access gateway does not support the delegation of 716 mobile network prefixes described in this specification. In this 717 case, forwarding of the previously delegated mobile network 718 prefixes is no longer performed. 720 o The new mobile access gateway supports the delegation of mobile 721 network prefixes described in this specification. There are two 722 possible cases upon the reception of the SOLICIT message by the 723 Delegating Router. If the MAG already knows the delegated mobile 724 network prefixes, it conveys them in a DMNP option included in the 725 Proxy Binding Update sent to the local mobility anchor, which then 726 authorizes them based on: a) the content of the associated binding 727 cache entry (if exists), b) the user profile (if the allocation is 728 static), or, c) checking that the delegated mobile network 729 prefixes are not already allocated. On the other hand, if the 730 mobile access gateway is not aware of the delegated mobile network 731 prefixes, it will include 0.0.0.0 / ::0 in a DMNP option included 732 in the Proxy Binding Update sent to the LMA, which will provide 733 the right prefixes back in the Proxy Binding Acknowledgement based 734 on a) the content of the associated binding cache entry (if 735 exits), b) the profile (if static allocation is used), or c) 736 dynamic assignment. 738 5.1.3.2. Delegating Router co-located with Local Mobility Anchor 740 A DHCPv6 Relay Agent function running on the mobile access gateway 741 will forward the DHCP messages to the local mobility anchor which has 742 the co-located Delegating Router function. The Requesting Router and 743 the Delegating Router complete the DHCP messages related to prefix 744 delegation. 746 During the DHCPv6 exchange, the standard DHCPv6 considerations apply 747 with respect to the interactions between the Delegating Router, 748 DHCPv6 Relay Agent and the Requesting Router. 750 The mobile access gateway learns from the co-located DHCPv6 Relay 751 Agent the prefixes allocated by the Delegating Router. The way in 752 which the mobile access gateway learns obtains this information from 753 the DHCPv6 Relay Agent function is beyond the scope of this document. 755 The mobile access gateway will apply the considerations in 756 Section 5.1.2 for requesting the local mobility anchor to enable 757 delegated prefix support. The mobile access gateway will include 758 exactly one instance of the Delegated Mobile Network Prefix option 759 with NON_ZERO prefix value for each of the mobile network prefixes 760 that the mobile access gateway is requesting the local mobility 761 anchor to allocate. The prefix value(s) in the option will be the 762 prefix(es) obtained via DHCP prefix delegation. 764 The mobile access gateway, upon successfully completing the Proxy 765 Binding Update signaling with the local mobility anchor, will provide 766 the obtained prefixes to the DHCPv6 Relay Agent for prefix 767 assignment. The Delegating Router is provided with the delegated 768 prefix(es) completing the standard DHCPv6 signaling. These prefixes 769 can then be then advertised in the mobile network, and therefore used 770 by the locally fixed nodes to auto configure IP addresses allowing to 771 gain access to the Internet. 773 o In case the Proxy Binding Update signaling with the local mobility 774 anchor is not completed successfully, for example because the 775 local mobility anchor is not authorized for delegated mobile 776 network prefix, the requested prefix is in use, or the delegated 777 prefix(es) do not match the ones allocated by DHCP prefix 778 delegation, the DHCPv6 Relay Agent MAY send a Reply message to the 779 Requesting Router with no IA_PREFIX suboptions and with a Status 780 Code option as described in [RFC3633], section 11.2. 782 In case the mobile router performs a handover and attaches to a 783 different mobile access gateway, the following cases are possible: 785 o The new mobile access gateway does not support the delegation of 786 mobile network prefixes described in this specification. In this 787 case, forwarding of the previously delegated mobile network 788 prefixes is no longer performed. 790 o The new mobile access gateway supports the delegation of mobile 791 network prefixes described in this specification. There are two 792 possible cases upon the reception of the SOLICIT message by the 793 DHCPv6 Relay Agent. If the MAG already knows the delegated mobile 794 network prefixes, it conveys them in a DMNP option included in the 795 Proxy Binding Update sent to the local mobility anchor, which then 796 authorizes them based on: a) the content of the associated binding 797 cache entry (if exists), b) the user profile (if the allocation is 798 static), or, c) checking that the delegated mobile network 799 prefixes are not already allocated. On the other hand, if the 800 mobile access gateway is not aware of the delegated mobile network 801 prefixes, it will include 0.0.0.0 / ::0 in a DMNP option included 802 in the Proxy Binding Update sent to the LMA, which will provide 803 the right prefixes back in the Proxy Binding Acknowledgement based 804 on a) the content of the associated binding cache entry (if 805 exits), b) the profile (if static allocation is used), or c) 806 dynamic assignment. 808 5.1.4. Packet Forwarding 810 On receiving an IP packet from a mobile router, the mobile access 811 gateway before tunneling the packet to the local mobility anchor MUST 812 ensure that there is an established binding for the mobile router and 813 the source IP address of the packet is a prefix delegated to that 814 mobile router. If the source address of the received IP packet is 815 not part of the delegated mobile network prefix, then the mobile 816 access gateway MUST NOT tunnel the packet to the local mobility 817 anchor. 819 On receiving an IP packet from the bi-directional tunnel established 820 with the local mobility anchor, the mobile access gateway MUST first 821 decapsulate the packet (removing the outer header) and then use the 822 destination address of the (inner) packet to forward it on the 823 interface through which the mobile router is reachable. 825 The above forwarding considerations are not applicable to the IP 826 traffic sent/received to/from the mobile router's home address (IPv4 827 HOA/HNP). For the mobile router's home address traffic, forwarding 828 considerations from [RFC5213] and [RFC5844] continue to apply. 830 5.2. LMA Considerations 832 5.2.1. Extensions to Binding Cache Entry Data Structure 834 In order to support this specification, the conceptual Binding Cache 835 Entry (BCE) data structure [RFC5213] needs to be extended to include 836 the delegated mobile network prefix (DMNP) list. Each entry in the 837 list represents a delegated mobile network prefix. 839 5.2.2. Signaling Considerations 841 If the Proxy Binding Update message does not include any Delegated 842 Mobile Network Prefix option(s) (Section 4.1), then the local 843 mobility anchor MUST NOT enable Delegated Prefix support for the 844 mobility session, and the Proxy Binding Acknowledgment message that 845 is sent in response MUST NOT contain any Delegated Mobile Network 846 Prefix option(s). 848 If the Proxy Binding Update message includes one or more Delegated 849 Mobile Network Prefix options, but the local mobility anchor is not 850 configured with Delegated Prefix support, then the local mobility 851 anchor will ignore the option(s) and process the rest of the option 852 as specified in [RFC5213]. This would have no effect on the 853 operation of the rest of the protocol. The Proxy Binding 854 Acknowledgement message that is sent in response will not include any 855 Delegated Mobile Network Prefix option(s). 857 If the Proxy Binding Update message has the Delegated Mobile Network 858 Prefix option(s) and if the local mobility anchor is configured for 859 Delegated Prefix support, then the local mobility anchor MUST enable 860 Delegated Mobile Network Prefix option for that mobility session. 861 The Proxy Binding Acknowledgement message that is sent in response 862 MUST include the Delegated Mobile Network Prefix option(s). The 863 following considerations apply. 865 o If there is at least one instance of the Delegated Mobile Network 866 Prefix option with a ALL_ZERO [RFC5213] prefix value, then this 867 serves as a request for the local mobility anchor to perform the 868 assignment of one or more delegated mobile network prefixes. 870 * A Delegated Mobile Network option with ALL_ZERO value and with 871 the (V) flag set to a value of (0), is a request for the local 872 mobility anchor to allocate one or more IPv6 prefixes. 874 * A Delegated Mobile Network option with ALL_ZERO value and with 875 the (V) flag set to a value of (1), is a request for the local 876 mobility anchor to allocate one or more IPv4 prefixes. 878 * Inclusion of multiple instances of Delegated Mobile Network 879 options with ALL_ZERO value, one with the (V) flag set to a 880 value of (1), and another instance with the (V) flag set to a 881 value of (0) is a request to allocate both IPv4 and IPv6 882 prefixes. 884 o If there are no instances of the Delegated Mobile Network Prefix 885 option present in the request with ALL_ZERO value, but has a 886 specific prefix value, then this serves as a request for the local 887 mobility anchor to perform the allocation of the requested 888 prefix(es). 890 * If any one of the requested prefixes are assigned to some other 891 mobility node, or not from an authorized pool that the local 892 mobility can allocate for that mobility session, then the Proxy 893 Binding Update MUST be rejected by sending a Proxy Binding 894 Acknowledgement message with Status field set to 895 REQUESTED_DMNP_IN_USE (Requested delegated mobile network 896 prefix is in use). 898 Upon accepting the Proxy Binding Update, the local mobility anchor 899 MUST send a Proxy Binding Acknowledgement message with the Status 900 field set to 0 (Proxy Binding Update accepted). 902 o The message MUST include one instance of the Delegated Mobile 903 Network Prefix option for each of the allocated IPv4/IPv6 904 delegated mobile network prefixes. 906 o The delegated mobile network prefix (DMNP) list in the mobile 907 router's Binding Cache entry has to be updated with the allocated 908 prefix(es). However, if the request is a de-registration request 909 with a lifetime value of (0), the delegated mobile network prefix 910 list has to be removed along with the Binding Cache entry. 912 o A route (or a platform-specific equivalent function that sets up 913 the forwarding) for each of the allocated prefixes over the tunnel 914 has to be added. However, if the request is a de-registration 915 request, with a lifetime value of (0), all the IPv4/IPv6 delegated 916 prefix routes created for that session have to be removed. 918 5.2.3. Packet Forwarding 920 The local mobility anchor MUST advertise a connected route into the 921 routing infrastructure for the IP prefixes delegated to all of the 922 mobile routers that it is serving. This step essentially enables the 923 local mobility anchor to be a routing anchor for those IP prefixes 924 and be able to intercept IP packets sent to those mobile networks. 926 On receiving a packet from a correspondent node with the destination 927 address matching any of the mobile router's delegated mobile network 928 prefixes, the local mobility anchor MUST forward the packet through 929 the bi-directional tunnel set up with the mobile access gateway where 930 the mobile router is attached. 932 On receiving an IP packet from the bi-directional tunnel established 933 with the mobile access gateway, the local mobility anchor MUST first 934 decapsulate the packet (removing the outer header) and then use the 935 destination address of the (inner) packet for forwarding decision. 936 The local mobility anchor MUST ensure that there is an established 937 binding for the mobile router and the source IP address of the packet 938 is a prefix delegated to a mobile router reachable over that bi- 939 directional tunnel. 941 The above forwarding considerations are not applicable to the IP 942 traffic sent/received to/from the mobile router's home address (IPv4 943 HOA/HNP). For the mobile router's home address traffic, forwarding 944 considerations from [RFC5213] and [RFC5844] continue to apply. 946 5.3. Security Policy Database (SPD) Example Entries 948 The use of DHCPv6, as described in this document, requires message 949 integrity protection and source authentication. The IPsec security 950 mechanism used by Proxy Mobile IPv6 [RFC5213] for securing the 951 signaling messages between the mobile access gateway and the local 952 mobility anchor can be used for securing the DHCP signaling between 953 the mobile access gateway and the local mobility anchor. 955 The Security Policy Database (SPD) and Security Association Database 956 (SAD) entries necessary to protect the DHCP signaling is specified 957 below. The format of these entries is based on [RFC4877] 958 conventions. The SPD and SAD entries are only example 959 configurations. A particular implementation of mobile access gateway 960 and local mobility anchor implementation can configure different SPD 961 and SAD entries as long as they provide the required security for 962 protecting DHCP signaling messages. 964 For the examples described in this document, a mobile access gateway 965 with address "mag_address_1", and a local mobility anchor with 966 address "lma_address_1" are assumed. 968 mobile access gateway SPD-S: 969 - IF local_address = mag_address_1 & 970 remote_address = lma_address_1 & proto = UDP & 971 local_port = any & remote_port = DHCP 972 Then use SA1 (OUT) and SA2 (IN) 974 mobile access gateway SAD: 975 - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): 976 local_address = mag_address_1 & 977 remote_address = lma_address_1 & 978 proto = UDP & remote_port = DHCP 979 - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): 980 local_address = lma_address_1 & 981 remote_address = mag_address_1 & 982 proto = UDP & local_port = DHCP 984 local mobility anchor SPD-S: 985 - IF local_address = lma_address_1 & 986 remote_address = mag_address_1 & proto = UDP & 987 local_port = DHCP & remote_port = any 988 Then use SA2 (OUT) and SA1 (IN) 990 local mobility anchor SAD: 991 - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): 992 local_address = lma_address_1 & 993 remote_address = mag_address_1 & 994 proto = UDP & local_port = DHCP 995 - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): 996 local_address = mag_address_1 & 997 remote_address = lma_address_1 & 998 proto = UDP & remote_port = DHCP 1000 6. Security Considerations 1002 The Delegated Mobile Network Prefix Option defined in this 1003 specification is for use in Proxy Binding Update and Proxy Binding 1004 Acknowledgement messages. This option is carried like any other 1005 mobility header option as specified in [RFC5213]. Therefore, it 1006 inherits from [RFC5213] its security guidelines and does not require 1007 any additional security considerations. 1009 The use of DHCPv6 in this specification is as defined in DHCPv6 base 1010 specification [RFC3315] and DHCPv6 Prefix Delegation specifications 1011 [RFC3633]. The security considerations specified in those 1012 specifications apply to this document. 1014 If IPsec is used, the IPsec security association that is used for 1015 protecting the Proxy Binding Update and Proxy Binding 1016 Acknowledgement, also needs to be used for protecting the DHCPv6 1017 signaling between the mobile access gateway and the local mobility 1018 anchor. Considerations specified in Section 5.3 identify the 1019 extensions to security policy entries [RFC4301] 1021 7. IANA Considerations 1023 This document requires the following IANA actions. 1025 o Action-1: This specification defines a new Mobility Header option, 1026 Delegated Mobile Network Prefix option. This mobility option is 1027 described in Section 4.1. The type value for this 1028 message needs to be allocated from the Mobility Options registry 1029 at http://www.iana.org/assignments/mobility-parameters. RFC 1030 Editor: Please replace in Section 4.1 with the assigned 1031 value, and update this section accordingly. 1033 o Action-2: This document also defines two new status code values 1034 for use in the Proxy Binding Acknowledgement message, as described 1035 in Section 4.2. These status codes are, 1036 NOT_AUTHORIZED_FOR_DELEGATED_MNP (Not Authorized for delegated 1037 mobile network prefix) with a status code value of , and 1038 REQUESTED_DMNP_IN_USE (Requested delegated mobile network prefix 1039 is in use) with a status code value of . These values 1040 have to be assigned from the same number space as allocated for 1041 other status codes [RFC6275] and update this section accordingly. 1043 8. Acknowledgments 1045 The authors would like to acknowledge Ryuji Wakikawa, Alexandru 1046 Petrescu, Behcet Sarikaya, Seil Jeon, Basavaraj Patil, Brian Haberman 1047 and Michal Hoeft for all the discussions and reviews of this draft. 1049 The work of Carlos J. Bernardos has also been partially supported by 1050 the European Community's Seventh Framework Programme (FP7-ICT-2009-5) 1051 under grant agreement n. 258053 (MEDIEVAL project) and by the 1052 Ministry of Science and Innovation of Spain under the QUARTET project 1053 (TIN2009-13992-C02-01). 1055 9. References 1056 9.1. Normative References 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, March 1997. 1061 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1062 and M. Carney, "Dynamic Host Configuration Protocol for 1063 IPv6 (DHCPv6)", RFC 3315, July 2003. 1065 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1066 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1067 December 2003. 1069 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1070 Internet Protocol", RFC 4301, December 2005. 1072 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 1073 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 1074 August 2006. 1076 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1077 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1078 April 2007. 1080 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1081 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1083 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1084 Mobile IPv6", RFC 5844, May 2010. 1086 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1087 in IPv6", RFC 6275, July 2011. 1089 [RFC6276] Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. 1090 Bernardos, "DHCPv6 Prefix Delegation for Network Mobility 1091 (NEMO)", RFC 6276, July 2011. 1093 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1094 "Prefix Exclude Option for DHCPv6-based Prefix 1095 Delegation", RFC 6603, May 2012. 1097 9.2. Informative References 1099 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1100 Terminology", RFC 4885, July 2007. 1102 [RFC6656] Johnson, R., Kinnear, K., and M. Stapp, "Description of 1103 Cisco Systems' Subnet Allocation Option for DHCPv4", 1104 RFC 6656, July 2012. 1106 Authors' Addresses 1108 Xingyue Zhou 1109 ZTE Corporation 1110 No.50 Software Avenue, Yuhuatai District 1111 Nanjing 1112 China 1114 Phone: +86-25-8801-4634 1115 Email: zhou.xingyue@zte.com.cn 1117 Jouni Korhonen 1118 Broadcom 1119 Porkkalankatu 24 1120 Helsinki FIN-00180 1121 Finland 1123 Email: jouni.nospam@gmail.com 1125 Carl Williams 1126 Consultant 1127 San Jose, CA 1128 USA 1130 Email: carlw@mcsr-labs.org 1132 Sri Gundavelli 1133 Cisco 1134 170 West Tasman Drive 1135 San Jose, CA 95134 1136 USA 1138 Email: sgundave@cisco.com 1139 Carlos J. Bernardos 1140 Universidad Carlos III de Madrid 1141 Av. Universidad, 30 1142 Leganes, Madrid 28911 1143 Spain 1145 Phone: +34 91624 6236 1146 Email: cjbc@it.uc3m.es 1147 URI: http://www.it.uc3m.es/cjbc/