Acknowledgement to 142 (Not Authorized for Prefix) to indicate this.
The Home Agent sets the status code to 143 (Forwarding Setup failed)
if it is unable to determine the information needed to set up
forwarding for the Mobile Network. This is used in the Implicit
mode, in which the Mobile Router does not include any prefix
information in the Binding Update.
6.7. Mobile Network Prefix De-registration
When the Home Agent successfully processes the de-registration BU, it
deletes the Binding Cache Entry for the Mobile Router’s Home Address
and stops proxying the Home Address. This is described in detail in
the Mobile IPv6 specification [1].
In addition, the Home Agent removes the bi-directional tunnel and
stops forwarding packets to the Mobile Network. The Home Agent
should keep all necessary information to clean up whichever routes it
installed, whether they come from an 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 Address Discovery
This document extends the Dynamic Home Agent Address Discovery
(DHAAD) defined in [1] so that Mobile Routers only attempt
registration with Home Agents that support them.
7.1. Modified Dynamic Home Agent Discovery Address Request
A new flag (R) (Support for Mobile Routers) is introduced in the
DHAAD Request message, defined in [1]. The Mobile Router sets this
flag to indicate that it wants to discover Home Agents supporting
Mobile Routers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A one-bit flag that when set indicates that the Mobile Router
wants to discover Home Agents supporting Mobile Routers.
For a description of the other fields in the message, see [1].
7.2. Modified Dynamic Home Agent Discovery Address Request
A new flag (R) (Support for Mobile Routers) is introduced in the
DHAAD Reply message, defined in [1]. If a Home Agent receives a
Dynamic Home Agent Discovery request message with the Mobile Router
Support Flag set, it MUST reply with a list of Home Agents supporting
Mobile Routers. The Mobile Router Support Flag MUST be set if there
is at least one Home Agent supporting Mobile Routers. If none of the
Home Agents support Mobile Routers, the Home Agent MAY reply with a
list of Home Agents that only support Mobile IPv6 Mobile Nodes. In
this case, the Mobile Router Support Flag MUST be set to 0.
The modified message format is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A one-bit flag that when set indicates that the Home Agents
listed in this message support Mobile Routers.
For a description of the other fields in the message, see [1].
7.3. Modified Home Agent Information Option
A new flag (R) (Support for Mobile Routers) is introduced in the Home
Agent Information Option defined in [1]. If a Home Agent supports
Mobile Routers, it SHOULD set the flag.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router Support Flag (R)
A one-bit flag that when set indicates that the Home Agent
supports Mobile Routers.
For a description of the other fields in the message, see [1].
8. Support for Dynamic Routing Protocols
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
Update from the Mobile Router. An alternative to this is for the
Home Agent and the Mobile Router to run an intra-domain routing
protocol such as RIPng [12] and OSPF [13] through the bi-directional
tunnel. The Mobile Router can continue running the same routing
protocol that it ran when 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
multiple subnets containing different IPv6 prefixes. Routing changes
in the Mobile Network are quickly propagated to the Home Agent.
Routing changes in the home link are quickly propagated to the Mobile
Router.
When the Mobile Router is attached to the home link, it runs a
routing protocol by sending routing updates through its egress
interface. When the Mobile Router moves and attaches to a visited
network, it should stop sending routing updates on the interface by
which it attaches to the visited link. This reduces the chances that
prefixes specific to the Mobile Network will be leaked to the visited
network if routing protocol authentication is not enabled in the
visited network and in the Mobile Network. It is expected that
normal deployment practices will include proper authentication
mechanisms to prevent unauthorized route announcements on both the
home and visited networks. The Mobile Router then starts sending
routing protocol messages through the bi-directional tunnel toward
the Home Agent. Most routing protocols use link-local 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 MUST NOT be forwarded to
another link by either the Mobile Router or the Home Agent.
When the Home Agent receives the inner packet, it processes the
encapsulated routing protocol messages and updates its routing table
accordingly. As part of normal routing protocol operation, the next
hop information in these routing entries is filled with the Mobile
Router’s link-local address, with the outgoing interface set to the
bi-directional tunnel.
Similarly, the Home Agent sends routing updates through the bi-
directional tunnel to the Mobile Router. The Mobile Router processes
these routing protocol messages and updates its routing table. For
all routes advertised by the Home Agent, the Mobile Router sets the
outgoing interface to the bi-directional tunnel to the Home Agent.
When the Mobile Router and the Home Agent exchange routes through a
dynamic routing protocol, the Mobile Router SHOULD NOT include Mobile
Network Prefixes in the Binding Update to the Home Agent. Depending
on its configuration, the Home Agent might not add routes based on
the prefix information in the Binding Updates and might use only the
routing protocol updates. Moreover, including prefix information in
both the Binding Updates and the routing protocol updates is
redundant.
As the routing protocol messages from the Home Agent to the Mobile
Router could potentially contain information about the internal
routing structure of the home network, these messages require
authentication and confidentiality protection. Appropriate
authentication and confidentiality protection mechanisms, defined in
[14], MUST be used. For protecting routing protocol messages by
using IPsec ESP [4], the bi-directional tunnel between the Mobile
Router and the Home Agent should be treated as the outgoing
interface, with the Home Agent and Mobile Router’s addresses as
source and destination addresses for the inner encapsulated messages.
If a link state routing protocol such as OSPFv3 is run by the Mobile
Router and the Home Agent, the recommendations in Appendix B should
be followed.
9. Security Considerations
All signaling messages between the Mobile Router and the Home Agent
MUST be authenticated by IPsec [8]. The use of IPsec to protect
Mobile IPv6 signaling messages is described in detail in the HA-MN
IPsec specification [2]. The signaling messages described in this
document extend Mobile IPv6 messages and do not require any changes
to what is described in [2].
The Mobile Router has to perform ingress filtering on packets
received from the Mobile Network to ensure that nodes in the Mobile
Network do not use the bi-directional tunnel to launch IP spoofing
attacks. In particular, the Mobile Router SHOULD check that the IP
source addresses in the packets received belong to the Mobile Network
Prefix and are not the same as one of the addresses used by the
Mobile Router. If the Mobile Router receives an IP-in-IP tunneled
packet from a node in the Mobile Network and it has to forward the
decapsulated packet, it SHOULD perform the above mentioned checks on
the source address of the inner packet.
The Home Agent has to verify that packets received through the bi-
directional tunnel belong to the Mobile Network. This check is
necessary to prevent nodes from using the Home Agent to launch
attacks that would have otherwise been prevented by ingress
filtering. The source address of the outer IPv6 header MUST be set
to the Mobile Router’s current Care-of Address. The source address
of the inner IPv6 header MUST be topologically correct with respect
to the IPv6 prefixes used in the Mobile Network.
If the Mobile Router sends a Binding Update with a one or more Mobile
Network Prefix options, the Home Agent MUST be able to verify that
the Mobile Router is authorized for the prefixes before setting up
forwarding for the prefixes.
When the Mobile Router runs a dynamic routing protocol as described
in section 8, it injects routing update messages into the Home Link.
As the routing protocol message could contain information about the
internal routing structure of the home network, these messages
require confidentiality protection. The Mobile Router SHOULD use
confidentiality protection through IPsec ESP as described in [14].
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
considerations when the Mobile Router operates as a Mobile Host.
10. IANA Considerations
This document defines a new Mobility Header Option, the Mobile
Network Prefix Option as described in section 4.3. The type value
for this option MUST be assigned from the same space used by the
mobility options defined in [1].
This document also defines the following new Binding Acknowledgement
status values. These status values are defined in section 4.2 and
MUST be assigned from the same space used for Binding Acknowledgement
status values in [1].
- Mobile Router Operation not permitted
- Invalid Prefix
- Not Authorized for Prefix
- Forwarding Setup failed (prefixes missing)
11. Contributors
We would like to acknowledge Ludovic Bellier, Claude Castelluccia,
Thierry Ernst [15], Miguel Catalina-Gallego, Christophe Janneteau,
T.J. Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya,
Alexis Olivereau, Charles E. Perkins, and Keisuke Uehara for their
work on earlier proposals for Network Mobility. This document has
inherited a lot of ideas from these proposals.
12. Acknowledgements
We thank all members of the NEMO Working Group, and of the preceding
MONET BoF, for fruitful discussions on the mailing list and at IETF
meetings.
Kent Leung, Marco Molteni, and Patrick Wetterwald are acknowledged
for their work on Network Mobility for IPv4 and IPv6.
Tim Leinmueller is acknowledged for many insightful remarks and for
section 7.
Jari Arkko, James Kempf, Chan-Wah Ng, and Erik Nordmark are
acknowledged for their thorough review and comments.
Souhwan Jung, Fan Zhao, S. Felix Wu, HyunGon Kim, and SungWon Sohn
are acknowledged for identifying threats related to tunneling between
the Mobile Network and the Home Agent.
13. References
13.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[9] Manner, J. and M. Kojo, Eds., "Mobility Related Terminology",
RFC 3753, June 2004.
[10] Ernst, T., and H.-Y. Lach, "Network Mobility Support
Terminology", Work in Progress, October 2004.
[11] Ernst, T., "Network Mobility Support Goals and Requirements",
Work in Progress, October 2004.
[12] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January
1997.
[13] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999.
[14] Gupta, M. and N. Melam, "Authentication/Confidentiality for
OSPFv3", Work in Progress, December 2004.
[15] Ernst, T., "Network Mobility Support in IPv6", PhD Thesis,
University Joseph Fourier, Grenoble, France. October 2001.
[16] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995.
[17] Thubert, P., et al., "NEMO Home Network models", Work in
Progress, October 2004.
Appendix A. Examples of NEMO Basic Support Operation
This section tries to illustrate the NEMO protocol by using a Mobile
Router and a Mobile Node belonging to different administrative
domains. The Mobile Router’s Mobile Network consists of a Local
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
attach.
Figure 1 depicts the scenario where both the Mobile Router and the
Mobile Node are at home.
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +-------------------+ +-------+
4:: |
|
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 1. Mobile Router and Mobile Node at home.
The Mobile Router then moves away from the home link and attaches to
a visited link. This is shown in Figure 2. The Mobile Router sends
a Binding Update to HA_MR when it attaches to a visited link and
configures a Care-of Address. HA_MR creates a binding cache entry
for the Mobile Router’s Home Address and also sets up forwarding for
the prefixes on the Mobile Network.
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
| 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------
Figure 2. Mobile Router on a visited link.
Figure 3 shows the Mobile Node moving away from its home link and
attaching to the Mobile Router. The Mobile Node configures a Care-of
Address from the prefix advertised on the Mobile Network and sends a
Binding Update to its Home Agent (HA_MN) and to its Correspondent
Node (CN_MN). Both HA_MN and CN_MN create binding cache entries for
the Mobile Node’s Home Address.
+-------+
| HA_MN | 1::2->6::2
1:: +---+---+
---------|3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
1::2->6::2 | 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+
Figure 3. Mobile Node attached to Mobile
Router on a visited link
Appendix B. Running Link State Routing Protocol with NEMO Basic Support
The bi-directional tunnel between the Mobile Router and the Home
Agent is used as a virtual interface over which routing protocol
messages are exchanged. When a link state routing protocol is run,
the following recommendations should be followed.
B.1. Tunnel Interface Considerations
If the tunnel interface goes up and down every time the Mobile Router
moves to a new visited network with a high level of mobility and a
sufficient number of Mobile Routers, the amount of interface state