Internet Draft
                                                     Jaehoon Paul Jeong
                                                          Kyeongjin Lee
                                                           Jungsoo Park
                                                          Hyoungjun Kim
draft-jeong-nemo-ro-ndproxy-02.txt                                 ETRI
Expires: August 2004                                   14 February 2004


              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 and DNS optimizations.  The route
   optimization is possible because mobile router relays the prefix of
   its care-of address to its mobile nodes by playing the role of 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
   resolutions without additional overhead of finding DNS server.




Jeong, et al.            Expires - August 2004                [Page 1]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


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......................................................4
   4. Neighbor Discovery extension..................................5
      4.1 RO Prefix Information option format.......................5
      4.2 Neighbor Solicitation (NS) message format.................6
      4.3 DNS Server option format..................................7
   5. Mobile Router.................................................8
      5.1 Process of RO Prefix Information option...................8
      5.2 Process of DNS Server option..............................9
      5.3 Delivery of Data Packets..................................9
      5.4 Movement of Mobile Router.................................9
   6. Mobile Node..................................................10
      6.1 Procedure of Route Optimization..........................10
          6.1.1 Generation of a new CoA............................10
          6.1.2 DAD for the new CoA................................10
          6.1.3 Return Routability and Binding Update..............11
      6.2 Procedure of DNS 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]-[8].  Especially,
   four important terms are defined as follows [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.


Jeong, et al.            Expires - August 2004                [Page 2]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004



     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 NEMO enables mobile network node (MNN) [7] and
   correspondent node (CN) to communicate through the bi-directional
   tunnel.  Data exchange between MNN and CN is performed not via
   optimal routing path, but via the 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 longer because of dog-legged routing and also packet
   size becomes bigger due to extra IPv6 header attached to packet per
   level of nesting [10].

   When we think over the 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 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 describes a
   way of optimizing the routes between MNs and CNs, independently of
   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.


Jeong, et al.            Expires - August 2004                [Page 3]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004



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 MR's performing ND-Proxy, which
   makes a CoA with the prefix advertised by access router and relays
   the prefix of access network into the whole mobile 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 MR performs neighbor discovery
   for the sake of the MNs within its mobile network.  Like this,
   through MR that performs ND-Proxy, access network and 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.  Two
   MRs, MR1 and MR2, receive the prefix information of access network
   (AR1_P) that was sent by an access router, AR1 as proxy-mode and
   relay it to their subnet link as router-mode [6].  Let's assume that
   the MNs, MN1 and MN2, move into the mobile network managed by MR1
   like Figure 1.   Also, let's assume that these visiting mobile nodes
   (VMN) communicate with the correspondent nodes, CN1 and CN2,


Jeong, et al.            Expires - August 2004                [Page 4]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


   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
   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 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, 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 a new O (Route-optimization)
   flag within prefix information option for route optimization [4].
   When this flag is set on, it indicates that the prefix included in
   the option can be used by MNs within a mobile network for 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                             +


Jeong, et al.            Expires - August 2004                [Page 5]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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 MNs within a mobile network.

   The RO Prefix Information option provides 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 [6].  A (Autonomous address-configuration) flag
   MUST be 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 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 [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 ...
    +-+-+-+-+-+-+-+-+-+-+-+-


Jeong, et al.            Expires - August 2004                [Page 6]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004



    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,
                   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, an RA
   message includes as many DNS Server options as DNS servers.  Figure 4
   shows the format of DNS Server option [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       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           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)



Jeong, et al.            Expires - August 2004                [Page 7]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


      Length          8-bit unsigned integer.  The length of the
                      option (including the type and length fields)
                      in units of 8 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 zero
                      means unspecified.  The field can be used for
                      load balancing of DNS queries with multiple
                      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.  MNs should contact the
                      source of this information, 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.

5. Mobile Router

   MR MUST process Prefix Information option for Route Optimization and
   DNS Server option for DNS Optimization, which 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 an MR's Home Address (HoA), the MR MUST perform the
   role of ND-Proxy and relay the prefix information.  Before MR
   advertises the prefix information through Router Advertisement (RA)
   message, it MUST set O flag indicating that this prefix can be used
   for route optimization of MNs, which are either local mobile nodes
   (LMN) or VMNs within the mobile network.

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


Jeong, et al.            Expires - August 2004                [Page 8]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004



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

5.2 Process of DNS Server option

   If 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 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 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 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 MN can be delivered to the access
   network to which the mobile network containing the MN is attached,
   via optimal path between the mobile and correspondent nodes.

   When the access router of the access network receives the data
   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 MN.  The
   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 MNs within its mobile network
   while forwarding their data packets along with neighbor discovery
   related to each destination node.

   When the access router knows the link-layer address of next-hop
   toward the destination MN, it forwards the IPv6 data packets to the
   MR corresponding to the link-layer address.  The packets are relayed
   to next-hop toward the destination node by MR until the packets
   arrive at the destination.  Like this, in the case where the mobile
   network where the destination node is placed is multi-level, the
   packets 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



Jeong, et al.            Expires - August 2004                [Page 9]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


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

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

6.1 Procedure of Route Optimization

   For 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 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 MN performs DAD for the new CoA through the extended NS message.
   The NS message of DAD for the new address is disseminated by MRs,
   acting as ND-Proxy, in the entire mobile network where the MN is
   placed [6].  Each MR memorizes the DAD for returning NA message to
   the originator or relayer of the extended NS message for a while.

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

   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



Jeong, et al.            Expires - August 2004               [Page 10]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


   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 MN performs the return routability
   and binding update procedure of MIPv6 [9].  If the MN is VMN for the
   mobile network where it is present, or as LMN, moves into another
   link of the mobile network to which its home link belongs, it SHOULD
   perform binding updates with both its HA and CNs.

6.2 Procedure of DNS Optimization

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

7. Security Considerations

   The route optimization and DNS optimization in this document does not
   add any other security problems to the NEMO, MIPv6, or ND protocol.
   Security issues regarding the ND protocol are being discussed in IETF
   SEND (Securing Neighbor Discovery) working group [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.

   Copyright (C) The Internet Society July 12, 2001. All Rights
   Reserved.

   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


Jeong, et al.            Expires - August 2004               [Page 11]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004


   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.

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

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

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

   [8] Jaehoon Paul Jeong et al., "IPv6 DNS Discovery based on Router
       Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01.txt,
       February 2004.

10. Informative References

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

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


Jeong, et al.            Expires - August 2004               [Page 12]


Internet-Draft  ND-Proxy based Route & DNS Optimizations  February 2004



   [11] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", 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 for ND-Proxy.

12. Authors' Addresses

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

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

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

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

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

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

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

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




Jeong, et al.            Expires - August 2004               [Page 13]