diff options
Diffstat (limited to 'doc/rfc/rfc8278.txt')
| -rw-r--r-- | doc/rfc/rfc8278.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8278.txt b/doc/rfc/rfc8278.txt new file mode 100644 index 0000000..3aabe4b --- /dev/null +++ b/doc/rfc/rfc8278.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Seite +Request for Comments: 8278 Orange +Category: Standards Track A. Yegin +ISSN: 2070-1721 Actility + S. Gundavelli + Cisco + January 2018 + + + Mobile Access Gateway (MAG) Multipath Options + +Abstract + + This specification defines extensions to the Proxy Mobile IPv6 + (PMIPv6) protocol that allow a mobile access gateway (MAG) to + register more than one proxy care-of address (pCoA) with the local + mobility anchor (LMA) and to simultaneously establish multiple IP + tunnels with the LMA. This capability allows the MAG to utilize all + the available access networks to route the mobile node's IP traffic. + This document defines the following two new mobility header options: + the MAG Multipath Binding option and the MAG Identifier option. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8278. + + + + + + + + + + + + + + + + +Seite, et al. Standards Track [Page 1] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 + 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Traffic Distribution Schemes . . . . . . . . . . . . . . 6 + 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. MAG Multipath Binding Option . . . . . . . . . . . . . . 7 + 4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10 + 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11 + 4.4. Signaling Considerations . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + + + + + + + + + +Seite, et al. Standards Track [Page 2] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +1. Introduction + + Multihoming support on IP hosts can greatly improve the user + experience. With the simultaneous use of multiple access networks, + multihoming brings better network connectivity, reliability, and + improved quality of communication. The following are some of the + goals and benefits of multihoming support: + + o Redundancy/Fault-Recovery + + o Load balancing + + o Load sharing + + o Preference settings + + According to [RFC4908], users of small-scale networks can benefit + from a mobile and fixed multihomed architecture using mobile IP + [RFC6275] and Network Mobility (NEMO) [RFC3963]. + + The motivation for this work is to extend the PMIPv6 protocol with + multihoming extensions [RFC4908] for realizing the following + capabilities: + + o Using GRE as mobile tunneling, possibly with its key extension + [RFC5845]. + + o Using UDP encapsulation [RFC5844] in order to support NAT + traversal in an IPv4 networking environment. + + o Using the prefix delegation mechanism [RFC7148]. + + o Using the Vendor Specific Mobility Option [RFC5094], for example, + to allow the MAG and LMA to exchange information (e.g., WAN + interface QoS metrics), which allows the appropriate traffic- + steering decisions to be made. + + PMIPv6 relies on two mobility entities: the MAG, which acts as the + default gateway for the end node (either a mobile or a fixed node) + attached to the MAG's access links, and the LMA, which acts as the + topological anchor point. IP tunnel is created with any one of the + supported encapsulation mode between the MAG and the LMA. Then, the + MAG and LMA distribute the end node's traffic over these tunnels. + All PMIPv6 operations are performed on behalf of the end node and its + correspondent node. Thus, it makes PMIPv6 well adapted to multihomed + architecture as considered in [RFC4908]. Taking the LTE and WLAN + networking environments as examples, the PMIPv6-based multihomed + architecture is depicted in Figure 1. In this example, IP flows, + + + +Seite, et al. Standards Track [Page 3] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + Flow-1 and Flow-3 are routed over Tunnel-1 and Flow-2 is routed over + Tunnel-2. However, IP traffic belonging to Flow-4 is distributed on + both Tunnel-1 and Tunnel-2 paths. + + Flow-1 + | + |Flow-2 _----_ + | | CoA-1 _( )_ Tunnel-1 Flow-1 + | | .---=======( LTE )========\ Flow-3 + | | | (_ _) \ Flow-4 + | | | '----' \ + | | +=====+ \ +=====+ _----_ + | '-| | \ | | _( )_ + '---| MAG | | LMA |-( Internet )-- + .---| | | | (_ _) + | .-| | / | | '----' + | | +=====+ / +=====+ + | | | _----_ / + | | | CoA-2 _( )_ Tunnel-2 / + | | .---=======( WLAN )========/ Flow-2 + | | (_ _) Flow-4 + | | '----' + |Flow-3 + | + Flow0-4 + + Figure 1: Multihomed MAG Using Proxy Mobile IPv6 + + The current version of PMIPv6 does not allow a MAG to register more + than one pCoA to the LMA. In other words, only one MAG/LMA link, + i.e., IP-in-IP tunnel, can be used at the same time. This document + overcomes this limitation by defining the multiple pCoAs extension + for PMIPv6. + +2. Conventions and Terminology + +2.1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + + + + + + + +Seite, et al. Standards Track [Page 4] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +2.2. Terminology + + All mobility-related terms used in this document are to be + interpreted as defined in [RFC5213], [RFC5844], and [RFC7148]. + Additionally, this document uses the following term: + + IP-in-IP + + IP-within-IP encapsulation [RFC2473] [RFC4213] + +3. Overview + +3.1. Example Call Flow + + Figure 2 is the call flow detailing multi-access support with PMIPv6. + The MAG in this example scenario is equipped with both WLAN and LTE + interfaces and is also configured with the multihoming functionality. + The steps of the call flow are as follows: + + Steps (1) and (2): The MAG attaches to both WLAN and LTE networks. + Then, the MAG obtains two different pCoAs, respectfully. + + Step (3): The MAG sends, over the LTE access, a Proxy Binding Update + (PBU) message with the new MAG Multipath Binding (MMB) and MAG + Network Access Identifier (MAG-NAI) options to the LMA. The request + can be for a physical mobile node attached to the MAG or for a + logical mobile node configured on the mobile access gateway. A + logical mobile node is a logical representation of a mobile node in + the form of a configuration that is always enabled on the MAG. The + mobility session that is created (i.e., create a Binding Cache Entry + (BCE)) on the LMA will be marked with multipath support. + + Step (4): The LMA sends back a Proxy Binding Acknowledgement (PBA) + including the Home Network Prefix (HNP) and other session parameters + allocated for that mobility session. + + Step (5): IP tunnel is created between the MAG and the LMA over LTE + access with any one of the supported encapsulation modes. + + Steps (6) to (8): The MAG repeats steps (3) to (5) on the WLAN + access. The MAG includes the HNP, received on step (4) in the PBU. + The LMA updates its binding cache by creating a new mobility session + for this MAG. + + Steps (9) and (10): The IP hosts MN_1 and MN_2 are assigned IP + addresses from the mobile network prefix delegated to the MAG by the + LMA. + + + + +Seite, et al. Standards Track [Page 5] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + +=====+ +=====+ +=====+ +=====+ +=====+ +=====+ + | MN_1| | MN_2| | MAG | | WLAN| | LTE | | LMA | + +=====+ +=====+ +=====+ +=====+ +=====+ +=====+ + | | | | | | + | | | | | | + | | | (1) ATTACH | | | + | | | <--------> | | | + | | | (2) ATTACH | | + | | | <---------------------->| | + | | | (3) PBU (MAG-NAI, MMB, ...) | + | | | ------------------------*-------------->| + | | | | + | | | Accept PBU + | | | (allocate HNP, + | | | create BCE) + | | | (4) PBA (MMB, ...) | + | | | <-----------------------*---------------| + | | | (5) TUNNEL INTERFACE CREATION over LTE | + | | |-============== TUNNEL ==*==============-| + | | | | + | | | (6) PBU (MAG-NAI, MMB, ...) | + | | | -----------*--------------------------->| + | | | | + | | | Accept PBU + | | | (update BCE) + | | | (7) PBA (MMB, ...) | + | | | <----------*--------------------------- | + | | | (8) TUNNEL INTERFACE CREATION over WLAN | + | | |-===========*== TUNNEL =================-| + | (9) ATTACH | | + | <---------------> | | + | |(10) ATTACH| | + | |<--------> | | + + Figure 2: Functional Separation of the Control and User Planes + +3.2. Traffic Distribution Schemes + + When the MAG has registered a multipath binding with the LMA, there + will be multiple established overlay tunnels between them. The MAG + and the LMA can use any one, or more, of the available tunnel paths + for routing the mobile node's IP traffic. This specification does + not recommend or define any specific traffic distribution scheme. + However, it identifies two well-known approaches that implementations + can potentially use. These approaches are per-flow and per-packet + traffic distribution schemes. + + + + + +Seite, et al. Standards Track [Page 6] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + Per-Flow Traffic Distribution: + + o In this approach, the MAG and the LMA associate each of the IP + flows (upstream and downstream) with a specific tunnel path. The + packets in a given IP flow are always routed on the same overlay + tunnel path; they are never split and routed concurrently on more + than one tunnel path. It is possible for a given flow to be moved + from one tunnel path to another, but the flow is never split. The + decision to bind a given IP flow to a specific tunnel path is + based on the traffic distribution policy. This traffic + distribution policy is either statically configured on both the + MAG and the LMA or dynamically negotiated over PMIPv6 signaling. + The Flow Binding extension [RFC6089] and Traffic Selectors for + Flow Bindings [RFC6088] define the mechanism and the semantics for + exchanging the traffic policy between two tunnel peers; the same + mechanism and the mobility options are used here. + + Per-Packet Traffic Distribution: + + o In this approach, packets belonging to a given IP flow will be + split and routed across more than one tunnel path. The exact + approach for traffic distribution or the distribution weights is + outside the scope of this specification. In a very simplistic + approach, assuming that the established tunnel paths have + symmetric characteristics, the packets can be equally distributed + on all the available tunnel paths. In a different scenario, when + the links have different speeds, the chosen approach can be based + on weighted distribution (e.g., n:m ratio). However, in any of + these chosen approaches, implementations have to be sensitive to + issues related to asymmetric link characteristics and the + resulting issues such as reordering, buffering, and the impact on + application performance. Care must be taken to ensure that there + is no negative impact on the application performance due to the + use of this approach. + +4. Protocol Extensions + +4.1. MAG Multipath Binding Option + + The MAG Multipath Binding option is a new mobility header option + defined for use with PBU and PBA messages exchanged between the LMA + and the MAG. + + This mobility header option is used for requesting multipath support. + It indicates that the MAG is requesting that the LMA register the + current CoA associated with the request as one of the many CoAs + + + + + +Seite, et al. Standards Track [Page 7] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + through which the MAG can be reached. It is also used for carrying + the information related to the access network associated with the + CoA. + + The MAG Multipath Binding option does not have any alignment + requirement. Its format is as shown in Figure 3: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | If-ATT | If-Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Binding ID |B|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: MAG Multipath Binding Option + + Type + + Type: MAG Multipath Binding (63) + + Length + + 8-bit unsigned integer indicating the length of the option in + octets, excluding the Type and Length fields. + + Interface Access-Technology Type (If-ATT) + + This 8-bit field identifies the Access-Technology type of the + interface through which the mobile node is connected. The + permitted values for this are from the Access Technology Type + registry <https://www.iana.org/assignments/mobility-parameters/> + defined in [RFC5213]. + + Interface Label (If-Label) + + This 8-bit unsigned integer represents the interface label. + + The interface label is an identifier configured on the WAN + interface of the MAG. All the WAN interfaces of the MAG that are + used for sending PBU messages are configured with a label. The + labels merely identify the type of WAN interface and are primarily + used in application-routing policies. For example, a Wi-Fi + interface can be configured with a label "9" and an LTE interface + with a label "11". Furthermore, the same label may be configured + on two WAN interfaces of similar characteristics (e.g., two + Ethernet interfaces with the same label). + + + + +Seite, et al. Standards Track [Page 8] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + Interface labels are signaled from the MAG to the LMA in the PBU + messages and both the LMA and MAG will be able to mark each of the + dynamically created Binding/Tunnel with the associated label. + These labels are used in generating consistent application-routing + rules on the both the LMA and the MAG. For example, there can be + a policy requiring HTTP packets to be routed over an interface + that has the interface label of "9", and if any of the interfaces + with interface label "9" are not available, the traffic needs to + be routed over the interface with the interface label "11". The + MAG and the LMA will be able to apply this routing rule with the + exchange of interface labels in PBU messages and by associating + the application flows to tunnels with the matching interface + labels. + + Binding Identifier (BID) + + This 8-bit unsigned integer is used for identifying the binding. + The permitted values are 1 through 254. The values 0 and 255 are + reserved. + + The MAG identifies each of the mobile node's bindings with a + unique identifier. The MAG includes the identifier in the PBU + message; when the PBU request is accepted by the LMA, the + resulting binding is associated with this BID in the mobile node's + Binding Cache entry. + + Bulk Re-registration Flag (B) + + If set to a value of (1), this flag notifies the LMA to consider + this as a request to update the binding lifetime of all the mobile + node's bindings upon accepting this specific request. The (B) + flag MUST NOT be set to a value of (1) if the value of the + Registration Overwrite (O) flag is set to a value of (1). + + Registration Overwrite (O) + + This flag, if set to a value of (1), notifies the LMA that upon + accepting this request, it should replace all of the mobile node's + existing bindings with this binding. This flag MUST NOT be set to + a value of (1) if the value of the Bulk Re-registration Flag (B) + is set to a value of (1). This flag MUST be set to a value of (0) + in De-Registration requests. + + Reserved + + This field is unused in this specification. The value MUST be set + to zero (0) by the sender and MUST be ignored by the receiver. + + + + +Seite, et al. Standards Track [Page 9] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +4.2. MAG Identifier Option + + The MAG Identifier option is a new mobility header option defined for + use with PBU and PBA messages exchanged between the LMA and the MAG. + This mobility header option is used for conveying the MAG's identity. + + This option does not have any alignment requirements. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Subtype | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: MAG Identifier Option + + Type + + Type: MAG Identifier (64) + + Length + + 8-bit unsigned integer indicating the length of the option in + octets, excluding the Type and Length fields. + + Subtype + + One-byte unsigned integer used for identifying the type of the + Identifier field. Accepted values for this field are the + registered type values from the "Mobile Node Identifier Option + Subtypes" registry <https://www.iana.org/assignments/mobility- + parameters/>. + + Reserved + + This field is unused in this specification. The value MUST be set + to zero (0) by the sender and MUST be ignored by the receiver. + + Identifier + + A variable-length identifier of the type indicated in the Subtype + field. + + + + + + + +Seite, et al. Standards Track [Page 10] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +4.3. New Status Code for Proxy Binding Acknowledgement + + This document defines the following new Status Code value for use in + PBA messages. + + The LMA SHOULD use this error code when rejecting a PBU message from + a MAG requesting a multipath binding. The following is the potential + reason for rejecting the request: + + o The LMA does not support multipath binding. + + CANNOT_SUPPORT_MULTIPATH_BINDING (Cannot Support Multipath Binding): + 180 + +4.4. Signaling Considerations + + o The MAG, when requesting multipath support, MUST include the MAG + Multipath Binding option (Section 4.1) in each of the PBU messages + that it sends through the different WAN interfaces. The inclusion + of this option serves as a hint that the MAG is requesting + multipath support. Furthermore, the MAG Identifier option MUST + also be present in the PBU message. + + o If the MAG is aware that the LMA supports the multipath binding + option defined in this specification and if it chooses to use + multiple paths, then it can send the PBU packets for each of the + paths, either sequentially or concurrently. However, if the MAG + is not aware of the LMA capability, then it SHOULD first discover + the LMA capability by sending PBU packets with multipath on only + one path first. This will ensure that the LMA will not be + overwriting the binding of one path with the other path. + + o If the LMA supports multipath capability as defined in this + specification and if it enables the same for a mobile node's + session per the MAG's request, then the LMA MUST include the + Multipath Binding option (Section 4.1) without the MAG-NAI option + (Section 4.2) in the corresponding PBA reply. + + o If the LMA is a legacy LMA that does not support this + specification, the LMA will skip the MAG Multipath Binding option + (and MAG-NAI option) and process the rest of the message as + specified in the base PMIPv6 specification ([RFC5213]). + Furthermore, the LMA will not include the MAG Multipath Binding + option (or the MAG-NAI option) in the PBA message. The MAG, upon + receiving the PBA message without the MAG Multipath Binding + option, SHOULD disable multipath support for the mobile node. + + + + + +Seite, et al. Standards Track [Page 11] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + o If the mobile node is not authorized for multipath support, then + the LMA will reject the request by sending a PBA message with the + Status field value set to CANNOT_SUPPORT_MULTIPATH_BINDING + (Section 4.3). The LMA MUST echo the MAG Multipath Binding option + (without the MAG-NAI option) in the PBA message. The MAG, upon + receiving this message, SHOULD disable multipath support for the + mobile node. + +5. IANA Considerations + + This specification defines a new mobility option: the MAG Multipath + Binding option. The format of this option is described in + Section 4.1. The type value 63 has been allocated for this mobility + option from the "Mobility Options" registry at + <http://www.iana.org/assignments/mobility-parameters>. + + This specification defines a new mobility option: the MAG Identifier + option. The format of this option is described in Section 4.2. The + type value 64 has been allocated for this mobility option from the + "Mobility Options" registry at <http://www.iana.org/assignments/ + mobility-parameters>. + + This document defines a new status value: + CANNOT_SUPPORT_MULTIPATH_BINDING (180) for use in PBA messages, as + described in Section 4.3. This value has been assigned from the + "Status Codes" registry at <http://www.iana.org/assignments/mobility- + parameters>. + +6. Security Considerations + + This specification allows a MAG to establish multiple PMIPv6 tunnels + with an LMA by registering a care-of address for each of its + connected access networks. This essentially allows the mobile node's + IP traffic to be routed through any of the tunnel paths based on the + negotiated flow policy. This new capability has no impact on the + protocol security. Furthermore, this specification defines two new + mobility header options: the MAG Multipath Binding option and the MAG + Identifier option. These options are carried like any other mobility + header option as specified in [RFC5213]. Therefore, it inherits + security guidelines from [RFC5213]. Thus, this specification does + not weaken the security of the PMIPv6 Protocol and does not introduce + any new security vulnerabilities. + + + + + + + + + +Seite, et al. Standards Track [Page 12] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. + Thubert, "Network Mobility (NEMO) Basic Support Protocol", + RFC 3963, DOI 10.17487/RFC3963, January 2005, + <https://www.rfc-editor.org/info/rfc3963>. + + [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 + Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, + December 2007, <https://www.rfc-editor.org/info/rfc5094>. + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", + RFC 5213, DOI 10.17487/RFC5213, August 2008, + <https://www.rfc-editor.org/info/rfc5213>. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, + <https://www.rfc-editor.org/info/rfc5844>. + + [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, + "Generic Routing Encapsulation (GRE) Key Option for Proxy + Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, + <https://www.rfc-editor.org/info/rfc5845>. + + [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, + "Traffic Selectors for Flow Bindings", RFC 6088, + DOI 10.17487/RFC6088, January 2011, + <https://www.rfc-editor.org/info/rfc6088>. + + [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., + and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and + Network Mobility (NEMO) Basic Support", RFC 6089, + DOI 10.17487/RFC6089, January 2011, + <https://www.rfc-editor.org/info/rfc6089>. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July + 2011, <https://www.rfc-editor.org/info/rfc6275>. + + + + + +Seite, et al. Standards Track [Page 13] + +RFC 8278 MAG Multipath Binding Options January 2018 + + + [RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and + CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile + IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, + <https://www.rfc-editor.org/info/rfc7148>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +7.2. Informative References + + [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, + December 1998, <https://www.rfc-editor.org/info/rfc2473>. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", RFC 4213, + DOI 10.17487/RFC4213, October 2005, + <https://www.rfc-editor.org/info/rfc4213>. + + [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, + R., and H. Ohnishi, "Multi-homing for small scale fixed + network Using Mobile IP and NEMO", RFC 4908, + DOI 10.17487/RFC4908, June 2007, + <https://www.rfc-editor.org/info/rfc4908>. + +Acknowledgements + + The authors of this document would like to acknowledge the + discussions and feedback on this topic from the members of the + Distributed Mobility Management Working Group. The authors would + also like to thank Jouni Korhonen, Jong Hyouk Lee, Dirk Von-Hugo, + Seil Jeon, Carlos Bernardos, Robert Sparks, Adam Roach, Kathleen + Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari, and Dhananjay + Patki for their review feedback. Special thanks to Mirja Kuehlewind + for a very thorough review and suggesting many text improvements. + + + + + + + + + + + + + + + +Seite, et al. Standards Track [Page 14] + +RFC 8278 MAG Multipath Binding Options January 2018 + + +Authors' Addresses + + Pierrick Seite + Orange + 4, rue du Clos Courtel, BP 91226 + Cesson-Sevigne 35512 + France + + Email: pierrick.seite@orange.com + + + Alper Yegin + Actility + Turkey + + Email: alper.yegin@actility.com + + + Sri Gundavelli + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + United States of America + + Email: sgundave@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Seite, et al. Standards Track [Page 15] + |