draft-ietf-dmm-pmipv6-dlif-02.txt   draft-ietf-dmm-pmipv6-dlif-03.txt 
DMM Working Group CJ. Bernardos DMM Working Group CJ. Bernardos
Internet-Draft A. de la Oliva Internet-Draft A. de la Oliva
Intended status: Standards Track UC3M Intended status: Standards Track UC3M
Expires: March 2, 2019 F. Giust Expires: April 23, 2019 F. Giust
Athonet Athonet
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
A. Mourad A. Mourad
InterDigital InterDigital
August 29, 2018 October 20, 2018
Proxy Mobile IPv6 extensions for Distributed Mobility Management Proxy Mobile IPv6 extensions for Distributed Mobility Management
draft-ietf-dmm-pmipv6-dlif-02 draft-ietf-dmm-pmipv6-dlif-03
Abstract Abstract
Distributed Mobility Management solutions allow for setting up Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does networks so that traffic is distributed in an optimal way and does
not rely on centrally deployed anchors to provide IP mobility not rely on centrally deployed anchors to provide IP mobility
support. support.
There are many different approaches to address Distributed Mobility There are many different approaches to address Distributed Mobility
Management, as for example extending network-based mobility protocols Management, as for example extending network-based mobility protocols
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 2, 2019. This Internet-Draft will expire on April 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5
3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7
3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8
3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11
3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12
3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13
3.6. The Distributed Logical Interface (DLIF) concept . . . . 12 3.6. The Distributed Logical Interface (DLIF) concept . . . . 13
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 16 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 17
4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 17 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 18
4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 18 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19
4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 19 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 20
4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 20 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 21
4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 21 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 22
4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 22 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 23
4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 22 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Comparison with Requirement document . . . . . . . . 25 Appendix A. Comparison with Requirement document . . . . . . . . 26
A.1. Distributed mobility management . . . . . . . . . . . . . 25 A.1. Distributed mobility management . . . . . . . . . . . . . 27
A.2. Bypassable network-layer mobility support for each A.2. Bypassable network-layer mobility support for each
application session . . . . . . . . . . . . . . . . . . . 26 application session . . . . . . . . . . . . . . . . . . . 27
A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 27
A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 28
A.5. Coexistence with deployed networks/hosts and operability A.5. Coexistence with deployed networks/hosts and operability
across different networks . . . . . . . . . . . . . . . . 27 across different networks . . . . . . . . . . . . . . . . 28
A.6. Operation and management considerations . . . . . . . . . 27 A.6. Operation and management considerations . . . . . . . . . 28
A.7. Security considerations . . . . . . . . . . . . . . . . . 27 A.7. Security considerations . . . . . . . . . . . . . . . . . 28
A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Implementation experience . . . . . . . . . . . . . 28 Appendix B. Implementation experience . . . . . . . . . . . . . 29
Appendix C. Applicability to the fog environment . . . . . . . . 29 Appendix C. Applicability to the fog environment . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The Distributed Mobility Management (DMM) paradigm aims at minimizing The Distributed Mobility Management (DMM) paradigm aims at minimizing
the impact of currently standardized mobility management solutions the impact of currently standardized mobility management solutions
which are centralized (at least to a considerable extent). which are centralized (at least to a considerable extent).
Current IP mobility solutions, standardized with the names of Mobile Current IP mobility solutions, standardized with the names of Mobile
IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite
the two most relevant examples, offer mobility support at the cost of the two most relevant examples, offer mobility support at the cost of
skipping to change at page 4, line 4 skipping to change at page 4, line 4
define finer granularity policies, as for example per-application). define finer granularity policies, as for example per-application).
The purpose of Distributed Mobility Management is to overcome the The purpose of Distributed Mobility Management is to overcome the
limitations of the traditional centralized mobility management limitations of the traditional centralized mobility management
[RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed
bringing the mobility anchor closer to the Mobile Node (MN). bringing the mobility anchor closer to the Mobile Node (MN).
Following this idea, in our proposal, the central anchor is moved to Following this idea, in our proposal, the central anchor is moved to
the edge of the network, being deployed in the default gateway of the the edge of the network, being deployed in the default gateway of the
mobile node. That is, the first elements that provide IP mobile node. That is, the first elements that provide IP
connectivity to a set of MNs are also the mobility managers for those connectivity to a set of MNs are also the mobility managers for those
MNs. In the following, we will call these entities Mobility Anchor MNs. In this document, we call these entities Mobility Anchors and
and Access Routers (MAARs). Access Routers (MAARs).
This document focuses on network-based DMM, hence the starting point This document focuses on network-based DMM, hence the starting point
is making PMIPv6 working in a distributed manner [RFC7429]. Mobility is making PMIPv6 working in a distributed manner [RFC7429]. Mobility
is handled by the network without the MNs involvement, but, is handled by the network without the MNs involvement, but,
differently from PMIPv6, when the MN moves from one access network to differently from PMIPv6, when the MN moves from one access network to
another, it also changes anchor router, hence requiring signaling another, it may also change anchor router, hence requiring signaling
between the anchors to retrieve the MN's previous location(s). Also, between the anchors to retrieve the MN's previous location(s). Also,
a key-aspect of network-based DMM, is that a prefix pool belongs a key-aspect of network-based DMM, is that a prefix pool belongs
exclusively to each MAAR, in the sense that those prefixes are exclusively to each MAAR, in the sense that those prefixes are
assigned by the MAAR to the MNs attached to it, and they are routable assigned by the MAAR to the MNs attached to it, and they are routable
at that MAAR. at that MAAR.
We consider partially distributed schemes, where the data plane only We consider partially distributed schemes, where the data plane only
is distributed among access routers similar to MAGs, whereas the is distributed among access routers similar to MAGs, whereas the
control plane is kept centralized towards a cardinal node used as control plane is kept centralized towards a cardinal node used as
information store, but relieved from any route management and MN's information store, but relieved from any route management and MN's
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Access Data Plane Node (Access-DPN) Access Data Plane Node (Access-DPN)
The following terms are defined and used in this document: The following terms are defined and used in this document:
MAAR (Mobility Anchor and Access Router). First hop router where the MAAR (Mobility Anchor and Access Router). First hop router where the
mobile nodes attach to. It also plays the role of mobility mobile nodes attach to. It also plays the role of mobility
manager for the IPv6 prefixes it anchors, running the manager for the IPv6 prefixes it anchors, running the
functionalities of PMIP's MAG and LMA. Depending on the prefix, functionalities of PMIP's MAG and LMA. Depending on the prefix,
it plays the role of Access-DPN, Home-DPA and Access-CPN. it plays the role of Access-DPN, Home-DPA and Access-CPN.
CMD (Central Mobility Database). Node that stores the BCEs allocated CMD (Central Mobility Database). The node that stores the BCEs
for the MNs in the mobility domain. It plays the role of Home- allocated for the MNs in the mobility domain. It plays the role
CPA. of Home-CPA.
P-MAAR (Previous MAAR). MAAR which was previously visited by the MN P-MAAR (Previous MAAR). When a MN moves to a new point of attachment
and is still involved in an active flow using an IPv6 prefix it a new MAAR might be allocated as its anchor point for future IPv6
has advertised to the MN (i.e., MAAR where that IPv6 prefix is prefixes. The MAAR that served the MN prior to new attachment
anchored). It plays the role of Home-DPA for the flows it is becomes the P-MAAR. It is still the anchor point for the IPv6
still serving for the MN's mobility session. There might be prefixes it had allocated to the MN in the past and serves as the
multiple P-MAARs for an MN's mobility session. Home-DPA for flows using these prefixes. There might be several
P-MAARs serving a MN when the MN is frequently switching points of
attachment while maintaining long-lasting flows.
S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. S-MAAR (Serving MAAR). The MAAR which the MN is currently attached
Depending on the prefix, it plays the role of Access-DPN, Home-DPA to. Depending on the prefix, it plays the role of Access-DPN,
and Access-CPN. Home-DPA and Access-CPN.
DLIF (Distributed Logical Interface). It is a logical interface at DLIF (Distributed Logical Interface). It is a logical interface at
the IP stack of the MAAR. For each active prefix used by the the IP stack of the MAAR. For each active prefix used by the MN,
mobile node, the S-MAAR has a DLIF configured (associated to each the S-MAAR has a DLIF configured (associated to each MAAR still
MAAR still anchoring flows). In this way, a S-MAAR exposes itself anchoring flows). In this way, an S-MAAR exposes itself towards
towards each MN as multiple routers, one as itself and one per each MN as multiple routers, one as itself and one per P-MAAR.
P-MAAR.
3. PMIPv6 DMM extensions 3. PMIPv6 DMM extensions
The solution consists of de-coupling the entities that participate in The solution consists of de-coupling the entities that participate in
the data and the control planes: the data plane becomes distributed the data and the control planes: the data plane becomes distributed
and managed by the MAARs near the edge of the network, while the and managed by the MAARs near the edge of the network, while the
control plane, besides those on the MAARs, relies on a central entity control plane, besides those on the MAARs, relies on a central entity
called Central Mobility Database (CMD). In the proposed called Central Mobility Database (CMD). In the proposed
architecture, the hierarchy present in PMIPv6 between LMA and MAG is architecture, the hierarchy present in PMIPv6 between LMA and MAG is
preserved, but with the following substantial variations: preserved, but with the following substantial variations:
o The LMA is relieved from the data forwarding role, only the o The LMA is relieved from the data forwarding role, only the
Binding Cache and its management operations are maintained. Hence Binding Cache and its management operations are maintained. Hence
the LMA is renamed into Central Mobility Database (CMD), which is the LMA is renamed into Central Mobility Database (CMD), which is
therefore an Home-CPA. Also, the CMD is able to send and parse therefore a Home-CPA. Also, the CMD is able to send and parse
both PBU and PBA messages. both PBU and PBA messages.
o The MAG is enriched with the LMA functionalities, hence the name o The MAG is enriched with the LMA functionalities, hence the name
Mobility Anchor and Access Router (MAAR). It maintains a local Mobility Anchor and Access Router (MAAR). It maintains a local
Binding Cache for the MNs that are attached to it and it is able Binding Cache for the MNs that are attached to it and it is able
to send and parse PBU and PBA messages. to send and parse PBU and PBA messages.
o The binding cache will be extended to include information o The binding cache will be extended to include information
regarding P-MAARs where the mobile node was anchored and still regarding P-MAARs where the mobile node was anchored and still
retains active data sessions, see Appendix B for further details. retains active data sessions, see Appendix B for further details.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
update information related to the MNs, stored as mobility sessions; update information related to the MNs, stored as mobility sessions;
hence, a centralized node maintains a global view of the network hence, a centralized node maintains a global view of the network
status. The CMD is queried whenever a MN is detected to join/leave status. The CMD is queried whenever a MN is detected to join/leave
the mobility domain. It might be a fresh attachment, a detachment or the mobility domain. It might be a fresh attachment, a detachment or
a handover, but as MAARs are not aware of past information related to a handover, but as MAARs are not aware of past information related to
a mobility session, they contact the CMD to retrieve the data of a mobility session, they contact the CMD to retrieve the data of
interest and eventually take the appropriate action. The procedure interest and eventually take the appropriate action. The procedure
adopted for the query and the messages exchange sequence might vary adopted for the query and the messages exchange sequence might vary
to optimize the update latency and/or the signaling overhead. Here to optimize the update latency and/or the signaling overhead. Here
is presented one method for the initial registration, and three is presented one method for the initial registration, and three
different approaches to update the mobility sessions using PBUs and different approaches for updating the mobility sessions using PBUs
PBAs. Each approach assigns a different role to the CMD: and PBAs. Each approach assigns a different role to the CMD:
o The CMD is a PBU/PBA relay; o The CMD is a PBU/PBA relay;
o The CMD is only a MAAR locator; o The CMD is only a MAAR locator;
o The CMD is a PBU/PBA proxy. o The CMD is a PBU/PBA proxy.
This solution can be categorized under Model-1: Split Home Anchor This solution can be categorized under Model-1: Split Home Anchor
Mode in [I-D.ietf-dmm-deployment-models]. As another note, the Mode in [I-D.ietf-dmm-deployment-models]. As another note, the
solution described in this document allows performing per-prefix solution described in this document allows performing per-prefix
anchoring decisions, to support e.g., some flows to be anchored at a anchoring decisions, to support e.g., some flows to be anchored at a
central Home-DPA (like a traditional LMA) or to enable an application central Home-DPA (like a traditional LMA) or to enable an application
to switch to the locally anchored prefix to gain route optimization, to switch to the locally anchored prefix to gain route optimization,
as indicated in [I-D.ietf-dmm-ondemand-mobility]. as indicated in [I-D.ietf-dmm-ondemand-mobility].
Note that a MN MAY move across different MAARs, which might result in Note that a MN MAY move across different MAARs, which might result in
several P-MAARs existing at a given moment of time, each of them several P-MAARs existing at a given moment of time, each of them
anchoring a prefix used by the MN. anchoring a different prefix used by the MN.
3.1. Initial registration 3.1. Initial registration
Upon the MN's attachment to a MAAR, say MAAR1 as shown in Figure 1, Initial registration is performed when an MN attaches to a network
if the MN is authorized for the service, an IPv6 global prefix for the first time (rather than attaching to a new network after
belonging to the MAAR1's prefix pool is reserved for it (Pref1) into moving from a previous one).
a temporary Binding Cache Entry (BCE) allocated locally. The prefix
is sent in a [RFC5213] PBU with the MN's Identifier (MN-ID) to the In this description (shown in Figure 1), it is assumed that:
CMD, which, since the session is new, stores a permanent BCE
containing as primary fields the MN-ID, the MN's prefix and MAAR1's 1. The MN is attaching to MAAR1.
address as Proxy-CoA. The CMD replies to MAAR1 with a PBA including
the usual options defined in PMIPv6 [RFC5213], meaning that the MN's 2. The MN is authorized to attach to the network.
registration is fresh and no past status is available. MAAR1 stores
the temporary BCE previously allocated and unicasts a Router Upon MN attachment, the following operations take place:
Advertisement (RA) to the MN including the prefix reserved before,
that can be used by the MN to configure an IPv6 address (e.g., with 1. MAAR1 assigns an IPv6 global prefix from its own prefix pool to
stateless auto-configuration, SLAAC). Alternative IPv6 auto- the MN (Pref1). It also stores this prefix (Pref1) in the
configuration mechanisms can also be used, though this document locally allocated temporary Binding Cache Entry (BCE).
describes the SLAAC-based one. The address is routable at the MAAR,
in the sense that it is on the path of packets addressed to the MN. 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the
Moreover, the MAAR acts as plain router for those packets, as no CMD.
encapsulation nor special handling takes place.
3. Since this is an initial registration, the CMD stores a permanent
BCE containing as primary fields the MN-ID, Pref1 and MAAr1's
address as a Proxy-CoA.
4. The CMD replies with a PBA with the usual options defined in
PMIPv6 [RFC5213], meaning that the MN's registration is fresh and
no past status is available.
5. MAAR1 stores the BCE described in (1) an unicast a Router
Advertisement (RA) to the MN with Pref1.
6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with
stateless auto-configuration, SLAAC).
Note that:
1. Alternative IPv6 auto-configuration mechanisms can also be used,
though this document describes the SLAAC-based one.
2. IP1 is routable at MAAR1, in the sense that it is on the path of
packets addressed to the MN.
3. MAAR1 acts as a plain router for packets destined to the MN, as
no encapsulation nor special handling takes place.
In the diagram shown in Figure 1 (and subsequent diagrams), the flow
of packets is presented using '*'.
+-----+ +---+ +--+ +-----+ +---+ +--+
|MAAR1| |CMD| |CN| |MAAR1| |CMD| |CN|
+-----+ +---+ +*-+ +-----+ +---+ +*-+
| | * | | *
MN | * +---+ MN | * +---+
attach. | ***** _|CMD|_ attach. | ***** _|CMD|_
detection | flow1 * / +-+-+ \ detection | flow1 * / +-+-+ \
| | * / | \ | | * / | \
local BCE | * / | \ local BCE | * / | \
skipping to change at page 8, line 6 skipping to change at page 8, line 31
| | Pref1 * | | Pref1 *
| | +*-+ | | +*-+
| | |MN| | | |MN|
| | +--+ | | +--+
Operations sequence Packets flow Operations sequence Packets flow
Figure 1: First attachment to the network Figure 1: First attachment to the network
Note that the registration process does not change regardless of the Note that the registration process does not change regardless of the
CMD's modes (relay, locator or proxy) described next. CMD's modes (relay, locator or proxy) described next. The procedure
is depicted in Figure 2.
3.2. The CMD as PBU/PBA relay 3.2. The CMD as PBU/PBA relay
When the MN moves from its current access and attaches to MAAR2 (now Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following
the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a operations take place:
temporary BCE, and it sends a plain PBU to the CMD for registration.
Upon PBU reception and BC lookup, the CMD retrieves an already
existing entry for the MN, binding the MN-ID to its former location;
thus, the CMD forwards the PBU to the MAAR indicated as Proxy CoA
(MAAR1), including a new mobility option to communicate the S-MAAR's
global address to MAAR1, defined as Serving MAAR Option in
Section 4.6. The CMD updates the P-CoA field in the BCE related to
the MN with the S-MAAR's address.
Upon PBU reception, MAAR1 can install a tunnel on its side towards 1. When the MN moves from its current point of attachment and
MAAR2 and the related routes for Pref1. Then MAAR1 replies to the attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6
CMD with a PBA (including the option mentioned before) to ensure that prefix (Pref2), it stores a temporary BCE, and it sends a plain
the new location has successfully changed, containing the prefix PBU to the CMD for registration.
anchored at MAAR1 in the Home Network Prefix option. The CMD, after
receiving the PBA, updates the BCE populating an instance of the
P-MAAR list. The P-MAAR list is an additional field on the BCE that
contains an element for each P-MAAR involved in the MN's mobility
session. The list element contains the P-MAAR's global address and
the prefix it has delegated (see Appendix B for further details).
Also, the CMD sends a PBA to the new S-MAAR, containing the previous
Proxy-CoA and the prefix anchored to it embedded into a new mobility
option called Previous MAAR Option (defined in Section 4.5), so that,
upon PBA arrival, a bi-directional tunnel can be established between
the two MAARs and new routes are set appropriately to recover the IP
flow(s) carrying Pref1.
Now packets destined to Pref1 are first received by MAAR1, 2. Upon PBU reception and BC lookup, the CMD retrieves an already
encapsulated into the tunnel and forwarded to MAAR2, which finally existing entry for the MN, binding the MN-ID to its former
delivers them to their destination. In uplink, when the MN transmits location; thus, the CMD forwards the PBU to the MAAR indicated as
packets using Pref1 as source address, they are sent to MAAR2, as it Proxy CoA (MAAR1), including a new mobility option to communicate
is MN's new default gateway, then tunneled to MAAR1 which routes them the S-MAAR's global address to MAAR1, defined as Serving MAAR
towards the next hop to destination. Conversely, packets carrying Option in Section 4.6. The CMD updates the P-CoA field in the
Pref2 are routed by MAAR2 without any special packet handling both BCE related to the MN with the S-MAAR's address.
for uplink and downlink. The procedure is depicted in Figure 2.
3. Upon PBU reception, MAAR1 can install a tunnel on its side
towards MAAR2 and the related routes for Pref1. Then MAAR1
replies to the CMD with a PBA (including the option mentioned
before) to ensure that the new location has successfully changed,
containing the prefix anchored at MAAR1 in the Home Network
Prefix option.
4. The CMD, after receiving the PBA, updates the BCE populating an
instance of the P-MAAR list. The P-MAAR list is an additional
field on the BCE that contains an element for each P-MAAR
involved in the MN's mobility session. The list element contains
the P-MAAR's global address and the prefix it has delegated (see
Appendix B for further details). Also, the CMD sends a PBA to
the new S-MAAR, containing the previous Proxy-CoA and the prefix
anchored to it embedded into a new mobility option called
Previous MAAR Option (defined in Section 4.5), so that, upon PBA
arrival, a bi-directional tunnel can be established between the
two MAARs and new routes are set appropriately to recover the IP
flow(s) carrying Pref1.
5. Now packets destined to Pref1 are first received by MAAR1,
encapsulated into the tunnel and forwarded to MAAR2, which
finally delivers them to their destination. In uplink, when the
MN transmits packets using Pref1 as source address, they are sent
to MAAR2, as it is MN's new default gateway, then tunneled to
MAAR1 which routes them towards the next hop to destination.
Conversely, packets carrying Pref2 are routed by MAAR2 without
any special packet handling both for uplink and downlink.
6.
+-----+ +---+ +-----+ +--+ +--+ +-----+ +---+ +-----+ +--+ +--+
|MAAR1| |CMD| |MAAR2| |CN| |CN| |MAAR1| |CMD| |MAAR2| |CN| |CN|
+-----+ +---+ +-----+ +*-+ +*-+ +-----+ +---+ +-----+ +*-+ +*-+
| | | * * | | | * *
| | MN * +---+ * | | MN * +---+ *
| | attach. ***** _|CMD|_ * | | attach. ***** _|CMD|_ *
| | det. flow1 * / +-+-+ \ *flow2 | | det. flow1 * / +-+-+ \ *flow2
| |<-- PBU ---| * / | \ * | |<-- PBU ---| * / | \ *
| BCE | * / | ******* | BCE | * / | *******
skipping to change at page 12, line 8 skipping to change at page 13, line 8
Operations sequence Data Packets flow Operations sequence Data Packets flow
PBU/PBA Messages with * contain PBU/PBA Messages with * contain
a new mobility option a new mobility option
Figure 4: Scenario after a handover, CMD as proxy Figure 4: Scenario after a handover, CMD as proxy
3.5. De-registration 3.5. De-registration
The de-registration mechanism devised for PMIPv6 cannot be used as is The de-registration mechanism devised for PMIPv6 cannot be used as is
in this solution. This is motivated by the fact that each MAAR in this solution. The reason for this is that each MAAR handles an
handles an independent mobility session (i.e., a single or a set of independent mobility session (i.e., a single or a set of prefixes)
prefixes) for a given MN, whereas the aggregated session is stored at for a given MN, whereas the aggregated session is stored at the CMD.
the CMD. Indeed, when a previous MAAR initiates a de-registration Indeed, when a previous MAAR initiates a de-registration procedure,
procedure, because the MN is no longer present on the MAAR's access because the MN is no longer present on the MAAR's access link, it
link, it removes the routing state for that (those) prefix(es), that removes the routing state for that (those) prefix(es), that would be
would be deleted by the CMD as well, hence defeating any prefix deleted by the CMD as well, hence defeating any prefix continuity
continuity attempt. The simplest approach to overcome this attempt. The simplest approach to overcome this limitation is to
limitation is to deny an old MAAR to de-register a prefix, that is, deny a P-MAAR to de-register a prefix, that is, allowing only a
allowing only a serving MAAR to de-register the whole MN session. serving MAAR to de-register the whole MN session. This can be
This can be achieved by first removing any layer-2 detachment event, achieved by first removing any layer-2 detachment event, so that de-
so that de-registration is triggered only when the session lifetime registration is triggered only when the session lifetime expires,
expires, hence providing a guard interval for the MN to connect to a hence providing a guard interval for the MN to connect to a new MAAR.
new MAAR. Then, a change in the MAAR operations is required, and at Then, a change in the MAAR operations is required, and at this stage
this stage two possible solutions can be deployed: two possible solutions can be deployed:
o A previous MAAR stops the BCE timer upon receiving a PBU from the o A previous MAAR stops the BCE timer upon receiving a PBU from the
CMD containing a "Serving MAAR" option. In this way only the CMD containing a "Serving MAAR" option. In this way only the
Serving MAAR is allowed to de-register the mobility session, Serving MAAR is allowed to de-register the mobility session,
arguing that the MN left definitely the domain. arguing that the MN definitely left the domain.
o Previous MAARs can, upon BCE expiry, send de-registration messages o Previous MAARs can, upon BCE expiry, send de-registration messages
to the CMD, which, instead of acknowledging the message with a 0 to the CMD, which, instead of acknowledging the message with a 0
lifetime, send back a PBA with a non-zero lifetime, hence re- lifetime, sends back a PBA with a non-zero lifetime, hence re-
newing the session, if the MN is still connected to the domain. newing the session, if the MN is still connected to the domain.
3.6. The Distributed Logical Interface (DLIF) concept 3.6. The Distributed Logical Interface (DLIF) concept
One of the main challenges of a network-based DMM solution is how to One of the main challenges of a network-based DMM solution is how to
allow a mobile node to simultaneously send/receive traffic which is allow a mobile node to simultaneously send/receive traffic which is
anchored at different MAARs, and how to influence on the preference anchored at different MAARs, and how to influence on the mobile
of the mobile node selecting the source IPv6 address for a new node's selection process of its source IPv6 address for a new flow,
communication, without requiring special support on the mobile node without requiring special support from the mobile node's IP stack.
stack. This document defines the Distributed Logical Interface This document defines the Distributed Logical Interface (DLIF), which
(DLIF), which is a software construct that allows to easily hide the is a software construct that allows to easily hide the change of
change of anchor from the mobile node. associated anchors from the mobile node.
+---------------------------------------------------+ +---------------------------------------------------+
( Operator's ) ( Operator's )
( core ) ( core )
+---------------------------------------------------+ +---------------------------------------------------+
| | | |
+---------------+ tunnel +---------------+ +---------------+ tunnel +---------------+
| IP stack |===============| IP stack | | IP stack |===============| IP stack |
+---------------+ +-------+-------+ +---------------+ +-------+-------+
| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
skipping to change at page 13, line 30 skipping to change at page 14, line 30
prefA::/64 x x prefB::/64 prefA::/64 x x prefB::/64
(AdvPrefLft=0) x x (AdvPrefLft=0) x x
(o) (o)
| |
+-----+ +-----+
prefA::MN1 | MN1 | prefB::MN1 prefA::MN1 | MN1 | prefB::MN1
(deprecated) +-----+ (deprecated) +-----+
Figure 5: DLIF: exposing multiple routers (one per P-MAAR) Figure 5: DLIF: exposing multiple routers (one per P-MAAR)
The basic idea of the DLIF concept is the following. Each serving The basic idea of the DLIF concept is the following: each serving
MAAR exposes itself towards a given MN as multiple routers, one per MAAR exposes itself towards a given MN as multiple routers, one per
P-MAAR associated to the MN. Let's consider the example shown in P-MAAR associated to the MN. Let's consider the example shown in
Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6
address (prefA::MN1) from a prefix locally anchored at MAAR1 address (prefA::MN1) from a prefix locally anchored at MAAR1
(prefA::/64). At this stage, MAAR1 plays both the role of anchoring (prefA::/64). At this stage, MAAR1 plays both the role of anchoring
and serving MAAR, and also it behaves as a plain IPv6 access router. and serving MAAR, and also behaves as a plain IPv6 access router.
MAAR1 creates a distributed logical interface to communicate (point- MAAR1 creates a distributed logical interface to communicate (point-
to-point link) with MN1, exposing itself as a (logical) router with a to-point link) with MN1, exposing itself as a (logical) router with a
specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g.,
prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF
mn1mar1. As explained below, these addresses represent the "logical" mn1mar1. As explained below, these addresses represent the "logical"
identity of MAAR1 towards MN1, and will "follow" the mobile node identity of MAAR1 towards MN1, and will "follow" the mobile node
while roaming within the domain (note that the place where all this while roaming within the domain (note that the place where all this
information is maintained and updated is out-of-scope of this draft; information is maintained and updated is out-of-scope of this draft;
potential examples are to keep it on the home subscriber server -- potential examples are to keep it on the home subscriber server --
HSS -- or the user's profile). HSS -- or the user's profile).
skipping to change at page 14, line 48 skipping to change at page 15, line 48
Figure 6: Distributed Logical Interface concept Figure 6: Distributed Logical Interface concept
Figure 6 shows the logical interface concept in more detail. The Figure 6 shows the logical interface concept in more detail. The
figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2
and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two
P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the
role of anchoring MAAR for the attached (served) MNs. Each MAAR has role of anchoring MAAR for the attached (served) MNs. Each MAAR has
one single physical wireless interface. one single physical wireless interface.
As introduced before, each MN always "sees" multiple logical routers As introduced before, each MN always "sees" multiple logical routers
-- one per P-MAAR -- independently of to which serving MAAR the MN is -- one per P-MAAR -- independently of its currently serving MAAR.
currently attached. From the point of view of the MN, these MAARs From the point of view of the MN, these MAARs are portrayed as
are portrayed as different routers, although the MN is physically different routers, although the MN is physically attached to one
attached to one single interface. The way this is achieved is by the single interface. The way this is achieved is by the serving MAAR
serving MAAR configuring different logical interfaces. If we focus configuring different logical interfaces. Focusing on MN1, it is
on MN1, it is currently attached to MAAR2 (i.e., MAAR2 is its serving currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and,
MAAR) and, therefore, it has configured an IPv6 address from MAAR2's therefore, it has configured an IPv6 address from MAAR2's pool (e.g.,
pool (e.g., prefB::/64). MAAR2 has set-up a logical interface prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top
(mn1mar2) on top of its wireless physical interface (phy if MAAR2) of its wireless physical interface (phy if MAAR2) which is used to
which is used to serve MN1. This interface has a logical MAC address serve MN1. This interface has a logical MAC address (LMAC6),
(LMAC6), different from the hardware MAC address (HMAC2) of the different from the hardware MAC address (HMAC2) of the physical
physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its
advertises its locally anchored prefix prefB::/64. Before attaching locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1
to MAAR2, MN1 visited MAAR1, configuring also an address locally was attached to MAAR1, configuring also an address locally anchored
anchored at this MAAR, which is still being used by the MN1 in active at that MAAR, which is still being used by MN1 in active
communications. MN1 keeps "seeing" an interface connecting to MAAR1, communications. MN1 keeps "seeing" an interface connecting to MAAR1,
as if it were directly connected to the two MAARs. This is achieved as if it were directly connected to the two MAARs. This is achieved
by the serving MAAR (MAAR2) configuring an additional distributed by the serving MAAR (MAAR2) configuring an additional distributed
logical interface: mn1mar1, which behaves exactly as the logical logical interface: mn1mar1, which behaves exactly as the logical
interface configured by the actual MAAR1 when MN1 was attached to it. interface configured by MAAR1 when MN1 was attached to it. This
This means that both the MAC and IPv6 addresses configured on this means that both the MAC and IPv6 addresses configured on this logical
logical interface remain the same regardless of the physical MAAR interface remain the same regardless of the physical MAAR which is
which is serving the MN. The information required by a serving MAAR serving the MN. The information required by a serving MAAR to
to properly configure this logical interfaces can be obtained in properly configure this logical interfaces can be obtained in
different ways: as part of the information conveyed in the PBA, from different ways: as part of the information conveyed in the PBA, from
an external database (e.g., the HSS) or by other means. As shown in an external database (e.g., the HSS) or by other means. As shown in
the figure, each MAAR may have several logical interfaces associated the figure, each MAAR may have several logical interfaces associated
to each attached MN, having always at least one (since a serving MAAR to each attached MN, having always at least one (since a serving MAAR
is also an anchoring MAAR for the attached MN). is also an anchoring MAAR for the attached MN).
In order to enforce the use of the prefix locally anchored at the In order to enforce the use of the prefix locally anchored at the
serving MAAR, the router advertisements sent over those logical serving MAAR, the router advertisements sent over those logical
interfaces playing the role of anchoring MAARs (different from the interfaces playing the role of anchoring MAARs (different from the
serving one) include a zero preferred prefix lifetime (and a non-zero serving one) include a zero preferred prefix lifetime (and a non-zero
valid prefix lifetime, so the prefix remains valid, while being valid prefix lifetime, so the prefix remains valid, while being
deprecated). The goal is to deprecate the prefixes delegated by deprecated). The goal is to deprecate the prefixes delegated by
these MAARs (which will be no longer serving the MN). Note that on- these MAARs (which will be no longer serving the MN). Note that on-
going communications keep on using those addresses, even if they are going communications may keep on using those addresses, even if they
deprecated, so this only affects to new sessions. are deprecated, so this only affects the establishment of new
sessions.
The distributed logical interface concept also enables the following The distributed logical interface concept also enables the following
use case. Suppose that access to a local IP network is provided by a use case: suppose that access to a local IP network is provided by a
given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that
the resources available at that network cannot be reached from the resources available at that network cannot be reached from
outside the local network (e.g., cannot be accessed by an MN attached outside the local network (e.g., cannot be accessed by an MN attached
to MAAR2). This is similar to the local IP access scenario to MAAR2). This is similar to the local IP access scenario
considered by 3GPP, where a local gateway node is selected for considered by 3GPP, where a local gateway node is selected for
sessions requiring access to services provided locally (instead of sessions requiring access to services provided locally (instead of
going through a central gateway). The goal is to allow an MN to be going through a central gateway). The goal is to allow an MN to be
able to roam while still being able to have connectivity to this able to roam while still being able to have connectivity to this
local IP network. The solution adopted to support this case makes local IP network. The solution adopted to support this case makes
use of RFC 4191 [RFC4191] more specific routes when the MN moves to a use of RFC 4191 [RFC4191] more specific routes when the MN moves to a
MAAR different from the one providing access to the local IP network MAAR different from the one providing access to the local IP network
(MAAR1 in the example). These routes are advertised through the (MAAR1 in the example). These routes are advertised through the
distributed logical interface representing the MAAR providing access distributed logical interface representing the MAAR providing access
to the local network (MAAR1 in this example). In this way, if MN1 to the local network (MAAR1 in this example). In this way, if MN1
moves from MAAR1 to MAAR2, any active session that MN1 may have with moves from MAAR1 to MAAR2, any active session that MN1 may have with
a node of the local network connected to MAAR1 will survive, being a node on the local network connected to MAAR1 will survive via the
the traffic forwarded via the tunnel between MAAR1 and MAAR2. Also, tunnel between MAAR1 and MAAR2. Also, any potential future
any potential future connection attempt towards the local network connection attempt towards the local network will be supported, even
will be supported, even though MN1 is no longer attached to MAAR1. though MN1 is no longer attached to MAAR1.
4. Message Format 4. Message Format
This section defines extensions to the Proxy Mobile IPv6 [RFC5213] This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages. protocol messages.
4.1. Proxy Binding Update 4.1. Proxy Binding Update
A new flag (D) is included in the Proxy Binding Update to indicate A new flag (D) is included in the Proxy Binding Update to indicate
that the Proxy Binding Update is coming from a Mobility Anchor and that the Proxy Binding Update is coming from a Mobility Anchor and
skipping to change at page 17, line 37 skipping to change at page 18, line 37
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAAR (D) MAAR (D)
The D is set to indicate that the sender of the message supports The D is set to indicate that the sender of the message supports
operating as a Mobility Anchor and Access Router. When a MAG that operating as a Mobility Anchor and Access Router. When a MAG that
does not support the extensions described in this document does not support the extensions described in this document
receives a message with the D-Flag set, the PBA in that case MUST receives a message with the D-Flag set, it MUST ignore the message
NOT be processed by the MAG and an error MUST be returned. and an error MUST be returned.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2 of and format of defined options are described in Section 6.2 of
[RFC6275]. The MAAR MUST ignore and skip any options that it does [RFC6275]. The MAAR MUST ignore and skip any options that it does
not understand. not understand.
skipping to change at page 18, line 33 skipping to change at page 19, line 33
+ + + +
| | | |
+ Anchored Prefix + + Anchored Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD1. IANA-1.
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 18. set to 18.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Anchored Prefix Anchored Prefix
A sixteen-byte field containing the mobile node's IPv6 Anchored A sixteen-byte field containing the mobile node's IPv6 Anchored
Prefix. Prefix. Only the first Prefix Length bytes are valid for the
Anchored Prefix. The rest of the bytes MUST be ignored.
4.4. Local Prefix Option 4.4. Local Prefix Option
A new Local Prefix option is defined for use with the Proxy Binding A new Local Prefix option is defined for use with the Proxy Binding
Update and Proxy Binding Acknowledgment messages exchanged between Update and Proxy Binding Acknowledgment messages exchanged between
MAARs. Therefore, this option can only appear if the D bit is set in MAARs. Therefore, this option can only appear if the D bit is set in
a PBU/PBA. This option is used for exchanging a prefix of a local a PBU/PBA. This option is used for exchanging a prefix of a local
network that is only reachable via the anchoring MAAR. There can be network that is only reachable via the anchoring MAAR. There can be
multiple Local Prefix options present in the message. multiple Local Prefix options present in the message.
skipping to change at page 19, line 35 skipping to change at page 20, line 36
+ + + +
| | | |
+ Local Prefix + + Local Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD2. IANA-2.
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 18. set to 18.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
skipping to change at page 19, line 49 skipping to change at page 21, line 4
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 18. set to 18.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Local Prefix Local Prefix
A sixteen-byte field containing the IPv6 Local Prefix. A sixteen-byte field containing the IPv6 Local Prefix. Only the
first Prefix Length bytes are valid for the IPv6 Local Prefix.
The rest of the bytes MUST be ignored.
4.5. Previous MAAR Option 4.5. Previous MAAR Option
This new option is defined for use with the Proxy Binding This new option is defined for use with the Proxy Binding
Acknowledgement messages exchanged by the CMD to a MAAR. This option Acknowledgement messages exchanged by the CMD to a MAAR. This option
is used to notify the S-MAAR about the previous MAAR's global address is used to notify the S-MAAR about the previous MAAR's global address
and the prefix anchored to it. There can be multiple Previous MAAR and the prefix anchored to it. There can be multiple Previous MAAR
options present in the message. Its format is as follows: options present in the message. Its format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 20, line 41 skipping to change at page 21, line 45
+ + + +
| | | |
+ Home Network Prefix + + Home Network Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD3. IANA-3.
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 33. set to 33.
Prefix Length Prefix Length
8-bit unsigned integer indicating the prefix length of the IPv6 8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Previous MAAR's address Previous MAAR's address
A sixteen-byte field containing the P-MAAR's IPv6 global address. A sixteen-byte field containing the P-MAAR's IPv6 global address.
Home Network Prefix Home Network Prefix
A sixteen-byte field containing the mobile node's IPv6 Home A sixteen-byte field containing the mobile node's IPv6 Home
Network Prefix. Network Prefix. Only the first Prefix Length bytes are valid for
the mobile node's IPv6 Home Network Prefix. The rest of the bytes
MUST be ignored.
4.6. Serving MAAR Option 4.6. Serving MAAR Option
This new option is defined for use with the Proxy Binding Update and This new option is defined for use with the Proxy Binding Update and
Proxy Binding Acknowledgement messages exchanged between the CMD and Proxy Binding Acknowledgement messages exchanged between the CMD and
a Previous MAAR. This option is used to notify the P-MAAR about the a Previous MAAR. This option is used to notify the P-MAAR about the
current Serving MAAR's global address. Its format is as follows: current Serving MAAR's global address. Its format is as follows:
0 1 2 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 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
skipping to change at page 21, line 37 skipping to change at page 22, line 44
+ + + +
| | | |
+ S-MAAR's address + + S-MAAR's address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD4. IANA-4.
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 16. set to 16.
Serving MAAR's address Serving MAAR's address
A sixteen-byte field containing the S-MAAR's IPv6 global address. A sixteen-byte field containing the S-MAAR's IPv6 global address.
skipping to change at page 22, line 32 skipping to change at page 23, line 36
+ + + +
| | | |
+ DLIF Link-local Address + + DLIF Link-local Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD5. IANA-5.
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. This field MUST be octets, excluding the type and length fields. This field MUST be
set to 16. set to 16.
DLIF Link-local Address DLIF Link-local Address
A sixteen-byte field containing the link-local address of the A sixteen-byte field containing the link-local address of the
skipping to change at page 23, line 23 skipping to change at page 24, line 31
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ DLIF Link-layer Address + + DLIF Link-layer Address +
. ... . . ... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD6. IANA-6.
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.
Reserved Reserved
This field is unused for now. The value MUST be initialized to 0 This field is unused for now. The value MUST be initialized to 0
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
skipping to change at page 23, line 48 skipping to change at page 25, line 7
logical interface to be configured on the S-MAAR. logical interface to be configured on the S-MAAR.
The content and format of this field (including byte and bit The content and format of this field (including byte and bit
ordering) is as specified in Section 4.6 of [RFC4861] for carrying ordering) is as specified in Section 4.6 of [RFC4861] for carrying
link-layer addresses. On certain access links, where the link- link-layer addresses. On certain access links, where the link-
layer address is not used or cannot be determined, this option layer address is not used or cannot be determined, this option
cannot be used. cannot be used.
5. IANA Considerations 5. IANA Considerations
This document defines new mobility options that require IANA actions. This document defines new mobility options that require IANA actions:
IANA-1 to IANA-6.
TBD.
6. Security Considerations 6. Security Considerations
The protocol extensions defined in this document share the same The protocol extensions defined in this document share the same
security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended
that the signaling messages, Proxy Binding Update and Proxy Binding that the signaling messages, Proxy Binding Update and Proxy Binding
Acknowledgment, exchanged between the MAARs are protected using IPsec Acknowledgment, exchanged between the MAARs are protected using IPsec
using the established security association between them. This using the established security association between them. This
essentially eliminates the threats related to the impersonation of a essentially eliminates the threats related to the impersonation of a
MAAR. MAAR.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex
Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and
Satoru Matsushima for their comments and discussion on the documents Satoru Matsushima for their comments and discussion on the documents
[I-D.bernardos-dmm-distributed-anchoring] and [I-D.bernardos-dmm-distributed-anchoring] and
[I-D.bernardos-dmm-pmip] on which the present document is based. [I-D.bernardos-dmm-pmip] on which the present document is based.
The authors would also like to thank Lyle Bertz for his deep review The authors would also like to thank Lyle Bertz and Danny Moses for
of this document and his very valuable comments and suggestions. their in-deep review of this document and their very valuable
comments and suggestions.
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 45 change blocks. 
182 lines changed or deleted 226 lines changed or added

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