One document matched: draft-wakikawa-nemo-basic-00.tx.txt
INTERNET DRAFT Ryuji Wakikawa
18 Feb 2003 Keisuke Uehara
Koshiro Mitsuya
Thierry Ernst
Keio University and WIDE
Basic Network Mobility Support
draft-wakikawa-nemo-basic-00.txt
Status of This Memo
This document is a submission to the Network Mobility Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the nemo@nal.motlabs.com mailing list.
Distribution of this memo is unlimited.
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 proposes a solution for Basic Network Support. It
proposes Mobile IPv6 extensions as advocated by the NEMO working
group. Our solution differs from Prefix Scope Binding Update (PSBU)
which was originally proposed before the NEMO working group was set
up. Our draft however uses mechanisms similar to those of PSBU, such
as ``Prefix binding'' and ``Searching mechanism of prefix binding''.
The main difference relies on the management of the permanent address
of the MR, which is assigned to the ingress interface, and not to the
egress interface.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page i]
Internet Draft Basic NEMO Support 18 Feb 2003
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 2
3. Protocol Overview 3
4. Mobile IPv6 extension 5
4.1. Binding Cache and Binding Update Management . . . . . . . 5
4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6
4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 6
4.4. Prefix Sub-option . . . . . . . . . . . . . . . . . . . . 7
4.5. Extended Use of Home Address Option . . . . . . . . . . . 7
4.6. Search Algorithm of Prefix Binding in Binding Cache . . . 8
5. Mobile Router Operation 9
5.1. Packet Processing . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Forwarding Packets to the Internet . . . . . . . 9
5.1.2. Receiving Packets from HA . . . . . . . . . . . . 9
5.1.3. MR acting as an end-node . . . . . . . . . . . . 9
5.2. Binding Processing . . . . . . . . . . . . . . . . . . . 10
5.2.1. Sending Binding Updates . . . . . . . . . . . . . 10
5.2.2. Receiving Binding Acknowledgments . . . . . . . . 10
5.3. Returning to HA link . . . . . . . . . . . . . . . . . . 11
5.4. Types of Tunneled Packets to HA . . . . . . . . . . . . . 12
6. Home Agent Operation 12
6.1. Processing Bindings . . . . . . . . . . . . . . . . . . . 12
6.1.1. Receiving Binding Updates . . . . . . . . . . . . 12
6.1.2. Sending Binding Acknowledgments . . . . . . . . . 13
6.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Sending Packets to MR . . . . . . . . . . . . . . 14
6.2.2. Receiving Packets from MR . . . . . . . . . . . . 14
6.3. Types of Tunneled Packets to MR . . . . . . . . . . . . . 15
7. Security Overview 15
8. Multicast Support 17
9. Mobile IPv6 Compatibility 17
R. Wakikawa et.al. Expires 18 Aug 2003 [Page ii]
Internet Draft Basic NEMO Support 18 Feb 2003
10. Nested Mobility 18
10.1. Visiting MN Attached to Mobile Network . . . . . . . . . 18
10.2. MR Attached to Mobile Network . . . . . . . . . . . . . . 18
Acknowledgments 18
Appendices 19
A. Specification Comparison with WG requirements 19
References 19
Authors' Addresses 21
1. Introduction
The proposed protocol is designed as an extension to Mobile IPv6.
All the requirements for a basic NEMO solution are described in [6].
The solution for basic network mobility support is to set up a
bi-directional tunnel between the MR and its HA. This protocol
establishes the bi-directional tunnel by binding operation of Mobile
IPv6. This draft extends the usage of home address option, binding
update option, and binding management and defines a prefix sub-option
for binding update message. This draft also extends the definition
of binding to manage a various prefix length for a home address.
Details regarding the modifications to existing Mobile IPv6 will be
mentioned later in this document.
A similar approach was first proposed as PSBU [7]. PSBU proposed the
notion of prefix binding. The difference from PSBU is the management
of MR's home address. This draft need not to assign a home address
which is different from a mobile network prefix. MR has still a
permanent address, but is the address of the ingress interface named
on the mobile router address instead of the address of the egress
interface on the same link as the HA.
This difference makes possible to communicate in various network
topologies such as nested mobility and multiple HA links which
are like home link of MR. It also achieves to authorize and
authenticate mobile network prefix with MR as described in section 7.
In addition, MR's host mobility by means of its home address
is managed as a part of network mobility. Therefore, it gives
several optimization to reduce the size of packets as described in
section 5.1.3 and section 5.3.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 1]
Internet Draft Basic NEMO Support 18 Feb 2003
2. Terminology
The keywords ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
``OPTIONAL'' in this document are to be interpreted as described in
RFC 2119 [2].
Most of terms are defined in [8].
Mobile Router Address (MR-A)
The permanent address generated by a delegated mobile network
prefix and statically assigned to the ingress interface.
Mobile Router Care-of Address (MR-CoA)
The address which is dynamically assigned to the egress
interface of MR on the foreign link.
Prefix Binding
The prefix binding associates between a mobile network prefix
and a MR-CoA. The prefix binding is stored in the binding cache
as well as a binding of Mobile IPv6[11]. The prefix binding
is first proposed in PSBU, but our prefix binding store the
information in the following two way:
- If a prefix binding is searched with the registered prefix
length, it becomes the binding for a mobile network prefix
- If a prefix binding is searched with 128-bit prefix length
as general Mobile IPv6, it becomes the binding of the MR.
In this case, the MR is treated as a MN.
Home Agent (HA)
HA MUST be able to delegate a prefix to a MR by any delegation
protocols. How to delegate prefix is currently out of scope
in this draft, but any updates of prefix delegation for mobile
network must be employed on this protocol. This will be
clarified in a forthcoming revision of the draft.
The HA MUST NOT have an address belonging to a mobile network
prefix, but it MUST be addressed by any IPv6 global address.
For dynamic configuration, a MR obtain a HA address during
prefix delegation operations.
MR MUST have a HA configured either statically or dynamically
in the Internet. The HA MUST advertise route information
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 2]
Internet Draft Basic NEMO Support 18 Feb 2003
of mobile network prefix by any routing protocols such
as OSPF6 [3], RIPng [15], BGP [14], etc. and it MUST be
identified as a gateway of the prefix in the Internet topology.
HA link
The HA link is not the link for a mobile network prefix, but
it is the link of the HA. The prefix advertised on the HA link
MUST be different from the mobile network prefix. The prefix
MUST be managed by HA. MR MAY return to the HA link. HA can
manage several HA links if needed. There is no difference in
the operations between single HA link and multiple HA links.
Prefix Sub-option
A mobility header sub-option is used to carry a prefix length
of a mobile network. This sub-option is valid only in Binding
Update (BU).
3. Protocol Overview
This section shows the protocol outline. The figure 1 is a typical
network configuration of a mobile network. MR is attached to a
visiting network in this figure. Protocol operations is split into
below steps.
1. MR acquisition of Mobile Network Prefix: At the beginning, MR
MUST have a mobile network prefix delegated from its HA. Dynamic
HA discovery can be used to discover the HA address by MR. MR
can also have a statically configured HA before starting any
operations.
2. MR configuration of MR-A to egress interfaces: The MR,
carrying a mobile network attaching to the Internet, has a home
address (MR-A) assigned to its ingress interface. The MR-A is
generated by the mobile network prefix (ex. mobile network
prefix and MR's EUI-64 identifier). The MR can be identified
with MR-A from the Internet regardless of its location in the
Internet.
3. MR configuration of MR-CoA to ingress interfaces: When the MR
moves to a different network, the MR obtains a topologically
correct global address as a MR-CoA at the egress interface.
4. MR sending BU to HA: The MR sends a BU to its HA to create a
prefix binding instead of host binding. The BU MUST contain a
home address option containing MR-A and a prefix sub-option with
the length of its mobile network prefix. The prefix sub-option
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 3]
Internet Draft Basic NEMO Support 18 Feb 2003
CN CN CN CN CN CN
___|__|___|___|___|___|___
|
___|_____________________
| |
| Internet |
|________________________|
__|_ __|__ <-- HA Address 3ffe:306:1130::eui64
| | | | Prefix Binding
| AR | | HA | MR-A/64<->MR-CoA
|____| |_____|
| ____|______ HA Link (3ffe:306:1130:1::/64)
_______|________
foreign link 3ffe:306:5555:7777::/64
|
|
__|<-- MR-CoA 3ffe:306:5555:7777::mr_eui64
| |
| MR | Mobile Network Prefix 3ffe:306:1130:200::/64
|____|
|<-- MR-A 3ffe:306:1130:200::mr_eui64
_____|_________
| |
__|__ __|__
| | | |
| MNN | | MNN |
|_____| |_____| 3ffe:306:1130:200::eui64
Figure 1: Example of Mobile Network Configuration
is defined in section 4.4. If the BU is successfully processed
by the HA, the MR creates a tunnel to the HA as shown in [11].
5. HA caching of Prefix Binding: When receiving the BU, the HA
caches prefix binding. The HA retrieves the mobile network
prefix from the MR-A with the mobile network prefix length in the
prefix sub-option. The MR-A is stored at the home address option
in the BU. The MR-CoA is stored in a source address field of IPv6
header. This prefix binding can also be treated as a Mobile IPv6
binding of the MR.
6. HA tunneling packets addressed to Mobile Network: The HA
intercepts and tunnels all packets destined to the MR's mobile
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 4]
Internet Draft Basic NEMO Support 18 Feb 2003
network prefix by IP-in-IP encapsulation. The HA operation of
tunneling packets is same as Mobile IPv6 except for binding
search. Since the MR registers the prefix binding containing the
prefix length, the HA MUST use address longest-match algorithm
to scan the binding cache database. First HA MUST search the
binding with 128-bit prefix length for intercepted packets.
If HA finds a binding, it MUST tunnel packets as Mobile IPv6
operation. Otherwise, the HA MUST compare the destination
address of intercepted packets with the MR's mobile network
prefix. If the HA finds a prefix binding, the HA MUST tunnel
packets to the registering MR-CoA.
7. Sending packet from MNN to a CN in the global Internet: When
a MNN in the mobile network sends packets to the Internet, the
MR intercepts the packets and encapsulates them to the HA. The
source address of encapsulated packets is the MR-CoA to bypass
ingress filtering. MR MUST NOT insert the home address option
as general Mobile IPv6, since falsification of MNNs' packets
on intermediate nodes like MR should be avoided from security
considerations. Although encapsulation of packets [4] add
additional IPv6 header, it does not change the orignal packets.
8. Sending packet from MR to HA or a CN in the global Internet:
When the MR sends packets to its registered HA as a MN, it is
RECOMMENDED to use a home address option storing the MR-A. These
operation is the same as Mobile IPv6. This keeps the additional
packet's size smaller than the additional size of tunneled
packets. e.x. home address option (20byte) is smaller than IPv6
header (40 bytes). The HA is RECOMMENDED to reply packets with
a routing header type 2. The MR MAY tunnel packets to the HA
instead of using a home address option, and vice versa.
If the destination is CNs, the MR MUST always tunnel packets via
HA.
9. MR management of routing information inside mobile network
The routing management inside a mobile network is not discussed
in this draft, but any protocol such as OSPF6, RIPng, or any
MANET protocol [18] can be used.
4. Mobile IPv6 extension
4.1. Binding Cache and Binding Update Management
This draft requires to have an additional item for binding cache and
binding update structures defined in Mobile IPv6, which is
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 5]
Internet Draft Basic NEMO Support 18 Feb 2003
- Prefix Length
The prefix length of a mobile network prefix. The mobile network
prefix is identified by MR-A and the prefix length.
MR MUST keep prefix length in its binding update list database.
HA MUST register the prefix length in its binding cache if the prefix
length is available in the BU. HA MUST use the prefix length to
search a binding cache database if needed.
4.2. Binding Update
When MR registers its prefix binding to its HA, the MR MUST set 'N'
flag and include the prefix sub-option.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|N| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Mobility Flag (N)
Network Mobility Flag: used for a prefix binding
registration. This flag defines that this BU contains a
prefix sub-option and is for a mobile network.
Reserved
Reserved field is reduced to 11 bits.
4.3. Binding Acknowledgment
Since the 'N' flag is valid only for the HA (i.e. home
registration), HA which receives BU with 'N' flag MUST reply BA
as described in section 6.1.2. The receiver also MUST reply BA
with correspondent error number if it encounters some error while
processing BU and its sub-option.
This document assigns new status codes for mobile network prefix
registration.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 6]
Internet Draft Basic NEMO Support 18 Feb 2003
2 Successfully registered a mobile network prefix
3 Successfully registered a mobile network prefix at HA link
140 Invalid Prefix Length
4.4. Prefix Sub-option
Prefix sub-option MAY only be appended in a BU message. Prefix
length field contains the length of a mobile network prefix.
Receiving nodes MUST use this prefix length whenever they refer to
binding cache database.
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 = 2 | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(alignment requirement: 2n)
Type
TBD
Length
2
The length of the option (excluding the type and length fields)
in units of 8 octets.
Prefix Length
The 8 bit IPv6 prefix length of a mobile network prefix
reserved
The 8 bit reserved field. MUST be set to zero.
4.5. Extended Use of Home Address Option
In Mobile IPv6 [11], Mobile Node (MN) uses one of its Care-of
Addresses (CoAs) as the source address in the packets' IPv6 header
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 7]
Internet Draft Basic NEMO Support 18 Feb 2003
and puts the home address in a home address option. CNs substitute
the MN's home address with the CoA when processing the packet. A
Home Address option is used in a packet sent by the MN to inform the
recipient of the fact that packets are of the MN's home address.
MR only uses home address option for BU packets and MUST NOT use
it for any packets other than control packets (i.e. BU) and its
originated packets. Insertion of the home address option on MR
alters orignal packets. Modifying MNNs' packets on MR should be
avoided for security considerations. Therefore, for outgoing data
packets from MNN, MR encapsulate packets with MR-CoA as an IPv6
source address to bypass ingress filtering. Although encapsulation
of packets add additional IPv6 header, it does not change orignal
packets.
If MR originates packets to its registering HA as a MN, it SHOULD use
the home address option as MN of Mobile IPv6.
4.6. Search Algorithm of Prefix Binding in Binding Cache
The similar search algorithm was first proposed in PSBU [7].
Prefix binding enables HA to find an appropriate prefix binding for
packets destined to mobile network. Mobile IPv6 always searches
a binding cache entry with 128-bit prefix length. Therefore, it
can not pick a prefix binding for packets destined to MNNs, because
addresses between MR (MR-A) and MNNs are different in 128-bit prefix
length. Thus, the binding cache MUST be searched by using a mobile
network prefix (a prefix length part of MR-A). The prefix between
MR (MR-A) and MNNs are the same.
The efficient algorithm for this situation is the address
longest-match. The sequence of this search is as shown below:
1 HA searches a binding cache database with 128-bit prefix length
as Mobile IPv6.
2 HA searches a binding cache database with a registered prefix
length in a prefix binding only if a prefix length is available
(i.e. the binding is a prefix binding).
When packets are destined to the MR-A itself (not MNN), the algorithm
enables HA to find a prefix binding as a Mobile IPv6 binding for
the MR-A. This is important when there are multiple MRs in a mobile
network and MRs advertised a same mobile network prefix. If HA
search a binding cache database only by the second algorithm, HA can
not determine which MR is the destination node of the packets. It is
because the mobile network prefix of each MR-A is the same value.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 8]
Internet Draft Basic NEMO Support 18 Feb 2003
5. Mobile Router Operation
5.1. Packet Processing
5.1.1. Forwarding Packets to the Internet
When MR receives packet from MNNs on its ingress interface and
intended to a CN in the global Internet, it MUSTS tunnels these
packets to its HA.
Outer IP header MUST be constructed as follows whenever the MR
tunnels packets.
- The source IP address of the outer IP header MUST be the MR-CoA
- The destination IP address of the outer IP header MUST be the HA
address.
5.1.2. Receiving Packets from HA
While away from home, MR will receive packets from correspondent
nodes tunneled via HA. Whenever the MR receives tunneled packets
destined to its mobile network prefix from the HA, the MR MUST check
the following sequences.
- The destination address of the outer IP header MUST be MR-CoA.
- The source address of the outer IP header MUST be the address of
the HA currently registering MR's binding.
If tunneled packets do not satisfy above conditions, the MR
SHOULD NOT route these packets to the final destination (i.e. The
destination node of inner IPv6 packets (MNN)).
5.1.3. MR acting as an end-node
If MR needs to communicate with a correspondent node with its MR-A,
it MUST send packets through bidirectional tunneling via HA described
in section 5.1.1.
Instead, if the destination of MR's packet is the MR's current
registering HA, MR SHOULD follow general Mobile IPv6 operation except
for the operations of ``returning home'' and ``Route Optimization''.
Packets from the MR SHOULD be carried with a home address option
set to the MR-A. Packets to the MR SHOULD be routed by a routing
header type 2 set to the MR-CoA. The HA MUST verify the MR-A with
registereing bindings. If the HA can not find the binding for the
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 9]
Internet Draft Basic NEMO Support 18 Feb 2003
MR-A, it MUST discard these packets and SHOULD send Binding Error
described in the Mobile IPv6 specification.
The MR SHOULD also accept tunneled packets originally destined to
MR-A from the HA, and the HA SHOULD also accept tunneled packets
originally destined to the HA from the MR-A.
Operation of ''returning home'' is described in the section 5.3. MR
MUST NOT start return routability operation for route optimization.
All the packets MUST be tunneled thorough HA (i.e. redirectional
tunneling).
5.2. Binding Processing
5.2.1. Sending Binding Updates
If prefix length is available in the binding update list, MR MUST
send BU with a prefix sub-option. The operation of sending BUs to HA
is same as Mobile IPv6 except for following procedure.
- 'N' bit MUST be set in BU
- 'L' bit MUST NOT be set in BU
- 'H' bit MUST be set in BU if the BU is for home registration.
- A prefix sub-option MUST be contained in the BU. In the prefix
sub-option, MR MUST set the length of its mobile network prefix.
MR MUST NOT send BU which do not match the above procedure.
5.2.2. Receiving Binding Acknowledgments
BA MUST be protected by IPsec transport mode. If the BA is not
protected by appropriate IPsec, MR MUST silently discard the BA.
Other procedures to verify BA is described in [11]
In the Mobile IPv6 specification, if the status field is less than
'128', it indicates successful registration of its binding. On the
other hand, this draft requires status value either '2' or '3' for
successful registration. MR MUST establish a tunnel with HA after
successful registration and starts tunneling packets from the mobile
network. If the value is not '2' and '3', the MR SHOULD retry to
send BU for its mobile network prefix or MAY stop sending BU.
If the status field is '3', the MR is back to HA link. The MR should
follow the operation described in section 5.3.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 10]
Internet Draft Basic NEMO Support 18 Feb 2003
If the status field indicates that the BU was rejected, the MR SHOULD
NOT send BUs to this destination.
5.3. Returning to HA link
CN CN CN CN CN CN
___|__|___|___|___|___|___
|
___|_____________________
| |
| Internet |
|________________________|
__|_ __|__ <-- HA Address 3ffe:306:1130::eui64
| | | | Prefix Binding
| AR | | HA | MR-A/64<->MR-CoA*
|____| |_____| (*MR-CoA is on-link address for HA)
| _________|______ HA Link (3ffe:306:1130:1::/64)
|
|
__|<-- MR-CoA 3ffe:306:1130:1::mr_eui64
| |
| MR | Mobile Network Prefix 3ffe:306:1130:200::/64
|____|
|<-- MR-A 3ffe:306:1130:200::mr_eui64
_____|_________
| |
__|__ __|__
| | | |
| MNN | | MNN |
|_____| |_____| 3ffe:306:1130:200::eui64
Figure 2: Mobile Network attached to the HA link
When MR returns to the link of its HA, the MR will obtain MR-CoA from
HA's router advertisement messages. The MR-CoA is different from the
mobile network prefix. Therefore, the MR MUST send BU like any other
foreign link. This is because the HA needs to know the exact HA link
where the MR has attached to. The MR detects the returning to HA
link by receiving BA with the status code '3' from the HA.
On the HA link, MR becomes on-link with the HA. Therefore the MR
SHOULD route packets directly to the HA. The MR MAY receive packets
directly route from the HA without any IP-in-IP encapsulation.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 11]
Internet Draft Basic NEMO Support 18 Feb 2003
The MR MUST accept these packets and route them correctly to a
destination of packets. The MR SHOULD route packets from MNN to the
HA without encapsulation.
5.4. Types of Tunneled Packets to HA
MR MUST determine whether packets should be tunneled to HA or not,
according to the following ruleset.
- Global Scoped Packets sent by MNN
If packets are sent by MNN with global scope and are addressed to
hosts out of mobile network, MR MUST tunnel these packets to HA.
- Link Local Scoped Packets in a mobile network
MR MUST NOT tunnel any link-local scoped packets inside mobile
network such as Neighbor Discovery Protocol (NDP) [16] packets
and packets destined to all node multicast address.
- Site Local Scoped Packets in a mobile network
This draft currently does not consider site local scoped packets.
Therefore, MR MUST NOT tunnel these packets and MUST route them
only inside its mobile network.
- Routing Messages of Mobile Network Prefix
MR MAY tunnel any routing messages of its mobile network prefix.
- Multicast Routing Message
MR MUST tunnel all control messages of multicast routing
protocols [9] [17] to HA.
- Multicast Packets
MR MUST tunnel multicast routing packets destined to a multicast
address with global scope as described in section 8
If MR received tunneled packets which does not satisfy the ruleset
described in section 6.3, it MUST silently discard these packets.
6. Home Agent Operation
6.1. Processing Bindings
6.1.1. Receiving Binding Updates
BU MUST be protected by IPsec transport mode described in the
section 7. Otherwise, HA MUST silently discard the BU.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 12]
Internet Draft Basic NEMO Support 18 Feb 2003
Verification of BU is the same as Mobile IPv6 except for following
procedure.
- If `N' bit is set in BU, Prefix sub-option MUST be present in the
option field. Otherwise, the HA MUST discard the BU and return
BA with status code set to '140' (Invalid Prefix Length).
- If 'N' bit is set and 'L' bit is also set in BU, the HA MUST
discard the BU and returns BA with status code set to '129'
(Administratively prohibited).
- If the ``Prefix Length'' of the prefix sub-option is equal to
'128', the HA MUST discard the BU and returns BA with status code
set to '140' (Invalid Prefix Length).
- If the ``Prefix Length'' of the prefix sub-option is greater than
'128', the HA MUST discard the BU and returns BA with status code
set to '140' (Invalid Prefix Length).
- If 'N' bit is set and 'H' bit is also set in BU, the HA MUST
register the prefix binding as home registration and MUST return
BA with status code set to '2'.
- If the prefix binding is successfully registered and MR-CoA is
generated by one of the HA's managed prefix, the HA MUST return
BA with status code set to '3' to indicate returning the HA link.
If HA successfully processes BU and registers a prefix binding for
the requesting MR, the HA MUST establish a tunnel with the MR. After
the registration, the HA MUST intercept packets destined to the
mobile network and MUST forward these packets to the MR by IP-in-IP
encapsulation. Since the HA is identified as a gateway of the mobile
network prefix in the Internet topology, the HA receives these
packets routed to itself.
6.1.2. Sending Binding Acknowledgments
Operation procedure of sending BA is same as the Mobile IPv6
specification except for following. MR-A is treated as a home
address.
IF the status code is '140', HA MUST NOT use a prefix binding for the
destination address of BA and MUST NOT use a routing header type 2
for BA.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 13]
Internet Draft Basic NEMO Support 18 Feb 2003
6.2. Packet Processing
6.2.1. Sending Packets to MR
While MR is away from HA link, HA intercepts packets destined to
the registered mobile network prefix. It MUST route packets to the
registered MR. Thus, the HA tunnels packets to registered MR-CoA by
IP-in-IP encapsulation.
Outer IP header MUST be constructed as follows whenever the HA
tunnels packets to the MR.
- The source IP address of the outer IP header MUST be the HA
address.
- The destination IP address of the outer IP header MUST be the
MR-CoA registered in the prefix binding.
If packets do not satisfy above conditions, the MR SHOULD NOT route
tunneled packets to the final destination (i.e. destination node of
inner IPv6 packets).
When MR is attached to a HA link, on the other hand, the HA
SHOULD route packets to the mobile network according to general
IP routing. The HA MAY NOT have exact routing entries for the
mobile network prefix, but it knows the next-hop address of the
mobile network prefix from the registered prefix binding. If the
MR-CoA is configured by one of the HA's prefix, the MR-CoA becomes
on-link at HA link. The HA should route packets to the next-hop
address (MR-CoA) of the registered prefix binding.
6.2.2. Receiving Packets from MR
While MR is away from HA link, HA receives packets tunneled to the HA
from the MR. Whenever the HA receives tunneled packets from the MR,
the HA MUST perform following common sequence.
- The destination address of the outer IP header MUST be the HA
address.
- The source address of the outer IP header MUST be the MR-CoA
which is registered in the prefix binding.
If packets do not satisfy above conditions, the HA SHOULD NOT route
tunneled packets to the final destination (i.e. destination node of
inner IPv6 packets).
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 14]
Internet Draft Basic NEMO Support 18 Feb 2003
If the MR is located at the HA link, it will route packets without
IP-in-IP encapsulation. The HA MUST verify MR's availability at its
HA link. The HA compares the MR-CoA with HA's managing prefixes. If
the MR-CoA is active at one of the HA link, the HA MUST route packets
to the destination of packets. Otherwise, the HA MUST silently
discard these packets. These packets may not be originated from the
mobile network, because the owner of the mobile network prefix (MR)
is not located at the HA link.
6.3. Types of Tunneled Packets to MR
HA MUST determine whether packets are tunneled to MR or not,
according to the following ruleset.
- Global Scoped Packets destined to a mobile network
If HA received packets destined to a mobile network prefix, the
HA MUST tunnel this packet to the MR.
- Routing Messages
HA MAY tunnel any routing information obtained by routing
protocols. While away from HA link, MR MUST NOT accept any
routing messages tunneled by the HA. Also, the MR SHOULD NOT
accept any routing messages to update its routing table except
for default routes at a visiting link.
- Multicast Routing Message
HA MUST tunnel all control messages of multicast routing
protocols [9] [17] to MR.
- Multicast Packets
HA MUST tunnel multicast packets destined to multicast listers in
mobile network according to multicast routing table.
If HA received tunneled packets which do not satisfy the ruleset of
tunneled packets described in section 5.4, it MUST silently discard
these packets.
7. Security Overview
BU and Binding Acknowledgment (BA) are protected by IPsec transport
mode [12] [13] like Mobile IPv6 [1]. Since this draft uses MR-A as
a home address of MR, BU MUST be protected by using MR-A. MR-A is
generated by a mobile network prefix, thus HA can authenticate MR and
also authorize the mobile network prefix by IPsec transport mode.
The establishment of Security Association (SA) by MR-A prevents
a malicious MR to send BUs for other MR's mobile network prefix
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 15]
Internet Draft Basic NEMO Support 18 Feb 2003
to the specified HA. MR is RECOMMENDED to use ESP mode to give
confidentiality to BU by encryption of BU.
IPsec tunnel operation for HoTI and HoT is not needed in this draft,
because route optimization is out of scope in Basic NEMO Support.
IKE [10] is currently not supported.
Following example can be applied to set up Security Association
between MR and HA. The format of description is defined in section
4.1 of [1].
Security Association on MR is set up manually as follows:
MR SPD OUT:
- IF source = MR-A & destination = HA & proto = MH
THEN USE SA1
MR SPD IN:
- IF source = HA & destination = MR-A & proto = MH
THEN USE SA2
MR SAD:
- SA1(OUT, spi_a, HA, ESP, TRANSPORT):
source = MR-A & destination = HA & proto = MH
- SA2(IN, spi_b, MR-A, ESP, TRANSPORT):
source = HA & destination = MR-A & proto = MH
HA MUST NOT set up Security Association for MR before delegating a
mobile network prefix to the MR. Security Association on HA is set up
manually as follows:
HA SPD OUT:
- IF source = HA & destination = MR-A & proto = MH
THEN USE SA2
HA SPD IN:
- IF source = MR-A & destination = HA & proto = MH
THEN USE SA1
MR SAD:
- SA2(IN, spi_b, MR-A, ESP, TRANSPORT):
source = HA & destination = MR-A & proto = MH
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 16]
Internet Draft Basic NEMO Support 18 Feb 2003
- SA1(OUT, spi_a, HA, ESP, TRANSPORT):
source = MR-A & destination = HA & proto = MH
To replace home address with MR-A, steps of processing IPsec
calculation is same as section 5.1, 5.2, 5.3, 5.4 of [1].
8. Multicast Support
If a mobile network needs to support multicast, MR SHOULD be capable
of operating Multicast Listener Discovery (MLD) [5]. The MR SHOULD
know which multicast groups MNNs are currently joining. Also, the
MR MUST tunnel packets destined to a multicast address via HA. The
MR MUST run a multicast routing protocol, because the MR needs to
route multicast packets to the upper multicast router which is the
HA. Thus, the HA MUST run a multicast routing protocol in order
to exchange multicast routing information from MR. HA SHOULD also
be capable of routing multicast packets. The HA routes multicast
routing messages from MR and tunnels appropriate multicast packets to
MR if there are multicast listers in mobile network.
If MR supports multicast, it MUST determine which multicast data
packets to forward via the tunnel between HA. The MR operates this
depending on address scope as follows.
- If multicast packet is addressed to a multicast address with
link-local scope, the MR MUST NOT tunnel them to the HA and MUST
silently discard them.
- If multicast packet is addressed to a multicast address with
site-local scope, the MR SHOULD NOT tunnel them to the HA and
MUST silently discard them.
- If multicast packet is destined to a multicast address with
global scope, the MU MUST tunnel them to the HA.
If the MR receives tunneled multicast packets from the HA, it MUST
route this multicast packets to listers of this multicast group in
the mobile network.
9. Mobile IPv6 Compatibility
This protocol is fully compatible with Mobile IPv6 without any
modifications.
MR sends BU only to HA, and MUST NOT send BU to other nodes. Even if
Mobile IPv6 CN receives BU from MR, it MUST silently discard the BU.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 17]
Internet Draft Basic NEMO Support 18 Feb 2003
10. Nested Mobility
10.1. Visiting MN Attached to Mobile Network
When Visiting MN (VMN) attaches to a mobile network, it obtains a
CoA from MR's router advertisements. This address can be used as
the general CoA defined in [11]. The VMN sends BU to its HA to
register the CoA. Any additional operation is not needed to the
VMN. Incoming packets from CN and outgoing packets from the VMN are
tunneled between the MR and the MR's HA despite the Mobile IPv6 route
optimization.
Return Routability procedure can be used in this draft without any
modifications. The VMN sends HoT and receives HoT via its HA though
the bi-directional tunnel to the MR's HA. The VMN also sends CoTI
and receives CoT thorough the bi-directional tunnel. Then, the VMN
sends BU with Binding Authorization Data sub-option thorough the
bi-directional tunnel.
Outgoing packets to CN are route optimized by home address option,
but is tunneled to the MR's HA first. Incoming packets are tunneled
via the MR's and are routed to the VMN by routing header type 2
option. Packets bypass the VMN's HA in each direction.
10.2. MR Attached to Mobile Network
When MR attaches to another mobile network, it obtains a MR-CoA named
after the mobile network prefix. This address can be used as the
general MR-CoA. The MR sends BU to its HA to register the MR-CoA.
Any additional operation is not needed to the MR. Incoming packets
to sub-NEMO can be routed to the sub-MR's MR-CoA by double tunneling
both via parent-MR's HA and via sub-MR's HA. Outgoing packets from
sub-NEMO are routed to a destination by bidirectional tunneling both
via sub-MR's HA and via parent-MR's HA.
The operation does not differ if there are more nested levels.
Acknowledgments
The authors would like to thank Masafumi Watari, Susumu Koshiba and
InternetCAR group at KEIO University for their comments.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 18]
Internet Draft Basic NEMO Support 18 Feb 2003
A. Specification Comparison with WG requirements
This section lists the possible issues compared to WG requirements.
This protocol meets the requirements which are not listed in this
section. These requirements are proposed in NEMO WG [6].
R12: ``The solution MUST function for multi-homed mobile networks.
More precisely:''
R12.1: ``The solution MUST support mobile networks with multiple
MRs,''
R12.2: ``The solution MUST support MR with multiple interfaces,''
R12.3: ``The solution must support MR with multiple global
addresses on an egress interface.''
R12.2 and R12.3 is achieved by the same operation of Mobile IPv6.
See section 11.5.3 of the Mobile IPv6 specification.
R12.3 is not discussed in detail in this draft now. we need more
consideration.
R15: ``The solution MUST ensure transparent continuation of routing
and management operations over the bi-directional tunnel when the
MR is away from home. (this includes e.g. routing protocols,
router renumbering, DHCPv6, etc)''
The solution meets the requirement of transparent continuation
of routing, but router renumbering and DHCPv6 need more
consideration.
References
[1] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents
(draft-ietf-mobileip-mipv6-ha-ipsec-02). Internet Draft,
Internet Engineering Task Force, January 2003.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[3] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for
Comments (Proposed Standard) 2740, Internet Engineering Task
Force, December 1999.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 19]
Internet Draft Basic NEMO Support 18 Feb 2003
[4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. Request for Comments (Proposed Standard) 2473,
Internet Engineering Task Force, December 1998.
[5] S. Deering, W. Fenner, and B. Haberman. Multicast Listener
Discovery (MLD) for IPv6. Request for Comments (Proposed
Standard) 2710, Internet Engineering Task Force, October 1999.
[6] T. Ernst. Network Mobility Support Requirements
(draft-ietf-nemo-requirements-00). Internet Draft,
Internet Engineering Task Force, February 2003.
[7] T. Ernst and et al. Mobile Networks Support in Mobile IPv6
(draft-ernst-mobileip-v6-network-03). Internet Draft, Internet
Engineering Task Force, March 2002.
[8] T. Ernst and et al. Network Mobility Support Terminology
(draft-ernst-monet-terminology-01). Internet Draft, Internet
Engineering Task Force, November 2002.
[9] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei.
Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
specification. Request for Comments (Experimental) 2362,
Internet Engineering Task Force, June 1998.
[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE).
Request for Comments (Proposed Standard) 2409, Internet
Engineering Task Force, November 1998.
[11] D. Johnson, C. Perkins, and J. Arkko. Mobility support in
IPv6 (draft-ietf-mobileip-ipv6-20). Internet Draft, Internet
Engineering Task Force, January 2003.
[12] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[13] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). Request for Comments (Proposed Standard) 2406, Internet
Engineering Task Force, November 1998.
[14] K. Lougheed and Y. Rekhter. Border Gateway Protocol (BGP).
Request for Comments (Experimental) 1105, Internet Engineering
Task Force, June 1989.
[15] G. Malkin and R. Minnear. RIPng for IPv6. Request for Comments
(Proposed Standard) 2080, Internet Engineering Task Force,
January 1997.
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 20]
Internet Draft Basic NEMO Support 18 Feb 2003
[16] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (ipv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[17] D. Waitzman, C. Partridge, and S. E. Deering. Distance Vector
Multicast Routing Protocol. Request for Comments (Experimental)
1075, Internet Engineering Task Force, November 1988.
[18] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and
A. Tuominen. Global Connectivity for IPv6 Mobile Ad Hoc
Networks (draft-wakikawa-manet-globalv6-02). Internet Draft,
Internet Engineering Task Force, November 2002.
Authors' Addresses
Ryuji Wakikawa Koshiro Mitsuya
Keio University and WIDE Keio University and WIDE
5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa
252-8520 JAPAN 252-8520 JAPAN
Phone: +81-466-49-1394 Phone: +81-466-49-1394
Fax: +81-466-49-1395 Fax: +81-466-49-1395
EMail: ryuji@sfc.wide.ad.jp EMail: mitsuya@sfc.wide.ad.jp
Keisuke Uehara Thierry Ernst
KEIO University and WIDE Keio University and WIDE
5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa
252-8520 JAPAN 252-8520 JAPAN
Phone: +81-466-49-1394 Phone: +81-466-49-1394
Fax: +81-466-49-1395 Fax: +81-466-49-1395
EMail: kei@wide.ad.jp EMail: ernst@sfc.wide.ad.jp
R. Wakikawa et.al. Expires 18 Aug 2003 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 21:39:51 |