One document matched: draft-petrescu-netext-pmip-nemo-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with emacs version 23 by Alexandru Petrescu -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<!-- <rfc category="info" ipr="full3978" -->
<!-- <rfc category="info" ipr="pre5378Trust200902" -->
<!-- docName="draft-petrescu-netext-pmip-nemo-00.txt"> -->
<rfc category="info" ipr="trust200902"
submissionType="independent"
docName="draft-petrescu-netext-pmip-nemo-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Network Mobility with Proxy Mobile IPv6</title>
<author initials='A. P.' surname="Petrescu"
fullname='Alexandru Petrescu'>
<organization abbrev='CEA'>CEA, LIST</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Gif-sur-Yvette
</city>
<region>
</region>
<code>
F-91191
</code>
<country>
France
</country>
</postal>
<phone>
+33 169089223
</phone>
<email>
alexandru.petrescu@cea.fr
</email>
</address>
</author>
<author initials='M. M. B.' surname="Boc"
fullname='Michael Mathias Boc'>
<organization abbrev='CEA'>CEA, LIST</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Gif-sur-Yvette
</city>
<region>
</region>
<code>
F-91191
</code>
<country>
France
</country>
</postal>
<phone>
+33 (0) 169083976
</phone>
<email>
michael.boc@cea.fr
</email>
</address>
</author>
<author initials='C. J.' surname='Janneteau'
fullname='Christophe Janneteau'>
<organization abbrev='CEA'>CEA, LIST</organization>
<address>
<postal>
<street>
Communicating Systems Laboratory, Point Courrier 173
</street>
<city>
Gif-sur-Yvette
</city>
<region>
</region>
<code>
F-91191
</code>
<country>
France
</country>
</postal>
<phone>
+33 (0) 169089182
</phone>
<email>
christophe.janneteau@cea.fr
</email>
</address>
</author>
<date/>
<area>
Internet
</area>
<workgroup>
NETEXT
</workgroup>
<abstract>
<t>
The Proxy Mobile IPv6 protocol supports Mobile Hosts
moving independently, but not Mobile Routers in charge of
moving networks.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Concentrated Description">
<t>
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.
</t>
<t>
The work presented in this draft is developped in the
context of Proxy Mobile IPv6 <xref target='RFC5213' />.
With respect to prefix division, similar methods have been
alluded to in the context of DHCPv6 Prefix Delegation by
<xref target='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.
</t>
<t>
Mechanisms for supporting Mobile Routers with PMIPv6 and
DHCPv6 are presented in
<xref target='I-D.ietf-netext-pd-pmip' /> and preceding
individual drafts.
</t>
<t>
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.
</t>
<t>
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).
</t>
<section title="HNP Division">
<t>
The mechanism "HNP Division" divides the Home Network
Prefix into two or more Mobile Network Prefixes (MNPs).
</t>
<t>
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.
</t>
<t>
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.
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
----
| CN |
----
|
Internet
|
----
| LMA|
----
|
Operator Network
/ \
/ \
---- ----
|MAG1| |MAG2|
---- ----
| HNP
----
| MR | ---> handover
----
---- ---- ---- |
|LFN2| |LFN3| |LFN5||
---- ---- ---- |MNP1 or MNP2
| | | |
-------------------+
]]>
</artwork>
</figure>
<t>
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).
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
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
]]>
</artwork>
</figure>
<t>
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).
</t>
<t>
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".
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="DHCPv6-PD and PMIPv6 Enhancements">
<t>
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.
</t>
<t>
For this mechanism, we consider the following PMIP
topology augmented with DHCP entities:
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
----
| CN |
----
|
Internet
|
----
| LMA|
----
----- |
| DSe |------ Operator Network
----- / \
/ \
---- ----
|MAG1| |MAG2|
|DRe1| |DRe2|
---- ----
| HNP
----
| MR | ---> handover
----
---- ---- ---- |
|LFN2| |LFN3| |LFN5||
---- ---- ---- |MNP1 or MNP2
| | | |
-------------------+
]]>
</artwork>
</figure>
<t>
The DSe entity is a DHCPv6 Server. Each MAG also runs a
DRe which is a DHCPv6 Relay.
</t>
<t>
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:
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
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
| | | | | |
]]>
</artwork>
</figure>
<t>
In case it is not acceptabe to modify the DSe the
following protocol is proposed:
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
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
| | | | | |
]]>
</artwork>
</figure>
<t>
D2PU and D2PA are new message formats, to be further
defined.
</t>
<t>
The structure of the PBU message is enhanced with respect
to the original. Its structure is presented in the
following figure:
</t>
<figure align="center">
<artwork align="left">
<![CDATA[
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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
'R' flag in PBU: it must be reset.
</t>
<t>
'Q' flag in PBU: it must be set. It signifies this PBU is
sent for an MNP (and not for an HNP).
</t>
<t>
Type field in the MNP Option: a new type TBA.
</t>
<t>
Length field in the MNP Option: the length of the MNP as
was assigned by DHCP.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
DHCPv6 and PMIPv6 have security options that should be used
in this contect as well.
</t>
<t>
Security risks exist in the process of MR performing proxy
Neighbor Discovery on behalf of LFN, if done without
explicit authorization provided by LFN.
</t>
<t>
Security risks exist when performing D2PU and D2PA.
</t>
</section>
<section anchor='Acknowledgements'
title='Acknowledgements'>
<t>
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.
</t>
<t>
In the process of filing for patent applications the
lawyers provided comments which led to better
descriptions.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
<?rfc
include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213" ?>
<?rfc
include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-krishnan-intarea-pd-epc-00"
?>
<?rfc
include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netext-pd-pmip-01"
?>
</references>
<section anchor='changelog'
title='ChangeLog'>
<t>
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
</t>
<t>
From nil to draft-petrescu-nextex-pmip-nemo-00.txt:
<list style='symbols'>
<t>
The -00 version is mostly a placeholder containing the
essence of the mechanisms.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:27:57 |