NEMO Working Group P. Valitalo
Internet-Draft VTT Electronics
Expires: September 8, 2005 March 8, 2005
Multihoming of (1,1,*) configured networks in Network Mobility Support
draft-valitalo-nemo-multihoming-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2005.
Copyright Notice
Copyright (c) The Internet Society (2005).
Abstract
This draft describes, how NEMO support works with multiple care-of
addresses, in a multihomed mobile network, when there exists one
home agent, one mobile router, and one or more mobile network
prefixes. Solution to the problem, how to register multiple care-of
addresses bound to a single home address in a NEMO support, is
proposed.
Valitalo Expires September 8, 2005 [Page 1]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. (1,1,*) Configuration . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems in the configuration . . . . . . . . . . . . . . . . . . 3
4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
When the mobile network has more than one point of attachment to
the Internet, mobile network is called being multihomed.
Multihoming situations can occur when the mobile network has
multiple Mobile Routers, mobile network is associated with multiple
Home Agents, or when the Mobile Router has multiple egress
interfaces.
In this document, potential problem in a system, which uses NEMO
Support [1], with one Home Agent, one Mobile Router and one or more
prefixes (1,1,* configuration) is described, and a solution is
proposed to the problem.
When the Mobile Router is away from home and has more than one
egress interface (for example, more than one connection to the
Internet), there may occur a problem with care-of addresses: In
Mobile IPv6 specification [2], it is denied to register more than
one care-of address to the home address in the Home Agent's Binding
Cache (BC). A solution to this problem has been proposed in [3],
which extends the Mobile IPv6 protocol by adding a Binding Unique
Identifier (BID) to the binding cache entry to allow the
registration of multiple care-of addresses (mCoA) bound to a single
home address. When the Mobile Router wants to register multiple
care-of addresses to the Home Agent, it sends first a Binding
Update (BU) to the Home Agent, registering the primary care-of
address first, with BID number set. If the primary care-of address
registration is successful, the Mobile Router can register the rest
of the care-of addresses. The BID number is used to identify the BC
entry later, in cases that multiple care-of addresses can't be
registered with a single BU, instead, every care-of address
registration requires own BU message.
Valitalo Expires September 8, 2005 [Page 2]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
2. (1,1,*) Configuration
The Mobile Router has multiple egress interfaces, which are
connected to the Internet. There exists only one Home Agent. The
mobile network has one or more mobile network prefixes, which are
advertised to the ingress interface by the Mobile Router.
+----+ p1 CoA1 +----+ +----------+
| MN |---+ +----+ +---| AR |---| | +----+
+----+ +---| |---+ +----+ | | | |
| MR | | Internet |---| HA |
+----+ +---| |---+ +----+ | | | |
| MN |---+ +----+ +---| AR |---| | +----+
+----+ p2 CoA2 +----+ +----------+
Figure 1. (1,1,N) configuration of the NEMO network.
3. Problems in the configuration
In [4] and [5], potential problems with multihoming configurations
have been analysed. The usage possibility of BID has been
recognized, but there is not further implementations where the BID
is in use.
For example, if the Mobile Router has 3 different egress interfaces
to the Internet, after binding update process, the binding cache at
the Home Agent could look like following, if the care-of addresses
are bound to a single home address:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address | Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HoA-1 | CoA-1 |
| | CoA-2 |
| | CoA-3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HoA-1 = Mobile Router's home address
CoA-x = Mobile Router's care-of address x
In [3], at chapter 5.2, it is stated that:
o "Note that there is no optimization such as registering multiple
care-of addresses by using a single Binding Update, because the
current Mobile IPv6 specification does not allow to send multiple
bindings by means of a single Binding Update"
Thus, in a case of registering multiple care-of addresses belonging
to the same home address, multiple Binding Update messages has to be
send from the Mobile Router to the Home Agent.
Valitalo Expires September 8, 2005 [Page 3]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
Problem is at the Binding Update message structure. Currently, in
NEMO support, the flags and their order at the Binding Update
message are defined as |A|H|L|K|M|R|, as seen below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags A, H, L, and K are defined by the MIPv6 specification [2]. The
M-flag is used for Mobility Anchor Point (MAP) registration
purposes, defined at HMIPv6 specification [6]. The R-flag is called
as "Mobile Router Flag", and is set to inform the Home Agent, if the
Binding Update message comes from the Mobile Router. R-flag is
defined at NEMO support.
In [3], a modification to the Binding Update message is proposed. To
enable the BID usage in the Binding Update messages, a new flag has
been defined, called as "Multiple Care-of Addresses Flag" and is
defined as "M". The flag is used to inform the recipient (Home Agent
or Corresponding Node) about the presence of the BID information.
The mCoA specification [3] defines the flag order in the Binding
Update as |A|H|L|K|R|M|, as seen below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|R|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the Binding Update flag order is compared to the order defined in
NEMO support [1], a couple of problems occur. The M-flag is defined
twice (in [3] and [6]), with different definitions, and the
placement of the flags is different.
Valitalo Expires September 8, 2005 [Page 4]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
In the Binding Acknowledgement message structure, no flag
modifications are needed, because the mCoA specification [3] does not
define any new flags. However, new status code is required. MIPv6
specification [2] defines status codes 0, 1, 128-139. NEMO
support [1] defines status codes 140-143. The mCoA specification [3]
defines status code 140, so it should be renumbered.
4. Proposed solution
4.1 Binding Update
Multiple care-of addresses flag is renamed and its position is
changed in the Binding Update. Flag is renamed from 'M' to 'B', and
moved to the rightmost position. Rest of the flags remain same as
listed in [1]. The redefined message structure is below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple care-of addresses flag (B)
This flag is used for multiple care-of addresses registration.
4.2 Binding Acknowledgement
Status code 140, "Binding Conflict", which is proposed at mCoA
specification, is renumbered to 144. Thus, the status codes
defined at [1] remain same.
140 Mobile Router Operation not permitted
141 Invalid Prefix
142 Not Authorized for Prefix
143 Forwarding Setup failed
144 Binding Conflict
Valitalo Expires September 8, 2005 [Page 5]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
5. References
[1] V. Devarapalli et. al. "Network Mobility (NEMO) Basic Support
Protocol", RFC 3963, January 2005.
[2] D. Johnson, C. Perkins, J. Arkko. "Mobility Support in IPv6",
RFC 3775, June 2004.
[3] R. Wakikawa, K. Uehara, T. Ernst, K. Nagami. "Multiple Care-of
Addresses Registration", Internet Draft,
draft-wakikawa-mobileip-multiplecoa-03 (work in progress), June
2004.
[4] C. Ng, E. Paik, T. Ernst. "Analysis of Multihoming in Network
Mobility Support", Internet Draft,
draft-ietf-nemo-multihoming-issues-02 (work in progress),
February 2005.
[5] N. Montavont et. al. "Analysis of Multihoming in Mobile IPv6",
Internet Draft,
draft-montavont-mobileip-multihoming-pb-statement-03 (work in
progress), January 2005.
[6] H. Soliman, C. Catelluccia, K. El Maki, L. Bellier.
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
Internet Draft, draft-ietf-mipshop-hmipv6-04 (work in progress),
December 2004.
Author's Address
Pekka Valitalo
VTT Electronics
Kaitovayla 1
90571 Oulu
Finland
E-Mail: pekka.valitalo@vtt.fi
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Valitalo Expires September 8, 2005 [Page 6]
Internet-Draft (1,1,*) Multihoming in NEMO March 2005
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the 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 copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING 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
Funding for the RFC Editor function is currently provided by the
Internet Society.