< draft-ietf-nemo-basic-support-02.txt   draft-ietf-nemo-basic-support-03.txt >
NEMO Working Group Vijay Devarapalli NEMO Working Group Vijay Devarapalli
INTERNET DRAFT Nokia INTERNET DRAFT Nokia
Category: Standards Track Ryuji Wakikawa Category: Standards Track Ryuji Wakikawa
Expires June 2004 Keio University Expires December 2004 Keio University
Alexandru Petrescu Alexandru Petrescu
Motorola Motorola
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
December 2003 June 2004
Network Mobility (NEMO) Basic Support Protocol Network Mobility (NEMO) Basic Support Protocol
draft-ietf-nemo-basic-support-02.txt draft-ietf-nemo-basic-support-03.txt
Status of This Memo Status of This Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note
other groups may also distribute working documents as Internet- that other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at: The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the NEMO Basic Support protocol that enables This document describes the Network Mobility (NEMO) Basic Support
mobile networks to attach to different points in the Internet. The protocol that enables mobile networks to attach to different points
protocol is an extension of Mobile IPv6 and allows for session in the Internet. The protocol is an extension of Mobile IPv6 and
continuity for every node in the mobile network as the network moves. allows for session continuity for every node in the mobile network as
It also allows every node in the mobile network to be reachable while the network moves. It also allows every node in the mobile network
moving around. The Mobile Router, which connects the network to the to be reachable while moving around. The Mobile Router, which
Internet, runs the NEMO Basic Support protocol with its Home Agent. connects the network to the Internet, runs the NEMO Basic Support
The protocol is designed in such a way that network mobility is protocol with its Home Agent. The protocol is designed in such a way
transparent to the nodes inside the mobile network. that network mobility is transparent to the nodes inside the mobile
network.
Contents Contents
Status of This Memo 1 Status of This Memo 1
Abstract 1 Abstract 1
1. Introduction 4 1. Introduction 4
2. Terminology 5 2. Terminology 5
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4. Message Formats 9 4. Message Formats 9
4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9
4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9
4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10
5. Mobile Router Operation 12 5. Mobile Router Operation 12
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 12 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 12
5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13
5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 13 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 13
5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 14 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Implicit Mode . . . . . . . . . . . . . . . . . . 14
5.4.2. Explicit Mode . . . . . . . . . . . . . . . . . . 14
5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 15 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 15
5.6. Neighbor Discovery for Mobile Router . . . . . . . . . . 16 5.6. Neighbor Discovery for Mobile Router . . . . . . . . . . 16
5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 16 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 16
5.8. Returning Home . . . . . . . . . . . . . . . . . . . . . 16 5.8. Returning Home . . . . . . . . . . . . . . . . . . . . . 16
6. Home Agent Operation 18 6. Home Agent Operation 18
6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18 6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18
6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18 6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18
6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18 6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18
6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19
6.3. Advertising Mobile Network Reachability . . . . . . . . . 20 6.3. Advertising Mobile Network Reachability . . . . . . . . . 20
6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 20 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 21
6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21
6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 21 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 22
6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22
7. Modifications to Dynamic Home Agent Discovery 23 7. Modifications to Dynamic Home Agent Discovery 24
7.1. Modified Dynamic Home Agent Discovery Request . . . . . . 23 7.1. Modified Dynamic Home Agent Discovery Request . . . . . . 24
7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . . 23 7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . . 24
7.3. Modified Home Agent Information Option . . . . . . . . . 24 7.3. Modified Home Agent Information Option . . . . . . . . . 25
8. Support for Dynamic Routing Protocols 25 8. Support for Dynamic Routing Protocols 26
9. Security Considerations 28
9. Security Considerations 27 10. IANA Considerations 29
10. IANA Considerations 28 11. Contributors 29
11. Contributors 28 12. Acknowledgements 29
12. Acknowledgements 28 A. Examples of NEMO Basic Support Operation 32
A. Examples of NEMO Basic Support Operation 31 B. Running Link State Routing Protocol with NEMO Basic Support 35
B.1. Tunnel Interface Considerations . . . . . . . . . . . . . 35
B.2. OSPF Area Considerations . . . . . . . . . . . . . . . . 35
B. Changes from Previous Version 34 C. Changes from Previous Version 37
1. Introduction 1. Introduction
This document describes protocol extensions to Mobile IPv6 (MIPv6) This document describes protocol extensions to Mobile IPv6 (MIPv6)
[1] to enable support for network mobility. The extensions are [1] to enable support for network mobility. The extensions are
backward compatible with Mobile IPv6. In particular, a NEMO backward compatible with Mobile IPv6. In particular, a NEMO
compliant Home Agent can operate as a Mobile IPv6 Home Agent as well. compliant Home Agent can operate as a Mobile IPv6 Home Agent as well.
The NEMO Basic Support works in such a way that session continuity is The NEMO Basic Support works in such a way that session continuity is
ensured for all the nodes in the mobile network even as the Mobile ensured for all the nodes in the mobile network even as the Mobile
skipping to change at page 4, line 34 skipping to change at page 4, line 34
The solution described in this document requires setting up a The solution described in this document requires setting up a
bi-directional tunnel between the Mobile Router and its Home Agent. bi-directional tunnel between the Mobile Router and its Home Agent.
This tunnel is set up when the Mobile Router sends a successful This tunnel is set up when the Mobile Router sends a successful
Binding Update to its Home Agent, informing the Home Agent of its Binding Update to its Home Agent, informing the Home Agent of its
current point of attachment. current point of attachment.
All traffic between the nodes in the mobile network and Correspondent All traffic between the nodes in the mobile network and Correspondent
Nodes passes through the Home Agent. This document does not describe Nodes passes through the Home Agent. This document does not describe
route optimization of this traffic. route optimization of this traffic.
The terminology document [9] describes Nested Mobility as a scenario The terminology document [10] describes Nested Mobility as a scenario
where a Mobile Router allows another Mobile Router to attach to its where a Mobile Router allows another Mobile Router to attach to its
mobile network. There could be arbitrary levels of nested mobility. mobile network. There could be arbitrary levels of nested mobility.
The operation of each Mobile Router remains the same whether the The operation of each Mobile Router remains the same whether the
Mobile Router attaches to another Mobile Router or to a fixed Access Mobile Router attaches to another Mobile Router or to a fixed Access
Router on the Internet. The solution described here does not place Router on the Internet. The solution described here does not place
any restriction on the number of levels for nested mobility. But it any restriction on the number of levels for nested mobility. But it
should be noted that this might introduce significant overhead on the should be noted that this might introduce significant overhead on the
data packets as each level of nesting introduces another IPv6 header data packets as each level of nesting introduces another IPv6 header
encapsulation. encapsulation.
This document does not discuss multihoming for Mobile Routers.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [7].
Network Mobility related terminology is defined in [8] [9]. This Network Mobility related terminology is defined in [9] and [10].
document in addition defines the following terms. This document in addition defines the following terms.
Mobile Network Prefix Mobile Network Prefix
An IPv6 prefix that is delegated to a Mobile An IPv6 prefix that is delegated to a Mobile
Router and advertised in the mobile network. There could Router and advertised in the mobile network. There could
be more than one Mobile Network Prefix being advertised in be more than one Mobile Network Prefix being advertised in
a mobile network. a mobile network.
Prefix Table Prefix Table
It is a list of Mobile Network Prefixes indexed by It is a list of Mobile Network Prefixes indexed by
the Home Address of a Mobile Router. The prefix table is the Home Address of a Mobile Router. The prefix table is
managed by the Home Agent and is used by the Home Agent managed by the Home Agent and is used by the Home Agent
to determine which Mobile Network Prefixes belong to a to determine which Mobile Network Prefixes belong to a
particular Mobile Router. particular Mobile Router.
3. Overview of the NEMO Protocol 3. Overview of the NEMO Protocol
A Mobile Network is a network segment or subnet which can move and A Mobile Network is a network segment or subnet which can move and
attach to arbitrary points in the Internet. A mobile network can attach to arbitrary points in the routing infrastructure. A mobile
only be accessed via specific gateways called Mobile Routers that network can only be accessed via specific gateways called Mobile
manage its movement. Mobile networks have atleast one Mobile Router Routers that manage its movement. Mobile networks have at least one
serving them. A Mobile Router does not distribute the mobile network Mobile Router serving them. A Mobile Router does not distribute
routes to the infrastructure at its point of attachment (i.e. in the the mobile network routes to the infrastructure at its point of
visited network). Instead, it maintains a bidirectional tunnel to a attachment (i.e. in the visited network). Instead, it maintains a
Home Agent that advertises an aggregation of mobile networks to the bidirectional tunnel to a Home Agent that advertises an aggregation
infrasructure. The Mobile Router is also the default gateway for the of mobile networks to the infrasructure. The Mobile Router is also
mobile network. the default gateway for the mobile network.
A mobile network can also consist of multiple and nested subnets. A A mobile network can also consist of multiple and nested subnets. A
router with no support for mobility may be permanently attached to router with no support for mobility may be permanently attached to
a mobile network for local distribution. Also, Mobile Routers may a mobile network for local distribution. Also, Mobile Routers may
be attached to mobile networks owned by different Mobile Routers and be attached to mobile networks owned by different Mobile Routers and
form a graph. In particular, with Basic NEMO Support, each Mobile form a graph. In particular, with Basic NEMO Support, each Mobile
Router is attached to another mobile network by a single interface, Router is attached to another mobile network by a single interface,
and if loops are avoided, the graph is a tree. and if loops are avoided, the graph is a tree.
A Mobile Router has an unique Home Address through which it is A Mobile Router has an unique Home Address through which it is
skipping to change at page 6, line 40 skipping to change at page 6, line 40
on the home link or the prefix delegated to the Mobile Router. on the home link or the prefix delegated to the Mobile Router.
The Mobile Router can have more than one Home Address if there The Mobile Router can have more than one Home Address if there
are multiple prefixes in the home link. The Mobile Router also are multiple prefixes in the home link. The Mobile Router also
advertises one or more prefixes in the mobile network attached to it. advertises one or more prefixes in the mobile network attached to it.
The actual mechanism for assigning these prefixes to a given Mobile The actual mechanism for assigning these prefixes to a given Mobile
Router is outside the scope of this specification. Router is outside the scope of this specification.
When the Mobile Router moves away from the home link and attaches to When the Mobile Router moves away from the home link and attaches to
a new access router, it acquires a Care-of Address from the visited a new access router, it acquires a Care-of Address from the visited
link. The Mobile Router can at any time act either as a Mobile Host link. The Mobile Router can at any time act either as a Mobile Host
or a Mobile Router. In either case, as soon as the Mobile Router or a Mobile Router. It acts as a Mobile Host as defined in [1] for
acquires a Care-of Address, it immediately sends a Binding Update to sessions originated by itself, while providing connectivity to the
its Home Agent as described in [1]. When the Home Agent receives Mobile Network. As soon as the Mobile Router acquires a Care-of
this Binding Update it creates a binding cache entry binding the Address, it immediately sends a Binding Update to its Home Agent as
Mobile Router's Home Address to its Care-of address at the current described in [1]. When the Home Agent receives this Binding Update
point of attachment. it creates a binding cache entry binding the Mobile Router's Home
Address to its Care-of address at the current point of attachment.
If the Mobile Router wishes to act as a Mobile Router and provide If the Mobile Router wishes to act as a Mobile Router and provide
connectivity to nodes in the mobile network, it indicates this to the connectivity to nodes in the mobile network, it indicates this to the
Home Agent by setting a flag (R) in the Binding Update. It MAY also Home Agent by setting a flag (R) in the Binding Update. It MAY also
include information about the Mobile Network Prefix in the Binding include information about the Mobile Network Prefix in the Binding
Update using one of the modes described in Section 5.2, so that the Update using one of the modes described in Section 5.2, so that the
Home Agent can forward packets meant for nodes in the mobile network Home Agent can forward packets meant for nodes in the mobile network
to the Mobile Router. A new Mobility Header Option is described in to the Mobile Router. A new Mobility Header Option is described in
this document to carry prefix information. This option is described this document to carry prefix information. This option is described
in Section 4.3. If the mobile network has more than one IPv6 prefix in Section 4.3. If the mobile network has more than one IPv6 prefix
and wants the Home Agent to setup forwarding for all these prefixes, and wants the Home Agent to setup forwarding for all these prefixes,
it includes multiple prefix information options in a single Binding it includes multiple prefix information options in a single Binding
Update. The Home Agent sets up forwarding for each of these prefixes Update. The Home Agent sets up forwarding for each of these prefixes
to the Mobile Router's Care-of Address. In some scenarios the Home to the Mobile Router's Care-of Address. In some scenarios the
Agent already knows which prefixes belong to a Mobile Router. In Home Agent already knows which prefixes belong to a Mobile Router
these scenarios, the Mobile Router does not include any prefix by an alternate mechanism such as static configuration. In these
information in the Binding Update. The Home Agent sets up forwarding scenarios, the Mobile Router does not include any prefix information
for all prefixes owned by the Mobile Router, when it receives a in the Binding Update. The Home Agent sets up forwarding for all
Binding Update from the mobile router with the router flag (R) set. prefixes owned by the Mobile Router, when it receives a Binding
Update from the mobile router with the router flag (R) set.
The Home Agent acknowledges the Binding Update by sending a Binding The Home Agent acknowledges the Binding Update by sending a Binding
Acknowledgement to the Mobile Router. A positive acknowledgement Acknowledgement to the Mobile Router. A positive acknowledgement
means that the Home Agent has set up forwarding for the mobile means that the Home Agent has set up forwarding for the mobile
network. Once the binding process completes, a bi-directional tunnel network. Once the binding process completes, a bi-directional tunnel
is established between the Home Agent and the Mobile Router. The is established between the Home Agent and the Mobile Router. The
tunnel end points are Mobile Router's Care-of Address and the Home tunnel end points are Mobile Router's Care-of Address and the Home
Agent's address. If a packet with a source address belonging to Agent's address. If a packet with a source address belonging to
the Mobile Network Prefix is received from the mobile network, the the Mobile Network Prefix is received from the mobile network, the
Mobile Router reverse-tunnels the packet to the Home Agent through Mobile Router reverse-tunnels the packet to the Home Agent through
skipping to change at page 7, line 41 skipping to change at page 7, line 43
When a data packet is sent by a Correspondent Node to a node in the When a data packet is sent by a Correspondent Node to a node in the
mobile network, it gets routed to the Home Agent which currently mobile network, it gets routed to the Home Agent which currently
has the binding for the Mobile Router. It is expected that the has the binding for the Mobile Router. It is expected that the
Mobile Router's network prefix would be aggregated at the Home Agent, Mobile Router's network prefix would be aggregated at the Home Agent,
which advertises the resulting aggregation. Alternatively, the Home which advertises the resulting aggregation. Alternatively, the Home
Agent may receive the data packets destined to the mobile network Agent may receive the data packets destined to the mobile network
by advertising routes to the Mobile Network Prefix. The actual by advertising routes to the Mobile Network Prefix. The actual
mechanism by which these routes are advertised is outside the scope mechanism by which these routes are advertised is outside the scope
of this document. When the Home Agent receives a data packet meant of this document. When the Home Agent receives a data packet meant
for a node in the mobile network, it tunnels the packet to Mobile for a node in the mobile network, it tunnels the packet to Mobile
Router's current Care-of address. The Mobile Router decapsulates Router's current Care-of address. The Mobile Router decapsulates the
the packet and forwards it onto the interface where the mobile packet and forwards it onto the interface where the mobile network
network is connected. The Mobile Router before decapsulating the is connected. The Mobile Router before decapsulating the tunneled
tunneled packet, has to check if the Source address on the outer IPv6 packet, has to check if the Source address on the outer IPv6 header
header is the Home Agent's address. It also has to make sure the is the Home Agent's address. However, this check is not necessary
destination address on the inner IPv6 header belongs to one of its if the packet is protected by IPsec in tunnel mode. The Mobile
Mobile Network Prefixes before forwarding the packet to the mobile Router also has to make sure the destination address on the inner
network. IPv6 header belongs to a prefix used in the Mobile Network before
forwarding the packet to the Mobile Network. Otherwise it should
drop the packet.
The mobile network could consist of nodes that do not support The mobile network could consist of nodes that do not support
mobility and nodes that support mobility. A node in the mobile mobility and nodes that support mobility. A node in the mobile
network can also be a fixed or a mobile router. The protocol network can also be a fixed or a mobile router. The protocol
described here ensures complete transparency of network mobility to described here ensures complete transparency of network mobility to
the nodes in the mobile network. Mobile Nodes that attach to the the nodes in the mobile network. Mobile Nodes that attach to the
mobile network treat it as a normal IPv6 access network and run the mobile network treat it as a normal IPv6 access network and run the
Mobile IPv6 protocol. Mobile IPv6 protocol.
It is also possible for the Mobile Router and the Home Agent to run It is also possible for the Mobile Router and the Home Agent to run
a routing protocol through the bi-directional tunnel. In that case, a routing protocol through the bi-directional tunnel. In that case,
the Mobile Router need not include prefix information in the Binding the Mobile Router need not include prefix information in the Binding
Update. Instead the Home Agent uses the routing protocol updates to Update. Instead the Home Agent uses the routing protocol updates to
setup forwarding for the mobile network. When running the routing setup forwarding for the mobile network. When running the routing
protocol it is required that the bi-directional tunnel be treated as protocol it is required that the bi-directional tunnel be treated as
a tunnel interface. The tunnel interface is included as the list of a tunnel interface. The tunnel interface is included in the list of
interfaces on which routing protocol is active. The Mobile Router interfaces on which routing protocol is active. The Mobile Router
should be configured not to run the routing protocol on its egress should be configured not to send any routing protocol messages on its
interface when it is away from the home link. egress interface when it is away from the home link and connected to
a visited link.
Finally, the Home Agent may be configured with static routes to the Finally, the Home Agent may be configured with static routes to the
Mobile Network Prefix via the Mobile Router's Home Address. In that Mobile Network Prefix via the Mobile Router's Home Address. In that
case, the routes are set independently of the binding flows and the case, the routes are set independently of the binding flows and
returning Home of a Mobile Router. The benefit is that such movement the returning Home of a Mobile Router. The benefit is that such
does not induce any additional signalling in the form of routing movement does not induce any additional signalling in the form of
updates in the Home Network. The drawback of that model is that the routing updates in the Home Network. The drawback of that model is
routes are present even if the related Mobile Routers that are not the routes are present even if the related Mobile Routers are not
reachable (at Home or bound) at a given point of time. reachable (at Home or bound) at a given point of time.
4. Message Formats 4. Message Formats
4.1. Binding Update 4.1. Binding Update
A new flag (R) is included in the Binding Update to indicate to the A new flag (R) is included in the Binding Update to indicate to the
Home Agent if the Binding Update is coming from a Mobile Router Home Agent if the Binding Update is coming from a Mobile Router
and not from a mobile node. The rest of the Binding Update format and not from a mobile node. The rest of the Binding Update format
remains the same as defined in [1]. remains the same as defined in [1].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|R| Reserved | Lifetime | |A|H|L|K|M|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R) Mobile Router Flag (R)
skipping to change at page 9, line 42 skipping to change at page 9, line 42
is set to 0, the Home Agent assumes that the Mobile Router is is set to 0, the Home Agent assumes that the Mobile Router is
just behaving as a Mobile Node, and MUST NOT forward packets just behaving as a Mobile Node, and MUST NOT forward packets
destined for the mobile network to the Mobile Router. destined for the mobile network to the Mobile Router.
Mobility Options Mobility Options
Variable length field which can include zero or more mobility Variable length field which can include zero or more mobility
options. This document defines a new mobility option in options. This document defines a new mobility option in
addition to what is defined in [1]. addition to what is defined in [1].
For a description of the other fields in the message, see [1]. For descriptions of the other fields in the message, see [1].
4.2. Binding Acknowledgement 4.2. Binding Acknowledgement
A new flag (R) is included in the Binding Acknowledgement to indicate A new flag (R) is included in the Binding Acknowledgement to indicate
that the Home Agent which processed the corresponding Binding Update that the Home Agent which processed the corresponding Binding Update
supports Mobile Routers. The flag is set only if the corresponding supports Mobile Routers. The flag is set only if the corresponding
Binding Update had the Mobile Router flag (R) set to 1. The rest of Binding Update had the Mobile Router flag (R) set to 1. The rest of
the Binding Acknowledgement format remains the same as defined in the Binding Acknowledgement format remains the same as defined in
[1]. [1].
skipping to change at page 10, line 28 skipping to change at page 10, line 28
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Flag (R) Mobile Router Flag (R)
The Mobile Router Flag is set to indicate that the Home Agent The Mobile Router Flag is set to indicate that the Home Agent
which processed the Binding Update supports Mobile Routers. It which processed the Binding Update supports Mobile Routers. It
is set to 1 only if the corresponding Binding Update had the is set to 1 only if the corresponding Binding Update had the
Mobile Router flag set to 1. Mobile Router flag set to 1.
For a description of the other fields in the message, see [1]. For descriptions of the other fields in the message, see [1].
This document also introduces the following new Binding This document also introduces the following new Binding
Acknowledgement status values. Acknowledgement status values. The values shown below are decimal
values.
140 Mobile Router Operation not permitted 140 Mobile Router Operation not permitted
141 Invalid Prefix 141 Invalid Prefix
142 Not Authorized for Prefix 142 Not Authorized for Prefix
143 Forwarding Setup failed 143 Forwarding Setup failed
Status values less than 128 indicate that the Binding Update was Status values less than 128 indicate that the Binding Update was
skipping to change at page 12, line 8 skipping to change at page 12, line 8
8 bit unsigned integer indicating the prefix length of the IPv6 8 bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option. prefix contained in the option.
Mobile Network Prefix Mobile Network Prefix
A 16 byte field contains the Mobile Network Prefix. A 16 byte field contains the Mobile Network Prefix.
5. Mobile Router Operation 5. Mobile Router Operation
Mobile Router operation is derived largely from the combined Mobile Router operation is derived largely from the combined
behaviors of a Host, of a Router [6], and of a Mobile Node [1]. behaviors of a Host, of a Router [5], and of a Mobile Node [1].
A Mobile Node can act in two different ways: (1) as a Mobile Host A Mobile Node can act in two different ways: (1) as a Mobile Host
(in which case the Mobile IPv6 Home Agent doesn't maintain any prefix (in which case the Home Agent doesn't maintain any prefix information
information related to the Mobile Host's Home Address, but does related to the Mobile Host's Home Address, but does maintain a
maintain a binding cache entry related to the Mobile Host's Home binding cache entry related to the Mobile Host's Home Address) and
Address) and (2) as a Mobile Router (in which case, in addition to (2) as a Mobile Router (in which case, in addition to maintaining the
maintaining the binding cache entry corresponding to the Mobile binding cache entry corresponding to the Mobile Router Home Address,
Router Home Address, the Mobile IPv6 Home Agent also maintains the Home Agent also maintains forwarding information related to
forwarding information related to prefixes assigned to the mobile prefixes assigned to the mobile network). The distinction between
network). The distinction between the the two modes is represented the the two modes is represented by the value of the Mobile Router
by the value of the Mobile Router flag (R). flag (R).
A Mobile Router MUST implement all requirements for IPv6 Mobile A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes
Nodes, Section 8.5 in [1]. However if a Mobile Router is not as described in Section 8.5 of [1].
expected to initiate sessions of its own and behaves purely as a
router serving the mobile network most of the time, then the Route
Optimization functionality MAY be implemented.
5.1. Data Structures 5.1. Data Structures
Like a Mobile Host, a Mobile Router also maintains a Binding Update Like a Mobile Host, a Mobile Router also maintains a Binding Update
List, described in Section 11.1 of Mobile IPv6 specification[1]. The List, described in Section 11.1 of Mobile IPv6 specification[1]. The
Binding Update list is a conceptual data structure which records Binding Update list is a conceptual data structure which records
information that is sent in the Binding Updates. There is one entry information that is sent in the Binding Updates. There is one entry
per each destination that the Mobile Router is currently sending per each destination that the Mobile Router is currently sending
Binding Updates to. Binding Updates to.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Binding Update List entry. This document introduces a new mobile Binding Update List entry. This document introduces a new mobile
router flag (R) for this entry. The status of this flag is stored in router flag (R) for this entry. The status of this flag is stored in
the Binding Update list whenever a Binding Update is sent. the Binding Update list whenever a Binding Update is sent.
A Mobile Router also maintains a Home Agent list populated according A Mobile Router also maintains a Home Agent list populated according
to the same procedure as a Mobile Host. to the same procedure as a Mobile Host.
5.2. Sending Binding Updates 5.2. Sending Binding Updates
A Mobile Router sends Binding Updates to its Home Agent as described A Mobile Router sends Binding Updates to its Home Agent as described
in [1]. It uses one of the following modes to instruct the Home in [1]. If the Mobile Router is not running a routing protocol
Agent to determine the prefixes that belong to the Mobile Router. In as described in Section 8, it uses one of the following modes to
all the modes, the Mobile Router sets the Mobile Router flag (R). instruct the Home Agent to determine the prefixes that belong to the
Mobile Router. In all the modes, the Mobile Router sets the Mobile
Router flag (R).
Implicit: Implicit:
In this mode, the Mobile Router does not include either a In this mode, the Mobile Router does not include a Mobile
Mobile Network Prefix Option or a Mobile Network Prefix Length Network Prefix Option in the Binding Update. The Home Agent
Option in the Binding Update (but it does include the Home can use any mechanism (not defined in this document) to
Address Option in the Destination Options header, as all Mobile determine the Mobile Network Prefix(es) owned by the Mobile
Hosts do). The Home Agent can use any mechanism (not defined Router and setup forwarding for the mobile network. One
in this document) to determine the Mobile Network Prefix(es) example would be manual configuration at the Home Agent mapping
owned by the Mobile Router and setup forwarding for the mobile the Mobile Router's Home Address to the information required
network. One example would be manual configuration at the for setting up forwarding for the mobile network.
Home Agent mapping the Mobile Router's Home Address to the
information required for setting up forwarding for the mobile
network.
Explicit: Explicit:
In this mode, the Mobile Router includes one or more Mobile In this mode, the Mobile Router includes one or more Mobile
Network Prefix Options in the Binding Update. These options Network Prefix Options in the Binding Update. These options
contain information about the Mobile Network Prefix(es) contain information about the Mobile Network Prefix(es)
configured on the mobile network. configured on the mobile network.
A Mobile Router MUST implement atleast one mode and MAY implement A Mobile Router MUST implement at least one mode and MAY implement
both modes. If the Mobile Router flag is set, Home Registration flag both modes. If a Mobile Router implements both modes, local
(H) MUST be set. configuration on the Mobile Router decides which mode to use. This
is out of scope for this document.
If the Mobile Router flag is set, Home Registration flag (H) MUST be
set.
If the Mobile Router has a valid binding cache entry at the Home
Agent, subsequent Binding Updates for the same Home Address should
have the same value for the Mobile Router Flag (R) as the value in
the binding cache.
5.3. Receiving Binding Acknowledgements 5.3. Receiving Binding Acknowledgements
The Mobile Router receives Binding Acknowledgements from the Home The Mobile Router receives Binding Acknowledgements from the Home
Agent, corresponding to the Binding Updates it sent. If the Binding Agent, corresponding to the Binding Updates it sent. If the Binding
Acknowledgement status is set to '0' (Binding Update accepted) and Acknowledgement status is set to '0' (Binding Update accepted) and
the Mobile Router flag (R) is set to 1, the Mobile Router assumes the Mobile Router flag (R) is set to 1, the Mobile Router assumes
that the Home Agent has successfully processed the Binding Update that the Home Agent has successfully processed the Binding Update
and has set up forwarding for the mobile network. The Mobile Router and has set up forwarding for the mobile network. The Mobile Router
can then start using the bi-directional tunnel for reverse tunneling can then start using the bi-directional tunnel for reverse tunneling
skipping to change at page 14, line 8 skipping to change at page 14, line 16
not set, then the Mobile Router concludes that its current Home not set, then the Mobile Router concludes that its current Home
Agent does not support Mobile Routers and performs Dynamic Home Agent does not support Mobile Routers and performs Dynamic Home
Agent Discovery again to discover Home Agents which support Mobile Agent Discovery again to discover Home Agents which support Mobile
Routers. Additional the Mobile Router MUST also de-register with the Routers. Additional the Mobile Router MUST also de-register with the
Home Agent which did not support Mobile Routers before attempting Home Agent which did not support Mobile Routers before attempting
registration with another Home Agent. registration with another Home Agent.
5.4. Error Processing 5.4. Error Processing
If the Binding Acknowledgement status is set to a value between 128 If the Binding Acknowledgement status is set to a value between 128
and 140, the Mobile Router takes necessary actions as described in and 139, the Mobile Router takes necessary actions as described in
the Mobile IPv6 specification [1]. the Mobile IPv6 specification [1]. For the Binding Acknowledgement
status values defined in this document, the following sections
explain the Mobile Router's behavior.
If the Mobile Router sent a Binding Update to the Home Agent in 5.4.1. Implicit Mode
implicit mode (i.e. the prefix field in the Binding Update list
entry is null) then the Mobile Router interprets only the error In Implicit mode, the Mobile Router interprets only error
status '140' (Mobile Router Operation not permitted) and '143' status '140' (Mobile Router Operation not permitted) and '143'
(Forwarding Setup failed). For this Binding Update, the Mobile (Forwarding Setup failed). The Mobile Router MUST discard Binding
Router MUST discard Binding Acknowledgements with codes '141' and Acknowledgements with status '141' and '142'.
'142'.
For the same Binding Update, if the status is '140', then the Mobile If the Binding Acknowledgement from the Home Agent has the status
Router should send a similar Binding Update (implicit mode) to '140', the Mobile Router SHOULD send a Binding Update to another Home
another Home Agent on the same home link. If no Home Agent replies Agent on the same home link. If no Home Agent replies positively
positively then the Mobile Router MUST refrain from sending any the Mobile Router MUST refrain from sending Binding Updates with the
Binding Update with the Mobile Router flag set to any Home Agent on Mobile Router flag set to any Home Agent on the home link, and log
the home link, and log the information. the information.
For the same Binding Update, if the status is '143', then the Mobile If the Binding Acknowledgemnet has the status '143', the Mobile
Router should send a similar Binding Update (implicit mode) to Router SHOULD send a Binding Update to another Home Agent on the same
another Home Agent on the same home link. If no Home Agent replies home link. If no Home Agent replies positively the Mobile Router
positively then Mobile Router SHOULD refrain from sending this SHOULD refrain from sending this Binding Update to any Home Agent on
Binding Update to any Home Agent on the home link, and MAY send the home link, and MAY send Binding Updates in Explicit mode to a
Binding Updates in another mode (e.g. explicitly include a prefix) Home Agent on the same home link.
to a Home Agent on the same home link.
If the Mobile Router sent a Binding Update to Home Agent in explict 5.4.2. Explicit Mode
mode then the Mobile Router interprets only the error status
'141' (Invalid Prefix) and '142' (Not Authorized for Prefix).
For this Binding Update, the Mobile Router MUST discard Binding
Acknowledgements with codes '140' and '143'.
For the same Binding Update, if the status is set to '141', then the If the Mobile Router sent a Binding Update to Home Agent in explicit
Mobile Router should send a similar Binding Update to another Home mode then the Mobile Router interprets only error status '140'
Agent on the same home link. If no Home Agent replies positively (Mobile Router Operation not permitted), '141' (Invalid Prefix) and
then Mobile Router SHOULD refrain from sending this Binding Updates '142' (Not Authorized for Prefix). The Mobile Router MUST discard
to any Home Agent on the home link. At this point, Mobile Router MAY Binding Acknowledgements with status '143'.
try to obtain and own a prefix by the same means that it initially
got assigned the current Mobile Network Prefix. Alternatively,
Mobile Router MAY send Binding Updates in another mode (e.g.
implicit mode) to a Home Agent on the same home link.
For the same Binding Update, if the status is set to '142', then the If the Binding Acknowledgement from the Home Agent has the status
Mobile Router should send a similar Binding Update to another Home '140', the Mobile Router SHOULD send a Binding Update to another Home
Agent on the same home link. If no Home Agent replies positively Agent on the same home link. If no Home Agent replies positively
then Mobile Router SHOULD refrain from sending this Binding Updates then the Mobile Router MUST refrain from sending Binding Updates with
to any Home Agent on the home link. Additionally, the Home Agent the Mobile Router flag set to any Home Agent on the home link, and
MUST stop advertising the respective prefix(es) in the mobile network log the information.
with associated Router Advertisements, and modify its own forwarding
information accordingly. Following this, the Mobile Router MAY send
Binding Updates in another mode (e.g. implicit) to a Home Agent on
the same home link.
If at the end of this Error Processing procedure the Mobile Router If the Binding Acknowledgement has the status '141' or '142', the
has tried every available modes of sending Binding Updates and still Mobile Router SHOULD send a Binding Update to another Home Agent
has not received a positive Binding Acknowledgement (status value on the same home link. If no Home Agent replies positively then
between 0 and 127) for this Home Address from any Home Agent on its the Mobile Router SHOULD refrain from sending Binding Updates to
home link, then the Mobile Router MUST stop sending Binding Updates any Home Agent on the home link. The Mobile Router MUST also stop
with the Mobile Router flag set for this Home Address and log the advertising the prefix in the Mobile Network and try to obtain new
information. IPv6 prefix information for the Mobile Network by the same means
that it initially got assigned the current Mobile Network Prefix.
Alternatively, Mobile Router MAY send Binding Updates in Implicit
mode to a Home Agent on the same home link.
If at the end of this Error Processing procedure, as described in
Sections 5.4.1 and 5.4.2, the Mobile Router has tried every available
modes of sending Binding Updates and still has not received a
positive Binding Acknowledgement, the Mobile Router MUST stop sending
Binding Updates with the Mobile Router flag set for this Home Address
and log the information.
In all the above cases, the Mobile Router MUST conclude that the Home In all the above cases, the Mobile Router MUST conclude that the Home
Agent did not create a binding cache entry for the Mobile Router's Agent did not create a binding cache entry for the Mobile Router's
Home Address. Home Address.
5.5. Establishment of Bi-directional Tunnel 5.5. Establishment of Bi-directional Tunnel
When a successful Binding Acknowledgement is received, the Mobile When a successful Binding Acknowledgement is received, the Mobile
Router sets up its endpoint of the bi-directional tunnel. Router sets up its endpoint of the bi-directional tunnel.
The bi-directional tunnel between Mobile Router and Home Agent allows The bi-directional tunnel between Mobile Router and Home Agent allows
packets to flow in both directions between these entities, while the packets to flow in both directions between these entities, while the
Mobile Router is connected to a Visited Link. The bi-directional Mobile Router is connected to a visited link. The bi-directional
tunnel involves two virtual links [3]: one virtual link has the tunnel is created by merging two unidirectional tunnels as described
address of the tunnel entry point as the Care-of Address of the in RFC 2473 [3]. The tunnel from the Mobile Router to the Home Agent
Mobile Router and the tunnel exit point as the address of the has the Care-of address of the Mobile Router as the tunnel entry
Home Agent; the other virtual link has as tunnel entry point the point and the Home Agent's address as the tunnel exit point. The
Home Agent address and as tunnel exit point the Care-of Address tunnel from the Home Agent to the Mobile Router has the Home Agent's
of the Mobile Router. Both addresses are unicast addresses. All address and the Mobile Router's Care-of address as the tunnel entry
IPv6 traffic to and from the mobile network is sent through this point and exit point respectively. All IPv6 traffic to and from the
bi-directional tunnel. mobile network is sent through this bi-directional tunnel.
A Mobile Router MAY limit the number of mobile routers that attach to A Mobile Router MAY limit the number of mobile routers that attach to
its mobile network (the number of levels in the nested aggregation) its mobile network (the number of levels in the nested aggregation)
by means of setting the Tunnel Encapsulation Limit field of the by means of setting the Tunnel Encapsulation Limit field of the
Tunnel Encapsulation option. Tunnel Encapsulation option.
A Mobile Router uses the Tunnel Hop Limit that is normally assigned A Mobile Router uses the Tunnel Hop Limit that is normally assigned
to routers (not to hosts). Please refer to [3] for more details. to routers (not to hosts). Please refer to [3] for more details.
5.6. Neighbor Discovery for Mobile Router 5.6. Neighbor Discovery for Mobile Router
skipping to change at page 18, line 5 skipping to change at page 17, line 14
hosts on the home link do not pick the Mobile Router as the hosts on the home link do not pick the Mobile Router as the
default router. default router.
- The Mobile Router MAY join the All Routers multicast group on the - The Mobile Router MAY join the All Routers multicast group on the
home link. home link.
- The Mobile Router MAY send routing protocol messages on its - The Mobile Router MAY send routing protocol messages on its
egress interface if it is configured to run a dynamic routing egress interface if it is configured to run a dynamic routing
protocol. protocol.
When the Mobile Router sends a de-registration Binding Update in
Explicit mode, it SHOULD not include any Mobile Network Prefix
options in the Binding Update. When the Home Agent removes a binding
cache entry, it deletes all the associated Mobile Network Prefix
routes.
6. Home Agent Operation 6. Home Agent Operation
In order for a Mobile Router to operate correctly, the Home Agent In order for a Mobile Router to operate correctly, the Home Agent
MUST satisfy all the requirements listed in Section 8.4 of [1]. The MUST satisfy all the requirements listed in Section 8.4 of [1]. The
Home Agent MUST implement both modes described in Section 5.2 of this Home Agent MUST implement both modes described in Section 5.2 of this
document. document.
6.1. Data Structures 6.1. Data Structures
6.1.1. Binding Cache 6.1.1. Binding Cache
skipping to change at page 19, line 26 skipping to change at page 19, line 26
to correspondent nodes (for route optimization). to correspondent nodes (for route optimization).
- Mobile IPv6 specification [1] requires that the Home Address in - Mobile IPv6 specification [1] requires that the Home Address in
the Binding Update should be configured from a prefix advertised the Binding Update should be configured from a prefix advertised
on the home link. Otherwise the Binding Update is rejected on the home link. Otherwise the Binding Update is rejected
with status value 132 [1]. This specification relaxes this with status value 132 [1]. This specification relaxes this
requirement so that the Home Agent rejects the Binding Update requirement so that the Home Agent rejects the Binding Update
only if Home Address does not belong to the prefix that the Home only if Home Address does not belong to the prefix that the Home
Agent is configured to serve. Agent is configured to serve.
If the Home Agent has a valid binding cache entry for the Mobile
Router and if the Binding Update has the Mobile Router Flag (R)
set to a value different from the value in the existing binding
cache entry, the Home Agent MUST reject the Binding Update and send
a Binding Acknowledgement with status set to 139 (Registration
type change disallowed). However, if the Binding Update is a
de-registration Binding Update, the Home Agent ignores the value of
the Mobile Router Flag (R).
If the Home Agent does not reject the Binding Update as described If the Home Agent does not reject the Binding Update as described
above, then it retrieves the Mobile Network Prefix information as above, and if a dynamic routing protocol is not being run between
the Home Agent and the Mobile Router as described in Section 8, then
the Home Agent retrieves the Mobile Network Prefix information as
described below. described below.
- If a Mobile Network Prefix Option is present in the Binding - If a Mobile Network Prefix Option is present in the Binding
Update, the prefix information for the Mobile Network Prefix is Update, the prefix information for the Mobile Network Prefix is
retrieved from the Mobile Network Prefix field and the Prefix retrieved from the Mobile Network Prefix field and the Prefix
Length field of the option. If the Binding Update contains more Length field of the option. If the Binding Update contains more
than one option, the Home Agent MUST set up forwarding for all of than one option, the Home Agent MUST set up forwarding for all of
the Mobile Network Prefixes. If the Home Agent fails to setup the Mobile Network Prefixes. If the Home Agent fails to setup
forwarding to all the prefixes listed in the Binding Update, then forwarding to all the prefixes listed in the Binding Update, then
it MUST NOT forward traffic to any of the prefixes, reject the it MUST NOT forward traffic to any of the prefixes, reject the
skipping to change at page 20, line 22 skipping to change at page 20, line 32
If all checks are passed, the Home Agent creates a binding cache If all checks are passed, the Home Agent creates a binding cache
entry for Mobile Router's Home Address, or updates the binding cache entry for Mobile Router's Home Address, or updates the binding cache
entry if it already exists. Otherwise, the Home Agent MUST NOT entry if it already exists. Otherwise, the Home Agent MUST NOT
register the binding of the Mobile Router's Home Address. register the binding of the Mobile Router's Home Address.
The Home Agent defends the Mobile Router's Home Address through Proxy The Home Agent defends the Mobile Router's Home Address through Proxy
Neighbor Discovery by multicasting onto the home link a Neighbor Neighbor Discovery by multicasting onto the home link a Neighbor
Advertisement message on behalf of the mobile router. All fields in Advertisement message on behalf of the mobile router. All fields in
the Proxy Neighbor Advertisement message should be set in the same the Proxy Neighbor Advertisement message should be set in the same
way they would be set by the Mobile Router itself if sending this way they would be set by the Mobile Router itself if sending this
Neighbor Advertisement while at home, as described in [7], with the Neighbor Advertisement while at home, as described in [6], with the
exception that the Router (R) bit in the Advertisement MUST be set if exception that the Router (R) bit in the Advertisement MUST be set if
the Mobile Router (R) flag has been set in the Binding Update. the Mobile Router (R) flag has been set in the Binding Update.
The Home Agent also creates a bi-directional tunnel to the mobile The Home Agent also creates a bi-directional tunnel to the mobile
router for the requested Mobile Network Prefix, or update an existing router for the requested Mobile Network Prefix, or update an existing
bi-directional tunnel as described in Section 6.4. bi-directional tunnel as described in Section 6.4.
6.3. Advertising Mobile Network Reachability 6.3. Advertising Mobile Network Reachability
In order to be able to receive packets meant for the mobile network, In order to be able to receive packets meant for the mobile network,
the Home Agent advertises reachability to the mobile network. If the the Home Agent advertises reachability to the mobile network. If
Home Link is configured with a prefix that is an aggregation and if the Home Link is configured with a prefix that is an aggregation and
the Mobile Network Prefix is aggregated under that prefix, then the if the Mobile Network Prefix is aggregated under that prefix, then
routing updates advertising reachability to the mobile network are the routing changes related to the Mobile Network may be restricted
sent only on the Home Link. If the Home Agent is the only default to the Home Link. If the Home Agent is the only default router on
router on the Home Link, routes to the Mobile Network Prefix get the Home Link, routes to the Mobile Network Prefix get aggregated
aggregated naturally under the Home Agent and the Home Agent does not naturally under the Home Agent and the Home Agent does not have to do
have to do anything special. anything special.
If the Home Agent receives routing updates through a dynamic routing If the Home Agent receives routing updates through a dynamic routing
protocol from the Mobile Router, those routes are propagated by protocol from the Mobile Router, it can be configured to propagate
the routing protocol running on the Home Agent on the relevant those routes on the relevant interfaces.
interfaces.
6.4. Establishment of Bi-directional Tunnel 6.4. Establishment of Bi-directional Tunnel
The implementation of the bi-directional tunnels and the mechanism The implementation of the bi-directional tunnels and the mechanism
of attaching them to the IP stack are outside the scope of this of attaching them to the IP stack are outside the scope of this
specification. However, all implementations MUST be capable of the specification. However, all implementations MUST be capable of the
following operations. following operations.
- The Home Agent can tunnel packets meant for the mobile network - The Home Agent can tunnel packets meant for the mobile network
prefix to the Mobile Router's current location, the Care-of prefix to the Mobile Router's current location, the Care-of
skipping to change at page 23, line 5 skipping to change at page 23, line 5
successfully processes the de-registration BU, it deletes the Binding successfully processes the de-registration BU, it deletes the Binding
Cache Entry for the Mobile Router's Home Address and stops proxying Cache Entry for the Mobile Router's Home Address and stops proxying
the Home Address. This is described in detail in the Mobile IPv6 the Home Address. This is described in detail in the Mobile IPv6
specification [1]. specification [1].
In addition, the Home Agent also removes the bi-directional tunnel In addition, the Home Agent also removes the bi-directional tunnel
and stops forwarding packets to the mobile network. The Home Agent and stops forwarding packets to the mobile network. The Home Agent
should keep all necessary information to clean up whichever routes it should keep all necessary information to clean up whichever routes it
installed, whether they come from implicit or explicit source. installed, whether they come from implicit or explicit source.
In Explicit mode, the Home Agent MUST ignore any Mobile Network
Prefix Options present in the de-registration Binding Update.
7. Modifications to Dynamic Home Agent Discovery 7. Modifications to Dynamic Home Agent Discovery
This document extends the Dynamic Home Agent Discovery mechanism This document extends the Dynamic Home Agent Discovery mechanism
defined in [1], so that Mobile Routers attempt registration only with defined in [1], so that Mobile Routers attempt registration only with
Home Agents that support Mobile Routers. Home Agents that support Mobile Routers.
7.1. Modified Dynamic Home Agent Discovery Request 7.1. Modified Dynamic Home Agent Discovery Request
A new flag (R) (Support for Mobile Routers) is introduced in the A new flag (R) (Support for Mobile Routers) is introduced in the
Dynamic Home Agent Discovery Reguest message defined in [1]. The Dynamic Home Agent Discovery Reguest message defined in [1]. The
skipping to change at page 23, line 40 skipping to change at page 24, line 40
For a description of the other fields in the message, see [1]. For a description of the other fields in the message, see [1].
7.2. Modified Dynamic Home Agent Discovery Reply 7.2. Modified Dynamic Home Agent Discovery Reply
A new flag (R) (Support for Mobile Routers) is introduced in the A new flag (R) (Support for Mobile Routers) is introduced in the
Dynamic Home Agent Discovery Reply message defined in [1]. If a Home Dynamic Home Agent Discovery Reply message defined in [1]. If a Home
Agent receives a Dynamic Home Agent Discovery request message with Agent receives a Dynamic Home Agent Discovery request message with
the Mobile Router Support flag set, it MUST reply with a list of Home the Mobile Router Support flag set, it MUST reply with a list of Home
Agents that support Mobile Routers. The Mobile Router Support flag Agents that support Mobile Routers. The Mobile Router Support flag
MUST be set if there is atleast one Home Agent that supports Mobile MUST be set if there is at least one Home Agent that supports Mobile
Routers. If none of the Home Agents support Mobile Routers, the Home Routers. If none of the Home Agents support Mobile Routers, the Home
Agent MAY reply with a list of Home Agents that support just Mobile Agent MAY reply with a list of Home Agents that support just Mobile
IPv6 Mobile Nodes. In this case, the Mobile Router Support flag MUST IPv6 Mobile Nodes. In this case, the Mobile Router Support flag MUST
be set to 0. be set to 0.
The modified message format is as follows. The modified message format is as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 46 skipping to change at page 25, line 46
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R| Reserved | | Type | Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime | | Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R) Mobile Router Support Flag (R)
A 1 bit flag which when set indicates that the Home Agent A 1-bit flag which when set indicates that the Home Agent
supports Mobile Routers. supports Mobile Routers.
For a description of the other fields in the message, see [1]. For a description of the other fields in the message, see [1].
8. Support for Dynamic Routing Protocols 8. Support for Dynamic Routing Protocols
In the solution described so far, forwarding to the mobile network In the solution described so far, forwarding to the mobile network
at the Home Agent is set up when the Home Agent receives a Binding at the Home Agent is set up when the Home Agent receives a Binding
Update from the Mobile Router. An alternative to this is for the Update from the Mobile Router. An alternative to this is for the
Home Agent and the Mobile Router to run an intra-domain routing Home Agent and the Mobile Router to run an intra-domain routing
protocol like RIPng [11] and OSPF [12] through the bi-directional protocol like RIPng [12] and OSPF [13] through the bi-directional
tunnel. The Mobile Router can continue running the same routing tunnel. The Mobile Router can continue running the same routing
protocol that it was running when it was attached to the home link. protocol that it was running when it was attached to the home link.
Support for running a intra-domain routing protocol is optional and
is governed by the configuration on the Mobile Router and the Home
Agent.
This feature is very useful when the mobile network is large with This feature is very useful when the mobile network is large with
multiple subnets containing different IPv6 prefixes. Routing changes multiple subnets containing different IPv6 prefixes. Routing changes
in the mobile network are propagated to the Home Agent quickly. in the mobile network are propagated to the Home Agent quickly.
Routing changes in the home link are also propogated to the Mobile Routing changes in the home link are also propagated to the Mobile
Router very quickly. Router very quickly.
When the Mobile Router is attached to the home link, it runs a When the Mobile Router is attached to the home link, it runs a
routing protocol by sending routing updates through its egress routing protocol by sending routing updates through its egress
interface. When the mobile router moves and attaches to a visited interface. When the mobile router moves and attaches to a visited
network, it MUST stop sending routing updates on the interface with network, it MUST stop sending routing updates on the interface
which it attaches to the visited link. This is very important so with which it attaches to the visited link. This is to reduce the
that IPv6 prefixes specific to the mobile network do not leak into chances that prefixes specific to the Mobile Network are leaked to
the visited network. The Mobile Router then starts sending routing the visited network in the case where routing protocol authentication
protocol messages through the bi-directional tunnel towards the Home is not enabled in the visited network and in the Mobile Network. It
Agent. Most routing protocols use link local addresses as source is expected that normal deployment practices will include proper
addresses for the routing information messages. The Mobile Router is authentication mechanisms to prevent unauthorized route announcements
allowed to use link local addresses for the inner IPv6 header of an on both home and visited networks. The Mobile Router then starts
encapsulated packet. But these messages after decapsulation MUST NOT sending routing protocol messages through the bi-directional tunnel
be forwarded to another link by either the Mobile Router or the Home towards the Home Agent. Most routing protocols use link local
Agent. addresses as source addresses for the routing information messages.
The Mobile Router is allowed to use link local addresses for the
inner IPv6 header of an encapsulated packet. But these routing
protocol messages with link local address MUST NOT be forwarded to
another link by either the Mobile Router or the Home Agent.
When the Home Agent receives the encapsulated routing protocol When the Home Agent receives the inner packet, it processes the
message, it processes the inner packets and updates its routing table encapsulated routing protocol messages and updates its routing table
accordingly. The next hop information in these routing entries is accordingly. As part of normal routing protocol operation, the next
filled with the Mobile Router's link local address with the outgoing hop information in these routing entries is filled with the Mobile
interface set to the bi-directional tunnel. Router's link local address with the outgoing interface set to the
bi-directional tunnel.
Similary, the Home Agent also sends routing updates through the Similary, the Home Agent also sends routing updates through the
bi-directional tunnel to the Mobile Router. The Mobile Router bi-directional tunnel to the Mobile Router. The Mobile Router
processes these routing protocol messages and updates its routing processes these routing protocol messages and updates its routing
table. For all routes advertised by the Home Agent, the Mobile table. For all routes advertised by the Home Agent, the Mobile
Router sets the outgoing interface to the bi-directional tunnel to Router sets the outgoing interface to the bi-directional tunnel to
the Home Agent. the Home Agent.
When the Mobile Router and the Home Agent exchange routes through When the Mobile Router and the Home Agent exchange routes through
a dynamic routing protocol, the Mobile Router should be careful in a dynamic routing protocol, the Mobile Router SHOULD NOT include
including the same Mobile Network Prefixes in the Binding Update to Mobile Network Prefixes in the Binding Update to the Home Agent. The
the Home Agent and in the routing protocol updates. The Home Agent Home Agent depending on its configuration might not add routes based
depending on its configuration might not add routes based on the on the prefix information in the Binding Updates at all, and might
prefix information in the Binding Updates at all, and might use only use only the routing protocol updates. Moreover, including prefix
the routing protocol updates. Moreover, including the same prefix information in both the Binding Updates and the routing protocol
information in both the Binding Update and the routing protocol updates is redundant.
update is redundant.
Since the routing protocol messages from the Home Agent to the Mobile Since the routing protocol messages from the Home Agent to the
Router could potentially contain information about the internal Mobile Router could potentially contain information about the
routing structure of the home network, these messages require internal routing structure of the home network, these messages
authentications and confidentiality protection. Confidentialy require authentication and confidentiality protection. Appropriate
protection using IPsec ESP [4] MUST be supported and SHOULD be authentication and confidentiality protection mechanisms defined in
used. For protecting routing protocol messages using ESP, the [14] MUST be used. For protecting routing protocol messages using
bi-directional tunnel between the Mobile Router and the Home ESP, the bi-directional tunnel between the Mobile Router and the
Agent should be treated as the outgoing interface, with link local Home Agent should be treated as the outgoing interface, with the
addresses as source and destination addresses for the messages. Home Agent's and Mobile Router's addresses as source and destination
IPsec ESP with a non-null encryption algorithm should be used addresses for the inner encapsulated messages.
in transport mode for protecting the routing protocol messages.
Examples of SPD entries for protecting OSPFv3 messages are described If a link state routing protocol like OSPFv3 is run by the Mobile
in [13]. Router and the Home Agent, the recommendations in Appendix B should
be followed.
9. Security Considerations 9. Security Considerations
All signaling messages between the Mobile Router and the Home Agent All signaling messages between the Mobile Router and the Home Agent
MUST be authenticated by IPsec [5]. The use of IPsec to protect MUST be authenticated by IPsec [8]. The use of IPsec to protect
Mobile IPv6 signaling messages is described in detail in the HA-MN Mobile IPv6 signaling messages is described in detail in the HA-MN
IPsec specification [2]. The signaling messages described in this IPsec specification [2]. The signaling messages described in this
document just extend Mobile IPv6 messages and do not require any document just extend Mobile IPv6 messages and do not require any
changes to what is described in the HA-MN IPsec specification. changes to what is described in the HA-MN IPsec specification.
The Mobile Router has to perform ingress filtering on packets The Mobile Router has to perform ingress filtering on packets
received from the mobile network to ensure that nodes in the Mobile received from the mobile network to ensure that nodes in the Mobile
Network do not use the bi-directional tunnel to launch IP spoofing Network do not use the bi-directional tunnel to launch IP spoofing
attacks. In particular the Mobile Router SHOULD check that the IP attacks. In particular the Mobile Router SHOULD check that the IP
source address in the packets received from the nodes in the Mobile source address in the packets received from the nodes in the Mobile
skipping to change at page 27, line 36 skipping to change at page 28, line 36
The Home Agent has to verify that packets received through the The Home Agent has to verify that packets received through the
bi-directional tunnel belong to the mobile network. This check is bi-directional tunnel belong to the mobile network. This check is
necessary in order to prevent nodes from using the Home Agent to necessary in order to prevent nodes from using the Home Agent to
launch attacks that would have otherwise been prevented by ingress launch attacks that would have otherwise been prevented by ingress
filtering. The source address of the outer IPv6 header MUST be set filtering. The source address of the outer IPv6 header MUST be set
to the Mobile Router's current Care-of address. The source address to the Mobile Router's current Care-of address. The source address
of the inner IPv6 header MUST be a topologically correct address with of the inner IPv6 header MUST be a topologically correct address with
respect to the IPv6 prefixes used in the mobile network. respect to the IPv6 prefixes used in the mobile network.
When the Mobile Router is running a dynamic routing protocol as When the Mobile Router is running a dynamic routing protocol as
described in Section 8, it injects routing update messages into the described in Section 8, it injects routing update messages into
Home Link. The Home Agent MUST verify that the Mobile Router is the Home Link. Since the routing protocol message could contain
allowed to send routing updates before processing the messages and information about the internal routing structure of the home network,
propagating the routing information. these messages require confidentiality protection. Confidentiality
protection through IPsec ESP as described in [14] SHOULD be used.
If the bi-directional tunnel between the Mobile Router and the Home
Agent is protected by ESP in tunnel mode for all IP traffic, then
no additional confidentiality protection specific to the routing
protocol is required.
Home agents and mobile routers may use IPsec ESP to protect payload
packets tunneled between themselves. This is useful to protect
communications against attackers on the path of the tunnel.
Please refer to the Mobile IPv6 specification [1] for security Please refer to the Mobile IPv6 specification [1] for security
considerations when the Mobile Router operates as a Mobile Host. considerations when the Mobile Router operates as a Mobile Host.
10. IANA Considerations 10. IANA Considerations
This document defines a new Mobility Header Option, the Mobile This document defines a new Mobility Header Option, the Mobile
Network Prefix Option. This option is described in Section 4.3. The Network Prefix Option. This option is described in Section 4.3. The
type value for this option needs to be assigned from the same space type value for this option needs to be assigned from the same space
used by the mobility options defined in [1]. used by the mobility options defined in [1].
skipping to change at page 29, line 5 skipping to change at page 30, line 5
meetings. meetings.
Kent Leung, Marco Molteni and Patrick Wetterwald for their work on Kent Leung, Marco Molteni and Patrick Wetterwald for their work on
Network Mobility for IPv4 and IPv6. Network Mobility for IPv4 and IPv6.
Tim Leinmueller for many insightful remarks and for Section 7. Tim Leinmueller for many insightful remarks and for Section 7.
Jari Arkko, James Kempf and Chan-Wah Ng for their thorough review and Jari Arkko, James Kempf and Chan-Wah Ng for their thorough review and
comments. comments.
References Normative References
[1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6. [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6.
Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in
progress). June 2003. progress). June 2003.
[2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect [2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents. Mobile IPv6 Signaling between Mobile Nodes and Home Agents.
Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
(work in progress). June 2003. (work in progress). June 2003.
[3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 [3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. RFC 2473, IETF. December 1998. Specification. RFC 2473, IETF. December 1998.
[4] S. Kent and R. Atkinson. IP Encapsulating Security Payload [4] S. Kent and R. Atkinson. IP Encapsulating Security Payload
(ESP). RFC 2402, IETF. November 1998. (ESP). RFC 2402, IETF. November 1998.
[5] S. Kent and R. Atkinson. Security Architecture for the Internet [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Protocol. RFC 2401, IETF. November 1998.
[6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, IETF. December 1998. Specification. RFC 2460, IETF. December 1998.
[7] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for [6] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for
IP Version 6 (IPv6). RFC 2461, IETF. December 1998. IP Version 6 (IPv6). RFC 2461, IETF. December 1998.
References [7] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF. March 1997.
[8] J. Manner and M. Kojo. Mobility Related Terminology. Internet Informative References
[8] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. RFC 2401, IETF. November 1998.
[9] J. Manner and M. Kojo. Mobility Related Terminology. Internet
Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt
(work in progress). November 2003. (work in progress). November 2003.
[9] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology. [10] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology.
Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work
in progress). May 2003. in progress). May 2003.
[10] T. Ernst. Network Mobility Support Goals and Requirements. [11] T. Ernst. Network Mobility Support Goals and Requirements.
Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work
in progress). May 2003. in progress). May 2003.
[11] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. [12] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF.
January 1997. January 1997.
[12] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, [13] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470,
IETF. December 1999. IETF. December 1999.
[13] M. Gupta and N. Melam. Authentication/Confidentiality for [14] M. Gupta and N. Melam. Authentication/Confidentiality for
OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt
(work in progress). December 2003. (work in progress). December 2003.
[14] T. Ernst. Network Mobility Support in IPv6. PhD Thesis, [15] T. Ernst. Network Mobility Support in IPv6. PhD Thesis,
University Joseph Fourier, Grenoble, France. October 2001. University Joseph Fourier, Grenoble, France. October 2001.
[15] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the [16] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the
InternetCAR perspective. Journal of Interconnection Networks InternetCAR perspective. Journal of Interconnection Networks
(JOIN), Vol. 4, No. 3. September 2003. (JOIN), Vol. 4, No. 3. September 2003.
[17] J. Moy. Extending OSPF to Support Demand Circuits. RFC 1793,
IETF. April 1995.
[18] P. Thubert, et. al. NEMO Home Network models. Internet Draft,
IETF. draft-ietf-home-network-models-00.txt (work in progress).
April 2004.
A. Examples of NEMO Basic Support Operation A. Examples of NEMO Basic Support Operation
This section tries to illustrate the NEMO protocol using a Mobile This section tries to illustrate the NEMO protocol using a Mobile
Router and a Mobile Node belonging to different administrative Router and a Mobile Node belonging to different administrative
domains. The Mobile Router's mobile network consists of a Local domains. The Mobile Router's mobile network consists of a Local
Fixed Node (LFN) and a Local Fixed Router (LFR) [9]. The LFR has Fixed Node (LFN) and a Local Fixed Router (LFR) [10]. The LFR has
an access link to which other Mobile Nodes or Mobile Routers could an access link to which other Mobile Nodes or Mobile Routers could
attach to. attach to.
Figure 1 depicts the scenario where both the Mobile Router and the Figure 1 depicts the scenario where both the Mobile Router and the
Mobile Node are at home. Mobile Node are at home.
+----+ +-------+ +----+ +-------+
| MN | | HA_MN | | MN | | HA_MN |
+--+-+ 1:: +---+---+ +--+-+ 1:: +---+---+
2+-------------+3 2+-------------+3
skipping to change at page 34, line 5 skipping to change at page 35, line 5
6:: |1 6:: |1
--------+- --------+-
|2 |2
+--+-+ +--+-+
| MN | | MN |
+----+ +----+
Figure 3: Mobile Node attached to Mobile Figure 3: Mobile Node attached to Mobile
Router on a Visited Link Router on a Visited Link
B. Changes from Previous Version B. Running Link State Routing Protocol with NEMO Basic Support
The following changes have been made to this document from version 01 The bi-directional tunnel between the Mobile Router and the Home
Agent is used a virtual interface over which routing protocol
messages are exchanged. When a link state routing protocol is run
the following recommendations should be followed.
- Dynamic Home Agent Discovery was modified to return only Home B.1. Tunnel Interface Considerations
Agents that support Mobile Routers. A new section was added to
the specification. (Issue 16).
- A new flag (R) was introduced in the Binding Acknowledgement for If the tunnel interface goes up and down every time the Mobile Router
the Home Agent to indicate to the Mobile Router that it processed moves to a new visited network, with high level of mobility and
the Mobile Router flag (R) in the corresponding Binding Update. sufficient number of mobile routers, the amount of interface state
(Issue 16). changes will adversely affect the Home Agent performance. This also
introduces a high level of instability in the home network. To
avoid this, the following should be considered when implementing the
bi-directional tunnel.
- Relaxed a Mobile IPv6 requirement which said the Home Agent MUST - A tunnel inteface is consistently assigned to each Mobile Router
drop a Binding Update if the home address is not configured from as long as it has a valid binding cache at the Home Agent
the home prefix. NEMO Home Agent drops the Binding Update only
if the Home Address does not belong to the prefix that the Home
Agent is currently configured to serve. (Issue 19)
- Explicit Prefix Length mode is removed. (Issue 20). - Everytime the Mobile Router moves and updates the binding cache
entry, the bi-directional tunnel should not be torn down and
setup again. The tunnel end points should be updated dynamically
with the Mobile Router's current care-of address.
- Text related to Mobile Router performing ingress filtering was - With a large number of interfaces, Hello packet processing may
added to the Security Considerations section to prevent some become a burden. Therefore the tunnel interface should be
threats due to tunneling. (Issue 23). treated as On-Demand circuits for OSPF [17].
- Added a new section on Mobile Router returning home. (Issue 25). B.2. OSPF Area Considerations
- Clarified that the Prefix Table is not required when a dynamic The following should be considered when the Home Network is
routing protocol is being run between the Mobile Router and the configured for running OSPF.
Home Agent. (Issue 26).
- Clarified the use of Prefix Table. (Issue 25). - The entire Home domain SHOULD NOT be configured as a single area
if a Home Agent supports Mobile Routers. At least the Home
Network should be configured as a separate area.
- Clarified Mobile Router sending router advertisements on its - The bi-directional tunnel interfaces to the Mobile Routers should
egress interface when at home. (Issue 21 and 26). never be included in the same area as the backbone links.
- Clarified implementation requirements with respect to the Mobile For a more detailed discussion on configuring a Home Network for NEMO
IPv6 specification. (Issue 27). Basic Support, please see [18].
- Modified/added network mobility terms so that the NEMO One disadvantage of running OSPFv3 with NEMO Basic Support is that
terminology document becomes an informative reference. (Issue there is a possibility that the Mobile Networks will be told of the
28). topology of the entire Home Network, including all the fixed and
mobile routers, while the only thing the Mobile Routers might really
need is a default route through the Home Agent.
- Provided more information for creating SPD entries for protecting To reduce the amount of routing protocol messages received by a
routing protocol messages. (Issue 29). Mobile Router, one can configure each bi-directional tunnel to a
Mobile Router as a separate area. But this requires that the Home
Agent support a large number of OSPF areas if it supports a large
number of Mobile Routers and might not be possible with most router
implementations.
Authors Addresses Another option is to configure multiple areas on the Home Link and
group a number of Mobile Routers into each area. This reduces the
number of areas that a Home Agent needs to support, but at the same
time reduces the amount of routing protocol traffic that a Mobile
Router receives.
C. Changes from Previous Version
The following changes have been made to this document from version 02
- Clarified that Mobile Network Prefix Options should be ignored in
de-registration binding updates. (Issue #30)
- Addressed tunnel interface concerns when dynamic routing
protocols are used. Added section B.1. (Issue #31)
- Addressed OSPF Area configuration considerations. Added section
B.2. (Issue #31)
- Clarified the use of link local addresses on the inner
encapsulated packets when routing protocol messages are exchanged
between the Mobile Router and the Home Agent. (Issue #31)
- Clarified that binding acknowledgement status values are in
decimal. (Issue #32)
- Clarifed that the Home Agent does not have to check the source
address of the outer IPv6 header against the binding cache if the
tunneled packet is protected by ESP in tunneled mode. (Issue
#33)
- Fixed the text which says Mobile Router does not process binding
acknowledgement with status value 140. (Issue #33)
- Added text to clarify the relationship between the use of a
Prefix Table and running a dynamic routing protocol. (Issue #33)
- Clarified the terminology used in describing bi-directional
tunnel setup. (Issue #34)
- Added text to specify that the Mobile Router has to implement
atleast one mode and may implement both. (Issue #34)
- Re-wrote section 5.4 for better clarity. (Issue #34)
- Mobile Router Flag in Binding Update conflicts with HMIPv6's M
flag. Moved the flag to a new position. (Issue #35)
- Clarified Binding Acknowledgement status value 139 and the Mobile
Router Flag. (Issue #38)
Authors' Address
Vijay Devarapalli Vijay Devarapalli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: vijay.devarapalli@nokia.com Email: vijay.devarapalli@nokia.com
Ryuji Wakikawa Ryuji Wakikawa
Keio University and WIDE Keio University and WIDE
skipping to change at page 36, line 7 skipping to change at page 39, line 7
Pascal Thubert Pascal Thubert
Cisco Systems Technology Center Cisco Systems Technology Center
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille 400, Avenue Roumanille
Biot - Sophia Antipolis 06410 Biot - Sophia Antipolis 06410
France France
Email: pthubert@cisco.com Email: pthubert@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on made any independent effort to identify any such rights. Information
the IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt Copies of IPR disclosures made to the IETF Secretariat and any
made to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementers or users of this specification can attempt made to obtain a general license or permission for the
be obtained from the IETF Secretariat. use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided
others, and derivative works that comment on or otherwise explain it on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
or assist in its implementation may be prepared, copied, published REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
and distributed, in whole or in part, without restriction of any INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
kind, provided that the above copyright notice and this paragraph IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
are included on all such copies and derivative works. However, THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
this document itself may not be modified in any way, such as by WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 104 change blocks. 
317 lines changed or deleted 430 lines changed or added

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