idnits 2.17.1 draft-ietf-dmm-mag-multihoming-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 : ---------------------------------------------------------------------------- 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 6, 2017) is 2423 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 10, 2018 Actility 6 S. Gundavelli 7 Cisco 8 September 6, 2017 10 MAG Multipath Binding Option 11 draft-ietf-dmm-mag-multihoming-05.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 10, 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 . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 (MAG-NAI, 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 LMA is a legacy LMA that does not support this 472 specification, the LMA will skip the MAG Multipath Binding option 473 (and MAG NAI option) and process the rest of the message as 474 specified in the base Proxy Mobile IPv6 specification ([RFC5213]). 475 Furthermore, the LMA will not include the MAG Multipath Binding 476 option (or the MAG NAI Option)in the PBA message. The MAG on 477 receiving the PBA message without the MAG Multipath Binding option 478 SHOULD disable Multipath support for the mobile node. 480 o If the mobile node is not authorized for Multipath support, then 481 the LMA will reject the request by sending a PBA message with the 482 Status field value set to CANNOT_SUPPORT_MULTIPATH_BINDING 483 (Section 4.3). The LMA will echo the MAG Multipath Binding option 484 and the MAG NAI option in the PBA message. The MAG on receiving 485 this message SHOULD disable Multipath support for the mobile node. 487 o If the request for multipath support is accepted, then the LMA 488 SHOULD enable multipath support for the mobile node and SHOULD 489 also echo the MAG Multipath Binding option and the MAG NAI option 490 in the corresponding PBA message. 492 5. IANA Considerations 494 This document requires the following IANA actions. 496 o Action-1: This specification defines a new mobility option, the 497 MAG Multipath-Binding option. The format of this option is 498 described in Section 4.1. The type value for this 499 mobility option needs to be allocated from the Mobility Options 500 registry at . 501 RFC Editor: Please replace in Section 4.1 with the 502 assigned value and update this section accordingly. 504 o Action-2: This specification defines a new mobility option, the 505 MAG Identifier option. The format of this option is described in 506 Section 4.2. The type value for this mobility option 507 needs to be allocated from the Mobility Options registry at 508 . RFC 509 Editor: Please replace in Section 4.2 with the assigned 510 value and update this section accordingly. 512 o Action-3: This document defines a new status value, 513 CANNOT_SUPPORT_MULTIPATH_BINDING () for use in Proxy 514 Binding Acknowledgement message, as described in Section 4.3. 515 This value is to be assigned from the "Status Codes" registry at 516 . The 517 allocated value has to be greater than 127. RFC Editor: Please 518 replace in Section 4.3 with the assigned value and update 519 this section accordingly. 521 6. Security Considerations 523 This specification allows a mobile access gateway to establish 524 multiple Proxy Mobile IPv6 tunnels with a local mobility anchor, by 525 registering a care-of address for each of its connected access 526 networks. This essentially allows the mobile node's IP traffic to be 527 routed through any of the tunnel paths based on the negotiated flow 528 policy. This new capability has no impact on the protocol security. 529 Furthermore, this specification defines two new mobility header 530 options, MAG Multipath-Binding option and the MAG Identifier option. 531 These options are carried like any other mobility header option as 532 specified in [RFC5213]. Therefore, it inherits security guidelines 533 from [RFC5213]. Thus, this specification does not weaken the 534 security of Proxy Mobile IPv6 Protocol, and does not introduce any 535 new security vulnerabilities. 537 7. Acknowledgements 539 The authors of this draft would like to acknowledge the discussions 540 and feedback on this topic from the members of the DMM working group. 541 The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee, 542 Dirk Von-Hugo, Seil Jeon, Carlos Bernardos, Robert Sparks, Adam 543 Roach, Kathleen Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari, 544 Mirja Kuehlewind, for their review feedback. 546 8. References 548 8.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 552 RFC2119, March 1997, 553 . 555 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 556 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 557 RFC 3963, DOI 10.17487/RFC3963, January 2005, 558 . 560 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 561 Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, 562 December 2007, . 564 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 565 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 566 RFC 5213, DOI 10.17487/RFC5213, August 2008, 567 . 569 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 570 T., and K. Nagami, "Multiple Care-of Addresses 571 Registration", RFC 5648, DOI 10.17487/RFC5648, 572 October 2009, . 574 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 575 Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, 576 . 578 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 579 "Generic Routing Encapsulation (GRE) Key Option for Proxy 580 Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, 581 . 583 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 584 "Traffic Selectors for Flow Bindings", RFC 6088, 585 DOI 10.17487/RFC6088, January 2011, 586 . 588 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 589 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 590 Network Mobility (NEMO) Basic Support", RFC 6089, 591 DOI 10.17487/RFC6089, January 2011, 592 . 594 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 595 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, 596 July 2011, . 598 [RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and 599 CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile 600 IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, 601 . 603 8.2. Informative References 605 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 606 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 607 December 1998, . 609 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 610 for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/ 611 RFC4213, October 2005, 612 . 614 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 615 R., and H. Ohnishi, "Multi-homing for small scale fixed 616 network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/ 617 RFC4908, June 2007, 618 . 620 Authors' Addresses 622 Pierrick Seite 623 Orange 624 4, rue du Clos Courtel, BP 91226 625 Cesson-Sevigne 35512 626 France 628 Email: pierrick.seite@orange.com 630 Alper Yegin 631 Actility 632 Turkey 634 Email: alper.yegin@actility.com 636 Sri Gundavelli 637 Cisco 638 170 West Tasman Drive 639 San Jose, CA 95134 640 USA 642 Email: sgundave@cisco.com