idnits 2.17.1 draft-ietf-dmm-mag-multihoming-06.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 (September 25, 2017) is 2405 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM WG P. Seite 3 Internet-Draft Orange 4 Intended status: Standards Track A. Yegin 5 Expires: March 29, 2018 Actility 6 S. Gundavelli 7 Cisco 8 September 25, 2017 10 MAG Multipath Binding Option 11 draft-ietf-dmm-mag-multihoming-06.txt 13 Abstract 15 This specification defines extensions to the Proxy Mobile IPv6 16 protocol for allowing a mobile access gateway to register more than 17 one proxy care-of-address with the local mobility anchor and to 18 simultaneously establish multiple IP tunnels with the local mobility 19 anchor. This capability allows the mobile access gateway to utilize 20 all the available access networks for routing mobile node's IP 21 traffic. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 29, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 59 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 7 64 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 8 66 4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10 67 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11 68 4.4. Signaling Considerations . . . . . . . . . . . . . . . . . 11 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Multihoming support on IP hosts can greatly improve the user 80 experience. With the simultaneoous use of multiple access networks, 81 multihoming brings better network connectivity, reliability and 82 improved quality of communication. Following are some of the goals 83 and benefits of multihoming support: 85 o Redundancy/Fault-Recovery 87 o Load balancing 89 o Load sharing 91 o Preferences settings 93 According to [RFC4908], users of Small-Scale Networks can take 94 benefit of multihoming using mobile IP [RFC6275] and Network Mobility 95 (NEMO) [RFC3963] architecture in a mobile and fixed networking 96 environment. This document is introducing the concept of multiple 97 Care-of Addresses (CoAs) [RFC5648] that have been specified since 98 then. 100 The motivation for this work is to extend Proxy Mobile IPv6 protocol 101 with multihoming extensions [RFC4908] for realizing the following 102 capabilities: 104 o using GRE as mobile tuneling, possibly with its key extension 105 [RFC5845] (a possible reason to use GRE is given on Section 3.2). 107 o using UDP encapsulation [RFC5844] in order to support NAT 108 traversal in IPv4 networking environment. 110 o Prefix Delegation mechanism [RFC7148]. 112 o Using the vendor specific mobility option [RFC5094], for example 113 to allow the MAG and LMA to exchange information (e.g. WAN 114 interface QoS metrics) allowing to make appropriate traffic 115 steering decision. 117 Proxy Mobile IPv6 (PMIPv6) relies on two mobility entities: the 118 mobile access gateway (MAG), which acts as the default gateway for 119 the end-node and the local mobility anchor (LMA), which acts as the 120 topological anchor point. Point-to-point links are established, 121 using IP-in-IP tunnels, between MAG and LMA. Then, the MAG and LMA 122 are distributing traffic over these tunnels. All PMIPv6 operations 123 are performed on behalf of the end-node and its corespondent node, it 124 thus makes PMIPv6 well adapted to multihomed architecture as 125 considered in [RFC4908]. Taking the LTE and WLAN networking 126 environments as an example, the PMIPv6 based multihomed architecture 127 is depicted on Figure 1. Flow-1,2 and 3 are distributed either on 128 Tunnel-1 (over LTE) or Tunnel-2 (over WLAN), while Flow-4 is spread 129 on both Tunnel-1 and 2. 131 Flow-1 132 | 133 |Flow-2 _----_ 134 | | CoA-1 _( )_ Tunnel-1 135 | | .---=======( LTE )========\ Flow-1 136 | | | (_ _) \Flow-4 137 | | | '----' \ 138 | | +=====+ \ +=====+ _----_ 139 | '-| | \ | | _( )_ 140 '---| MAG | | LMA |-( Internet )-- 141 .---| | | | (_ _) 142 | .-| | / | | '----' 143 | | +=====+ / +=====+ 144 | | | _----_ / 145 | | | CoA-2 _( )_ Tunnel-2 / 146 | | .---=======( WLAN )========/ Flow-2 147 | | (_ _) Flow-3 148 | | '----' 149 |Flow-3 150 | 151 Flow0-4 153 Figure 1: Multihomed MAG using Proxy Mobile IPv6 155 The current version of Proxy Mobile IPv6 does not allow a MAG to 156 register more than one proxy Care-of-Adresse to the LMA. In other 157 words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at 158 the same time. This document overcomes this limitation by defining 159 the multiple proxy Care-of Addresses (pCoAs) extension for Proxy 160 Mobile IPv6. 162 2. Conventions and Terminology 163 2.1. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 2.2. Terminology 171 All mobility related terms used in this document are to be 172 interpreted as defined in [RFC5213], [RFC5844] and [RFC7148]. 173 Additionally, this document uses the following terms: 175 IP-in-IP 177 IP-within-IP encapsulation [RFC2473], [RFC4213] 179 3. Overview 181 3.1. Example Call Flow 183 Figure 2 is the callflow detailing multi-access support with PMIPv6. 184 The MAG in this example scenario is equipped with both WLAN and LTE 185 interfaces and is also configured with the multihoming functionality. 186 The steps of the callflow are as follows: 188 Steps (1) and (2): the MAG attaches to both WLAN and LTE networks; 189 the MAG obtains respectively two different proxy care-of-addresses 190 (pCoA). 192 Step (3): The MAG sends, over the WLAN access, a Proxy Binding Update 193 (PBU) message, with the new MAG Multipath Binding (MMB) and MAG 194 Identifier (MAG-NAI) options to the LMA. The request can be for a 195 physical mobile node attached to the MAG, or for a logical mobile 196 node configured on the mobile node. A logical mobile node is ALWAYS- 197 ATTACHED mobile node configuration enabled on the MAG. The mobility 198 session that is created (i.e. create a Binding Cache Entry) on the 199 LMA will be marked with multipath support. 201 Step (4): the LMA sends back a Proxy Binding Acknowledgement (PBA) 202 including the HNP and other session parameters allocated for that 203 mobility session. 205 Step (5): IP tunnel (IP-in-IP, GRE ...) is created over the WLAN 206 access. 208 Steps (6) to (8): The MAG repeats steps (3) to (5) on the LTE access. 209 The MAG includes the HNP, received on step (4) in the PBU. The LMA 210 update its binding cache by creating a new mobility session for this 211 MAG. 213 Steps (9) and (10): The IP hosts MN_1 and MN_2 are assigned IP 214 addresses from the mobile network prefix delegated by the MAG. 216 +=====+ +=====+ +=====+ +=====+ +=====+ +=====+ 217 | MN_1| | MN_2| | MAG | | WLAN| | LTE | | LMA | 218 +=====+ +=====+ +=====+ +=====+ +=====+ +=====+ 219 | | | | | | 220 | | | | | | 221 | | | (1) ATTACH | | | 222 | | | <--------> | | | 223 | | | (2) ATTACH | | 224 | | | <---------------------->| | 225 | | | (3) PBU (MAG-NAI, MMB, ...) | 226 | | | ------------------------*-------------->| 227 | | | | 228 | | | Accept PBU 229 | | | (allocate HNP, 230 | | | create BCE) 231 | | | (4) PBA (MMB, ...) | 232 | | | <-----------------------*---------------| 233 | | | (5) TUNNEL INTERFACE CREATION over WLAN | 234 | | |-============== TUNNEL ==*==============-| 235 | | | | 236 | | | (6) PBU (MAG-NAI, MMB, ...) | 237 | | | -----------*--------------------------->| 238 | | | | 239 | | | Accept PBU 240 | | | (update BCE) 241 | | | (7) PBA (MAG-NAI, MMB, ...) | 242 | | | <----------*--------------------------- | 243 | | | (8) TUNNEL INTERFACE CREATION over LTE | 244 | | |-===========*== TUNNEL =================-| 245 | (9) ATTACH | | 246 | <---------------> | | 247 | |(10) ATTACH| | 248 | |<--------> | | 250 Figure 2: Functional Separation of the Control and User Plane 252 3.2. Traffic distribution schemes 254 When the MAG has registered multipath binding with the LMA, there 255 will be multiple established overlay tunnels between them. The MAG 256 and the LMA can use any one, or more of the available tunnels paths 257 for routing the mobile node's IP traffic. This specification does 258 not recommend, or define any specific traffic distribution scheme, 259 however it identifies two well-known approaches that implementations 260 can potentially use. These approaches are, Per-flow and Per-packet 261 Traffic distribution schemes. 263 Per-Flow Traffic Distribution: 265 o In this approach the MAG and the LMA associate each of the IP 266 flows (upstream and downstream) to a specific tunnel path. The 267 packets in a given IP flow are always routed on the same overlay 268 tunnel path; they are never split and routed concurrently on more 269 than one tunnel path. It is possible a given flow may be moved 270 from one tunnel path to another, but the flow is never split. The 271 decision to bind a given IP flow to a specific tunnel path is 272 based on traffic distribution policy. This traffic distribution 273 policy is either statically configured on both the MAG and the 274 LMA, or dynamically negotiated over Proxy Mobile IPv6 signaling. 275 The Flow Binding extension [RFC6089] and Traffic Selectors for 276 Flow Bindings [RFC6088] defines the mechanism and the semantics 277 for exchanging the traffic policy between two tunnel peers and the 278 same mechanism and the mobility options are used here. 280 Per-Packet Traffic Distribution: 282 o In this approach, packets belonging a given IP flow will be split 283 and routed across more than one tunnel paths. The exact approach 284 for traffic distribution, or the distribution weights is outside 285 the scope of this specification. In a very simplistic approach, 286 assuming the established tunnel paths have symmetric 287 characteristics, the packets can be equally distributed on all the 288 available tunnel paths. In a different scenario when the links 289 have different speeds, the chosen approach can be based on 290 weighted distribution (Ex: n:m ratio). However, in any of these 291 chosen approaches, implementations have to be sensitive to issues 292 related to asymmetric link characteristics and the resulting 293 issues such as re-ordering, buffering and the impact to the 294 application performance. Care must be taken to ensure there is no 295 negative impact to the application performance due to the use of 296 this approach. 298 4. Protocol Extensions 300 4.1. MAG Multipath-Binding Option 302 The MAG Multipath-Binding option is a new mobility header option 303 defined for use with Proxy Binding Update and Proxy Binding 304 Acknowledgement messages exchanged between the local mobility anchor 305 and the mobile access gateway. 307 This mobility header option is used for requesting multipath support. 308 It indicates that the mobile access gateway is requesting the local 309 mobility anchor to register the current care-of address associated 310 with the request as one of the many care-addresses through which the 311 mobile access gateway can be reached. It is also for carrying the 312 information related to the access network associated with the care-of 313 address. 315 The MAG Multipath-Binding option has an alignment requirement of 316 8n+2. Its format is as shown in Figure 3: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | If-ATT | If-Label | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Binding-Id |B|O| RESERVED | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 3: MAG Multipath Binding Option 328 Type 330 To be assigned by IANA. 332 Length 334 8-bit unsigned integer indicating the length of the option in 335 octets, excluding the type and length fields. 337 Interface Access-Technology Type (If-ATT) 339 This 8-bit field identifies the Access-Technology type of the 340 interface through which the mobile node is connected. The 341 permitted values for this are from the Access Technology Type 342 registry defined in [RFC5213]. 344 Interface Label (If-Label) 345 This 8-bit unsigned integer represents the interface label. 347 The interface label is an identifier configured on the WAN 348 interface of the MAG. All the WAN interfaces of the MAG that are 349 used for sending PBU messages are configured with a label. The 350 labels merely identify the type of WAN interface and are primarily 351 used in Application routing policies. For example, a Wi-Fi 352 interfaces can be configured with a label RED and a LTE interface 353 with a label BLUE. Furthermore, the same label may be configured 354 on two WAN interfaces of similar characteristics (Ex: Two Ethernet 355 interfaces with the same label). 357 Interfaces labels are signaled from the MAG to LMA in the PBU 358 messages and both the LMA and MAG will be able to mark each of the 359 dynamically created Binding/Tunnel with the associated label. 360 These labels are used in generating consistent application routing 361 rules on the both the LMA and the MAG. For example, there can be 362 a policy requiring HTTP packets to be routed over interface that 363 has Label RED, and if any of the RED interfaces are not available, 364 the traffic needs to be routed over the BLUE interface. The MAG 365 and the LMA will be able to apply this Routing Rule with the 366 exchange of Labels in PBU messages and by associating the 367 application flows to tunnels with the matching labels. 369 Binding-Identifier (BID) 371 This 8-bit unsigned integer is used for identifying the binding. 372 The permitted values are 1 through 254. The values, 0 and 255 are 373 reserved. 375 The MAG identifies each of the mobile node's binding with a unique 376 identifier. The MAG includes the identifier in the PBU message 377 and when the PBU request is accepted by the LMA, the resulting 378 Binding is associated with this binding identifier. 380 Bulk Re-registration Flag (B) 382 This flag, if set to a value of (1), is to notify the local 383 mobility anchor to consider this request as a request to update 384 the binding lifetime of all the mobile node's bindings, upon 385 accepting this specific request. This flag MUST NOT be set to a 386 value of (1), if the value of the Registration Overwrite Flag (O) 387 is set to a value of (1). 389 Binding Overwrite (O) 391 This flag, if set to a value of (1), notifies the local mobility 392 anchor that upon accepting this request, it should replace all of 393 the mobile node's existing bindings with this binding. This flag 394 MUST NOT be set to a value of (1), if the value of the Bulk Re- 395 registration Flag (B) is set to a value of (1). This flag MUST be 396 set to a value of (0), in de-registration requests. 398 Reserved 400 This field is unused in this specification. The value MUST be set 401 to zero (0) by the sender and MUST be ignored by the receiver. 403 4.2. MAG Identifier Option 405 The MAG Identifier option is a new mobility header option defined for 406 use with Proxy Binding Update and Proxy Binding Acknowledgement 407 messages exchanged between the local mobility anchor and the mobile 408 access gateway. This mobility header option is used for conveying 409 the MAG's identity. 411 This option does not have any alignment requirements. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Subtype | Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Identifier ... ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: MAG Identifier Option 423 Type 425 To be assigned by IANA. 427 Length 429 8-bit unsigned integer indicating the length of the option in 430 octets, excluding the type and length fields. 432 Subtype 434 One byte unsigned integer used for identifying the type of the 435 Identifier field. Accepted values for this field are the 436 registered type values from the Mobile Node Identifier Option 437 Subtypes registry. 439 Reserved 440 This field is unused in this specification. The value MUST be set 441 to zero (0) by the sender and MUST be ignored by the receiver. 443 Identifier 445 A variable length identifier of type indicated in the Subtype 446 field. 448 4.3. New Status Code for Proxy Binding Acknowledgement 450 This document defines the following new Status Code value for use in 451 Proxy Binding Acknowledgement message. 453 The LMA SHOULD use this error code when rejecting a Proxy Binding 454 Update message from a MAG requesting a multipath binding. Following 455 is the potential reason for rejecting the request: 457 o The LMA does not support multipath binding. 459 CANNOT_SUPPORT_MULTIPATH_BINDING (Cannot Support Multipath Binding): 460 462 4.4. Signaling Considerations 464 o The MAG when requesting multipath support MUST include the MAG 465 Multipath Binding Option (Section 4.1) in each of the PBU messages 466 that it sends through the different WAN interfaces. The inclusion 467 of this option serves as a hint that the MAG is requesting 468 Multipath support. Furthermore, the MAG Identifier option MUST 469 also be present in the PBU message. 471 o If the MAG is aware that the LMA supports the multipath feature 472 defined in this specification and if it chooses to enable multiple 473 path feature, then it can send the PBU packets for each of the 474 paths, either sequentially, or concurrently. However, if the MAG 475 is not aware of the LMA capability, then it should first discover 476 the LMA capability by sending PBU packets with multipath on only 477 one path first. This will ensure the LMA will not be over-writing 478 the binding of one path with the other path. 480 o If the LMA supports multipath capability as defined in this 481 specification and if it enables the same for a mobile node's' 482 session per the MAG's request, then the LMA MUST include the 483 Multipath Binding Option (Section 4.1), without the MAG NAI Option 484 Section 4.2 in the corresponding PBA reply. 486 o If the LMA is a legacy LMA that does not support this 487 specification, the LMA will skip the MAG Multipath Binding option 488 (and MAG NAI option) and process the rest of the message as 489 specified in the base Proxy Mobile IPv6 specification ([RFC5213]). 490 Furthermore, the LMA will not include the MAG Multipath Binding 491 option (or the MAG NAI Option)in the PBA message. The MAG on 492 receiving the PBA message without the MAG Multipath Binding option 493 SHOULD disable Multipath support for the mobile node. 495 o If the mobile node is not authorized for Multipath support, then 496 the LMA will reject the request by sending a PBA message with the 497 Status field value set to CANNOT_SUPPORT_MULTIPATH_BINDING 498 (Section 4.3). The LMA will echo the MAG Multipath Binding option 499 and the MAG NAI option in the PBA message. The MAG on receiving 500 this message SHOULD disable Multipath support for the mobile node. 502 o If the request for multipath support is accepted, then the LMA 503 SHOULD enable multipath support for the mobile node and SHOULD 504 also echo the MAG Multipath Binding option and the MAG NAI option 505 in the corresponding PBA message. 507 5. IANA Considerations 509 This document requires the following IANA actions. 511 o Action-1: This specification defines a new mobility option, the 512 MAG Multipath-Binding option. The format of this option is 513 described in Section 4.1. The type value for this 514 mobility option needs to be allocated from the Mobility Options 515 registry at . 516 RFC Editor: Please replace in Section 4.1 with the 517 assigned value and update this section accordingly. 519 o Action-2: This specification defines a new mobility option, the 520 MAG Identifier option. The format of this option is described in 521 Section 4.2. The type value for this mobility option 522 needs to be allocated from the Mobility Options registry at 523 . RFC 524 Editor: Please replace in Section 4.2 with the assigned 525 value and update this section accordingly. 527 o Action-3: This document defines a new status value, 528 CANNOT_SUPPORT_MULTIPATH_BINDING () for use in Proxy 529 Binding Acknowledgement message, as described in Section 4.3. 530 This value is to be assigned from the "Status Codes" registry at 531 . The 532 allocated value has to be greater than 127. RFC Editor: Please 533 replace in Section 4.3 with the assigned value and update 534 this section accordingly. 536 6. Security Considerations 538 This specification allows a mobile access gateway to establish 539 multiple Proxy Mobile IPv6 tunnels with a local mobility anchor, by 540 registering a care-of address for each of its connected access 541 networks. This essentially allows the mobile node's IP traffic to be 542 routed through any of the tunnel paths based on the negotiated flow 543 policy. This new capability has no impact on the protocol security. 544 Furthermore, this specification defines two new mobility header 545 options, MAG Multipath-Binding option and the MAG Identifier option. 546 These options are carried like any other mobility header option as 547 specified in [RFC5213]. Therefore, it inherits security guidelines 548 from [RFC5213]. Thus, this specification does not weaken the 549 security of Proxy Mobile IPv6 Protocol, and does not introduce any 550 new security vulnerabilities. 552 7. Acknowledgements 554 The authors of this draft would like to acknowledge the discussions 555 and feedback on this topic from the members of the DMM working group. 556 The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee, 557 Dirk Von-Hugo, Seil Jeon, Carlos Bernardos, Robert Sparks, Adam 558 Roach, Kathleen Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari, 559 for their review feedback. Special thanks to Mirja Kuehlewind for a 560 very thorugh review and suggesting many text improvements. 562 8. References 564 8.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 568 RFC2119, March 1997, 569 . 571 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 572 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 573 RFC 3963, DOI 10.17487/RFC3963, January 2005, 574 . 576 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 577 Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, 578 December 2007, . 580 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 581 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 582 RFC 5213, DOI 10.17487/RFC5213, August 2008, 583 . 585 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 586 T., and K. Nagami, "Multiple Care-of Addresses 587 Registration", RFC 5648, DOI 10.17487/RFC5648, 588 October 2009, . 590 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 591 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 592 . 594 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 595 "Generic Routing Encapsulation (GRE) Key Option for Proxy 596 Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, 597 . 599 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 600 "Traffic Selectors for Flow Bindings", RFC 6088, 601 DOI 10.17487/RFC6088, January 2011, 602 . 604 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 605 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 606 Network Mobility (NEMO) Basic Support", RFC 6089, 607 DOI 10.17487/RFC6089, January 2011, 608 . 610 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 611 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, 612 July 2011, . 614 [RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and 615 CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile 616 IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, 617 . 619 8.2. Informative References 621 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 622 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 623 December 1998, . 625 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 626 for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/ 627 RFC4213, October 2005, 628 . 630 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 631 R., and H. Ohnishi, "Multi-homing for small scale fixed 632 network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/ 633 RFC4908, June 2007, 634 . 636 Authors' Addresses 638 Pierrick Seite 639 Orange 640 4, rue du Clos Courtel, BP 91226 641 Cesson-Sevigne 35512 642 France 644 Email: pierrick.seite@orange.com 646 Alper Yegin 647 Actility 648 Turkey 650 Email: alper.yegin@actility.com 652 Sri Gundavelli 653 Cisco 654 170 West Tasman Drive 655 San Jose, CA 95134 656 USA 658 Email: sgundave@cisco.com