wdiff draft-jeong-nemo-ro-ndproxy-01.txt draft-jeong-nemo-ro-ndproxy-02.txt

Individual Submission
Internet Draft
Jaehoon Paul Jeong
Kyeong-Jin
Kyeongjin Lee
Jung-Soo
Jungsoo Park
Hyoung-Jun
Hyoungjun Kim
<draft-jeong-nemo-ro-ndproxy-01.txt>
draft-jeong-nemo-ro-ndproxy-02.txt ETRI
Expires: April August 2004 14 February 2004 2 October 2003

ND-Proxy based Route and DNS Optimizations for
Mobile Nodes in Mobile Network

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted [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 specifies a mechanism for enabling mobile nodes in IPv6
mobile network to perform route optimization. and DNS optimizations. The route
optimization is possible because mobile router relays the prefix of
its Care-of care-of address to its mobile nodes by playing the role of ND-proxy. ND-
proxy. Through binding updates associated with the network prefix of
an access network, the mobile nodes can perform route optimization.
In addition, this document explains how mobile nodes can optimize its
DNS name resolution through RA-based DNS discovery. By announcing
the address of local recursive DNS server, mobile router allows
mobile nodes using the DNS server to optimize their DNS name resolution.
resolutions without additional overhead of finding DNS server.

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].

Table of Contents

1. Terminology...................................................2
2. Introduction..................................................3
3. Overview......................................................3 Overview......................................................4
4. Neighbor Discovery extension..................................4 extension..................................5
4.1 RO Prefix Information option format.......................4 format.......................5
4.2 Neighbor Solicitation (NS) message format.................5 format.................6
4.3 DNS Server option format..................................6 format..................................7
5. Mobile Router.................................................8
5.1 Process of RO Prefix Information option...................8
5.2 Process of DNS Server option..............................8 option..............................9
5.3 Delivery of Data Packets..................................8 Packets..................................9
5.4 Movement of Mobile Router.................................9
6. Mobile Node...................................................9 Node..................................................10
6.1 Procedure of Route Optimization...........................9 Optimization..........................10
6.1.1 Generation of a new CoA.............................9 CoA............................10
6.1.2 DAD for the new CoA.................................9 CoA................................10
6.1.3 Return Routability and Binding Update..............10 Update..............11
6.2 Procedure of DNS Optimization............................10
6.2.1 RDNSS Configuration................................10
6.2.2 RDNSS Selection....................................10 Optimization............................11
7. Security Considerations......................................11
8. Copyright....................................................11
9. Normative References.........................................12
10. Informative References......................................12
11. Acknowledgements............................................13
12. Authors' Addresses..........................................13

1. Terminology

This document uses the terminology described in [3]-[7]. Especially [3]-[8]. Especially,
four important terms are defined as follows [5][7]: [6][8]:

Multilink Subnet (MS)

A collection of independent links, connected by routers, but
sharing a common subnet prefix.

ND-Proxy

A router proxying and relaying for all nodes on its router-mode
interfaces except proxy-mode interfaces among its network
interfaces.

Multilink-Subnet Router (MSR)

A router which has interfaces attached to different links in a
MS, and which plays the role of ND-Proxy.

Recursive DNS Server (RDNSS)

A Recursive DNS Server is a name server that offers the
recursive service of DNS name resolution.

2. Introduction

Recently, the demand and necessity of network mobility (NEMO) [3] is
increasing along with those of host mobility based on Mobile IPv6
(MIPv6) [9]. The purpose of network mobility is to guarantee the
continuity of the sessions of fixed nodes or mobile nodes (MN) within
mobile networks, such as car, bus, subway train, airplane and
submarine. The current solution is based on bi-directional tunnel
between home agent (HA) and mobile router (MR) [3]. The basic
support protocol of mobile network (NEMO) NEMO enables mobile network
nodes node (MNN) [7] and
correspondent nodes node (CN) to communicate through the bi-directional
tunnels. The deeper multi-level network this NEMO gets,
tunnel. Data exchange between MNN and CN is performed not via
optimal routing path, but via the longer non-optimal path including bi-
directional tunnel. MR's HA intercepts all of packets destined to
the MNNs and tunnels them to the MR. Also, the MNNs' outbound
packets are tunneled in order to pass ingress filtering [3][9]. This
mechanism is very simple but it gives up a powerful feature of MIPv6,
route optimization (RO) without ingress filtering. In addition, when
the mobile network has multiple nested MRs, packet delay between MNN
and CN becomes by longer because of dog-legged routing. This document specifies how routing and also packet
size becomes bigger due to optimize extra IPv6 header attached to packet per
level of nesting [10].

When we think over the routes between mobile nodes applicability of NEMO in our daily life, we
can forecast that network mobility service will be provided in
vehicles, such as bus, subway train and correspondent nodes.
Also, this airplane, because most
passengers in such vehicles will have hand-held PC or PDA as MN
rather than fixed node in near future. Therefore, it is necessary to
provide route optimization for such MNs. This document provides describes a
way to optimize DNS name resolution of
mobile nodes, through optimizing the autoconfiguration routes between MNs and CNs, independently of recursive DNS server.
the level of nesting and without the extra IPv6 header. The route
optimization mechanism is based on the proxying function of MR, which
informs MNs within mobile network of the access network prefix to
make a care-of address (CoA) passing ingress filtering, and also
relays packets between access router and MN. This proxying for RO is
performed through IPv6 Neighbor Discovery (ND), which is called ND-
Proxy.

3. Overview

+---+ ******************* +---+
|CN1+---* Internet *---+CN2|
+---+ ******************* +---+
|
|
+-+-+
|AR1|
RA(AR1_P)| +-+-+
V |
----------+---------------+---------------+----------- Link1
|Proxy-mode |Proxy-mode
+-+-+ +------+ +-+-+ +------+
|MR1+--+RDNSS1| |MR2+--+RDNSS2|
RA(AR1_P)| +-+-+ +------+ RA(AR1_P)| +-+-+ +------+
V |Router-mode V |Router-mode
---+-----+-----+--- Link2 ---+------+-----+--- Link3
| | | Proxy-mode|
+-+-+ +-+-+ +-+-+ +-+-+
|MN1| |MN2| |MN3| |MR3|
+---+ +---+ +---+ +-+-+ | RA(AR1_P)
Router-mode| V
---+-----+-----+--- Link4
| |
+-+-+ +-+-+
|MN4| |MN5|
+---+ +---+

Figure 1. Multilink Subnet for Route Optimization

The route optimization is possible by mobile router's MR's performing ND-
Proxy, ND-Proxy, which
makes a Care-of Address (CoA) CoA with the prefix advertised by access router and delivers relays
the prefix of access network into the
NEMO. Each whole mobile node network. Each MN
can make its new CoA with router advertisement message including
access network prefix and perform the return routability and binding
update procedure. As ND-Proxy, the
mobile router MR performs neighbor discovery instead
for the sake of the mobile nodes MNs within its NEMO. mobile network. Like this,
through mobile router MR that performs ND-
Proxy, ND-Proxy, access network and NEMO mobile network
are configured into a multilink subnet. Figure 1 shows an example of
a multilink subnet comprised of four links from Link1 to Link4. Three mobile routers from Two
MRs, MR1 to MR3
relay and MR2, receive the prefix information of access network
(AR1_P) that was sent by an access router, AR1. AR1 as proxy-mode and
relay it to their subnet link as router-mode [6]. Let's assume that
the mobile nodes MNs, MN1 and
MN2 MN2, move into the mobile network managed by mobile router MR1
like Figure 1. Also, let's assume that these visiting mobile nodes
(VMN) communicate with the correspondent nodes, CN1 and CN2,
respectively. If these visiting mobiles can get the prefix of access
network and make their new CoA, through the binding update with their
correspondent node, they can communicate each other via an optimized
path. This dissemination of access network's prefix is performed by
mobile router
MR which becomes attached to a foreign access network, not its home
network. Likewise, MN3 can optimize the route through MR2. MN4 and
MN5 can perform route optimization through MR2 and MR3, too.

The optimization of DNS name resolution is possible by mobile
router's MR's
announcing the address of local recursive DNS server as well as the
prefix information of access network. In Figure 1, by DNS Server
option included in RA message, MR1 announces the address of Recursive
DNS Server, RDNSS1, within its mobile network to its router-mode link,
Link2. Therefore, mobile nodes MNs within Link2, MN1 and MN2, can optimize their
DNS name resolution by using local DNS server, RDNSS1.

4. Neighbor Discovery extension

In order to support the route optimization, ND implementation in MR
and MN must be extended to process the prefix information option for
RO and that in Local Fixed Node (LFN) within mobile network, which
has no mechanism for MIPv6, need no change.

4.1 RO Prefix Information option format

The mechanism of this document needs the addition of a new O (Route-optimization)
flag within prefix information option for route optimization [3]. [4].
When this flag is set, set on, it indicates that the prefix included in
the option can be used by mobile nodes MNs within a NEMO mobile network for the route
optimization. Figure 2 shows the format of the modified prefix
information option, RO Prefix Information option, which is included
in RA message.

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 | Prefix Length |L|A|O|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. Prefix Information Option Format for Route Optimization

Field:

O 1-bit route-optimization flag. When set indicates
that this prefix can be used for the route
optimization of mobile nodes MNs within NEMO. a mobile network.

The RO Prefix Information option provides a mobile node an MN with the network
prefix of access network and allows it to autoconfigure its new CoA
through stateless address autoconfiguration and to perform binding
update. The Prefix Information option appears in RA message and MUST
be silently ignored for other messages. L (On-link) flag MAY be
either 0 or 1. Namely, this route optimization can be either on-link
or off-link model [5]. [6]. A (Autonomous address-configuration) flag
MUST be 1, set on, indicating IPv6 stateless address autoconfiguration.

4.2 Neighbor Solicitation (NS) message format

NS message MUST be extended for Duplicate Address Detection (DAD) for
the address based on RO prefix of access network. to be performed in the whole mobile
network, not just within a link. Therefore, there is a need to
discriminate between the normal NS message and extended NS message
for route optimization [3]. [4]. Figure 3 shows the format of the
modified NS message.

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3. Extended Neighbor Solicitation Message Format

Fields:

M 1-bit multi-hop flag. When set indicates
that this NS message SHOULD be relayed to the other
links of a multilink subnet.

Target IPv6 Address
The IPv6 address of the target of the solicitation
that will be used as solicitation,
e.g., CoA. It MUST NOT be a multicast address.

4.3 DNS Server option format

DNS Server option contains the IPv6 address of the recursive DNS
server. When advertising more than one DNS Server option are advertised, option, an RA
message includes as many DNS Server options as DNS servers are included in an RA message. servers. Figure 4
shows the format of DNS Server option [7]. [8].

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 | Pref | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address of DNS Server +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4. DNS Server Option Format

Fields:

Type 8-bit identifier of the option type (TBD: IANA)

Option Name Type

DNS Server (TBD)

Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The value 0 is invalid.
Mobile nodes MUST silently discard a Neighbor
Discovery (ND) packet that contains an option
with length zero. octets SHOULD be 0x03 (3 x 8 = 24
octets).

Pref The preference of a DNS server. A 4-bit unsigned
integer. A decimal value of 15 indicates the
highest preference. A decimal value of 0
indicates that the DNS server can not be used. zero
means unspecified. The field can be used for selecting an RDNSS
among
load balancing of DNS queries with multiple RDNSSes.

Valid
RDNSSes according to local policy.

Lifetime 32-bit unsigned integer. The maximum time, in
seconds, over which this DNS server is used for
name resolution. Mobile nodes MNs should contact the
source of this information, mobile router, MR, before
expiry of this time interval. A value of all one
bits (0xffffffff) represents infinity. A value
of zero means that the DNS server must not be
used any more.

IPv6 Address of DNS Server
Recursive DNS Server's address for DNS name
resolution.

"Pref"=0 SHOULD require a "Valid Lifetime"=0 because the
corresponding DNS server SHOULD not be used any more.

5. Mobile Router

Mobile router

MR MUST process Prefix Information option for Route Optimization (RO) and
DNS Server option for DNS Optimization, which
are may be included in RA
message.

5.1 Process of RO Prefix Information option

Only if the prefix announced by an access router is different from
the prefix of a mobile router's an MR's Home Address (HoA), the mobile router MR MUST perform the
role of ND-Proxy and relay the prefix information. Before mobile router MR
advertises the prefix information through Router Advertisement (RA)
message, it MUST set route-optimization O flag indicating that this prefix can be used
for route optimization of
mobile nodes, MNs, which are either local mobile nodes
(LMN) or visiting mobile
nodes VMNs within the mobile network.

If a mobile node an MN within a mobile network receives the new prefix information
option through RA message and can recognize this option, it MAY
prefer this new RO prefix information option to the normal prefix information
option that contains the mobile network prefix assigned by the mobile router's MR's
home network. By performing binding update with the prefix of the
access network, the mobile node MN can optimize the routes between its
correspondent nodes and itself.

ND-Proxy MUST join the solicited-node multicast address(es) addresses that
correspond to the IP address(es) IPv6 addresses assigned to the mobile node MNs for which it is
proxying [3]. for processing ND messages related to the MNs [4].

5.2 Process of DNS Server option

If mobile router MR has its own local RDNSS like MR1 and MR2 in Figure 1, it SHOULD
announce the address of RDNSS to its router-mode link(s).

If mobile router MR receives DNS Server option from its proxy-mode link(s), it
SHOULD relay the option to its router-mode link(s) through its RA
message. In the case that mobile router where MR has its own local RDNSS, it announces
the DNS Server option of its RDNSS with higher precedence than those
of other RDNSSes.

5.3 Delivery of Data Packets

After a mobile node an MN gets a new CoA within a mobile network and performs
binding update associated with the address, the data packets of
correspondent node toward the mobile node are MN can be delivered to the access
network to which the NEMO mobile network containing the mobile node MN is attached,
via optimal path between the mobile and correspondent nodes.

When the access router of the access network receives the data
packets,
packets toward an MN and there is no neighbor information for the MN,
it multicasts normal Neighbor Solicitation (NS) message to the
solicited-node multicast address of the destination IPv6 address in
order to find out the link-layer address of the destination mobile
node. MN. The mobile router,
MR, knowing the link-layer address of the target, responds to the NS
message by returning its own link-layer address in a unicast Neighbor
Advertisement (NA) message as ND-Proxy, which knows the IPv6
addresses and link-layer addresses of mobile
nodes MNs within its mobile network during the DAD of each CoA of
while forwarding their data packets along with neighbor discovery
related to each
mobile destination node.

When the access router knows the link-layer address to of next-hop
toward the
destination, destination MN, it forwards the IPv6 data packets to the mobile router
MR corresponding to the link-layer address. The mobile router relays
the packets are relayed
to next-hop toward the destination mobile node. In node by MR until the packets
arrive at the destination. Like this, in the case that where the NEMO mobile
network where the destination node is placed is multi-level, the
packets are may be relayed to the destination node by more than one MR
according to the route information in each MR's destination and
neighbor caches.

5.4 Movement of Mobile Router
When an MR moves into another access network and detects its movement
by movement detection algorithm [9], it performs binding update with
its HA with a new CoA based on the new access network prefix, and
then relays the prefix for RO into its other router-mode interfaces.
This allows the MRs and nodes to perform route optimization based on
the new access network prefix. When the MR returns to its home
network, it deregisters with its HA and advertises RA message that
contains RO Prefix Information option for the previous access network
prefix with Valid Lifetime and Preferred Lifetime set to zeroes and O
flag set on, and also Prefix Information option for MR's mobile router.
network prefix. The RO Prefix Information option SHOULD be
advertised at least three times. This RA message allows the MRs and
MNs below the MR explicitly to release their current CoA and to use
the MR's mobile network prefix in order to configure their addresses
according to MIPv6 protocol [9].

6. Mobile Node

Mobile node

MN MUST process Prefix Information option for Route
Optimization (RO) RO and DNS Server
option for DNS Optimization, which are included in RA message.

6.1 Procedure of Route Optimization

For route optimization, mobile node RO, MN generates a new CoA based on the access network prefix and
performs binding update for the CoA.

6.1.1 Generation of a new CoA

Whenever a mobile node an MN receives RA message containing RO prefix information
option that includes a new network prefix of access network, it makes
a new CoA.

6.1.2 DAD for the new CoA

The mobile node MN performs DAD for the new CoA through the extended NS message.
The NS message of DAD for the new address is relayed to the
other links disseminated by a mobile router, MRs,
acting as ND-Proxy, on in the link entire mobile network where the mobile node MN is
placed [5]. The mobile router [6]. Each MR memorizes the DAD for returning NA message to
the sender originator or relayer of the extended NS message. message for a while.

If there is no NA returned and the after DAD is successful, timeout, the mobile node MN configures the verified
address as its new CoA in its network interface.

Notice that

Therefore, the DAD for the link-local addresses and global addresses
based on mobile network prefix assigned by home network is performed
through normal NS message only within a link and the DAD for the
global addresses based on access network prefix is performed through
extended NS message within a multilink subnet, which is relayed by
ND-Proxies.

6.1.3 Return Routability and Binding Update

After configuring the new CoA, the mobile node MN performs the return routability
and binding update procedure of Mobile IPv6 [8]. MIPv6 [9]. If the
mobile node MN is visiting mobile node (VMN) VMN for the
mobile network where it is present, or as local mobile node (LMN), LMN, moves into another
link of the mobile network to which its home link belongs to,
it SHOULD perform binding updates with both its home agent and
correspondent nodes. In case that as LMN, the mobile node is present
at home link and receives RO prefix information option, namely when
the mobile node's HoA and CoA belong to the same link, belongs, it SHOULD
perform not deregistration with its home agent which is its mobile
router simultaneously, but binding updates with both its home agent HA and correspondent nodes. CNs.

6.2 Procedure of DNS Optimization

The optimization of DNS name resolution is possible by mobile
router's MR's
announcing the address of local recursive DNS server as well
as RDNSS along with RO prefix
information through RA message [7]. like in Section 5.2 [8]. The DNS
server can exist either within mobile network or within access
network. The address of recursive DNS server RDNSS is delivered to mobile nodes MNs through DNS Server
option, one of RA options. Especially, visiting mobile
nodes will VMNs can optimize their DNS
name resolution resolutions effectively by using
local recursive DNS server.

6.2.1 RDNSS Configuration

The addresses of DNS servers are announced by DNS Server options in
RA message. These addresses can be used for recursive DNS service
providing DNS name resolution. If mobile node receives DNS Server
option, it SHOULD store RDNSS's address in the configuration file for
its DNS resolver; i.e., /etc/resolv.conf in UNIX.

6.2.2 RDNSS Selection

When mobile node perceives multiple RDNSSes through RA message, it
stores the RDNSS addresses in order into the configuration file which
its DNS resolver uses for DNS name resolution on the basis of the
value of "Pref" field in the DNS Server option. The following
algorithm is simply based on the rule of selecting an RDNSS in the
order from the most preferred RDNSS, provided that its preference
value is not zero. The processing of the DNS Server option received
in RA message by a mobile node is as follows:

For each DNS Server option:

Step (a) : Receive and parse all DNS Server options.

Step (b) : Arrange the addresses of RDNSSes in a descending order, in
the respect of preference value, namely starting with the
biggest value of "Pref" field of the DNS Server option and
store them in the configuration file used by resolver for
DNS name Resolution (DNS configuration).

Step (c) : For each DNS Server option, check the following: If the
Value of "Pref" or "Valid Lifetime" field is set to zero,
exclude the corresponding RDNSS entry from the list of
RDNSSes of DNS configuration in order to let the RDNSS not
used any more.

Whenever the DNS resolver on the mobile node performs the name
resolution, it refers to the address of RDNSS in order from the first
RDNSS stored in its DNS configuration. Like this, in case that there
are several mobile routers advertising RDNSS in a multilink subnet,
"Pref" field is used to select local RDNSS.

7. Security Considerations

The route optimization and DNS optimization in this document does not
add any other security problems to the NEMO, Mobile IPv6, MIPv6, or Neighbor
Discovery (ND) protocols. ND protocol.
Security issues regarding the ND protocol are being discussed in IETF
SEND (Securing Neighbor Discovery) working group [9]. [11].

8. Copyright

The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by 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
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

9. Normative 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] Vijay Devarapalli et al., "Nemo Basic Support Protocol", draft-
ietf-nemo-basic-support-02.txt, December 2003.

[4] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
IP version 6", RFC 2461, December 1998.

[4]

[5] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[5]

[6] Dave Thaler and Chistian Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, June 2002.

[6] Thierry Ernst,

[7] T. Ernst and H.-Y. Lach, "Network Mobility Support Terminology", draft-
ietf-nemo-terminology-00.txt,
draft-ietf-nemo-terminology-00.txt, May 2003.

[7]

[8] Jaehoon Jeong, Soohong D. Park, Luc Beloeil and Syam Madanapalli, Paul Jeong et al., "IPv6 DNS Discovery based on Router
Advertisement", draft-jeong-
dnsop-ipv6-dns-discovery-00.txt, July 2003. draft-jeong-dnsop-ipv6-dns-discovery-01.txt,
February 2004.

10. Informative References

[8]

[9] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-22.txt, May
draft-ietf-mobileip-ipv6-24.txt, June 2003.

[9] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill

[10] Pascal Thubert and Marco Molteni, "IPv6 Reverse Routing Header
and P. Nikander, its application to Mobile Networks", draft-thubert-nemo-
reverse-routing-header-03.txt, October 2003.

[11] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01.txt,
June 2003. draft-ietf-
send-ndopt-03.txt, January 2004.

11. Acknowledgements

The authors would like to acknowledge the previous contribution of
Dave Thaler and Christian Huitema. Huitema for ND-Proxy.

12. Authors' Addresses

Jaehoon Paul Jeong
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea

Phone: +82 42 860 1664
EMail: paul@etri.re.kr

Kyeong-Jin

Kyeongjin Lee
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea

Phone: +82 42 860 6484
EMail: leekj@etri.re.kr

Jung-Soo

Jungsoo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea

Phone: +82 42 860 6514
EMail: pjs@etri.re.kr

Hyoung-Jun

Hyoungjun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea

Phone: +82 42 860 6576
EMail: khj@etri.re.kr