INTERNET-DRAFT Thierry Ernst, WIDE and INRIA
Alexis Olivereau, Motorola Labs Paris
Ludovic Bellier, INRIA
Claude Castelluccia, INRIA
Hong-Yon Lach, Motorola Labs Paris
March 2002
Mobile Networks Support in Mobile IPv6
(Prefix Scope Binding Updates)
draft-ernst-mobileip-v6-network-03.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft addresses the problems of routing datagrams to nodes
located behind the mobile router (MR) that connects a mobile network
(MONET) to the Internet, in IPv6. Mobile IPv6 [MIPv6], the solution
to support host mobility, is unable to support an entire network that
changes its point of attachment. We show, by means of an experiment,
that the Home Agent fails in redirecting packets to nodes behind the
MR, and that direct routing can not be performed either. It is thus
provided Mobile IPv6 extensions to support simple cases of MONETs. A
Prefix Scope Binding Update is an enhanced Mobile IPv6 Binding Update
which associates a careof-address (CoA) with a prefix instead of a
single address.
Ernst & Olivereau Expires September 2002 [Page 1]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
Table of Contents
Status of This Memo
Abstract
1. Introduction
2. Terminology and Assumptions
2.1. Terminology
2.3. Assumptions
3. Why can't Mobile IPv6 support MONETs ?
3.1. Review of Mobile IP and MONETs
3.2. Experimentation
3.2.1. Test Bed
3.2.1. Registration with the Home Agent
3.2.2. First experiment: Communication between CN and MR
3.2.3. Second experiment: Communication between CN and LFN1
3.3. Conclusion
4. Mobile IPv6 Extensions to Support MONETs
4.1. Packet format of the Binding Update
4.1.1. New Binding Update Option format
4.1.2. MONET Prefix Sub-Option
4.2. Cache Management
4.2.1. Binding Cache Entries
4.2.2. Searching the Binding Cache Entries
4.3. Extended Mobile IPv6 protocol Operation
4.3.1. Correspondent Node Operation
4.3.2. Home Agent Operation
4.3.3. MR Operation
5. Security Issues
5.1. Authentication
5.2. Authorization
5.3. Prefix Ownership
6. Changes since last draft
Acknowledgments
References
Author's Addresses
Ernst & Olivereau Expires September 2002 [Page 2]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
1. Introduction
The purpose of traditional mobility support is to provide continuous
Internet connectivity to mobile hosts (host mobility support). In
contrast, network mobility support is concerned with situations where
an entire network (composed by one or more subnets) dynamically
changes its point of attachment to the Internet and thus its
reachability in the topology. We shall refer to such a network as a
mobile network (MONET). Cases of MONETs include networks attached to
people (PANs) and networks of sensors deployed in aircrafts, ships,
trains, busses, cars, etc. Potential scenarios are exhibited in
[TERMINOLOGY] and [SCOPE].
Mobile IPv4 [MIPv4] and Mobile IPv6 [MIPv6] are solutions for host
mobility support in IPv4 and IPv6 [IPv6] respectively. Although it is
claimed that Mobile IPv4 could support MONETs equally as single
mobile nodes ([MIPv4] section 4.5, [Perkins98] section 5.12,
[Solomon98] section 11.2), we argue that this is not true for Mobile
IPv6. Indeed, we have carefully studied Mobile IPv6's ability for
supporting MONETs, and we came to the conclusion that some
modifications are needed to support them. As we show, the Home Agent
(HA) fails in redirecting packets intended to nodes behind the mobile
router (MR) which connects the MONET to the Internet. As a result
from this, communication cannot be established between nodes behind
the MR and nodes in the Internet.
Some implementations that do not strictly follows [MIPv6] may
interpret it in a way that would allow the HA to redirect packets to
nodes behind the MR, but we advocate that is surely leading to
misinterpretation and pitfalls. Thus, we advocate that MONETs should
be taken into account explicitly. We also advocate that nodes behind
the MR MUST NOT take part in the MONET's mobility management as a
result of the MR changing its point of attachment.
We therefore propose to extend Mobile IPv6 with "Prefix Scope Binding
Updates" as a means to provide continuous Internet connectivity for
both the MR and nodes behind it, in a simple, easy, optimal and
transparent way. It is assumed that all nodes in the MONET share a
common prefix (MONET Prefix) and that the careof-address (CoA)
belongs to the MR. A Prefix Scope Binding Update is an enhanced
Binding Update that associates a CoA to a prefix instead of a single
address. A node receiving such a Prefix Scope Binding Update is able
to route any packet that shows this prefix in the destination field
via the MR's CoA, therefore insuring permanent Internet connectivity
and direct routing to all nodes in the MONET.
In order to keep things simple, this draft does not address specific
issues related with nested mobility, and multi-homing. We only
Ernst & Olivereau Expires September 2002 [Page 3]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
consider LFNs (Local Fixed Nodes) behind the MR.
This document assumes the reader is familiar with the terminology
defined in [TERMINOLOGY] and [MIPv6], while reading [SCOPE, REQUI-1,
REQUI-2, REQUI-3] is recommended. More information may be found on
the MONET web page and mailing list [WEB-MONET]. The material
presented in this document is mostly taken from [Ernst01].
2. Terminology and Assumptions
2.1. Terminology
____
| |
| CN |
|____|
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_ ____
| | Access | | | | Home
| R2 | Router | R1 | | HA | Agent
|____| |____| |____|
_____|________|____ home
__|_ link
| |
| MR | Mobile Router
|____|
_________|_______ internal
__|___ __|___ link
| | | |
| LFN2 | | LFN1 | Local Fixed Nodes
|______| |______|
Figure 1: MONET attached to its home link
The following terms are as defined in [MIPv6]:
o Home Agent (HA)
o home address
o careof-address (CoA)
o Mobile Node (MN)
Ernst & Olivereau Expires September 2002 [Page 4]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
o home link
o foreign link
____
| |
| CN |
|____|
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_ ____
| | | | | | Home
| R2 | | R1 | | HA | Agent
|____| |____| |____|
_______|__ foreign __|________|____ home
__|_ link | link
| |
| MR | Mobile Router
|____|
_____|_________ internal
__|__ __|__ link
| | | |
| LFN | | LFN |
|_____| |_____|
Figure 2: MONET attached to a foreign link
The following terms peculiar to MONETs are defined in [TERMINOLOGY]:
o MONET (mobile network)
o MR (mobile router)
o Node behind MR
o LFN (Local Fixed Node)
o LMN (Local Mobile Node)
o VMN (Visiting Mobile Node)
o Mobile Network Prefix
o ingress interface
Ernst & Olivereau Expires September 2002 [Page 5]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
o egress interface
Figure 1 illustrates a MONET attached to its home link. In figure 2,
the MONET moves and MR attaches to a foreign link. Figure 3
illustrates a larger MONET.
____
| |
| CN |
|____|
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_ ____
| | Access | | | |
| R2 | Router | R1 | | HA |
|____| |____| |____|
_____|________|____ home
Access _|__ link
Router | | |
_____ |__| MR | Mobile Router
| |__| |____|
| LFN | | __|_____________ internal
|_____| | __|__ __|__ link 1
_____ | | | | |
| |__| | LFN | | LFN | Local Fixed Nodes
| LFN | | |_____| |_____|
|_____| |
| internal
link 2
Figure 3: Larger MONET with 2 subnets
2.2. Assumptions
In order to keep things as simple as possible, we make the following
assumptions and observations:
o No Multi-homing: the MONET attaches to the Internet through only
one MR, and the MR has only one egress interface.
o MONET Prefix: network prefix common to all IP addresses in the
MONET when the MR is attached to the home link. For a MONET
containing only one subnet, the MONET Prefix is the prefix of this
Ernst & Olivereau Expires September 2002 [Page 6]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
subnet. Note that the MONET Prefix is NOT the home subnet prefix
(i.e. the IP subnet prefix corresponding to the mobile router's
home address, as defined in [MIPv6]). We do not either make any
assumption on the number of bits common to the MONET Prefix and
the home subnet prefix. The MONET Prefix may be a sub-prefix of
the home subnet prefix. If, for example, the latter is a /60, the
MONET Prefix must be larger than /60, and the first 60 bits of
both prefixes are identical. Alternatively, they could also
diverge from a smaller number of bits. For instance, an
organization may decide to split the SLA field of the IPv6 address
in several sub-fields (SLA1, SLA2). In this case, the MONET may be
identified by a unique SLA1, and the home subnet prefix by another
one. If the length of the SLA1 field is 8 bits, the length of the
MONET Prefix is 60 bits and the MONET could contain up to 2^4
subnets.
o MR's egress interface is configured with the Home Subnet Prefix
o MR's ingress interface is configured with the MONET Prefix.
o All LFNs in the MONET are configured with the MONET Prefix.
o Nodes behind the MR are only LFNs (Local Fixed Nodes). We
therefore do not consider specific issues related with LMNs (Local
Mobile Nodes) nor VMNs (Visiting Mobile Nodes).
Although we have put these assumptions in order to restrict ourselves
to the most common and easiest instances of MONETs, our solution may
not necessarily be limited to these. We simply do not address the
specific issues related to more complex MONETs like those comprising
VMNs and LMNs. This should be investigated later. We note that
Hierarchical Mobile IPv6 Extended Mode [HMIPv6] proposes to handle
VMNs, but it may need additional features such as the ones proposed
in this draft.
3. Why can't Mobile IPv6 support MONETs ?
In this section, we first review how the Mobile IP specifications
deal with MONETs. We then show the results of an experimentation we
have conducted to outline Mobile IPv6's inability to support MONETs.
Then we discuss why the existing Mobile IPv6 specification is unable
to support MONETs if the MR performs Mobile IPv6.
3.1. Review of Mobile IP and MONET support
Mobile IPv4 proposes to support MONETs as standard mobile nodes (see
[MIPv4] section 4.5, [Perkins98] section 5.12, [Solomon98] section
11.2). In this situation, the mobile node is the MR connecting the
Ernst & Olivereau Expires September 2002 [Page 7]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
MONET to the fixed Internet. It has a permanent home address on its
home link and gets a new CoA at each subsequent foreign link. As any
mobile node, MR sends a Binding Update to its home agent HA to
instruct it to intercept and tunnel packets via the CoA. The HA is
therefore able to intercept packets intended to the home address of
MR.
In order to intercept packets intended to LFNs, Mobile IPv4 suggests
either of the following two solutions:
o the HA may be configured with a permanent registration for each
LFN which indicates MR's address as the LFN's CoA.
o the MR may advertise connectivity to the entire MONET using
normal IP routing protocols.
Mobile IPv6 [MIPv6] and Mobile IPv4 with Routing Optimization
[MIPv4-RO] could in principle support MONETs similarly as in Mobile
IPv4. However, although mentioned in [MIPv4], the current
specifications [MIPv4-RO] and [MIPv6] don't mention them anymore.
3.2. Experimentation
The following sections describe an experimentation conducted to
highlight shortcomings of the current Mobile IPv6 specification for
supporting MONETs. It shows [MIPv6] does not allow to route a packet
from the fixed Internet to a LFN behind the MR. This experimentation
has been conducted on our IPv6 test bed using Francis Dupont "INRIA"
IPv6 implementation under FreeBSD.
3.2.1. Test Bed
As this is illustrated on figure 5, MR has two interfaces. At home,
the egress interface is attached to the home link
(3ffe:306:1130:100::/64) and is configured with the home address
(3ffe:306:1130:100::eui64). The ingress interface is on the internal
link (3ffe:306:1130:200::/64) and his configured with the MONET
Prefix. LFN1 is a fixed node on the internal link. The MR moves and
attaches to a foreign link (3ffe:306:5555:7777::/64) while performing
MIPv6. In a first experiment, a CN in the fixed Internet pings MR. In
a second experiment, the CN pings LFN1.
3.2.2. Registration with the Home Agent
MR obtains a CoA on the foreign link and registers its primary CoA
with its HA. Once the HA receives a valid Binding Update from the
MR, it records in its Binding Cache the binding between MR's home
address and MR's CoA. The home address is used as the key for
Ernst & Olivereau Expires September 2002 [Page 8]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
searching the Binding Cache [MIPv6, section 4.6]. In order to
intercept packets, HA claims to be the MR. This is performed by
means of a "gratuitous" Neighbor Advertisement message on behalf
of the mobile node (i.e. MR), as described in [MIPv6, section
9.5].
More precisely, when it receives a home registration from MR, the
HA:
o opens a NDP proxy to intercept packets addressed to MR's home
address.
o opens a tug (a virtual interface, i.e. IPv6 in IPv6 tunnel)
between MR's CoA and itself.
o adds a host-specific route (a route to a host, not to a
prefix) for MR's home address via MR's CoA through the tug.
____
| |
| CN |
|____|
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_ ____
| | | | | | Home Agent
| R2 | | R1 | | HA | Binding cache:
|____| |____| |____| 3ffe:306:1130:100::eui64 -> COA
| | |
_______|_ foreign __|________|____ home link
| link | 3ffe:306:1130:100::/64
| 3ffe:306:5555:7777::/64
__|_
| | Mobile Router
| MR | home address 3ffe:306:1130:100::eui64
|____| COA 3ffe:306:5555:7777::eui64
|
_____|_________ internal link
| | 3ffe:306:1130:200::/64
__|___ __|___
| | | |
| LFN2 | | LFN1 | Local Fixed Node 1
|______| |______| 3ffe:306:1130:200::eui64
Figure 5: Packets sent from CN to LFN1 are dropped by Home Agent
Ernst & Olivereau Expires September 2002 [Page 9]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
3.2.3. First experiment: Communication between CN and MR
CN pings MR's home address (3ffe:306:1130:100::eui64). When the
packet gets to the home network via R1, R1 sends NDP messages to
discover the MAC address corresponding to the destination address
(i.e. MR's home address). HA answers with its address on behalf of
MR. The packet gets routed to the HA. In the standard IPv6 input
function of the HA, the packet is routed through the tug, i.e.
tunneled to MR's CoA. The packet therefore gets re-roouted to the
current location of the MR where it is de-tunneled and correctly
received.
3.2.4. Second experiment: Communication between CN and LFN1
CN pings LFN1's IP address (3ffe:306:1130:200::eui64). When the
packet gets to the home network, R1 checks its routing table to
reach LFN1. R1 has a route to the MONET; MR's home address is the
next hop toward LFN1. R1 sends NDP messages to discover MR's MAC
address. HA answers with its address on behalf of the MR. The
packet is transmitted on the home link and intercepted by HA.
However, HA does not have a route to the MONET Prefix. The ping
packet is thus sent to the default route, i.e. R1, which forwards
it again to the HA. THE PING PACKET ENTERS A ROUTING LOOP UNTIL
THE TTL EXPIRES.
3.3. Conclusion
We see that obtaining a CoA and requesting the HA to redirect
incoming packets intended for MR doesn't require modifications in
[MIPv6] as this could be done independently for a host or for a
router. As a result, packets intended to MR are correctly intercepted
by the HA and tunneled to MR.
However, although HA is able to intercept datagrams intended to LFNs,
it is unable to encapsulate them to MR's CoA because it does not have
a route to the MONET Prefix. The MR's registration only tells the HA
to record a host-specific route in its routing table. A network route
for the MONET Prefix (prefix of the MR's ingress interface) via MR's
CoA is missing.
Since the HA is unable to redirect packets intended to LFNs and CNs
don't have an entry in their Binding Cache to route packets directly
to LFNs, no communication at all is possible between CNs and LFNs. We
conclude that the Mobile IPv6 specification needs:
o explicit clarification in order for the HA to redirect all
packets intended to the MONET, but extensions are more likely
needed.
Ernst & Olivereau Expires September 2002 [Page 10]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
o extension in order to transmit packets from the CN to LFNs by
the most optimal route.
Some other Mobile IPv6 implementations do indeed interpret the
behavior of the HA in face of a MR registration. In such
implementations, the HA may have a network route for the MONET Prefix
via MR's CoA. We advocate that such an implementation does not
strictly follow [MIPv6] and may probably not comply with it. Leaving
too much room for interpretation surely leads to misinterpretation
and pitfalls, not to say security holes. Thus, MONETs should be taken
into account explicitly, and separately from [MIPv6].
4. Mobile IPv6 extensions to support MONETs
4.0. Overview
According to the observations made in section 3.2.4, we propose to
extend Mobile IPv6 with "Prefix Scope Binding Updates". Instead of
establishing a one-to-one relationship between a home address and a
CoA, the binding establishes a many-to-one relationship between the
set of nodes that share the same MONET Prefix and a CoA.
Prefix Scope Binding Updates are Binding Updates that associate a CoA
with the MONET Prefix instead of the full 128-bits IPv6 home address.
The MONET Prefix is carried in a new Sub-Option and requires a new
flag in the Mobile IPv6 Binding Update Option.
MR sends Prefix Scope Binding Updates to its HA and all the CNs
communicating with the MR itself or any LFNs behind it. The Prefix
Scope Binding Update instructs its recipients to use the MONET Prefix
as a netmask in the Binding Cache. The procedure for searching the
Binding Cache is slightly modified for this purpose. As a result, the
MR's CoA is returned for all destination addresses corresponding to
the MONET Prefix.
As we can see, a sole Prefix Scope Binding Update message allows
registration of an entire MONET, independently of the number of LFNs,
and transparently to them. Our solution therefore preserve routing
aggregation. In addtion, direct routinng between a CN and the MONET
is also made possible by means of a single registration. This is
particularly useful for a CN communicating with several LFNs from the
same MONET.
4.1. Packet Format of the Binding Update
We propose to extend the Mobile IPv6 Binding Update Option with an
extra flag "Prefix Scope Registration" (P) taken from the "Reserved"
field. In addition, the "MONET Prefix Sub-Option" is a new sub-
Ernst & Olivereau Expires September 2002 [Page 11]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
option that contains the MONET Prefix.
4.1.1. New Binding Update Option Format
The Binding Update option is encoded in type-length-value (TLV)
format as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D|P|Rsrvd| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Prefix Scope Registration (P)
When set, it indicates that the sending mobile node attempts to
register a CoA for an entire network. It also requests the
receiving node to process the MONET Prefix Sub-Option and to
re-route packets with a destination address that corresponds to
the MONET Prefix.
Rsrvd
This field is reduced from a 4-bit field to a 3-bit field to
account for the addition of the "Prefix Scope Registration"
bit. The remaining 3 bits are unused and MUST be initialized
to zero by the sender and MUST be ignored by the receiver.
4.1.2. MONET Prefix Sub-Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ MONET Prefix +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MONET Prefix is filled by the sending mobile node to request
the receiving node to record a Prefix Scope entry in the Binding
Ernst & Olivereau Expires September 2002 [Page 12]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
Cache (see section 4.2).
The Prefix Length field is set to the (nonzero) length of the
MONET Prefix.
The MONET Prefix field is set to the prefix of the MONET.
4.2. Cache Management
4.2.1. Binding Cache Entries
Binding Cache entries are as defined in [MIPv6] with minor
changes:
- is added a "Prefix Scope Registration" (P) flag indicating
whether this Binding Cache entry corresponds to a 128-bits
address or a prefix. If set, the "home address" field is filled
with a MONET Prefix instead of a full 128-bits address.
- the value of the "Prefix Length" field received in the
Binding Update that created or last modified this Binding Cache
entry is modified. This field is only valid if the "Prefix
Scope Registration" flag or the "Home Registration" flag is set
on this Binding Cache entry. If the "Prefix Scope Registration"
flag is set, the "Prefix Length corresponds to the length of
the MONET Prefix, otherwise the meaning is as defined in
[MIPv6].
4.2.2. Searching the Binding Cache Entries
The Binding Cache is searched for an entry corresponding to the
destination address of the packet. The destination address is
compared against the home address field of entries recorded in the
Binding Cache.
If the "Prefix Scope Registration" flag is set in the entry under
comparison, the comparison is made on the "Prefix Length" set of
initial bits. If the prefix of the destination matches the MONET
Prefix recorded in the entry, the destination is located in a
MONET.
If the "Prefix Scope Registration" flag is not set, the comparison
is made on the 128-bits addresses. If the destination address
matches the home address, the destination is a mobile node.
In both case, the CoA of the corresponding entry is returned.
4.3. Extended Mobile IPv6 Protocol Operation
Ernst & Olivereau Expires September 2002 [Page 13]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
The MR is a new entity similar to the MN. The MR Operation makes use
of most of the MN Operation extended with the ability to set the (P)
bit to 1, to fill the MONET Prefix Sub-Option, and to send Binding
Updates to all CNs that communicate with any LFN in the MONET.
The CN Operation and the HA Operation are extended in order to
process the MONET Prefix Sub-Option and to transmit packets to the
CoA of the MR. The MONET Prefix Sub-Option is processed if the (P)
bit from the Binding Update Option is set. Packets are transmitted to
the MR's CoA if the destination address matches the MONET Prefix.
The following sections only describe changes according to sections 8,
9 and 10 of the [MIPv6].
4.3.1. Correspondent Node Operation
Receiving (Prefix Scope) Binding Updates
Upon receiving a Binding Update, the CN performs validity
checks as described in [MIPv6] section 8.2. In addition, if the
"Prefix Scope Registration" (P) bit in the Binding Update
Option is set, the CN received a Binding Update from a MR and
the Binding Update must include a MONET Prefix Sub-Option. This
option MUST be ignored if the "Prefix Scope Registration" (P)
bit is not set.
If the Binding Update is valid, the CN creates a new entry in
its Binding Cache as this is performed in [MIPv6]. In addition,
if the (P) bit is set, the CN creates a second Binding Cache
entry similar to the first one as follows:
o the "Prefix Scope Registration" bit is taken from the
corresponding field as found in the Binding Update Option,
o the "Prefix Length" field is taken from the corresponding
field as found in the MONET Prefix Sub-Option,
o the "Home Address" field is filled with the prefix taken
from the "MONET Prefix" field as found in the MONET Prefix
Sub-Option.
Figure 6 shows the content of the Binding Cache.
Sending Packets
Before sending any packet, the CN examines searches the Binding
Cache for an entry corresponding to the destination address
(see section 4.2.2 "Searching the Binding Cache"). If a CoA is
Ernst & Olivereau Expires September 2002 [Page 14]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
returned, a routing header is inserted as specified in [MIPv6].
4.3.2. Home Agent Operation
Primary care-of address registration
Upon receiving a Binding Update, the HA performs validity
checks as described in [MIPv6] section 9.3. In addition, if the
"Prefix Scope Registration" (P) bit in the Binding Update
Option is set, the HA received a Binding Update from a MR and
the Binding Update must include a MONET Prefix Sub-Option. This
option MUST be ignored if the "Prefix Scope Registration" (P)
bit is not set.
If the Binding Update is valid, the HA creates a new entry in
its Binding Cache as it is performed in [MIPv6]. In addition,
if the (P) bit is set, the HA creates a second Binding Cache
entry similar to the first one as follows:
o the "Prefix Scope Registration" bit is taken from the
corresponding field as found in the Binding Update Option,
o the "Prefix Length" field is taken from the corresponding
field as found in the MONET Prefix Sub-Option,
o The "Home Address" field is filled with the prefix taken
from the "MONET Prefix" field as found in the MONET Prefix
Sub-Option.
Figure 6 shows the content of the Binding Cache.
Intercepting Packets
Datagrams sent by the CN to the IP address of the LFN are
routed up to the home link of the MR where they are intercepted
by the HA as specified in [MIPv6] section 9.5.
Tunneling Intercepted Packets to a Mobile Node
For any packet sent to a mobile node or a LFN for which the HA
is the original sender of the packet, the HA is operating as a
CN and the procedures described in section 4.3.1. applies.
While acting as a HA, all packets addressed to the MR or a LFN
are intercepted on the home link. The HA examines its Binding
Cache for an entry corresponding to the destination address
(see section 4.2.2 "Searching the Binding Cache"). If a CoA is
returned, the packet is tunneled to this CoA as specified in
Ernst & Olivereau Expires September 2002 [Page 15]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
[MIPv6].
4.3.3. MR Operation
Obtaining a care-of address
Similarly to a standard MN Operation defined in [MIPv6], the MR
obtains a new CoA on each subsequent foreign links using either
stateless or stateful DHCPv6 address configuration.
____
| |
| CN | Binding cache:
|____| 3ffe:306:1130:100::eui64 -> COA
| 3ffe:306:1130:200/64 -> COA
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_ ____
| | | | | | Home Agent
| R2 | | R1 | | HA | Binding cache:
|____| |____| |____| 3ffe:306:1130:100::eui64 -> COA
| | | 3ffe:306:1130:200/64 -> COA
| | |
_______|__ foreign __|________|____ home link
| link | 3ffe:306:1130:100::/64
__|_
| | Mobile Router
| MR | home address 3ffe:306:1130:100::eui64
|____| COA 3ffe:306:5555:7777::eui64
|
_____|_________ internal link
| | 3ffe:306:1130:200::/64
__|___ __|___
| | | |
| LFN2 | | LFN1 | Local Fixed Node 1
|______| |______| 3ffe:306:1130:200::eui64
Figure 6 : MONET Prefix is recorded in the Binding Cache
Receiving encapsulated packets from the Home Agent
The MR may receive packet encapsulated to its CoA. Those
packets may indeed be intended to the MR itself or to any LFN
served by the MR. The reception of an encapsulated packet
Ernst & Olivereau Expires September 2002 [Page 16]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
tunneled from the MR's HA is an indication that the original
sender may not have a Binding Cache entry for the MONET Prefix.
In this case, the MR may deduce that a Prefix Scope Binding
Update should be sent to the original sender of the packet.
Sending Prefix Scope Binding Updates
A MR serving as a gateway to a MONET sends Prefix Scope Binding
Update datagrams to its HA, its own CNs, and CNs of the LFNs it
is serving. Prefix Scope Binding Updates are sent as specified
in [MIPv6] section 10.6 and 10.8 and the Binding List is filled
accordingly. In addition, the MR sets the "Prefix Scope
Registration" bit in the Binding Update Option and inserts a
MONET Sub-Option. The "Prefix Length" and the "MONET Prefix"
fields are filled according to the MONET Prefix owned by the
MR.
Bypassing ingress filtering
In order to bypass ingress filtering, the MR may encapsulate
all outgoing packets to the destination with its CoA as the
outer source address.
5. Security Issues
Prefix Scope Binding Update faces a number of security issues and is
subject to modifications when a solution to secure Mobile IPv6 is
found [MIPv6-SECURITY]. We are therefore monitoring ongoing
discussion on the IETF mobileip mailing list.
5.1. Authentication
The registration of the MR's CoA for a MONET Prefix does not break
authentication and does not differ from the standard Mobile IPv6
registration for a Mobile Node. In Mobile IPv6, the Mobile Node is
authenticated by the CN based on its home address, whatever the
content of the Binding Update. Similarly, nothing breaks the
authentication of the sender of a Prefix Scope Binding Update. The MR
operates as a standard Mobile Node and has a home address.
Authentication is still based on this home address. Recipients of
the prefix scope Binding Updates are not misled about the identity of
the sender. The MR is clearly authenticated by its HA and CNs
whatever is contained in the Binding Update.
5.2. Authorization
Discussion in the mailing list and IETF meetings have advocated a
need to extend Mobile IPv6 with authorization. In the standard Mobile
Ernst & Olivereau Expires September 2002 [Page 17]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
IPv6, the Mobile Node is authenticated by its HA and CNs but those
have no guarantee that the Mobile Node is allowed to send a Binding
Update for the home address specified in the Binding Update. Indeed,
the Mobile IPv6 policy is to accept whatever is being carried in the
Binding Update as long as the sender is authenticated.
A MR willing to send Prefix Scope Binding Updates faces the same
authorization issue. In addition, a means is required to authorize a
MR to register a binding between the MONET Prefix and its CoA. In
other words, we need a means to certify that the MR actually owns and
serves the MONET Prefix.
5.3. Prefix Ownership
Two solutions are currently considered as suitable for ensuring
address ownership for a Mobile Node: Cryptographically Generated
Addresses (CGA) and Return Routability (RR) [IETF-52]. Both could be
adapted for MRs, although it would require some enhancements to the
protocols.
A Cryptographically Generated Address is obtained from a hash of a
public key. The address is thus bound to a private key / public key
pair that is used to sign the Binding Update. Extending the concept
of CGA towards 'Cryptographically Generated Sub-Prefixes' does not
seem to be applicable, except for specially long sub-prefixes.
Indeed, the robustness of the algorithm against collisions is
directly dependent on the space available to generate the (hopefully)
unique identifier.
Return Routability model consists in verifying that the claimed home
address is actually reachable at the given CoA. RR-based solutions
would be easier to consider for ensuring prefix ownership. Whereas
it cannot be envisioned to check return routability for every
possible address behind the claimed prefix, it can be sufficient to
check only a limited number of addresses, provided that they are
properly chosen. For example, MR Home Agent address, MR Home Address,
and any MNN Home Address may be enough for a CN to validate a
received Prefix Scope Binding Update.
Ernst & Olivereau Expires September 2002 [Page 18]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
6. Changes since last draft
Changes from draft-v2 to draft-v3
- Security section updated to take into account recent discussion
on the mobileip mailing list about security: section 5.2.1 and
5.2.2 are replaced by section 5.3.
- Terminology: all the terminology used in this draft has been
refined in order to comply with [TERMINOLOGY] discussed in [WEB-
MONET].
- Rewording of most sections
Changes from draft-v1 to draft-v2
- Abstract rewritten
- Extended section about security issues.
- Clarification between "home subnet prefix" and "MONET Prefix" in
the terminology.
- Section 3.3 divided into 3.3 and 3.4
- Added section "Receiving encapsulated packets from the Home
Agent"
- Minor misspelling corrections
Changes from draft-v0 to draft-v1
- Updated definitions of the terminology section 2.2,
particularly:
o clarified the distinction between possible kinds of nodes
located in the MONET: Local Fixed Nodes (LFN) and Visiting
Mobile Nodes (VMN).
o clarified that the MR has (at least) two interfaces, one on
the home link, one on the internal link (within the MONET)
- New example showing IPv6 addresses
- Added a description of an experimentation outlining HA is unable
to tunnel packets to the MONET if the final destination is not the
MR itself.
Ernst & Olivereau Expires September 2002 [Page 19]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
- Enhanced section about security concerns
Acknowledgments
This work has originally been supported by Motorola Labs Paris and
ANRT (French ``Association Nationale de la Recherche Technique'')
under CIFRE convention number 97595. This CIFRE convention
associates: a firm, Motorola Labs (Paris, France); a French academic
laboratory (INRIA Rhône-Alpes, Grenoble) and a French university
(University Joseph Fourier, Grenoble). We would like to thank Francis
Dupont (ENST Bretagne) for his careful reading, valuable comments and
suggestions, and also Christophe Janneteau (Motorola Labs), Alexandru
Petrescu (Motorola Labs), Ryuji Wakikawa (WIDE Project, Keio
University), and Koshiro Mitsuya (WIDE Project, Keio University) for
all their comments. The first author would like to thank both
Motorola Labs Paris and INRIA Rhône-Alpes, for being given the
opportunity to bring this topic to the IETF.
References
[Ernst01] Thierry Ernst "Network Mobility Support in IPv6",
PhD Thesis, University Joseph Fourier Grenoble,
France, October 2001.
[HMIP] Hesham Soliman, Claude Castelluccia,
"Hierarchical MIPv6 mobility management",
<draft-ietf-mobileip-hmipv6-03.txt>,
IETF, February 2001. Work in progress.
[IETF-52] Proceedings IETF Meeting
Salt Lake City, December 2001,
http://www.ietf.org/proceedings/01dec/slides/mobileip-6/
[IPv6] S. Deering and R. Hinden.
Internet Protocol Version 6 (IPv6) Specification.
RFC 2460, December 1998.
[MIPv4] C. Perkins (Editor). "IP Mobility Support",
RFC 2002, October 1996.
[MIPv4-RO] C. Perkins and D. B. Johnson. "Route Optimization in
Mobile IP", Sun Microsystems and Carnegie Mellon
University, February 2000. Work in progress.
[MIPv6] D. B. Johnson and C. Perkins. "Mobility Support in
IPv6", April 2000. Work in progress.
[MIPv6-SECURITY] G. Montenegro, A. Petrescu "MIPv6 Security:
Ernst & Olivereau Expires September 2002 [Page 20]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
Assessment of Proposals"
<draft-montenegro-mobileip-mipv6-seceval-00.txt>,
IETF, November 2001. Work in progress.
[Ownnership] P. Nikander. An Address Ownership Problem in IPv6,
<draft-nikander-ipng-address-ownership-00.txt>,
IETF, February 2001. Work in progress.
[Perkins98] C. Perkins, "Mobile IP, Design Principles and
Practices". Wireless Communications Series.
Addison-Wesley, 1998. ISBN 0-201-63469-4.
[REQUI-1] Thierry Ernst, Hong-Yon Lach
"Requirements for Network Mobility Support",
<draft-ernst-monet-requirements-00.txt>,
IETF, February 2001. Work in progress.
[REQUI-2] Lach, Boot, Janneteau, Olivereau, Petrescu
"Mobile Network Scenarios, Scope and Requirements",
<draft-lach-monet-requirements-00.txt>,
IETF, February 2002. Work in progress.
[REQUI-3] T. J. Kniveton, J. T. Malinen, V. Devarapalli,
C. Perkins. "Mobile Router Support with Mobile IP"
<draft-kniveton-monet-requirements.txt>,
IETF, February 2002. Work in progress.
[Solomon98] J. D. Solomon. "Mobile IP, The Internet Unplugged".
Prentice Hall Series in Computer Networking and
Distributed Systems. Prentice Hall PTR, 1998.
ISBN 0-13-856246-6.
[TERMINOLOGY] Thierry Ernst, Hong-Yon Lach
"Terminology for Network Mobility Support",
<draft-ernst-monet-terminology-00.txt>,
IETF, February 2002. Work in progress.
[WEB-MONET] MONET web page http://www.nal.motlabs.com/monet
Author's Addresses
Please direct questions about this memo to first author
Thierry Ernst,
WIDE Project and INRIA
Jun Murai lab, Keio University
5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan.
Phone : +81-466-49-1100
Ernst & Olivereau Expires September 2002 [Page 21]
INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002
Fax : +81-466-49-1395
E-mail: ernst@sfc.wide.ad.jp
Web: http://www.sfc.wide.ad.jp/~ernst/
Alexis Olivereau
Motorola Labs Paris,
Networking and Applications Lab (NAL)
Espace Technologique - Saint Aubin
91193 Gif-sur-Yvette Cedex, France
Phone: +33 1 69 35 25 16
Email: Alexis.Olivereau@crm.mot.com
Ludovic Bellier
INRIA - PLANETE team
ZIRST-655 avenue de l'Europe
38330 Montbonnot Saint Martin, France
Email: Ludovic.Bellier@inrialpes.fr
Claude Castelluccia
INRIA - PLANETE team
ZIRST-655 avenue de l'Europe
38330 Montbonnot Saint Martin, France
Phone: +33 4 76 61 52 15
Email: Claude.Castelluccia@inrialpes.fr
Hong-Yon Lach
Motorola Labs Paris,
Networking and Applications Lab (NAL)
Espace Technologique - Saint Aubin
91193 Gif-sur-Yvette Cedex, France
Phone: +33 1 69 35 25 36
Email: Hong-Yon.Lach@crm.mot.com
Ernst & Olivereau Expires September 2002 [Page 22]