[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                              Fumio Teraoka
INTERNET DRAFT                                    Keio University/Sony CSL
                                                         Masahiro Ishiyama
                                                                   Toshiba
                                                         Mitsunobu Kunishi
                                                           Keio University
                                                              24 June 2003


           LIN6: A Solution to Mobility and Multi-Homing in IPv6

                     <draft-teraoka-ipng-lin6-02.txt>



Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC 2026.

   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

   LIN6 is a protocol supporting mobility and multi-homing in IPv6.  LIN6
   introduces the node id, not the interface id, for each node.  Each node
   can be identified by its node id no matter where the node is connected
   and no matter how many interfaces the node has.  In the IPv6 layer,
   64-bit node id called LIN6 ID is used while 128-bit node-id called LIN6
   generalized ID is used above the Transport layer.  TCP connections and
   security associations can be preserved even if the node moves to another
   subnet or the node changes the using interface in a multi-homing
   environment without modifying TCP or IPsec.  In comparison with Mobile
   IPv6, LIN6 has several advantages in terms of header overhead and fault
   tolerance.





Teraoka                   Expires 23 December 2003                 [Page 1]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


1.  Introduction

   This document describes the protocol specification of
   LIN6[IEICE01,WPMC01].  We propose LINA (Location Independent Network
   Architecture) to solve several problems such as mobility and multi-
   homing by redesigning network architecture and addressing.  LIN6 is an
   application of LINA to IPv6[RFC2460].  LIN6 supports mobility and multi-
   homing with IPsec[RFC2401] in IPv6.

   From mobility support viewpoint, LIN6 has several advantages in
   comparison with Mobile IPv6[MIPv6] as follows:

   o LIN6 has no header overhead because it does not use any extension
     headers of IPv6 while Mobile IPv6 uses the Destination Options Header
     for the Home Address Option and the Routing Header for optimal
     routing.

   o LIN6 is more fault tolerant than Mobile IPv6. In Mobile IPv6, the
     Home Agent cannot be replicated to the subnet other than the home link
     of the mobile node.  LIN6 introduces the Mapping Agent which can be
     replicated anywhere in the Internet.

   o LIN6 keeps end-to-end communication model, that is, LIN6 does not use
     any packet intercepter/forwarder such as the Home Agent of Mobile
     IPv6.  There is no tunneling in LIN6.

   LIN6 also has several advantages from viewpoint of multi-homing support.
   Assume that Node-A starts TCP communication with Node-B, a multi-homing
   node with two network interfaces, by using IPsec.

   o Node-A can recognize the identity of Node-B by the LIN6 address of
     Node-B no matter which network interface of Node-B is used.

   o The same security association (SA) can be used between Node-A and
     Node-B no matter which network interface of Node-B is used.

   o The TCP connection and the SA are still available even after the used
     network interface of Node-B is switched to another during
     communication.


2.  Terminology

   This document uses the following terms.

      node:
         The node is the general term to specify the equipment that
         understands IP in the Internet.  The node includes hosts, mobile
         terminals, routers, and so on.

      LIN6 ID:



Teraoka                   Expires 23 December 2003                 [Page 2]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


         The LIN6 ID is assigned to the node and uniquely identifies the
         node in the Internet.  It is 64 bits in length.

      LIN6 prefix:
         The LIN6 prefix is a predefined constant value attached to the
         head of the LIN6 ID to construct the LIN6 generalized ID.


      LIN6 generalized ID:
         The LIN6 generalized ID is the identifier of the node used in the
         transport layer and the upper layers.  It is 128 bits in length.
         The higher 64 bits of the LIN6 generalized ID is the LIN6 prefix
         and the lower 64 bits is the LIN6 ID.  The LIN6 generalized ID is
         assigned to the node, not to the network interface.  Application
         programs use the LIN6 generalized ID to indicate the target node.
         TCP establishes the TCP connection between two LIN6 generalized
         IDs.  Note that the LIN6 generalized ID does not appear in the
         IPv6 header on the link.

      network prefix:
         The network prefix indicates the subnet to which the node is
         connected.  It is attached to the head of the LIN6 ID to construct
         the LIN6 address.

      LIN6 address:
         The LIN6 address is assigned to the network interface of the node.
         The higher 64 bits of the LIN6 address is the network prefix and
         the lower 64 bits is the LIN6 ID so that the LIN6 address
         specifies the identifier of the node as well as the point of
         attachment to the Internet of the node.  Note that the LIN6
         address appears in the IPv6 header on the link and is not passed
         to the transport layer.

      stationary address:
         The stationary address is a LIN6 address assigned to a stationary
         node that understands LIN6.  In the lower half of the stationary
         address, the Universal/Local bit of EUI-64 is set to zero while
         that bit in the LIN6 address is set to one.

      mapping:
         The mapping is the relation between the LIN6 ID and the network
         prefix.

      Mapping Agent:
         The Mapping Agent (MA) is the function that maintains the mapping
         of the mobile node.  Each mobile node is associated with one or
         more Mapping Agents.  The relation between the LIN6 ID of the
         mobile node and the address of the Mapping Agent is registered
         with the DNS.

      Mapping Cache:



Teraoka                   Expires 23 December 2003                 [Page 3]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


         The Mapping Cache is the cache for mapping in the node.

      normal IPv6 address:
         The aggregatable global unicast address.


3.  Protocol Overview

3.1.  Address

   LIN6 uses two types of network addresses: the LIN6 generalized ID and
   the LIN6 address.  Figure 1 depicts their formats.  The LIN6 generalized
   ID is 128 bits in length and is used in the transport layer and the
   upper layers.  LIN6 generalized ID is the identifier of the node in the
   transport layer and the upper layers and does not change even if the
   node moves.  The LIN6 address is also 128 bits in length and is used in
   the network layer.  The LIN6 address specifies both the location and the
   identifier of the node.  The network prefix part of the LIN6 address
   changes when the node moves to anther subnet.  The formats of the LIN6
   generalized ID and the LIN6 address are the same as the format of IPv6
   aggregatable global unicast address[RFC2374].


                   <-------- 64 bits --------> <-------- 64 bits ------->
      LIN6        +---------------------------+--------------------------+
      generalized |   LIN6 prefix (constant)  |          LIN6-ID         |
      ID          +---------------------------+--------------------------+

                  +---------------------------+--------------------------+
     LIN6 address |      network prefix       |          LIN6-ID         |
                  +---------------------------+--------------------------+

   aggregatable   +--+------+---+------+------+--------------------------+
   global unicast |FP|TLA ID|res|NLA ID|SLA ID|     Interface ID         |
   address        +--+------+---+------+------+--------------------------+

            Figure 1: The LIN6 generalized ID and the LIN6 address


   Both the LIN6 generalized ID and the LIN6 address consist of two fields:
   the network prefix and the LIN6 ID.  Both fields are 64 bits in length.
   The LIN6 ID is the global unique identifier of the node.  EUI-64[EUI64]
   will be used as LIN6-ID.  The network prefix of the LIN6 address
   indicates the subnet to which the node is connected while that of the
   LIN6 generalized ID is the constant value and is called the LIN6 prefix.
   In other words, the LIN6 address indicates both the location and the
   identifier of the node while the LIN6 generalized only identifies the
   node.  Thus, the LIN6 generalized ID is used in the transport layer and
   the upper layers to identify the node, and the LIN6 address is used in
   the network layer to indicate both the location and the identifier of
   the node.  Note that the LIN6 ID and the LIN6 generalized ID are



Teraoka                   Expires 23 December 2003                 [Page 4]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


   assigned per node while the LIN6 address is assigned per network
   interface.  Also note that the normal IPv6 address, i.e., the
   aggregatable global unicast address, is assigned to the network
   interface of the node in addition to the LIN6 address.


3.2.  Address Processing

   Figure 2 shows the procedures of address processing.  As mentioned
   above, the LIN6 generalized ID consists of the (constant) LIN6 prefix
   and the LIN6 ID.  In packet transmission, the transport layer specifies
   the LIN6 generalized ID of the destination node to the network layer.
   The network layer obtains the network prefix, i.e., the current
   location, of the destination node by some means (see Section 3.3).  The
   network layer concatenates the obtained network prefix and the LIN6 ID
   contained in the LIN6 generalized ID to create the LIN6 address of the
   destination node.

   In packet reception, the source address field of the packet contains the
   LIN6 address of the source node.  The network layer concatenates the
   LIN6 prefix and the LIN6 ID contained in the LIN6 address of the source
   node to create the LIN6 generalized ID, and then the network layer
   notifies the transport layer of the packet reception with the LIN6
   generalized ID of the source node.  Thus, from the transport layer's
   viewpoint, communication is done between the two LIN6 generalized IDs.





























Teraoka                   Expires 23 December 2003                 [Page 5]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


            <Transmission>                      <Reception>
    +--------------+--------------+   +--------------+--------------+
    | LIN6 prefix  |   LIN6 ID    |   | LIN6 prefix  |   LIN6 ID    |
    +--------------+--------------+   +--------------+--------------+
   transport       |      LIN6 generalized ID        ^
   layer           |                                 |
   ----------------|---------------------------------|----------------
   network layer   |                                 |
                   v                                 |
    +--------------+--------------+   +--------------+--------------+
    | LIN6 prefix  |   LIN6 ID    |   | LIN6 prefix  |   LIN6 ID    |
    +--------------+--------------+   +--------------+--------------+
                            |                        ^
           +------------+   |                        |
           |  mapping   |   |                +------>+<------+
           v            |   v                |               |
   +--------------+ +--------------+ +--------------+ +--------------+
   |network prefix| |    LIN6 ID   | | LIN6 prefix  | |   LIN6 ID    |
   +--------------+ +--------------+ +--------------+ +--------------+
           |                |                                ^
           +------>+<-------+                                |
                   |                                         |
                   v                                         |
    +--------------+--------------+    +--------------+--------------+
    |network prefix|   LIN6 ID    |    |network prefix|   LIN6 ID    |
    +--------------+--------------+    +--------------+--------------+
                   |           LIN6 address           ^
                   |                                  |
   ----------------|----------------------------------|----------------
   data link       v                                  |
   layer

                         Figure 2: Address processing


3.3.  Distinction between the LIN6 Address and the Normal IPv6 Address

   As shown on the right side of Figure 2, the receiving node must
   distinguish the LIN6 address from the normal IPv6 address to decide
   whether address conversion must be done.  From address format viewpoint,
   however, the LIN6 address is indistinguishable from the normal IPv6
   address.  (i.e., LIN6 is fully compatible with IPv6.)  There are some
   methods to distinguish the two address types.  As a temporary solution,
   LIN6 employs a special value as a part of the LIN6 ID.  To distinguish
   the LIN6 address, Sony CSL obtained the OUI value 0x00-01-4A of
   EUI-64[EUI64].  According to the IPv6 addressing scheme, the
   Universal/Local bit of EUI-64 must be reversed in the global IPv6
   address.  Thus, if the upper 24 bits of the lower 64 bits of the IPv6
   address is 0x02-01-4A, the IPv6 address is the LIN6 address.





Teraoka                   Expires 23 December 2003                 [Page 6]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


3.4.  Stationary Address

   As mentioned above, LIN6 introduces the 64-bit LIN6 ID as the node
   identifier.  The identity of a mobile node is guaranteed by the LIN6 ID
   even if the network prefix of the node changes.  In case of a stationary
   node the entire 128-bit can be used as the node identifier because the
   network prefix does not usually change.  Thus, LIN6 introduces another
   type of LIN6 address, the stationary address which is assigned to a
   stationary node.

   The upper half of the stationary address is the normal network prefix.
   To distinguish the stationary address, the first three bytes of the
   lower half of the stationary address must be a special value such as the
   OUI value of Sony CSL in which the Universal/Local bit is set to zero.
   The remaining five bytes of the lower half of the stationary address can
   be generated randomly by the stationary node.  Upon generating a
   stationary address, the Duplicate Address Detection procedure must be
   done.

   By introducing the stationary address, it is not required to assign the
   LIN6 ID to stationary nodes.  The LIN6 ID must be assigned only to
   mobile nodes.  This reduces administrative workload for LIN6 ID
   assignment.

   Upon transmission, if the destination address is a stationary address,
   this address is set to the destination address field of the IPv6 header
   without the address processing described in Section 3.2.  Upon
   reception, if the source address is a stationary address, this address
   is passed to the upper layer without the address processing.


3.5.  Mapping Agent

   The relation between the LIN6 ID and the network prefix is called
   mapping.  LIN6 introduces the Mapping Agent (MA) to maintain the mapping
   of the mobile node.  The Mapping Agent maintains the mapping of the
   mobile node and replies to queries about mapping.  Each mobile node is
   associated with one or more Mapping Agents.  When the network prefix of
   the mobile node changes, i.e., when the mobile node moves, the mobile
   node registers the new network prefix with one of the Mapping Agents
   that maintain the mapping of the mobile node.  Consistency among the
   databases on the Mapping Agents must be kept by some procedures.  These
   procedures are beyond of the scope of this document.

   It can be assumed that the relation between the mobile node and its
   Mapping Agent is almost static in contrast to the mapping of the mobile
   node.  LIN6 makes use of the Domain Name System (DNS) to maintain the
   relation between the mobile node and its Mapping Agents.  A new DNS
   record MA is introduced to register the address of the Mapping Agent of
   the mobile node with the DNS database.




Teraoka                   Expires 23 December 2003                 [Page 7]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


3.6.  Communication Procedure

   The LIN6 Communication procedure is shown in Figure 3.  Assume that
   Node-A tries to send a packet to Node-B.  For simplicity, Node-A and
   Node-B are associated with only a single Mapping Agent, respectively
   (MA-A and MA-B).  The communication procedure is as follows:

   1. At first, Node-A and Node-B register their network prefixes with MA-
      A and MA-B, respectively.  The Authentication Header of IPv6 is used
      in registration.

   2. The Node-A obtains the address (AAAA record) of Node-B from the name
      server by indicating the domain name of Node-B.  The obtained address
      is the LIN6 generalized ID of Node-B.

   3. Node-A obtains the address of MA-B from the name server by indicating
      the LIN6 generalized ID of Node-B.

   4. Node-A obtains the network prefix of Node-B from MA-B by indicating
      the LIN6 ID of Node-B.

   5. Node-A sends a packet to Node-B.

   6. To avoid impersonation, Node-B must obtain the network prefix of
      Node-A from MA-A.  Node-B obtains the address of MA-A from the name
      server by indicating
      the LIN6 generalized ID of Node-A.

   7. Node-B obtains the network prefix of Node-A from MA-A by indicating
      the LIN6 ID of Node-A.

   8. Node-B sends a packet to Node-A.


   NS: Name Server    +------+         1
   MA: Mapping Agent  | MA-B | <---------------+
                      +------+                 |
                          ^                    |
                         4|                    |
                          V         5          |
   +----+    2, 3     +------+ ----------> +------+      6      +----+
   | NS | <---------> |Node-A|             |Node-B| <---------> | NS |
   +----+             +------+ <---------- +------+             +----+
                          |         8          ^
                          |                   7|
                          |                    V
                          |        1       +------+
                          +--------------->| MA-A |
                                           +------+

                      Figure 3: Communication procedures



Teraoka                   Expires 23 December 2003                 [Page 8]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


3.7.  IPsec Operation

   In the sending node, IPsec is processed as follows.  When the packet is
   passed from the transport layer, the source and destination address
   fields in the IPv6 header contain LIN6 generalized IDs.  The security
   association is decided by using the destination LIN6 generalized ID, and
   then IPsec calculation is executed.  After that, the source and
   destination LIN6 generalized IDs are converted to LIN6 addresses.

   In the receiving node, IPsec is processed as follows.  Upon packet
   reception, the source and destination address fields of IPv6 header
   contain LIN6 addresses.  First, these LIN6 addresses are converted to
   LIN6 generalized IDs.  The security association is decided by using the
   destination LIN6 generalized ID, and then IPsec calculation is executed.


3.8.  Mobility Support

3.8.1.  Mobility Support Type 1: Basic Procedure

   Mobility support in LIN6 is shown in Figure 4.  Assume that SAs are
   established between the mobile node (MN) and the correspondent node
   (CN), and between the MN and the MA.  This mechanism relies on the SA to
   avoid impersonation.

   1. The MN registers its current network prefix with the Mapping Agent
      (MA).  The Authentication Header is used in this registration.

   2. The CN obtains the LIN6 address and MA's address from the name
      server.

   3. The CN obtains MN's network prefix from the MA.

   4. The CN sends a packet to the MN.  The source address of this packet
      is the normal IPv6 address because the CN is stationary in this case.

   5. The MN returns a packet to the CN.  The source address of the
      received packet is used as the destination address of the return
      packet because the source address of the received packet is the
      normal IPv6 address.

   6. The MN moves to another subnet.

   7. The MN registers the new network prefix with the MA and the CN.  The
      Authentication Header is used in these registrations.

   8. The CN sends a packet to the MN.







Teraoka                   Expires 23 December 2003                 [Page 9]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


                         +----+     4     +----+   6
             +----+  2   |    | --------> | MN | -----+
             | NS |<---->|    | <-------- |    |      |
             +----+      | CN |     5     +----+      V
                         |    |        7    |       +----+
                         |    | <-----------|------ | MN |
                         |    | ------------|-----> |    |
                         +----+        8    |       +----+
                           ^                |         |
                          3|                |         |
                           V                |         |
                         +----+      1      |         |
                         | MA | <-----------+   7     |
                         |    | <---------------------+
                         +----+

                          Figure 4: Mobility Support


3.8.2.  Mobility Support Type 2: Mapping Refresh Message

   Figure 5 shows mobility support in which there is no SA between the MN
   and the CN.  In terms of avoiding impersonation, this mechanism is as
   secure as the current internet where every node trusts the DNS.  This
   mechanism relies on the DNS and the MA.  Steps 1 to 6 are the same as
   Figure 4.

   7. The MN registers the new network prefix with the MA.  The
      Authentication Header is used in this registration.

   8. The MN sends the Mapping Refresh Message to CN to notify the CN of
      the event that the MN has moved.

   9. The CN obtains the new network prefix of the MN from the MA.

   10. The CN sends a packet to the MN.


















Teraoka                   Expires 23 December 2003                [Page 10]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


                         +----+     4     +----+   6
             +----+  2   |    | --------> | MN | -----+
             | NS |<---->|    | <-------- |    |      |
             +----+      | CN |     5     +----+      V
                         |    |        8    |       +----+
                         |    | <-----------|------ | MN |
                         |    | ------------|-----> |    |
                         +----+       10    |       +----+
                          ^  ^              |         |
                         3|  |9             |         |
                          V  V              |         |
                         +----+      1      |         |
                         | MA | <-----------+   7     |
                         |    | <---------------------+
                         +----+

             Figure 5: Mobility Support (no SA between MN and CN)


3.8.3.  Mobility Support Type 3: Cookie

   Figure 6 shows mobility handling mechanism that uses a cookie for
   authentication.  This mechanism is effective in the environment in which
   there is no possibility of eavesdropping.  For example, messages are
   encrypted on wireless links and wired links are well managed to avoid
   eavesdropping.  Steps 1 and 2 are the same as Figure 4.

   3. The CN receives MN's network prefix from the MA.  At the same time,
      the CN notifies the MA of CN's cookie.

   4. The MA notifies the MN of CN's cookie.  This notification uses IPsec
      Authentication Header.

   5. The CN sends a packet to the MN.

   6. The MN returns a packet to the CN.

   7. The MN moves to another subnet.

   8. The MN registers the new network prefix with the CN.  This
      registration includes CN's cookie received from the MA.  The CN can
      trust this registration if the cookie sent to the MA and the cookie
      received from the MN are the same.

   9. The MN registers the new network prefix with the MA.  The
      Authentication Header is used in this registration.

   10. The CN sends a packet to the MN.






Teraoka                   Expires 23 December 2003                [Page 11]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


                         +----+     5     +----+   7
             +----+  2   |    | --------> | MN | -----+
             | NS |<---->|    | <-------- |    |      |
             +----+      | CN |     6     +----+      V
                         |    |        8   | ^      +----+
                         |    | <----------|-|----- | MN |
                         |    | -----------|-|----> |    |
                         +----+        10  | |      +----+
                           ^               | |        |
                          3|               | |4       |
                           V               | |        |
                         +----+      1     | |        |
                         | MA | <----------+ |        |
                         |    | -------------+     9  |
                         |    | <---------------------+
                         +----+

            Figure 6: Mobility Support (simplified authentication)




3.9.  Multi-Homing Support

   Figure 7 shows multi-homing support in LIN6.  In the figure, Node-B is a
   multi-homing host which has two network interfaces.  Node-A and Node-B
   have the LIN6 generalized ID, "LIN6_P+ID_A" and "LIN6_P+ID_B",
   respectively, where "LIN6_P" is the LIN6 Prefix, and "ID_A" and "ID_B"
   are the identifiers of Node-A and Node-B, respectively.  Node-A has the
   LIN6 address, "P_A+ID_A", where "P_A" is the network prefix of Node-A.
   Node-B has two LIN6 addresses, "P_B1+ID_B" and "P_B2+ID_B", where "P_B1"
   and "P_B2" are the network prefixes of Node-B corresponding to the two
   network interfaces.

   1. Node-A establishes a TCP connection with Node-B by using IPsec.  This
      TCP connection is established between {LIN6_P+ID_A, port_A} and
      {LIN6_P+ID_B, port_B}.  The SA of IPsec is established between
      "LIN6_P+ID_A" and "LIN6_P+ID_B".  Assume that Node-A obtains "P_B1"
      and "P_B2" as the network prefixes of Node-B and selects "P_B1".  The
      packet in the TCP connection has "P_A+ID_A" and "P_B1+ID_B" as the
      source/destination addresses.  The packets in the TCP connection
      traverse Path_A in the figure.

   2. Assume that Path_A crashes due to some reason, and ICMP Unreach is
      returned to Node-A.

   3. Node-A knows that Path_A is unavailable and selects "P_B2" as the
      network prefix of Node-B.  The packet in the TCP connection has
      "P_A+ID_A" and "P_B2+ID_B" as the source/destination addresses.  The
      packets in the TCP connection traverse Path_B in the figure.
      Although the LIN6 address of Node-B changes, the TCP connection and



Teraoka                   Expires 23 December 2003                [Page 12]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


      the SA are still available even after the path change because the TCP
      connection is established between {LIN6_P+ID_A, port_A} and
      {LIN6_P+ID_B}, and the SA is established between "LIN6_P+ID_A" and
      "LIN6_P+ID_B".


                           1. (old) TCP connection
                      +-----------------------------+
                      |                             |
                      | +-------X 2. ICMP Unreach   |
                  <---+ |                           |
                        |  +=====================+  |
                  <---- +  |  Path_A       "P_B1"|  V
         +------+          |                   +------+
         |Node-A|==========+                   |Node-B| "ID_B"
         +------+ "P_A"    |                   +------+
          "ID_A"           |  Path_B       "P_B2"|  ^
                  <-----+  +=====================+  |
                        |                           |
                        +---------------------------+
                           3. (new) TCP connection

                        Figure 7: Multi-Homing Support


4.  Packet Formats

4.1.  Data Packet

   LIN6 uses the normal IPv6 header in which the LIN6 addresses are used in
   the source address field and the destination address field.  Figure 8
   shows the format of the normal IPv6 header.






















Teraoka                   Expires 23 December 2003                [Page 13]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |version| Traffic Class |               Flow Label              |
   +-------+---------------+-------+---------------+---------------+
   |        Payload Length         |  Next Header  |   Hop Limit   |
   +-------------------------------+---------------+---------------+
   |                                                               |
   +                                                               +
   |                        Source Address                         |
   +                        (LIN6 Address)                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   +                                                               +
   |                      Destination Address                      |
   +                        (LIN6 Address)                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +---------------------------------------------------------------+

                     Figure 8: IPv6 (LIN6) header format


4.2.  Mapping Update and Reply Messages

   When a mobile node moves to another subnet, i.e., when the network
   prefix of the mobile node changes, the mobile node sends the Mapping
   Update Message to the Mapping Agent and the correspondent nodes.  Upon
   receiving the Mapping Update Message, the Mapping Agent or the
   correspondent node returns the Mapping Reply Message to the mobile node.
   The Mapping Update and Reply Messages are UDP packets.  The
   Authentication Header of IPv6 must be included in the Mapping Update
   Message to avoid illegal mapping update.  Figure 9 shows the formats of
   the Mapping Update and Reply Messages.


















Teraoka                   Expires 23 December 2003                [Page 14]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


                                  0        0        1               3
                                  0        8        6               1
                             +-->+--------+--------+-----------------+
                             |   |  Type  |  code  |      Flags      |
                             |   +--------+--------+-----------------+
                             |   |          Sequence Number          |
                             |   +-----------------------------------+
                             |   |                                   |
                             |   +          Network Prefix           +
                             |   |                                   |
   +----------------------+  |   +-----------------------------------+
   |   IPv6 Base Header   |  |   |                                   |
   +----------------------+  |   +              LIN6 ID              +
   |Authentication Header |  |   |                                   |
   +----------------------+  |   +-----------------------------------+
   |      UDP Header      |  |   |             Timestamp             |
   +----------------------+--+   +-----------------------------------+
   |Mapping Update Request|      |             Lifetime              |
   +----------------------+----->+-----------------------------------+
    (a) Mapping Update
        Request Message


   +----------------------+
   |   IPv6 Base Header   |
   +----------------------+       0        0        1               3
   |Authentication Header |       0        8        6               1
   +----------------------+  +-->+--------+--------+-----------------+
   |       UDP Header     |  |   |  Type  |  Code  |      Flags      |
   +----------------------+--+   +--------+--------+-----------------+
   | Mapping Update Reply |      |          Sequence Number          |
   +----------------------+----->+-----------------------------------+
    (b) Mapping Update
        Reply Message

                Figure 9 Mapping Update Request/Reply formats


      Source Address: the LIN6 address of the source node.

      Destination Address: the LIN6 address of the destination node.

      Source Port: TBD.

      Destination Port: TBD.

      Type:
         0x01: update request
         0x02: update reply

      Code:



Teraoka                   Expires 23 December 2003                [Page 15]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


         0x00: succeeded
         0x01: authentication failed
         0x02: ...

      Flags: TBD

      Sequence Number:
         the source node of the Mapping Update Request Message assigns this
         field a sequence number.  This value is copied to this field of
         the Mapping Update Reply Message.

      LIN6 ID: the LIN6 ID of the source node.

      Network Prefix: the current network prefix of the source node.

      Timestamp: the current time.

      Lifetime: the period of time in which this mapping is valid.



4.3.  MA Query and Reply Messages

   When a node wants to send a packet to a mobile node, the node sends the
   MA Query Message to the Mapping Agent to obtain the current network
   prefix of the mobile node.  When the Mapping Agent receives the MA Query
   Message, it returns the MA Reply Message to the node to notify the
   network prefix of the mobile node.  Figure 10 shows the format of the MA
   Query and Reply Messages.

























Teraoka                   Expires 23 December 2003                [Page 16]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


                            0        0        1               3
                            0        8        6               1
                       +-->+--------+--------+-----------------+
                       |   |  Type  |  Code  |      Flags      |
                       |   +--------+--------+-----------------+
                       |   |          Sequence Number          |
                       |   +-----------------------------------+
                       |   |                                   |
                       |   +           Network Prefix          +
                       |   |                                   |
                       |   +-----------------------------------+
                       |   |                                   |
   +----------------+  |   +               LIN6 ID             +
   |IPv6 Base Header|  |   |                                   |
   +----------------+  |   +-----------------------------------+
   |   UDP Header   |  |   |             Timestamp             |
   +----------------+--+   +-----------------------------------+
   | MA Query/Reply |      |              Lifetime             |
   +----------------+----->+-----------------------------------+

                    Figure10 MA Query/Reply Message format


      Source Address: the LIN6 address of the source node.

      Destination Address: the LIN6 address of the destination node.

      Source Port: TBD.

      Destination Port: TBD.

      Type:
         0x01: query
         0x02: reply

      Code:
         0x00: succeeded
         0x01: no mapping exists
         0x02: ...

      Flags: TBD.

      Sequence Number:
         the source node of the MA Query Message assigns this field a
         sequence number.  This value is copied to this field of the MA
         Reply Message.

      LIN6 ID: the LIN6 ID of the target node.

      Network Prefix: the current network prefix of the target node.




Teraoka                   Expires 23 December 2003                [Page 17]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


      Timestamp: the timestamp of this mapping.

      Lifetime: the period of time in which this mapping is valid.



4.4.  Mapping Refresh Message

   Figure 11 shows the format of the Mapping Refresh Message.  When the
   network prefix of a node changes due to, for example, node movement, if
   there is no security association between the node and the correspondent
   node, the node sends the Mapping Refresh Message to the correspondent
   node.  Upon receiving the Mapping Refresh Message, the receiving node
   sends the MA Query Message to obtain the new network prefix of the node
   sending the Mapping Refresh Message.


                            0        0        1               3
                            0        8        6               1
                       +-->+--------+--------------------------+
                       |   |  Type  |        reserved          |
   +----------------+  |   +--------+--------------------------+
   |IPv6 Base Header|  |   |                                   |
   +----------------+  |   +              LIN6 ID              +
   |   UDP Header   |  |   |                                   |
   +----------------+--+   +-----------------------------------+
   |Mapping Refresh |      |             Timestamp             |
   +----------------+----->+-----------------------------------+

                   Figure11 Mapping Refresh Message format


      Source Address: the LIN6 address of the source node.

      Destination Address: the LIN6 address of the destination node.

      Source Port: TBD.

      Destination Port: TBD.

      Type: TBD

      LIN6 ID: the LIN6 ID of the target node.

      Timestamp: the timestamp of this mapping.









Teraoka                   Expires 23 December 2003                [Page 18]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


5.  Processing on the Mobile Node

5.1.  Bootstrap

   When the mobile node is powered on, it obtains the network prefix of the
   subnet to which it is connected by sending the Router Solicitation
   Message[RFC2461] and receiving the Router Advertisement Message.  Next,
   the mobile node sends a DNS query packet to obtain the address of the
   Mapping Agent that maintains the mapping of the mobile node.  Next, the
   mobile node establishes a security association of IPsec[RFC2401] with
   the Mapping Agent.  Next, the mobile node sends the Mapping Update
   Request Message to the Mapping Agent to register the current network
   prefix and receives the Mapping Update Reply Message.


5.2.  Processing on Movement

   The mobile node detects the change of the point of attachment to the
   Internet by some mechanisms, for example, 1) interrupt by hardware, 2)
   upcall from the link layer, and 3) router advertisement message.  When
   the mobile node detects a location change, first, it sends the Router
   Solicitation Message and receives the Router Advertisement Message to
   obtain the network prefix of the subnet to which the mobile node is
   connected.  Next, the mobile node sends the Mapping Update Request
   Message to the Mapping Agent to notify the current network prefix.  The
   mobile node also sends the Mapping Update Request Message to the
   correspondent nodes with which it has a security association.  The
   Mapping Update Request Message must include the Authentication Header.
   The mobile node sends the Mapping Refresh Message to the correspondent
   nodes with which it has no security association.


6.  Processing on Mapping Agent

   Upon receiving the Mapping Update Request Message from the mobile node,
   first, the Mapping Agent makes it sure that the Authentication Header is
   correct.  If authentication fails, the Mapping Agent returns the Mapping
   Update Reply Message with the error code Authentication Failed.  If
   authentication succeeds, the Mapping Agent updates the mapping of the
   mobile node and returns the Mapping Update Reply Message to the mobile
   node.

   If the mobile node is associated with two or more Mapping Agents,
   consistency among the databases on the Mapping Agents must be kept by
   some procedures.  These procedures are beyond of the scope of this
   document.








Teraoka                   Expires 23 December 2003                [Page 19]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


7.  Packet Transmission and Reception

7.1.  Packet Transmission

   When the network layer receives a packet transmission request from the
   transport layer, the network layer makes sure that the destination
   address passed from the TCP/UDP is a LIN6 generalized ID or a normal
   IPv6 address by checking the upper 64 bits of the destination address.
   If the destination address is a normal IPv6 address, the network layer
   executes the normal IPv6 transmission procedure.  If the destination
   address is a LIN6 generalized ID, the network layer executes the LIN6
   procedure described below.

   The network layer extracts the LIN6 ID from the LIN6 generalized ID and
   searches the Mapping Cache for the network prefix by using the LIN6 ID
   as the key.  If the network prefix is found, the network layer
   concatenates the network prefix and the LIN6 ID to create the LIN6
   address of the destination node.  After that, the network layer executes
   the normal IPv6 transmission procedure.

   If the network prefix of the destination node is not found in the
   Mapping Cache, the node keeps the packet waiting for transmission, and
   then sends the MA Query Message to the Mapping Agent to obtain the
   network prefix.  If the source node does not know the address of the
   Mapping Agent, it obtains the Mapping Agent's address from the name
   server by indicating the LIN6 ID of the destination address.  Upon
   receiving the MA Reply Message, the node creates the LIN6 address of the
   destination node, and then executes the normal IPv6 transmission
   procedure.


7.2.  Packet Reception

   When the network layer receives a packet from the link layer, first the
   network layer makes sure that the source address of the IPv6 header is a
   LIN address or a normal IPv6 address.  Refer to the next subsection
   about how to distinguish between the LIN6 address and the normal IPv6
   address.  If the source address is the normal IPv6 address, the network
   layer executes the normal IPv6 reception procedure.

   If the source address is the LIN6 address, the network layer removes the
   network prefix part of the LIN6 address, and then attaches the LIN6
   prefix to create the LIN6 generalized ID of the source node.  After
   that, the network layer executes the normal IPv6 reception procedure.


7.3.  Mapping Refresh Message Reception

   When a node receives the Mapping Refresh Message, it sends the MA Query
   Message to the Mapping Agent of the node sending the Mapping Refresh
   Message.  If the node does not know the address of the Mapping Agent, it



Teraoka                   Expires 23 December 2003                [Page 20]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


   obtains the Mapping Agent's address from the name server by indicating
   the LIN6 ID of the node sending the Mapping Refresh Message.


8.  Intellectual Property Right

   There are mechanisms included in the following pending patent
   applications that have been FILED to the Japanese Patent office.

   - Japanese application No.2000-005560 Sony

   - Japanese application No.2000-036693 Toshiba

   These include the mapping agent and address processing mechanisms. It
   must be stressed that they have only been filed, and have not been
   granted. They have been filed separately by Sony and Toshiba.

   We really intend to contribute to development of the Internet community
   and to keep a good relationship with IETF. And our primary concern is to
   promote our technology so that others may feel it is useful and
   worthwhile in the spirit of the IETF.

   If indeed the mechanisms are granted as patents, the patents will be
   licensed under reasonable and non-discriminatory conditions to any
   person who wants to implement the mechanisms.


Author's Address

   o Fumio Teraoka
     Keio University
     3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522, Japan.
     Phone: +81-45-566-1425
     and
     Sony Computer Science Laboratories, Inc.
     3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141-0022, Japan.
     Phone: +81-3-5448-4380
     Email: tera@wide.ad.jp

   o Masahiro Ishiyama
     R&D Center, Toshiba.
     1 Komukai Toshiba-Cho, Saiwai-Ku, Kawasaki, Kanagawa 212-8582, Japan.
     Phone: +81-44-549-2238
     Email: masahiro@isl.rdc.toshiba.co.jp

   o Mitsunobu Kunishi
     Keio University
     3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522, Japan.
     Phone: +81-45-566-1425
     Email: kunishi@tokoro-lab.org




Teraoka                   Expires 23 December 2003                [Page 21]


draft-teraoka-ipng-lin6-03.txt                                 24 June 2003


References

[IEICE01] M. Ishiyama, M. Kunishi, K. Uehara, H. Esaki, and F. Teraoka.
          LINA: A New Approach to Mobility Support in Wide Area Networks,
          IEICE Transactions on Communication, Vol. E84-B no. 8, Aug. 2001.

[WPMC01]  M. Ishiyama, M. Kunishi, K. Uehara, and F. Teraoka.  An Analysis
          of Mobility Handling in LIN6.  In Proc. of 4th International Sym-
          posium on Wireless Personal Multimedia Communications, Sep. 2001.

[RFC2460] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
          Specification.  RFC 2460, Dec. 1998.

[MIPv6]   C. Perkins. Mobility Support in IPv6.  Internet Draft draft-ietf-
          mobileip-ipv6-14.txt, Jul. 2001.

[RFC2401] S. Kent and R. Atkinson.  Security Architecture for the Internet
          Protocol.  RFC 2401, Nov. 1998.

[RFC2374] R. Hinden, M. O'Dell, and S. Deering.  An IPv6 Aggregatable
          Global Unicast Address Format.  RFC 2374, Jul, 1998

[EUI64]   IEEE. Guidelines for 64-bit Global Identifier (EUI-64) Registra-
          tion Authority, http://standards.ieee.org/regauth/oui/tutori-
          als/EUI64.html, 1997.





























Teraoka                   Expires 23 December 2003                [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/