draft-ietf-dmm-mag-multihoming-01.txt   draft-ietf-dmm-mag-multihoming-02.txt 
DMM WG P. Seite DMM WG P. Seite
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track A. Yegin Intended status: Standards Track A. Yegin
Expires: September 3, 2016 Samsung Expires: January 26, 2017 Samsung
S. Gundavelli S. Gundavelli
Cisco Cisco
March 2, 2016 July 25, 2016
MAG Multipath Binding Option MAG Multipath Binding Option
draft-ietf-dmm-mag-multihoming-01.txt draft-ietf-dmm-mag-multihoming-02.txt
Abstract Abstract
The document [RFC4908] proposes to rely on multiple Care-of Addresses The document [RFC4908] proposes to rely on multiple Care-of Addresses
(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO; (CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO;
[RFC3963]) to enable Multihoming technology for Small-Scale Fixed [RFC3963]) to enable Multihoming technology for Small-Scale Fixed
Networks. In the continuation of [RFC4908], this document specifies Networks. In the continuation of [RFC4908], this document specifies
a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile
IPv6 [RFC5213]. This extension allows a multihomed Mobile Access IPv6 [RFC5213]. This extension allows a multihomed Mobile Access
Gateway (MAG) to register more than one proxy care-of-address to the Gateway (MAG) to register more than one proxy care-of-address to the
Local Mobility Anchor (LMA). Local Mobility Anchor (LMA).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2016. This Internet-Draft will expire on January 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 6 3.2. Traffic distribution schemes . . . . . . . . . . . . . . 6
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 7 4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . 7
4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9 4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9
4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Using several links, the multihoming technology can improve Using several links, the multihoming technology can improve
connectivity availability and quality of communications; the goals connectivity availability and quality of communications; the goals
and benefits of multihoming are as follows: and benefits of multihoming are as follows:
o Redundancy/Fault-Recovery o Redundancy/Fault-Recovery
o Load balancing o Load balancing
o Load sharing o Load sharing
o Preferences settings o Preferences settings
According to [RFC4908], users of Small-Scale Networks can take According to [RFC4908], users of Small-Scale Networks can take
benefit of multihoming using mobile IP [RFC6275] and Network Mobility benefit of multihoming using mobile IP [RFC6275] and Network Mobility
(NEMO) [RFC3963] architecture in a mobile and fixed networking (NEMO) [RFC3963] architecture in a mobile and fixed networking
environment. This document was introducing the concept of multiple environment. This document is introducing the concept of multiple
Care-of Addresses (CoAs) [RFC5648] that have been specified since Care-of Addresses (CoAs) [RFC5648] that have been specified since
then. then.
In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based
multihomed achitecture could be defined. The motivation to update multihomed achitecture could be defined. The motivation to update
[RFC4908] with proxy Mobile IPv6 is to leverage on latest mobility [RFC4908] with proxy Mobile IPv6 is to leverage on latest mobility
working group achievments, namely: working group achievments, namely:
o using GRE as mobile tuneling, possibly with its key extension o using GRE as mobile tuneling, possibly with its key extension
[RFC5845] (a possible reason to use GRE is given on Section 3.2). [RFC5845] (a possible reason to use GRE is given on Section 3.2).
skipping to change at page 4, line 29 skipping to change at page 4, line 25
.---| | | | (_ _) .---| | | | (_ _)
| .-| | / | | '----' | .-| | / | | '----'
| | +=====+ / +=====+ | | +=====+ / +=====+
| | | _----_ / | | | _----_ /
| | | CoA-2 _( )_ Tunnel-2 / | | | CoA-2 _( )_ Tunnel-2 /
| | .---=======( WLAN )========/ Flow-2 | | .---=======( WLAN )========/ Flow-2
| | (_ _) Flow-3 | | (_ _) Flow-3
| | '----' Flow-4 | | '----' Flow-4
|Flow-3 |Flow-3
| |
Flow0=-4 Flow0-4
Figure 1: Multihomed MAG using Proxy Mobile IPv6 Figure 1: Multihomed MAG using Proxy Mobile IPv6
Current version of Proxy Mobile IPv6 does not allow a MAG to register The current version of Proxy Mobile IPv6 does not allow a MAG to
more than one proxy Care-of-Adresse to the LMA. In other words, only register more than one proxy Care-of-Adresse to the LMA. In other
one MAG/LMA link, i.e. IP-in-IP tunnel, tunnel can be used at the words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at
same time. This document overcome this limitation by defining the the same time. This document overcomes this limitation by defining
multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile the multiple proxy Care-of Addresses (pCoAs) extension for Proxy
IPv6. Mobile IPv6.
2. Conventions and Terminology 2. Conventions and Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
skipping to change at page 5, line 13 skipping to change at page 5, line 4
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
All mobility related terms used in this document are to be All mobility related terms used in this document are to be
interpreted as defined in [RFC5213], [RFC5844] and [RFC7148]. interpreted as defined in [RFC5213], [RFC5844] and [RFC7148].
Additionally, this document uses the following terms: Additionally, this document uses the following terms:
IP-in-IP IP-in-IP
IP-within-IP encapsulation [RFC2473], [RFC4213] IP-within-IP encapsulation [RFC2473], [RFC4213]
3. Overview 3. Overview
3.1. Example Call Flow 3.1. Example Call Flow
Figure 2 is the callflow detailing multi-access support with PMIPv6. Figure 2 is the callflow detailing multi-access support with PMIPv6.
The MAG in this example scenario is equipped with both WLAN and LTE The MAG in this example scenario is equipped with both WLAN and LTE
interfaces and is also configured with the MAG functionality. A interfaces and is also configured with the multihoming functionality.
logical-NAI with ALWAYS-ON configuration is enabled on the MAG. The The steps of the callflow are as follows:
mobility session that is created on the LMA is for the logical-NAI.
The IP hosts MN_1 and MN_2 are assigned IP addresses from the
delegated mobile network prefix.
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+ Steps (1) and (2): the MAG attaches to both WLAN and LTE networks;
| MN_1| | MN_2| | MAG | | WLAN| | LTE | | LMA | the MAG obtains respectively two different proxy care-of-addresses
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+ (pCoA).
| | | | | |
| | | | | | Step (3): The MAG sends, over the WLAN access, a Proxy Binding Update
| | | (1) ATTACH | | | (PBU) message, with the new MAG Multipath Binding (MMB) and MAG
| | | <--------> | | | Identifier (MAG-NAI) options to the LMA. A logical-NAI (MAG-NAI)
| | | (2) ATTACH | | with ALWAYS-ON configuration is enabled on the MAG. The mobility
| | | <---------------------->| | session that is created (i.e. create a Binding Cache Entry) on the
| | | (3) PBU (NAI, MAG-NAI, DMNP, MMB) | LMA is for the logical-NAI. The LMA and allocates a Home Network
| | | ------------------------*----------> | Prefix (HNP), that shall be delegated to mobile nodes, to the MAG.
| | | (4) PBA (NAI, DMNP) |
| | | <-----------------------*----------- | Step (4): the LMA sends back a Proxy Binding Acknowledgement (PBA)
| | | (5) TUNNEL INTERFACE CREATION | including the HNP allocated to the MAG.
| | |-============== TUNNEL ==*===========-|
| | | | Step (5): IP tunnel (IP-in-IP, GRE ...) is created over the WLAN
| | | (6) PBU (NAI, MAG-NAI, DMNP, MMB) | access.
| | | -----------*-----------------------> |
| | | (7) PBA (NAI, DMNP) | Steps (6) to (8): The MAG repeats steps (3) to (5) on the LTE access.
| | | <----------*------------------------ | The MAG includes the HNP, received on step (4) in the PBU. The LMA
| | | (8) TUNNEL INTERFACE CREATION | update its binding cache by creating a new mobility session for this
| | |-===========*== TUNNEL ==============-| MAG.
| (9) | |
| <------------------> | | Steps (9) and (10): The IP hosts MN_1 and MN_2 are assigned IP
| | (10) | | addresses from the mobile network prefix delegated by the MAG.
| |<-----------> | |
+=====+ +=====+ +=====+ +=====+ +=====+ +=====+
| 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 (MAG-NAI, HNP) |
| | | <-----------------------*---------------|
| | | (5) TUNNEL INTERFACE CREATION over WLAN |
| | |-============== TUNNEL ==*==============-|
| | | |
| | | (6) PBU (MAG-NAI, HNP, MMB) |
| | | -----------*--------------------------->|
| | | |
| | | Accept PBU
| | | (update BCE)
| | | (7) PBA (MAG-NAI, HNP) |
| | | <----------*--------------------------- |
| | | (8) TUNNEL INTERFACE CREATION over LTE |
| | |-===========*== TUNNEL =================-|
| (9) ATTACH | |
| <---------------> | |
| |(10) ATTACH| |
| |<--------> | |
Figure 2: Functional Separation of the Control and User Plane Figure 2: Functional Separation of the Control and User Plane
3.2. Traffic distribution schemes 3.2. Traffic distribution schemes
Once tunnels are established, traffic distribution can be managed When receiving packets from the MN, the MAG distributes packets over
either on a per-flow or on a per-packet basis: tunnels that have been established. Traffic distribution can be
managed either on a per-flow or on a per-packet basis:
o Per-flow traffic management: each IP flow (both upstream and o Per-flow traffic management: each IP flow (both upstream and
downstream) is mapped to a given tunnel, corresponding to a given downstream) is mapped to a given tunnel, corresponding to a given
WAN interface. Flow binding extension [RFC6089] is used to WAN interface. Flow binding extension [RFC6089] is used to
exchange, and synchronize, IP flow management policies (i.e. rules exchange, and synchronize, IP flow management policies (i.e. rules
associating traffic selectors [RFC6088] to a tunnel). associating traffic selectors [RFC6088] to a tunnel).
o Per-packet management: the LMA and the MAG distribute packets, o Per-packet management: the LMA and the MAG distribute packets,
belonging to a same IP flow, over more than one bindings (i.e. belonging to a same IP flow, over more than one bindings (i.e.
more than one WAN interface). When operating at the packet level, more than one WAN interface). When operating at the IP packet
traffic distribution scheme introduces packet latency and out-of- level, different packets distribution algorithms are possible.
order delivery. Sequence number can be added, to tunneled For example, the algorithm may give precedence to one given
packets, to allow LMA and MAG making reordering before packets access: the MAG overflows traffic from the primary access, e.g.
delivery. For that purpose, GRE with sequence number option WLAN, to the second one, only when load on primary access reaches
a given threshold. The distribution algorithm is left to
[RFC5845] can be used as tunneling mechanism. More detailed implementer but whatever the algorithm is, packets distribution
considerations (e.g. definition of control algorithm) on Per- likely introduces packet latency and out-of-order delivery. LMA
packet distribution scheme is out the scope of this document. and MAG shall thus be able to make reordering before packets
delivery. Sequence number can be can be used for that purpose,
for example using GRE with sequence number option [RFC5845].
However, more detailed considerations on reordering and IP packet
distribution scheme (e.g. definition of packets distribution
algorithm) are out the scope of this document.
Because latency introduced by per-packet can cause injury to some Because latency introduced by per-packet can cause injury to some
application, per-flow and per-packet distribution schemes could be application, per-flow and per-packet distribution schemes could be
used in conjunction. For example, high throughput services (e.g. used in conjunction. For example, high throughput services (e.g.
video streaming) may benefit from per-packet distribution scheme, video streaming) may benefit from per-packet distribution scheme,
while latency sensitive applications (e.g. VoIP) are not be spread while latency sensitive applications (e.g. VoIP) are not be spread
over different WAN paths. over different WAN paths. IP flow mobility extensions, [RFC6089] and
[RFC6088], can be used to provision the MAG with such flow policies.
4. Protocol Extensions 4. Protocol Extensions
4.1. MAG Multipath-Binding Option 4.1. MAG Multipath-Binding Option
The MAG Multipath-Binding option is a new mobility header option The MAG Multipath-Binding option is a new mobility header option
defined for use with Proxy Binding Update and Proxy Binding defined for use with Proxy Binding Update and Proxy Binding
Acknowledgement messages exchanged between the local mobility anchor Acknowledgement messages exchanged between the local mobility anchor
and the mobile access gateway. and the mobile access gateway.
skipping to change at page 8, line 4 skipping to change at page 8, line 20
| Binding-Id |B|O| RESERVED | | Binding-Id |B|O| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MAG Multipath Binding Option Figure 3: MAG Multipath Binding Option
Type Type
<IANA-1> To be assigned by IANA. <IANA-1> To be assigned by IANA.
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. octets, excluding the type and length fields.
This 8-bit field identifies the Access-Technology type of the Interface Access-Technology Type (If-ATT)
interface through which the mobile node is connected. The permitted
values for this are from the Access Technology Type registry defined
in [RFC5213].
This 8-bit field represents the interface label represented as an This 8-bit field identifies the Access-Technology type of the
unsigned integer. The mobile node identifies the label for each of interface through which the mobile node is connected. The
the interfaces through which it registers a CoA with the home agent. permitted values for this are from the Access Technology Type
When using static traffic flow policies on the mobile node and the registry defined in [RFC5213].
home agent, the label can be used for generating forwarding policies.
For example, the operator may have policy which binds traffic for
Application "X" needs to interface with Label "Y". When a
registration through an interface matching Label "Y" gets activated,
the home agent and the mobile node can dynamically generate a
forwarding policy for forwarding traffic for Application "X" through
mobile IP tunnel matching Label "Y". Both the home agent and the
mobile node can route the Application-X traffic through that
interface. The permitted values for If-Label are 1 through 255.
This 8-bit field is used for carrying the binding identifier. It Interface Label (If-Label)
uniquely identifies a specific binding of the mobile node, to which
this request can be associated. Each binding identifier is
represented as an unsigned integer. The permitted values are 1
through 254. The BID value of 0 and 255 are reserved. The mobile
access gateway assigns a unique value for each of its interfaces and
includes them in the message.
This flag, if set to a value of (1), is to notify the local mobility This 8-bit field represents the interface label represented as an
anchor to consider this request as a request to update the binding unsigned integer. The MAG identifies the label for each of the
lifetime of all the mobile node's bindings, upon accepting this interfaces through which it registers a pCoA with the LMA. When
specific request. This flag MUST NOT be set to a value of (1), if using static traffic flow policies on the mobile node and the home
the value of the Registration Overwrite Flag (O) flag is set to a agent, the label can be used for generating forwarding policies.
value of (1). For example, the operator may have policy which binds traffic for
Application "X" needs to interface with Label "Y". When a
registration through an interface matching Label "Y" gets
activated, the home agent and the mobile node can dynamically
generate a forwarding policy for forwarding traffic for
Application "X" through mobile IP tunnel matching Label "Y". Both
the home agent and the mobile node can route the Application-X
traffic through that interface. The permitted values for If-Label
are 1 through 255.
This flag, if set to a value of (1), notifies the local mobility Binding-Identifier (BID)
anchor that upon accepting this request, it should replace all of the
mobile node's existing bindings with this binding. This flag MUST This 8-bit field is used for carrying the binding identifier. It
NOT be set to a value of (1), if the value of the Bulk Re- uniquely identifies a specific binding of the mobile node, to
registration Flag (B) is set to a value of (1). This flag MUST be which this request can be associated. Each binding identifier is
set to a value of (0), in de-registration requests. represented as an unsigned integer. The permitted values are 1
through 254. The BID value of 0 and 255 are reserved. The mobile
access gateway assigns a unique value for each of its interfaces
and includes them in the message.
Bulk Re-registration Flag (B)
This flag, if set to a value of (1), is to notify the local
mobility anchor to consider this request as a request to update
the binding lifetime of all the mobile node's bindings, upon
accepting this specific request. This flag MUST NOT be set to a
value of (1), if the value of the Registration Overwrite Flag (O)
is set to a value of (1).
Binding Overwrite (O)
This flag, if set to a value of (1), notifies the local mobility
anchor 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 Reserved
This field is unused in this specification. The value MUST be set 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. to zero (0) by the sender and MUST be ignored by the receiver.
4.2. MAG Identifier Option 4.2. MAG Identifier Option
The MAG Identifier option is a new mobility header option defined for The MAG Identifier option is a new mobility header option defined for
use with Proxy Binding Update and Proxy Binding Acknowledgement use with Proxy Binding Update and Proxy Binding Acknowledgement
skipping to change at page 10, line 33 skipping to change at page 11, line 10
assigned value and update this section accordingly. assigned value and update this section accordingly.
o Action-2: This specification defines a new mobility option, the o Action-2: This specification defines a new mobility option, the
MAG Identifier option. The format of this option is described in MAG Identifier option. The format of this option is described in
Section 4.2. The type value <IANA-2> for this mobility option Section 4.2. The type value <IANA-2> for this mobility option
needs to be allocated from the Mobility Options registry at needs to be allocated from the Mobility Options registry at
<http://www.iana.org/assignments/mobility-parameters>. RFC <http://www.iana.org/assignments/mobility-parameters>. RFC
Editor: Please replace <IANA-2> in Section 4.2 with the assigned Editor: Please replace <IANA-2> in Section 4.2 with the assigned
value and update this section accordingly. value and update this section accordingly.
o Action-4: This document defines a new status value, o Action-3: This document defines a new status value,
CANNOT_SUPPORT_MULTIPATH_BINDING (<IANA-4>) for use in Proxy CANNOT_SUPPORT_MULTIPATH_BINDING (<IANA-3>) for use in Proxy
Binding Acknowledgement message, as described in Section 4.3. Binding Acknowledgement message, as described in Section 4.3.
This value is to be assigned from the "Status Codes" registry at This value is to be assigned from the "Status Codes" registry at
<http://www.iana.org/assignments/mobility-parameters>. The <http://www.iana.org/assignments/mobility-parameters>. The
allocated value has to be greater than 127. RFC Editor: Please allocated value has to be greater than 127. RFC Editor: Please
replace <IANA-4> in Section 4.3 with the assigned value and update replace <IANA-4> in Section 4.3 with the assigned value and update
this section accordingly. this section accordingly.
6. Security Considerations 6. Security Considerations
This specification allows a mobile access gateway to establish This specification allows a mobile access gateway to establish
skipping to change at page 11, line 21 skipping to change at page 11, line 45
7. Acknowledgements 7. Acknowledgements
The authors of this draft would like to acknowledge the discussions The authors of this draft would like to acknowledge the discussions
and feedback on this topic from the members of the DMM working group. and feedback on this topic from the members of the DMM working group.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005, RFC 3963, DOI 10.17487/RFC3963, January 2005,
<http://www.rfc-editor.org/info/rfc3963>. <http://www.rfc-editor.org/info/rfc3963>.
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094,
December 2007, <http://www.rfc-editor.org/info/rfc5094>. December 2007, <http://www.rfc-editor.org/info/rfc5094>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>. <http://www.rfc-editor.org/info/rfc5213>.
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
T., and K. Nagami, "Multiple Care-of Addresses T., and K. Nagami, "Multiple Care-of Addresses
Registration", RFC 5648, DOI 10.17487/RFC5648, Registration", RFC 5648, DOI 10.17487/RFC5648, October
October 2009, <http://www.rfc-editor.org/info/rfc5648>. 2009, <http://www.rfc-editor.org/info/rfc5648>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
<http://www.rfc-editor.org/info/rfc5844>. <http://www.rfc-editor.org/info/rfc5844>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy "Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
<http://www.rfc-editor.org/info/rfc5845>. <http://www.rfc-editor.org/info/rfc5845>.
skipping to change at page 12, line 19 skipping to change at page 12, line 45
DOI 10.17487/RFC6088, January 2011, DOI 10.17487/RFC6088, January 2011,
<http://www.rfc-editor.org/info/rfc6088>. <http://www.rfc-editor.org/info/rfc6088>.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089, Network Mobility (NEMO) Basic Support", RFC 6089,
DOI 10.17487/RFC6089, January 2011, DOI 10.17487/RFC6089, January 2011,
<http://www.rfc-editor.org/info/rfc6089>. <http://www.rfc-editor.org/info/rfc6089>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
July 2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and [RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile
IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014,
<http://www.rfc-editor.org/info/rfc7148>. <http://www.rfc-editor.org/info/rfc7148>.
8.2. Informative References 8.2. Informative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/ for IPv6 Hosts and Routers", RFC 4213,
RFC4213, October 2005, DOI 10.17487/RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>. <http://www.rfc-editor.org/info/rfc4213>.
[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,
R., and H. Ohnishi, "Multi-homing for small scale fixed R., and H. Ohnishi, "Multi-homing for small scale fixed
network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/ network Using Mobile IP and NEMO", RFC 4908,
RFC4908, June 2007, DOI 10.17487/RFC4908, June 2007,
<http://www.rfc-editor.org/info/rfc4908>. <http://www.rfc-editor.org/info/rfc4908>.
Authors' Addresses Authors' Addresses
Pierrick Seite Pierrick Seite
Orange Orange
4, rue du Clos Courtel, BP 91226 4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512 Cesson-Sevigne 35512
France France
 End of changes. 27 change blocks. 
123 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/