No Specific Working Group C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: December 30, 2004 J. Hirano
Panasonic
July 2004
Host/Edge Multihoming Problem Statement
draft-ng-edge-multihoming-problem-statement-00
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,
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document analyzes multihoming from the perspective of the
Internet edge: i.e. hosts and other edge networks. We built on top
of the previous work that describes goals and benefits of
multihoming, and identify problems for the provisioning of
multihoming at the edge level. In this memo, we first look at the
problem of multihoming for a generic IPv6 node, followed by narrowing
the analysis down to mobile hosts and networks.
Ng & Hirano Expires December 30, 2004 [Page 1]
Internet-Draft Edge Multihoming Problem July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Upper Layer Transparency . . . . . . . . . . . . . . . . . . . 4
2.1 Receiver is Multihomed . . . . . . . . . . . . . . . . . . 4
2.2 Sender is Multihomed . . . . . . . . . . . . . . . . . . . 5
2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Outgoing Path . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Incoming Path . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Peer Knowledge . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Infrastructure Knowledge . . . . . . . . . . . . . . . . . 9
5. Mobility Considerations . . . . . . . . . . . . . . . . . . . 11
5.1 Multihomed Mobile IPv6 Node . . . . . . . . . . . . . . . 11
5.1.1 Upper Layer Transparency . . . . . . . . . . . . . . . 11
5.1.2 Outgoing Path . . . . . . . . . . . . . . . . . . . . 11
5.1.3 Incoming Path . . . . . . . . . . . . . . . . . . . . 12
5.2 Multihomed Mobile Networks . . . . . . . . . . . . . . . . 12
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Ng & Hirano Expires December 30, 2004 [Page 2]
Internet-Draft Edge Multihoming Problem July 2004
1. Introduction
Multihoming has attracted wide interest recently. Within the IETF,
Site Multihoming for IPv6 (multi6) Working Group is looking at the
multihoming problem from the perspective of an IPv6 site, and
provisioning of multihoming in IPv6 is being solved more or less
using the core network. This document aims to look at multihoming
from the perspective of the Internet edge: i.e. hosts and other edge
networks.
Benefits of multihoming has been identified in RFC 3582 [1] and
"draft-multihoming-generic-goals-and-benefits-00" [2]. However,
there is no clear problem statement on the provisioning of
multihoming at the edge level. It is an objective of this draft to
identify such problems.
By "edge", we refer to hosts or stub networks attached at the edge of
the Internet that does not have any transit traffic. The host and
network may themselves be mobile. This document will attempt to look
at multihoming problem at two different levels of details: (a) no
assumption on the mobility of the edge elements; and (b) when the
edge elements are mobile.
It is assumed that the readers are familiar with the goals, benefits
and deployments scenarios as spelt out in [2].
We begin by first looking at the problem of multihoming for a generic
edge element from three different perspective:
1. From the perspective of upper layer protocols (i.e transport and
above), we explore the problem multihoming brings with regards to
continuity of upper layer sessions. This is done in Section 2.
2. From the perspective of multihomed edge elements, we look into
the problem of sending packets out given the source is
multihomed. This is done in Section 3.
3. From the perspective of peers of multihomed edge elements, we
describe the problem of sending packets to a destination that is
multihomed. This is done in Section 4.
Following these, problem specific to multihomed edge elements that
are mobile is investigated in Section 5.
Ng & Hirano Expires December 30, 2004 [Page 3]
Internet-Draft Edge Multihoming Problem July 2004
2. Upper Layer Transparency
By definition, a multihomed node has multiple IPv6 addresses. Here,
we assumed that it has multiple global-scoped IPv6 addresses (i.e.
excluding node-local, link-local, and site-local addresses).
One immediate problem faced by a multihomed node is the question of
which address to use. It may be trivially selected, or chosen based
on certain policy or preferences settings. No matter how chosen,
there is now an issue of upper layer transparency.
The more common and widely used transport layer protocols by far are
TCP and UDP. These transport protocols associate end-point addresses
with each session. Thus, to these protocols, a change in either the
source address or destination address would mean a different session.
In order to enjoy benefits of multihoming, it is often necessary to
change the address used. Thus, there is a problem of how to achieve
upper layer transparency when employing multihoming mechanisms. In
other words, the problem is to achieve multihoming without breaking
legacy transport protocols such as TCP and UDP.
There are two parts to consider in upper layer transparency: (a) the
receiver is multihomed, and (b) the sender is multihomed.
2.1 Receiver is Multihomed
When the receiver is multihomed, the sender has a choice of using one
of the multiple addresses as the destination (we ignore for now the
question of how the sender learns of these multiple addresses). The
problem in this case is how to use these different addresses in the
destination address field and yet have the transport protocol at the
receiver associates these packets to the same transport session.
As an illustration (refer to Figure 1), suppose a node, TX, sends to
another node, RX, two packets belonging to the same transport
session. In the first packet, node TX decided to use RX.Addr1 as the
destination address, and in the second packet, node TX decided to use
RX.Addr2 as the destination address. The problem is how does the
transport protocol at node RX knows that the two packets belong to
the same session.
Ng & Hirano Expires December 30, 2004 [Page 4]
Internet-Draft Edge Multihoming Problem July 2004
Packet 2 Packet 1
+---------------+ +---------------+
| src: TX.Addr | | src: TX.Addr |
| dst: RX.Addr2 | | dst: RX.Addr1 |
| ... ... | | ... ... |
+----+ +---------------+ +---------------+ +----+
| TX |------------------------------------------| RX |
+----+ +----+
IP: TX.Addr IP: RX.Addr1, RX.Addr2
Figure 1: Packets from the same transport session with different
destination addresses
2.2 Sender is Multihomed
When the sender is multihomed, the sender may have to switch among
multiple source addresses for reasons of ingress filtering [3]. The
problem in this case is how to use these different addresses in the
source address field and yet have the transport protocol at the
receiver associates these packets to the same transport session.
As an illustration (refer to Figure 2), suppose a node, TX, sends to
another node, RX, two packets belonging to the same transport
session. In the first packet, node TX uses TX.Addr1 as the source
address, and in the second packet, node TX uses TX.Addr2 as the
source address. The problem is how does the transport protocol at
node RX knows that the two packets belong to the same session.
Packet 2 Packet 1
+---------------+ +---------------+
| src: TX.Addr2 | | src: TX.Addr1 |
| dst: RX.Addr | | dst: RX.Addr |
| ... ... | | ... ... |
+----+ +---------------+ +---------------+ +----+
| TX |------------------------------------------| RX |
+----+ +----+
IP: TX.Addr1, TX.Addr2 IP: RX.Addr
Figure 2: Packets from the same transport session with different
source addresses
2.3 Discussion
It can be perceived that a possible approach is to separate the
currently overloaded IP address into individual functions: an
"identifying" address used to identify the multihomed node, and one
Ng & Hirano Expires December 30, 2004 [Page 5]
Internet-Draft Edge Multihoming Problem July 2004
or more "locating" addresses used to route packets to/from the
multihomed node. In this case, the protocol layers above IP will use
the "identifying" address, and the protocol layers below IP will use
the "locating" address.
Ng & Hirano Expires December 30, 2004 [Page 6]
Internet-Draft Edge Multihoming Problem July 2004
3. Outgoing Path
A multihomed node would usually has multiple, independent, routes to
the Internet. Given these routes, how do a multihomed node choose
which route to send a packet? Such decision can be made arbitrarily,
or based on certain preferences or policy.
In addition, it is sometimes necessary for the multihomed node to
select the route based on the actual source address used on a packet.
This is mainly due to ingress filtering. Ingress filtering occurs
when an intermediate router discards packet because the
source-address of the packet is not of a valid prefix [3].
As an illustration, consider a node N with two independent routes to
the Internet through two Internet Service Providers, ISP-A and ISP-B,
as shown in Figure 3. ISP-A assigns node N an address PA.N from the
prefix PA, and ISP-B assigns node N an address PB.N from the prefix
PB. Both ISPs implements ingress filtering to prevent malicious
subscribers from performing IP spoofing.
Prefix: PA +-------+ +----------+
/-----| ISP-A |----| |
/ +-------+ | |
IP: +---+ | |
PA.N | N | | Internet |
PB.N +---+ | |
\ +-------+ | |
\-----| ISP-B |----| |
Prefix: PB +-------+ +----------+
Figure 3: Multihomed node obtaining different addresses from
different ISPs
In such cases, to avoid ingress filtering, node N is forced to send
packets with source address PA.N through ISP-A, and send packets with
source address PB.N through ISP-B.
3.1 Discussion
With relation to "Upper Layer Transparency" (Section 2), it is
interesting to note that should the upper layer transparency problem
be solved, the problem of ingress filtering for outgoing path may
then be trivial. For instance, we assume that the problem of upper
layer transparency is solved with an "identifying" address and a set
of "locating" addresses. Then, the multihomed node can choose the
locating address as the packet source based on the route selected
such that the packet would not be discarded by ingress filtering.
Ng & Hirano Expires December 30, 2004 [Page 7]
Internet-Draft Edge Multihoming Problem July 2004
Using the same scenario depicted in Figure 3, suppose node N now
acquired an identifying address of ID.N. Then, the pair of addresses
PA.N and PB.N will be the locating addresses. Whenever node N wants
to send packet through ISP-A, it changes the source address of that
packet to PA.N. Similarly, whenever node N wants to send packet
through ISP-B, it changes the source address of that packet to PB.N.
Ng & Hirano Expires December 30, 2004 [Page 8]
Internet-Draft Edge Multihoming Problem July 2004
4. Incoming Path
When a node is multihomed, there are multiple paths to send a packet
to the node. The question is then how does a particular path get
selected to be the delivery route of any given packet. If the
address of the multihomed node is identical across all paths, then it
is up the routing infrastructure to select the path. It will be
subjected to the routing policy of the core routers to pick
arbitrarily or based on certain parameters (such as congestion
condition on each path, etc) a delivery route. The sender or the
multihomed node has little control over which route to take.
However, if the addresses of the multihomed node is different on each
path, the route taken will be decided by the destination address on
each packet. The question is then how does the sender knows the
different addresses belonging to the multihomed node. This is the
problem of "Peer Knowledge". A slight alternative is instead of
having every peer node that communicates with the multihomed node to
know the set of addresses, only a smaller set of intermediate
elements in the routing infrastructure know. This is the problem of
"Infrastructure Knowledge".
4.1 Peer Knowledge
This is the problem of how a multihomed node notifies the peer node
it is communicating with the set of addresses that it owns. A
solution that solves this problem must also address the following
issues:
o What is the form of signaling?
o How are the list of addresses communicated to the peer node?
o How can the peer node ascertain the specified list of addresses
are indeed owned by the multihomed node?
4.2 Infrastructure Knowledge
Alternatively, perhaps it is not necessary for the peer node to learn
all of the addresses of the multihomed node. It might suffice for a
selected pool of nodes to know the addresses. In this case, the peer
node needs only know the "identifying" address of the multihomed
node, and will only use this "identifying" address in the destination
field of the packet. A set of intermediate routers will capture
these packets, and translate the "identifying" address to one of the
known "locating" addresses of the multihomed node.
Ng & Hirano Expires December 30, 2004 [Page 9]
Internet-Draft Edge Multihoming Problem July 2004
A solution that solves the problem of infrastructure knowledge should
also addresses the following issues (most are similar to those listed
in Section 4.1):
o What is the form of signaling?
o How are the list of addresses communicated to the intermediate
router(s)?
o How can the intermediate router(s) ascertain the specified list of
addresses are indeed owned by the multihomed node?
o How can the intermediate router(s) change the "identifying"
address in the destination field of the packet to one of the
"locating" addresses?
o What is the impact of changing addresses by intermediate routers
on the end-to-end integrity of the packet?
Ng & Hirano Expires December 30, 2004 [Page 10]
Internet-Draft Edge Multihoming Problem July 2004
5. Mobility Considerations
In this section, we focused our attention to multihomed nodes that
are mobile. There might be problems related to multihoming that are
specific to mobile nodes. There might also be problems that are
exemplified (and perhaps intensified) when multihomed nodes are
mobile. We first consider the case when the mobile multihomed node
is a host. Then, we consider the case when a mobile network is
multihomed.
5.1 Multihomed Mobile IPv6 Node
When we refer to a mobile node, it is implied that the node employs
Mobile IPv6 [4] to gain mobility support while roaming across
different access networks. It is assumed that the readers are
familiar with temrs used in Mobile IPv6. There is a draft on
multihoming problem with Mobile IPv6 [5] which raise issues
multihoming with a mobile node that are similar to those described
here. This section however looks at the problem from another angle.
5.1.1 Upper Layer Transparency
The concept of home-address and care-of-addresses associated with a
mobile node may be an effective mechanism for achieving upper layer
transparency. However, a multihomed mobile node may have multiple
home-addresses. Thus, there is still a need to identify the
"identifying" address for use with transport (and upper) layer
protocols.
5.1.2 Outgoing Path
A multihomed mobile node may have multiple care-of-addresses. In
order to use more than one egress link, it might be necessary for the
mobile node to use these multiple care-of-addresses simultaneously
(for example, to overcome ingress filtering at the access network).
Hence there is a need for the ability to bind multiple
care-of-addresses to one home-address. This is currently addressed
by [6].
The problem of ingress filtering, however, is two-fold. It can occur
at the access network, as well as the home network. Figure 4
illustrates this case. In the access network, when mobile node MN
sends a packet through AR-A, it must use the care-of-address of
PA.MN; and when MN sends a packet through AR-B, it must use the
care-of-address of PB.MN. In the home network, when MN tunnels the
packet to home-agent HA-1, it must use the home-address P1.MN; and
when MN tunnels the packet to home-agent HA-2, it must use the
home-address P2.MN. This greatly limits the way MN can enjoy the
Ng & Hirano Expires December 30, 2004 [Page 11]
Internet-Draft Edge Multihoming Problem July 2004
benefits of multihoming.
It must be noted that should the mobile node MN have a way of binding
both care-of-addresses PA.MN and PB.MN simultaneously to both
home-addresses P1.MN and P2.MN, then it can choose the
care-of-address to use base on the access network it wishes to use
for outgoing packets. This solves the first part of the problem:
ingress filtering at the access network. It is, nonetheless, still
limited to using only a specific home agent for the home-address it
uses (i.e. The second problem of ingress filtering at the home
network remains unsolved).
Prefix: PA +------+ +----------+ +------+
HoA: P1.MN /-----| AR-A |----| |----| HA-1 |
CoA: PA.MN / +------+ | | +------+
+----+ | | Prefix: P1
| MN | | Internet |
+----+ | | Prefix: P2
HoA: P2.MN \ +------+ | | +------+
CoA: PB.MN \-----| AR-B |----| |----| HA-2 |
Prefix: PB +------+ +----------+ +------+
Figure 4: Multihomed mobile node with multiple home agents
5.1.3 Incoming Path
The use of binding updates in MIPv6 [4] lends itself very well to
solving the problem of peer knowledge and infrastructure knowledge.
The most important prerequisite is then to solve the problem of
binding multiple care-of-addresses.
5.2 Multihomed Mobile Networks
The problem of mobile network is discussed in [7] and [8]. There is
an extensive analysis of the multihoming issues with mobile networks
[9]. This section merely highlights any problems that are specific
or more relevant to mobile networks. Interested readers should refer
to [9] for details.
Most of the problems relating to upper layer transparency, ingress
filtering at the access network, ingress filtering at the home
network, peer knowledge and infrastructure knowledge for mobile
networks share similar concerns as with a mobile host (see Section
5.1). One particularly interesting problem of ingress filtering at
the home network is shown in Figure 5 below.
In Figure 5, the mobile network has two mobile routers MR-A and MR-B,
Ng & Hirano Expires December 30, 2004 [Page 12]
Internet-Draft Edge Multihoming Problem July 2004
with home agents HA-A and HA-B respectively. Each mobile router
advertises a different mobile network prefix (PA and PB). Thus, the
mobile network node MNN configures two IPv6 addresses: PA.MNN and
PB.MNN. Hence, MNN is multihomed.
Prefix: PA +------+ +----+ +----------+ +------+
+--| MR-A |---| AR |--| |----| HA-A |
| +------+ +----+ | | +------+
IP: +-----+ | | | Prefix: PA
PA.MNN | MNN |--+ | Internet |
PB.MNN +-----+ | | | Prefix: PB
| +------+ +----+ | | +------+
+--| MR-B |---| AR |--| |----| HA-B |
Prefix: PB +------+ +----+ +----------+ +------+
Figure 5: Multihomed mobile network with multiple mobile routers and
home agents
However, MNN cannot forward packet with source address equals PA.MNN
to MR-B. This will cause ingress filtering at HA-B to occur (or even
at MR-B). This is contrary to normal Neighbor Discovery [10]
practice that an IPv6 node is free to choose any router as its
default router regardless of the prefix it choose to use. A simple
solution is to impose a requirement that all mobile network nodes
must set their default router to the router that advertises the
prefix the mobile network nodes configured their address from. If no
such requirements are to be imposed on mobile network nodes, then a
multihoming solution for mobile networks must address this problem.
Ng & Hirano Expires December 30, 2004 [Page 13]
Internet-Draft Edge Multihoming Problem July 2004
6. Conclusion
This document analyzed multihoming from the perspective of the
Internet edge: i.e. hosts and other edge networks. We built on top
of the previous work done in [2] and [1], which describe goals and
benefits of multihoming, and identify problems for the provisioning
of multihoming at the edge level.
We have looked at the problem of multihoming for a generic edge
element from three different perspectives:
1. From the perspective of upper layer protocols (i.e transport and
above), we explored the problem multihoming brings with regards
to continuity of upper layer sessions.
2. From the perspective of multihomed edge elements, we looked into
the problem of sending packets out given the source is
multihomed.
3. From the perspective of peers of multihomed edge elements, we
described the problem of sending packets to a destination that is
multihomed.
Following these, problem specific to multihomed edge elements that
are mobile (i.e. mobile hosts and mobile networks that are
multihomed) were analyzed.
Ng & Hirano Expires December 30, 2004 [Page 14]
Internet-Draft Edge Multihoming Problem July 2004
7 References
[1] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
[2] Ernst, T., "Goals and Benefits of Multihoming",
draft-multihoming-generic-goals-and-benefits-00 (work in
progress), February 2004.
[3] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Montavont, N., "Problem Statement for multihomed Mobile Nodes",
draft-montavont-mobileip-multihoming-pb-statement-00 (work in
progress), October 2003.
[6] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-02 (work in progress),
September 2003.
[7] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02 (work in progress), February
2004.
[8] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[9] Ng, C. and J. Charbon, "Multi-Homing Issues in Bi-Directional
Tunneling", draft-ng-nemo-multihoming-issues-03 (work in
progress), February 2004.
[10] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
Ng & Hirano Expires December 30, 2004 [Page 15]
Internet-Draft Edge Multihoming Problem July 2004
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
EMail: cwng@psl.com.sg
Jun Hirano
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
EMail: hirano.jun@jp.panasonic.com
Ng & Hirano Expires December 30, 2004 [Page 16]
Internet-Draft Edge Multihoming Problem July 2004
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.
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.
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ng & Hirano Expires December 30, 2004 [Page 17]