One document matched: draft-ng-nemo-multihoming-issues-00.txt
Network Mobility Working Group C. W. Ng
Internet-Draft Panasonic Singapore Labs
Expires: August 2003 T. Tanaka
Panasonic Mobile Communications
February 2003
Multi-Homing Issues in Bi-Directional Tunneling
draft-ng-nemo-multihoming-issues-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes deployment scenario of multi-homed NEMO and
attempts to identify issues that arises when supporting multi-homing
in NEMO. This document also proposes an approach to facilitate
multi-homing in NEMO. However, it is not the objective of this memo
to define a specification for multi-homing support in NEMO.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Ng & Tanaka Expires - August 2003 [Page 1]
Internet-Draft Multi-homing Issues in NEMO February 2003
Table of Contents
1. Introduction...................................................3
1.1. Terms Used................................................5
1.2. Organization..............................................5
2. Multi-Homing in NEMO...........................................6
2.1. Deployment Scenarios of Multi-homed NEMO..................6
2.1.1. Single Mobile Router with Multiple Egress Interfaces
Bound to a Single Home Agent................................6
2.1.2. Single Mobile Router with Multiple Egress Interfaces
Bound to Different Home Agents..............................7
2.1.3. Multiple Mobile Routers..............................8
2.2. Issues of Multi-Homing in NEMO............................9
3. Using Multi-Homing Features in Bi-Directional Tunnels.........11
3.1. Detecting Presence of Alternate Routes...................11
3.2. Re-Establishment of Bi-Directional Tunnels...............12
3.2.1. Using Alternate Egress Interface....................12
3.2.2. Using Alternate Mobile Router.......................12
3.3. To Avoid Tunneling Loop..................................13
3.4. Other Considerations.....................................13
4. Security Considerations.......................................14
References.......................................................14
Author's Addresses...............................................16
Ng & Tanaka Expires - August 2003 [Page 2]
Internet-Draft Multi-homing Issues in NEMO February 2003
1. Introduction
The problem of Network Mobility Support (NEMO) is identified in
various previous works [3,4,5,6]. In essence, the problem of network
in motion is to provide continuous Internet connectivity to nodes in
a network that moves as a whole. Nodes within the network that moves
may not be aware of the network changing its point of attachment to
the Internet. This differs from the traditional problem of mobility
support as addressed by Mobile IPv4 [7] in Internet Protocol version
4 (IPv4) [8] and Mobile IPv6 [9] in Internet Protocol version 6
(IPv6) [10].
In Mobile IP, each mobile node has a permanent home domain. When the
mobile node is attached to its home network, it is assigned a
permanent global address known as a home-address (HoA). When the
mobile node is away, i.e. attached to some other foreign networks, it
is usually assigned a temporary global address known as a care-of-
address (CoA). The idea of mobility support is such that the mobile
node can be reached at the home-address even when it is attached to
other foreign networks. This is done in [7,9] with the introduction
of an entity at the home network known as a home agent (HA). Mobile
nodes register their care-of-addresses with the home agents using
messages known as Binding Updates. The home agent is responsible to
intercept messages that are addressed to the mobile node's home-
address, and forward the packet to the mobile node's care-of-address
using IP-in-IP Tunneling [11,12].
Extending the concept of mobility support for individual hosts to
mobility support for a network of nodes, the objective of a network
in motion solution is to provide a mechanism where nodes in a mobile
network can be reached by their permanent addresses, no matter where
on the Internet the mobile network is attached to. There exist a few
prior attempts to provide network mobility support, most of them
based on using bi-directional tunnels between the mobile routers and
the home agents of the mobile routers [13,14,15,16,17].
In bi-directional tunnels between mobile routers and home agents, the
mobile router controlling a mobile network performs routing of
packets to and from the mobile network when it is in its home domain.
When the mobile router and its mobile network move to a foreign
domain, the mobile router registers its care-of-address with its home
agent. An IP-in-IP tunnel is then set up between the mobile router
and the home agent. Every packet going to the mobile network will be
intercepted by the home agent and forwarded to the mobile router
through the IP-in-IP tunnel. The mobile router then forwards the
packet to a host in its mobile network. When a node in its mobile
network wishes to send a packet out of the network, the mobile router
intercepts the packet and forward the packet to the home agent
Ng & Tanaka Expires - August 2003 [Page 3]
Internet-Draft Multi-homing Issues in NEMO February 2003
through the IP-in-IP tunnel. The home agent then sends the packet
out to the intended recipient.
However, the simple approach of bi-directional tunnel does not cater
well to other powerful features of IPv4 and IPv6, such as multi-
homing. A network in motion can be multi-homed if there exist a
plurality of egress interfaces that offer independent routes to the
global Internet. If all of these interfaces belong to the same
mobile router, then only the mobile router is multi-homed. The
mobile network nodes behind the mobile router see only one egress
router, thus they are not multi-homed. On the other hand, if these
interfaces belong to separate routers, then the mobile network nodes
will see different egress routers and can attach to more than one of
these egress routers simultaneously. These mobile network nodes are
thus multi-homed themselves.
Mobile networks typically have wireless connection to the global
network. Though wireless technology has improved tremendously over
the recent years, it is still more prone to channel instability and
noise when compared to wired networks. One of the advantages of
multi-homing is that mobile network nodes can use an alternative path
to reach and be reached by the global Internet when one of its uplink
is down. This is extremely useful for wireless-based mobile nodes,
as it provides a back up mechanism to the unstable wireless uplink.
However, with bi-directional tunneling mechanism employed by mobile
routers, nodes only chose one mobile router as their default router.
When this mobile router loses its connection to the global Internet,
it can no longer maintain a tunnel with its home agent. Thus all
nodes that made use of the mobile router will lose their connectivity
to the global network as well, even though there may exits another
mobile router on the same network that has an active link to the
global Internet.
Mobile network nodes may eventually realize that their default router
no longer has a route to the global network, and select an alternate
mobile router as their default router. Such a scheme relies on the
mobile network nodes to perform their own route discovery. It adds
processing load to mobile network nodes, which may have very limited
processing powers (e.g. embedded devices), and incurs additional
delays (for the mobile network nodes to realize their current default
route is down). In addition, different mobile routers will advertise
different subnet prefixes, and thus when mobile nodes eventually
switch their default routers, they will have to use different care-
of-addresses. This requires sending of binding updates to their
home-agents, further increasing the lag of recovery.
Ng & Tanaka Expires - August 2003 [Page 4]
Internet-Draft Multi-homing Issues in NEMO February 2003
1.1. Terms Used
It is assumed that readers are familiar with the NEMO terminology
described in [18]. In addition, the following definitions of terms
are used in this memo:
Alternate Mobile Router
This term is used when discussing the behaviour of a mobile
router. It refers to another mobile router that is connected
to the same mobile network and has an independent route to the
global Internet.
Alternate Egress Interface
This term is used when discussing the behaviour of a mobile
router with multiple egress interfaces. It refers to another
egress interface that is connected to the global Internet.
Failed Egress Interface
This term refers to the egress interface of a mobile router
that has lost its connection to the global Internet.
1.2. Organization
In the remaining portions of this memo, we will first describe the
motivations and scenarios for deploying multi-homed mobile networks
in Section 2. The issues in using bi-directional tunneling in a
multi-homed mobile network will also be described. In Section 3, we
explore into possible solutions to the problems listed in Section 2,
and investigate methods of optimizing bi-directional tunneling to
employ features of multi-homing.
Ng & Tanaka Expires - August 2003 [Page 5]
Internet-Draft Multi-homing Issues in NEMO February 2003
2. Multi-Homing in NEMO
2.1. Deployment Scenarios of Multi-homed NEMO
2.1.1. Single Mobile Router with Multiple Egress Interfaces Bound to a
Single Home Agent
First type of multi-homed mobile network contains only one mobile
router. This mobile router have a plurality of egress interfaces,
all of which bounds to the same home agent. In such cases, the
mobile router usually only advertise a single network prefix to the
mobile network. This is illustrated in Figure 2.1 below.
+-------------------------+
| | Binding Cache |
| | HoA CoA |
| | 1::1 2::1 |
| Home | 1::2 3::1 |
| Agent |=================|
| | Routing Table |
| | Dest Next-Hop |
| | 1:1::/96 1::1 |
+-------------------------+
|
|
+-------------------------------------+
| |
| Internet |
| |
+-------------------------------------+
| |
Interface 1 | | Interface 2
CoA=2::1 | | CoA=3::1
HoA=1::1 | | HoA=1::2
| |
+--------------------+
| Mobile Router |
+--------------------+
| prefix=1:1::/96
----------------?----------------
|
+----------------+
| Mobile Network | address=1:1::x
| Node x |
+----------------+
Figure 2.1 - Single MR with Multiple Egress Interfaces to a Single
Home Agent.
Ng & Tanaka Expires - August 2003 [Page 6]
Internet-Draft Multi-homing Issues in NEMO February 2003
One example of this type of deployment scenario is that a single
Internet Service Provider (ISP) offers two different wireless public
access methods such as IEEE 802.11 and GPRS. A mobile router with
both access interfaces (i.e. 802.11 and GPRS capabilities) may
subscribe to the same ISP and is allowed to use both access methods.
The ISP will choose to provide a single home agent for the same
mobile router for ease of management.
2.1.2. Single Mobile Router with Multiple Egress Interfaces Bound to
Different Home Agents
The second type of multi-homed mobile network involves a single
mobile router with more than one egress interfaces. Each of these
egress interfaces is bound to different home agents. This is
illustrated in Figure 2.2 below. The mobile router can advertise a
single network prefix and inject the appropriate routing update to
the home agents (not shown in the figure). In this case, the mobile
router uses only one interface for bi-directional tunneling.
Alternatively, the mobile router could also advertise two different
network prefixes (as shown in the figure). Both egress interfaces
are then utilized, and the mobile router maintains two active bi-
directional tunnels with both home agents.
Example of this kind of deployment scenarios is when a mobile router
subscribes to different ISPs. For instance, it may subscribe to
802.11 public access services using one ISP, and subscribe to GPRS
services from another ISP. In this case, the two different ISPs will
provide two different home agents for the same mobile router.
Ng & Tanaka Expires - August 2003 [Page 7]
Internet-Draft Multi-homing Issues in NEMO February 2003
+-------------------------+ +-------------------------+
| Binding Cache | | | | Binding Cache |
| HoA CoA | | | | HoA CoA |
| 1::1 3::1 | Home | | Home | 2::1 4::1 |
|=================| Agent | | Agent |=================|
| Routing Table | 1 | | 2 | Routing Table |
| Dest Next-Hop | | | | Dest Next-Hop |
| 1:1::/96 1::1 | | | | 2:1::/96 2::1 |
+-------------------------+ +-------------------------+
| |
| |
+-------------------------------------+
| |
| Internet |
| |
+-------------------------------------+
| |
Interface 1 | | Interface 2
CoA=3::1 | | CoA=4::1
HoA=1::1 | | HoA=2::1
| |
+--------------------+
| Mobile Router |
+--------------------+
| prefix=1:1::/96, 2:1::/96
----------------?----------------
|
+----------------+
| Mobile Network | address=1:1::x
| Node x | or 2:1::x
+----------------+
Figure 2.2 - Single MR with Multiple Egress Interfaces to Different
Home Agents.
2.1.3. Multiple Mobile Routers
The third type of multi-homed mobile network involves multiple mobile
routers on the same mobile network. Each of these mobile routers
advertise an egress route to the global Internet. In such cases, two
different network prefixes are advertised to the mobile network
nodes. This is illustrated in Figure 2.3 below.
Example of this kind of deployment scenarios is when a mobile network
contains more than one device with independent routes to the global
Internet. An excellent illustration is the Wireless Personal Area
Network (W-PAN) where a mobile phone on the W-PAN connects to the
Ng & Tanaka Expires - August 2003 [Page 8]
Internet-Draft Multi-homing Issues in NEMO February 2003
Internet via GPRS services, and a Personal Digital Assistant (PDA) on
the same W-PAN connects to the Internet via 802.11 public access.
+-------------------------+ +-------------------------+
| Binding Cache | | | | Binding Cache |
| HoA CoA | | | | HoA CoA |
| 1::1 3::1 | Home | | Home | 2::1 4::1 |
|=================| Agent | | Agent |=================|
| Routing Table | 1 | | 2 | Routing Table |
| Dest Next-Hop | | | | Dest Next-Hop |
| 1:1::/96 1::1 | | | | 2:1::/96 2::1 |
+-------------------------+ +-------------------------+
| |
| |
+-------------------------------------+
| |
| Internet |
| |
+-------------------------------------+
| |
CoA=3::1 | | CoA=4::1
HoA=1::1 | | HoA=2::1
| |
+----------+ +----------+
| Mobile | | Mobile |
| Router 1 | | Router 2 |
+----------+ +----------+
prefix=1:1::/96 | | prefix=2:1::/96
-------?--------?--------?-------
|
+----------------+
| Mobile Network | address=1:1::x
| Node x | or 2:1::x
+----------------+
Figure 2.3 - Multiple MRs on the Same Mobile Network.
2.2. Issues of Multi-Homing in NEMO
When a mobile network is multi-homed, mobile network nodes can choose
to use different routes to send packets to the global Internet,
either by way of using different global addresses, or by forwarding
the packets to different routers.
However, with bi-directional tunneling mechanism employed by mobile
routers, mobile network nodes only chose one mobile router as their
default router. When this mobile router loses its connection to the
global Internet, it can no longer maintain a tunnel with its home
Ng & Tanaka Expires - August 2003 [Page 9]
Internet-Draft Multi-homing Issues in NEMO February 2003
agent. Thus all mobile network nodes that made use of the mobile
router will lose their connectivity to the global network as well.
This is hardly desirable, since there may exits another mobile router
on the same network that has an active link to the global Internet.
Mobile network nodes may eventually realize that their default router
no longer has a route to the global network, and select an alternate
mobile router as their default router. Such a scheme relies on the
mobile network nodes to perform their own route discovery. It adds
processing load to mobile network nodes, which may have very limited
processing powers (e.g. embedded devices), and incurs additional
delays (for the mobile network nodes to realize their current default
route is down). In addition, different mobile routers will advertise
different subnet prefixes, and thus when mobile nodes eventually
switch their default routers, they will have to use different care-
of-addresses. This requires sending of binding updates to their
home-agents, further increasing the lag of recovery.
Ng & Tanaka Expires - August 2003 [Page 10]
Internet-Draft Multi-homing Issues in NEMO February 2003
3. Using Multi-Homing Features in Bi-Directional Tunnels
In order to utilize the additional robustness provided by multi-
homing, mobile routers that employ bi-directional tunneling with
their home agents should dynamically change their tunnel exit points
depending on the link status. For instance, if a mobile router
detects that one of its egress interface is down, it should detect if
any other alternate route to the global Internet exists. This
alternate route may be provided by any other mobile routers connected
to one of its ingress interfaces that has an independent route to the
global Internet, or by another active egress interface the mobile
router it self possess. If such an alternate route exists, the
mobile router should re-establish the bi-directional tunnel using
this alternate route.
In the remaining part of this section, we will attempt to investigate
methods of performing such re-establishment of bi-directional
tunnels. It is not the objective of this memo to specify a new
protocol specifically tailored to provide this form of re-
establishments. Instead, we will limit ourselves to currently
available mechanisms specified in Mobile IPv6 and Neighbour Discovery
in IPv6 [19].
3.1. Detecting Presence of Alternate Routes
To actively utilize the robustness provided by multi-homing, a mobile
router must first be capable of detecting alternate routes. This can
be manually configured into the mobile router by the administrators
if the configuration of the mobile network is relatively static. It
is however highly desirable for mobile routers to be able to discover
alternate routes automatically for greater flexibility.
The case where a mobile router possesses multiple egress interface
(bound to the same home agent or otherwise) should be trivial, since
the mobile router should be able to "realize" it has multiple routes
to the global Internet.
In the case where multiple mobile routers are on the mobile network,
each mobile router has to detect the presence of other mobile router.
A mobile router can do so by listening for Router Advertisement
message on its *ingress* interfaces. When a mobile router receives a
Router Advertisement message with a non-zero Router Lifetime field
from one of its ingress interfaces, it knows that another mobile
router which can provide an alternate route to the global Internet is
present in the mobile network.
Ng & Tanaka Expires - August 2003 [Page 11]
Internet-Draft Multi-homing Issues in NEMO February 2003
3.2. Re-Establishment of Bi-Directional Tunnels
When a mobile router detects that the link be which its current bi-
directional tunnel with its home agent is using is down, it needs to
re-establish the bi-directional tunnel using an alternate route
detected. We consider two separate cases here: firstly, the
alternate route is provided by another egress interface that belongs
to the mobile router; secondly, the alternate route is provided by
another mobile router connected to the mobile network. We refer to
the former case as an alternate route provided by an alternate egress
interface, and the latter case as an alternate route provided by an
alternate mobile router.
3.2.1. Using Alternate Egress Interface
When an egress interface of a mobile router loses the connection to
the global Internet, the mobile router can make use of its alternate
egress interface should it possess multiple egress interfaces. The
most direct way to do so is for the mobile router to send a binding
update to the home agent of the failed interface using the care-of-
address assigned to the alternate interface in order to re-establish
the bi-directional tunneling using the care-of-address on the
alternate egress interface. After a successful binding update, the
mobile router encapsulates outgoing packets through the bi-
directional tunnel using the alternate egress interface.
The idea is to use the global address (most likely a care-of-address)
assigned to an alternate egress interface as the new (back-up) care-
of-address of the mobile router to re-establish the bi-directional
tunneling with its home agent.
3.2.2. Using Alternate Mobile Router
When the mobile router loses a connection to the global Internet, the
mobile router can utilize a route provided by an alternate mobile
router (if one exists) to re-establish the bi-directional tunnel with
its home agent. First, the mobile router has to obtain a care-of-
address from the alternate mobile router (i.e. attaches itself to the
alternate mobile router). Next, it sends binding update to its home
agent using the care-of-address obtained from the alternate mobile
router From then on, the mobile router can encapsulates outgoing
packets through the bi-directional tunnel using via the alternate
mobile router.
The idea is to obtain a care-of-address from the alternate mobile
router and use this as the new (back-up) care-of-address of the
mobile router to re-establish the bi-directional tunneling with its
home agent.
Ng & Tanaka Expires - August 2003 [Page 12]
Internet-Draft Multi-homing Issues in NEMO February 2003
Note that every packet sent from/to mobile network nodes to/from
their correspondent nodes will experience two levels of encapsulation.
First level of tunneling is done between a mobile router which the
mobile network node uses as its default router and the mobile
router's home agent. The second level of tunneling is done between
the alternate mobile router and its home agent.
3.3. To Avoid Tunneling Loop
The method of re-establishing the bi-directional tunnel as described
in Section 3.2 may lead to infinite loops of tunneling. This happens
when two mobile routers on a mobile network lose connection to the
global Internet at the same time and each mobile router tries to re-
establish bi-directional tunnel using the other mobile router. We
refer to this phenomenon as tunneling loop.
One approach to avoid tunneling loop is for a mobile router that has
lost connection to the global Internet to insert an option into the
Router Advertisement message it broadcasts periodically. This option
serves to notify other mobile routers on the link that the sender no
longer provides global connection. Note that setting a zero Router
Lifetime field will not work well since it will cause mobile network
nodes that are attached to the mobile router to stop using the mobile
router as an access router too (in which case, things are back to
square one).
3.4. Other Considerations
When a mobile network is multi-homed, mobile network nodes may
receive Router Advertisements that advertise different network
prefixes. This is usually the case when the multi-homed mobile
network has two or more mobile routers advertising different routes
to the global Internet. It may also occur when the mobile network
has only one mobile router with multiple egress interfaces bound to
different home agents. In these situations, mobile network nodes
typically only select one to form its global (possibly care-of)
address.
In view of this, it may be desirable for mobile network node to be
able to acquire "preference" information on each mobile network
prefix from the mobile routers. This allows default address
selection mechanism such as that specified in [20] to be used.
Further exploration on setting such "preference" information in
Router Advertisement based on performance of the bi-directional
tunnel might prove to be useful.
Ng & Tanaka Expires - August 2003 [Page 13]
Internet-Draft Multi-homing Issues in NEMO February 2003
4. Security Considerations
Currently the following security threat is identified with multi-
homing in NEMO:
- A malicious node in a mobile network advertises an Router
Advertisement message with a non-zero Router Lifetime field,
tricking mobile network nodes and even mobile routers to forward
all packets through it.
This is not specific to the multi-homing approach described in this
document. However, an authentication mechanism that can authenticate
a mobile router from mobile network node when it attaches may be able
to prevent such attacks.
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Soliman, H., and Pettersson, M., "Mobile Networks (MONET)
Problem Statement and Scope", Internet Draft, draft-soliman-
monet-statement-00.txt, Work In Progress, Feb 2002.
[4] Ernst, T. et. al., "Network Mobility Support Requirements",
Internet Draft, draft-ietf-nemo-requirements-00.txt, Work In
Progress, Feb 2003.
[5] Lach, H. et. al., "Mobile Networks Scenarios, Scope and
Requirements", Internet Draft, draft-lach-monet-requirements-
00.txt, Work In Progress, Feb 2002.
[6] Kniventon, T. J., and Yegin, A. E., "Problem Scope and
Requirements for Mobile Networks Working Group", Internet
Draft, draft-kniventon-monet-requiremetns-00.txt, Work In
Progress, Feb 2002.
[7] Perkins, C. E. et. al., "IP Mobility Support", IETF RCF 2002,
Oct 1996.
[8] DARPA, "Internet Protocol", IETF RFC 791, Sep 1981.
Ng & Tanaka Expires - August 2003 [Page 14]
Internet-Draft Multi-homing Issues in NEMO February 2003
[9] Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility
Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-
19.txt, Work In Progress, Oct 2002.
[10] Deering, S., and Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", IETF RFC 2460, Dec 1998.
[11] Simpson, W., "IP in IP Tunneling", IETF RFC 1853, Oct 1995.
[12] Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6",
IETF RFC 2473, Dec 1998.
[13] Kniveton, T. et. al., "Mobile Router Tunneling Protocol",
Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress,
Nov 2002.
[14] Petrescu, A., et. al., "Issues in Designing Mobile IPv6 Network
Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet-
Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress, Oct
2002.
[15] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and
Its Application to Mobile Networks", Internet Draft: draft-
thubert-nemo-reverse-routing-header-01.txt, Work In Progress,
Oct 2002.
[16] Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and
Olivereau, A., "Mobile Networks Support in Mobile IPv6 (Prefix
Scope Binding Updates)", Internet Draft: draft-ernst-mobileip-
v6-network-03.txt, Work In Progress, Mar 2002.
[17] Ng, C. W., and Takeshi, T., "Securing Nested Tunnels
Optimization with Access Router Option", Internet Draft: draft-
ng-nemo-access-router-option-00.txt, Work In Progress, Oct
2002.
[18] Ernst, T., and Lach, H., "Network Mobility Support
Terminology", Internet Draft, draft-ernst-nemo-terminology-
00.txt, Work In Progress, Oct 2002.
[19] Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery
for IPv6", IETF RFC 2461, Dec 1998.
[20] Draves, R., "Default Address Selection for IPv6", draft-ietf-
ipv6-default-addr-select-09.txt, Work in progress.
Ng & Tanaka Expires - August 2003 [Page 15]
Internet-Draft Multi-homing Issues in NEMO February 2003
Author's Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 6554 5420
Email: cwng@psl.com.sg
Takeshi Tanaka
R&D center
Panasonic Mobile Communications Co., Ltd.
5-3, Hikarinooka, Yokoshuka-shi, Kanagawa
239-0847, Japan
Phone: +81-46-840-5494
Email: Takeshi.Tanaka@yrp.mci.mei.co.jp
Ng & Tanaka Expires - August 2003 [Page 16] | PAFTECH AB 2003-2026 | 2026-04-22 22:34:11 |