| NETEXT | A. P. Petrescu |
| Internet-Draft | M. M. B. Boc |
| Intended status: Informational | C. J. Janneteau |
| Expires: January 10, 2013 | CEA |
| July 11, 2012 |
Network Mobility with Proxy Mobile IPv6
draft-petrescu-netext-pmip-nemo-01.txt
The Proxy Mobile IPv6 protocol supports Mobile Hosts moving independently, but not Mobile Routers in charge of moving networks.
This draft addresses this problem. The goal is to allow bidirectional communication between a Local Fixed Node (in the moving network) and a Correspondent Node (situated arbitrarily somewhere in the Internet). First, a mechanism of "prefix division" is presented, whereby the Home Network Prefix typically assigned by PMIPv6 to a MH is used by MR to form Mobile Network sub-Prefix(es); they are used by LFNs within the moving network to form addresses; this avoids changes in the PMIPv6 protocol specification. A second mechanism proposes enhancements to the use of the DHCPv6 Prefix Delegation protocol entities informing the PMIPv6 entities about the allocated MNP; this is achieved by equaling MNID and DUID.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The term Mobile Router has several meanings. One of the agreed meanings at IETF, documented in terminology RFCs, is that of an entity implementing the Mobile IPv6 protocol with NEMOv6 extensions, and accomodating changes in its Care-of Address, maintaining a stable Home Address with the help of a Home Agent, and in charge of LFNs in a moving network whose addresses do not change. Another meaning is that of a router which moves around and does not necessarily change its IP address. In the context of this draft we consider this latter meaning. We ignore whether or not the MR runs Mobile IPv6.
The work presented in this draft is developped in the context of Proxy Mobile IPv6 [RFC5213]. With respect to prefix division, similar methods have been alluded to in the context of DHCPv6 Prefix Delegation by [I-D.krishnan-intarea-pd-epc] (with a slide presentation in the DHC WG at IETF77) and of OSPFv3 by draft-arkko-homenet-prefix-assignment-01.
Mechanisms for supporting Mobile Routers with PMIPv6 and DHCPv6 are presented in [I-D.ietf-netext-pd-pmip] and preceding individual drafts.
The methods presented in this draft are different from most if not all existing documented methods to accomodate moving networks with PMIPv6. In particular, the HNP Division offers several MNPs for use by LFNs, does not modify PMIPv6, does not require the use of DHCPv6-PD but has an inconveninent in that it may not accommodate Ethernet LFNs with SLAAC. The DHCPv6-PD and PMIPv6 enhancements offer MNPs potentially completely different than HNP, may use Ethernet LFNs with SLAAC, modify MAG, LMA, DHCP Relay and potentially DHCP Server.
Moreover, the PMIPv6 and DHCPv6 enhancements presented in this draft rely on the use of MNID being equal to the DUID, a feature absent from existing proposals. Also, with this mechanism the entity performing the allocation of an MNP is the DHCPv6 Server (and not the LMA).
The mechanism "HNP Division" divides the Home Network Prefix into two or more Mobile Network Prefixes (MNPs).
It is assumed that in a domain running PMIPv6 the LMA assigns a Home Network Prefix (HNP) to the Mobile Host. If we consider this Mobile Host to be a Mobile Router, in charge of a set of Local Fixed Nodes (LFNs) in a moving network, it is necessary to use a Mobile Network Prefix (MNP) within the moving network. Simply using HNP to form addresses for LFNs, without modifying MR behaviour with respect to its routing table, is not sufficient.
The topology illustrated in the next figure depicts a domain where PMIPv6 is run, and a Mobile Router in charge of a set of LFNs forming a moving network.
----
| CN |
----
|
Internet
|
----
| LMA|
----
|
Operator Network
/ \
/ \
---- ----
|MAG1| |MAG2|
---- ----
| HNP
----
| MR | ---> handover
----
---- ---- ---- |
|LFN2| |LFN3| |LFN5||
---- ---- ---- |MNP1 or MNP2
| | | |
-------------------+
For a HNP with prefix length 64, two or more MNPs are generated, each having a prefix length longer than 64. For brevity and without losing generality, we present a detailed division example for a fictitious addressing system whose "IP" addresses are of a maximum length of 5 bits (instead of 128 bits of IPv6).
A0 11000/5
A2 11010/5 To be used by LFN2
A3 11011/5 To be used by LFN3
+--------> MNP1 1101/4
|
|
HNP 11000/2 +--------> A1 11001/5 To be used on egress of MR
|
|
+--------> MNP2 111/3
A4 11100/5
A5 11101/5 To be used by LFN5
A6 11110/5 To be used by LFN6
A7 11111/5
In this example, the HNP/2 11000 is assigned by LMA to MR. The MR divides this into MNP1 1101/4 and MNP2 111/3, and an address A1 11001/5. The MNP1 and MNP2 are used to help LFNs within the moving network to configure full /5 addresses. This may be achieved either with DHCPv6 (MR or a DHCPv6 Server send these addresses) or with stateless address auto-configuration (MR or a Router send Router Advertisements containing MNP1 and/or MNP2).
In most PMIPv6 implementations for MHs, the MAG contains a routing table entry with respect to the allocated HNP. Depending on the nature of the link between MAG and MR, this entry has two different forms: [HNP, vif, *] in case of point-to-point links (typically used in cellular systems) and [HNP, eth, *] (typically used in WiFi hotspot shared links). The vif is a virtual interface, e.g. "ppp0", whereas eth is a real interface, e.g. "eth0".
In the case of point-to-point links, it is not necessary to add any additional behaviour for MR to work (LFN to be reachable from CN). It is sufficient for MR to perform HNP division as described above.
On the contrary, in the case of shared links, it is necessary to perform an operation of Neighbor Discovery proxying on the Mobile Router. When MAG receives a packet from CN addressed to LFN, it would solicit the MAC address of LFN on the MAG-MR link (even though LFN is not present on that link). For this reason, the MR must pretend it owns the IP address of LFN and respond to that solicitation with its own MAC address.
The HNP division mechanism requires that the MNP be part of the HNP (e.g. MNP must have the leftmost n bits the same as the prefix length of HNP), and its length be longer. In case of an HNP/64 and the use of Ethernet for LFNs, only the DHCPv6 protocol can be used by LFNs, and not SLAAC, because stateless address auto-configuration is not possible for MNPs whose prefix length is longer than 64, the Interface ID being of length precisely 64 for Ethernet.
A second mechanism considers the use of MNP completely different than HNP (may differ on the leftmost bit), hence the use of SLAAC with Ethernet LFNs and HNP/64 is possible, but whereby the PMIPv6 protocol implementation must be modified; this mechanism involves also the use of the DHCPv6 Prefix Delegation protocol.
For this mechanism, we consider the following PMIP topology augmented with DHCP entities:
----
| CN |
----
|
Internet
|
----
| LMA|
----
----- |
| DSe |------ Operator Network
----- / \
/ \
---- ----
|MAG1| |MAG2|
|DRe1| |DRe2|
---- ----
| HNP
----
| MR | ---> handover
----
---- ---- ---- |
|LFN2| |LFN3| |LFN5||
---- ---- ---- |MNP1 or MNP2
| | | |
-------------------+
The DSe entity is a DHCPv6 Server. Each MAG also runs a DRe which is a DHCPv6 Relay.
It is necessary to modify the DRe, LMA and MAG behaviour. Depending on deployment, it may be preferable to modify or to not modify the DHCPv6 Server as well. In case it is not acceptable to modify the DSe the following protocol is proposed:
LFN MR MAG DSe LMA CN
| RA defr | | | | |
|<--------| DHCPReq | | | |
| |-------->| | | |
| | | RelFwd | | |
| | |------->| | |
| | |DUID=MNID | |
| | | | | |
| | | RelRep | | |
| | |<-------| | |
| | | MNP | | |
| | | | | |
| | | PBU MNID, MNP | |
| | |--------|------>| |
| | | PBA MNID, MNP | |
| | |<-------|-------| |
| | DHCPRep | | | |
| RA MNP |<--------| | | |
|<--------| | | | |
| | | | | |
|<--------|---------|========|=======|------->| app data
| | | | | |
In case it is not acceptabe to modify the DSe the following protocol is proposed:
LFN MR MAG DSe LMA CN
| RA defr | | | | |
|<--------| DHCPReq | | | |
| |-------->| | | |
| | | RelFwd | | |
| | |------->| | |
| | |DUID=MNID | |
| | | | | |
| | | | D2PU | |
| | | |------>| |
| | | | MNID | |
| | | | MNP | |
| | | | | |
| | | | D2PA | |
| | | |<----- | |
| | | | MNID | |
| | | RelRep | MNP | |
| | |<-------| | |
| | | | | |
| | | PBU MNID, MNP | |
| | |--------|------>| |
| | | | | |
| | | PBA MNID, MNP | |
| | |<-------|-------| |
| | DHCPRep | | | |
| RA MNP |<--------| | | |
|<--------| | | | |
| | | | | |
|<------------------=========|========------->| app data
| | | | | |
D2PU and D2PA are new message formats, to be further defined.
The structure of the PBU message is enhanced with respect to the original. Its structure is presented in the following figure:
Proxy Binding Update Message (existing + Q)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|Q| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Node Identifier Option (existing)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Network Prefix (MNP) Option (NEW)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix (MNP) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'R' flag in PBU: it must be reset.
'Q' flag in PBU: it must be set. It signifies this PBU is sent for an MNP (and not for an HNP).
Type field in the MNP Option: a new type TBA.
Length field in the MNP Option: the length of the MNP as was assigned by DHCP.
DHCPv6 and PMIPv6 have security options that should be used in this contect as well.
Security risks exist in the process of MR performing proxy Neighbor Discovery on behalf of LFN, if done without explicit authorization provided by LFN.
Security risks exist when performing D2PU and D2PA.
The mechanisms described in this draft were inspired by several discussions on the NETEXT and intarea email lists. Contributors of these discussions are acknowledged here.
In the process of filing for patent applications the lawyers provided comments which led to better descriptions.
Administratively, this work has been performed in the framework of CELTIC project CP7-011 MEVICO. The authors would like to acknowledge the contributions of their colleagues, although the views expressed are those of the authors and do not necessarily represent the project.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5213] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. |
| [I-D.krishnan-intarea-pd-epc] | Krishnan, S, Garneij, F, Korhonen, J and T Savolainen, "Prefix Delegation in Evolved Packet Core networks", Internet-Draft draft-krishnan-intarea-pd-epc-00, February 2010. |
| [I-D.ietf-netext-pd-pmip] | Zhou, X, Korhonen, J, Williams, C and G Gundavelli, "Prefix Delegation for Proxy Mobile IPv6", Internet-Draft draft-ietf-netext-pd-pmip-01, October 2011. |
The changes are listed in reverse chronological order, most recent changes appearing at the top of the list.
From nil to draft-petrescu-nextex-pmip-nemo-00.txt:
From draft-petrescu-netext-pmip-nemo-00 to -01: