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

Versions: 01 02 03 04

Internet Engineering Task Force                              Fumio Teraoka
INTERNET DRAFT                                                    Sony CSL
                                                              29 June 1995


                   Options for Mobility Support in IPv6
                  draft-teraoka-ipv6-mobility-sup-01.txt



Status of this Memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract

   This memo describes a protocol for mobility support in IPv6.  This
   protocol is based on the same concept of VIP, a protocol for mobility
   support in IPv4.  The basic concept is separation of identifiers and
   addresses.  TCP/UDP uses the identifier.  The identifier is mapped to an
   address, and then the packet is routed in accordance with the address.
   End nodes as well as intermediate routers can have authentic mapping
   information for routing optimization and fault tolerance.  Since the
   source address field in the IPv6 header indicates the actual address of
   the source node, there is no problem on source address spoofing.


1.  Introduction

   A mobility support protocol in IPv4 (Mobile-IP) is under development in
   IETF.  For compatibility with the existing Internet, Mobile-IP makes use
   of a technique called tunneling to forward packets to mobile nodes.
   However, tunneling has several problems in terms of network architecture
   as well as network management.  Since mobility support is a requirement
   for IPv6[1], it must be designed with careful consideration of network



Teraoka                  Expires: 29 December 1995                 [Page 1]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


   architecture.

   This memo describes a protocol for mobility support in IPv6[2].  This
   protocol is based on the same concept of VIP[3], a protocol for mobility
   support in IPv4.  The basic concept is separation of identifiers and
   addresses.  Both the identifier and the address have the same format.
   The identifier of a mobile node never changes no matter where it moves.
   The address of a mobile node specifies the point of attachment to the
   Internet.  The address is used only for packet routing, not for
   identifying the node.  The identifier of a mobile node is the address in
   its `home subnet' so that it can also be used as the default address of
   the mobile node.

   TCP/UDP specifies a node with the identifier, not with the address.  For
   routing optimization and fault tolerance of network partitioning, each
   node can have a cache called Address Mapping Table (AMT).  AMT entries
   can be created or updated upon receiving or forwarding packets
   transmitted by mobile nodes.

   This protocol introduces five new options to support mobility: `source
   ID', `registration request', and `registration acknowledgment' options
   as destination options, and `destination ID' and `mapping information'
   options as hop-by-hop-options.


2.  Terminology

   This memo uses the following terms:

      o  node.  The general term for both a host and a router.

      o  mobile node.  A node that changes the point of attachment to the
         Internet.

      o  address.  A number that specifies the point of attachment to the
         Internet.  An address is assigned to each network interface of a
         node.  In IPv6, a 128-bit number is used as the address[4].  The
         address of an interface changes when the node moves to another
         subnet.  The node must obtain an address by some method when it is
         connected to a subnet.

      o  identifier.  A number that uniquely identifies a node.  Each node
         has one identifier regardless of the number of network interfaces
         it has.  The identifier is immutable no matter where the node is
         connected in the Internet.  The identifier has the same format of
         the address and can be used as the default address of the node.

      o  home subnet.  The subnet indicated by the identifier of a mobile
         node.

      o  address resolution.  A function that maps an identifier to the



Teraoka                  Expires: 29 December 1995                 [Page 2]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


         address.

      o  address mapping table (AMT): A table that consists of entries,
         each of which holds the mapping information between an identifier
         and an address.  Each node should have an AMT for address
         resolution and fault tolerance of network partitioning.

      o  address resolver.  A node that performs address resolution.  There
         are two types of address resolvers for a mobile node:

         - primary resolver.  An address resolver connected to the home
           subnet of a mobile node.  A primary resolver advertizes routing
           information of the home subnet.  A mobile node notifies its
           primary resolver(s) of its identifier and the current address
           when its address changes.  A primary resolver may be a router
           connected to the home subnet.  A primary resolver may also be a
           host that has a `pseudo' network interface connected to the
           `pseudo' home subnet.

         - cache resolver.  An address resolver not connected to the home
           subnet of a mobile node.  A cache resolver creates or updates
           its AMT upon forwarding a packet with the mapping information
           option or upon receiving a packet with the source ID option.


3.  Formats

   This protocol introduces the `source ID' option as a destination option
   and the `destination ID' option as a hop-by-hop option for a packet
   carrying an upper layer PDU.  The `registration request' and
   `registration acknowledgment' options are introduced as destination
   options for a mobile node to register its current address with its
   primary resolver(s).  The `mapping information' option as a hop-by-hop
   option is also used with the registration request option.

   The reason why the registration request packet has the mapping
   information option as a hop-by-hop option is to create or update AMT
   entries on every node along the packet forwarding path.


3.1.  Data Packet Format

   The entire format of a packet carrying an upper layer PDU is depicted in
   Figure 1.  The packet consists of the IPv6 Header, the Hop-by-Hop
   Options Header, the Authentication Header, the Destination Options
   Header, and an upper layer PDU.








Teraoka                  Expires: 29 December 1995                 [Page 3]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 Header                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Hop-by-Hop Options Header                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Authentication Header                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Destination Options Header                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Transport Layer Header and User Data              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: IPv6 packet carrying an upper layer PDU


3.1.1.  Destination ID Option Format

   The destination ID option as a hop-by-hop option specifies the
   identifier of the final destination node of a packet.  It also specifies
   the version number of the identifier/address pair of the final
   destination node.  This option is examined on every node along the
   forwarding path for address resolution of the final destination node,
   i.e., the Destination Address field of the IPv6 Header will be modified
   on the router that has newer mapping information for the final
   destination node.  The format of the destination ID option is depicted
   in Figure 2.


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |Opt Data Len=20|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination Address Version                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                    Destination Identifier                     +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: destination ID option (hop-by-hop option)


      o  Option Type.  The value is 0x2?, which indicates that this option
         is excluded from integrity assurance computation of the
         Authentication Header[5].

      o  Option Data Length.  The length is 20 octets.




Teraoka                  Expires: 29 December 1995                 [Page 4]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      o  Destination Address Version.  A 32-bit number that specifies the
         version of the destination identifier/address pair.  The value in
         this field changes when address resolution occurs along the
         forwarding path.

      o  Destination Identifier.  A 128-bit number that uniquely identifies
         the final destination node regardless of the location, ie.,
         regardless of the Destination Address in the IPv6 Header.


3.1.2.  Source ID Option Format

   The source ID option as a destination option specifies the identifier of
   the source node of a packet.  It also specifies the version number of
   the identifier/address pair of the source node.  It is examined only on
   the final destination node.  This option with the Authentication Header
   allows the destination node to create or update an authentic AMT entry
   for the source node.  The format of the source ID option is depicted in
   Figure 3.


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |Opt Data Len=28|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source Address Version                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Source Identifier                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: source ID option (destination option)


      o  Option Type.  The value is 0x0?, which indicates that this option
         is included in integrity assurance computation of the
         Authentication Header.

      o  Option Data Length.  The length is 28 octets.

      o  Source Address Version.  A 32-bit number that specifies the
         version of the source identifier/address pair.  This number must
         be incremented monotonously when a new address is assigned.



Teraoka                  Expires: 29 December 1995                 [Page 5]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      o  Timestamp.  A 32-bit number that specifies the time in second when
         the source node transmits this packet.  This field is used to
         prevent replay attack.

      o  Holding Time.  A 32-bit number that specifies the time in second
         for which a node should keep the AMT entry for the source node of
         this packet.

      o  Source Identifier.  A 128-bit number that uniquely identifies the
         source node regardless of the location, ie., regardless of the
         Source Address in the IPv6 Header.


3.2.  Registration Request Packet Format

   The entire format of a registration request packet is depicted in Figure
   4.  A registration request packet consists of the IPv6 Header, the Hop-
   by-Hop Options Header, and the Destination Options Header.  It may have
   the Authentication Header.  The registration request packet should not
   have an upper layer PDU.


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 Header                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Hop-by-Hop Options Header                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination Options Header                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: Registration request packet format


3.2.1.  Mapping Information Option Format

   The mapping information option as a hop-by-hop option specifies an
   authentic identifier/address pair and its holding time.  This option
   allows a forwarding node to create or update the authentic AMT entry on
   the node.  The format of the mapping information option is depicted in
   Figure 5.














Teraoka                  Expires: 29 December 1995                 [Page 6]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |OptData Len=108|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                          Identifier                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Address                            +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      Authentication Data                      |
      |               (RSA digital signature: 64 octets)              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: mapping information option (hop-by-hop option)


      o  Option Type.  The value is 0x0?, which indicates that this option
         is included in integrity assurance computation of the
         Authentication Header.

      o  Option Data Length.  The length is 108 octets.

      o  Address Version.  A 32-bit number that specifies the version of
         the identifier/address pair.

      o  Timestamp.  A 32-bit number that specifies the time in second when
         the source node transmits this packet.  This field is used to
         prevent replay attack.

      o  Holding Time.  A 32-bit number that specifies the time in second
         for which a node should keep the AMT entry for the node specified
         by the Identifier field.




Teraoka                  Expires: 29 December 1995                 [Page 7]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      o  Identifier.  A 128-bit number that uniquely identifies the node
         whose AMT entry should be created or updated.

      o  Address.  An IPv6 address of the node whose AMT entry should be
         created or updated.

      o  Authentication Data.  RSA digital signature.  A 64-octets number
         that authenticates and guarantees the integrity of the option
         data.


3.2.2.  Registration Request Option Format

   The registration request option indicates some control information upon
   registration of the current location of a mobile node.  This option is
   examined only on the final destination node, i.e., the primary resolver
   of the mobile node transmitting the registration request packet.  The
   format of the registration request option is depicted in Figure 6.


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |Opt Data Len= 4|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           reserved            |             Flags             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: Registration request option in the Destination Options Header


      o  Option Type.  The value is 0x0?, which indicates that this option
         is included in integrity assurance computation of the
         Authentication Header.

      o  Flags.  Currently, only one flag `A' is defined.  If `A' flag is
         set in the registration request packet, the registration
         acknowledgment packet must be returned.


3.3.  Registration Acknowledgment Packet

   The entire format of a registration acknowledgment packet is depicted in
   Figure 7.  A registration acknowledgment packet consists of the IPv6
   Header, the Authentication Header, and the Destination Options Header.
   The registration acknowledgment packet should not have an upper layer
   PDU.









Teraoka                  Expires: 29 December 1995                 [Page 8]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 Header                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Authentication Header                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination Options Header                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 7: Registration acknowledgment packet format



3.3.1.  Registration Acknowledgment Option Format

   The registration acknowledgment option as a destination option indicates
   the identifier and the identifier/address version number to be
   acknowledged for registration.  This option is examined only on the
   final destination node, i.e., the mobile node that transmitted the
   registration request packet.  The format of the registration
   acknowledgment option is depicted in Figure 8.


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  |Opt Data Len=20|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                          Identifier                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 8: registration acknowledgment option (destination option)


      o  Option Type.  The value is 0x0?, which indicates that this option
         is included in integrity assurance computation.

      o  Address Version.  The address version in the registration request
         packet.

      o  Identifier.  The Identifier in the registration request packet.


4.  AMT Entry Format

   Each node should have an Address Mapping Table (AMT) for address



Teraoka                  Expires: 29 December 1995                 [Page 9]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


   resolution and fault tolerance of network partitioning.  When a node
   receives a packet with the source ID option, it creates or updates the
   AMT entry for the node specified by the Source Identifier field of the
   source ID option.  When a node receives or forwards a packet with the
   mapping information option, it creates or updates the AMT entry for the
   node specified by the Identifier field of the mapping information
   option.  If a node has an appropriate AMT entry, it executes address
   resolution for the destination address when it transmits or forwards a
   packet.  The format of the AMT entry is depicted in Figure 9.


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            status             |           reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                           Identifier                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Address                            +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 9: Address mapping table entry format


      o  Status.  Flags that show the status of this entry.  There are
         three flags as follows:

         -  invalid: if this flag is set, this entry is invalid.  The
            reason why an invalid AMT entry exists is to detect a stale AMT
            entry for another node.

         -  home: if this flag is set, the node that holds this AMT entry
            is connected to the home subnet of the node specified by this
            AMT entry.




Teraoka                  Expires: 29 December 1995                [Page 10]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


         -  local: if this flag is set, the node specified by this AMT
            entry is connected to the same subnet.

      o  Address Version.  The address version of the identifier/address
         pair.

      o  Timestamp.  The timestamp of the source ID option or the mapping
         information option that created or updated this entry.

      o  Holding Time.  The value of this field is periodically
         decremented.  This entry is deleted when the value becomes zero.

      o  Identifier.  The key of this entry.

      o  Address.  The current address of the node specified by the
         Identifier field.


5.  Authentication

   A packet carrying an upper layer PDU has the Authentication Header to
   guarantee the integrity of the packet.  The source ID option is included
   in integrity assurance computation.  A node receiving a packet with the
   source ID option can authenticate the source node and create an
   authentic AMT entry for the source node.  The algorithm used in the
   Authentication Header is beyond the scope of this memo.

   The registration request packet has the mapping information option.
   Since the mapping information option includes RSA digital signature as
   authentication data, forwarding nodes as well as the destination node of
   a registration request packet can authenticate the mapping information
   and create an authentic AMT entry.  The following fields are included in
   calculation of authentication data in the mapping information option:
   Address Version, Timestamp, Holding Time, Identifier, and Address.  The
   key is 512 bits in length.  Protocols for public key distribution is
   beyond the scope of this memo.


6.  Connecting to a Subnet

   When a mobile node is connected to a subnet, it obtains a temporary IPv6
   address in the subnet by some means such as Address Auto-configuration.
   Again, the identifier of the mobile node never changes.  The mobile node
   transmits a registration request packet to the anycast address
   specifying its home subnet.  On the forwarding path of this packet,
   authentic AMT entries for the mobile node is created or updated on
   intermediate nodes as well as the primary resolver(s) in the home
   subnet.






Teraoka                  Expires: 29 December 1995                [Page 11]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


6.1.  Procedures on a Mobile Node

   The registration request packet has the mapping information option in
   the Hop-by-Hop Options Header and the registration request option in the
   Destination Options Header.  Each field of the mapping information
   option is set as follows:

      o  Address Version: the version number of the pair of the temporary
         IPv6 address and the identifier.

      o  Timestamp: the current time at which this packet is transmitted.

      o  Holding Time: the time in second for which the AMT entry for this
         mobile node should be kept.

      o  Identifier: the identifier of the mobile node.

      o  Address: the temporary IPv6 address of the interface to be used.

      o  Authentication Data: RSA digital signature which covers the above
         five fields.

   The mobile node may set the `A' flag in the Flags field of the
   registration request option in the registration request packet if it
   wants to receive the registration acknowledgment packet from its primary
   resolver.  The mobile node retransmits the registration request packet
   if the waiting timer of the registration acknowledgment packet expires.

   The mobile node specifies the holding time of the AMT entry by the
   Holding Time field in the mapping information option in the registration
   request packet.  To refresh the AMT entry on the primary resolver, the
   mobile node periodically transmits the registration request packet in a
   certain interval of time, e.g., half of the holding time.


6.2.  Procedures on an Intermediate Node

   When an intermediate node forwards the registration request packet, it
   may execute the following procedures.

      1. Authentication: the intermediate node authenticates the mapping
         information option if it has the public key of the mobile node
         specified by the Identifier field of the option.  If the
         authentication succeeded, AMT modification is executed.

      2. AMT modification: the intermediate node creates an AMT entry for
         the mobile node specified by the Identifier field of the mapping
         information option if it does not have the entry for the mobile
         node, or it updates the existing AMT entry if it has an obsolete
         AMT entry, ie., the Address Version in the mapping information
         option is newer (larger) than that of the AMT entry.



Teraoka                  Expires: 29 December 1995                [Page 12]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


      When an intermediate node has an obsolete AMT entry exists, it may
      broadcast the received packet to all the interfaces it has.  This
      broadcast stops at the node that does not have a related AMT entry.


6.3.  Procedures on a Primary Resolver in the Home Subnet

   When a primary resolver in the home subnet receives the registration
   request packet, it executes the authentication procedure and the AMT
   modification procedure described above, and then broadcasts this
   registration request packet within the home subnet if the subnet is of
   broadcast-type.  If the primary resolver had an obsolete AMT entry, it
   also transmits this registration request packet to the address specified
   by the Address field of the obsolete AMT entry.

   If the `A' flag is set in the Flags field of the registration request
   option, the primary resolver returns the registration acknowledgment
   packet to the mobile node.  Each field of the registration
   acknowledgment option in the registration acknowledgment packet is set
   as follows:

      o  Address Version: the value in the Address Version field of the
         mapping information option in the related registration request
         packet.

      o  Identification: the value in the Identifier field of the mapping
         information option in the related registration request packet.

   The Destination Address field of the IPv6 Header is assigned the value
   in the Address field of the mapping information option in the related
   registration request packet.


7.  Data Communication

   TCP/UDP specifies the destination node with the identifier.  Address
   resolution for the destination node is executed on the source node, an
   intermediate node, or a primary resolver in the home subnet of the
   destination node, and then the packet is routed to the destination node.


7.1.  Procedures on the Source Node

   The source node creates an IPv6 packet with the destination ID option,
   the source ID option, and the Authentication Header.  A transmission
   request from the TCP/UDP layer specifies the destination node with the
   identifier, not the address.  This destination identifier is assigned to
   the Identifier field of the Destination ID option.

   The source node attempts to resolve the destination identifier into an
   address by accessing the AMT.  If the AMT entry for the destination node



Teraoka                  Expires: 29 December 1995                [Page 13]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


   exists, the values in the Address field and the Address Version field of
   the entry are assigned to the Destination Address field of the IPv6
   Header and the Destination Address Version field of the Destination ID
   option, respectively.  If not, the Destination Address field of the IPv6
   Header is also assigned the identifier of the destination node, and the
   Destination Address Version field is assigned zero.

   The fields in the source ID option (Source Identifier, Source Address
   Version, Holding Time, and Timestamp) are filled with appropriate
   values, and then integrity computation of the Authentication Header is
   executed.


7.2.  Procedures on an Intermediate Node

   An intermediate node may execute address resolution upon forwarding a
   packet with the Destination ID option.  In address resolution, the
   Destination Address field in the IPv6 Header and the Destination Address
   Version field of the Destination ID option will be modified.  If the AMT
   entry for the destination node of the packet exists, the Destination
   Address Version field of the Destination ID option is compared with the
   Address Version field of the entry.  If the entry has newer information,
   the Destination Address field of the IPv6 Header and the Destination
   Address Version field of the Destination ID option are modified in
   accordance with the entry.


7.3.  Procedures on the Destination Node

   The destination node executes the AMT modification procedure described
   above, and then it notifies the upper layer of the receipt of a packet
   with the identifier of the source node, not the address.

Author's Address:

   o  Fumio Teraoka
      Sony Computer Science Laboratory Inc.
      3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141, Japan.
      Phone: +81-3-5448-4380
      Email: tera@csl.sony.co.jp

References

[1] F. Kastenholz and C. Partridge.  Technical Criteria for Choosing IP:The
    Next Generation (IPng).  RFC 1726, December 1994.

[2] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
    Specification.  Internet-Draft draft-ietf-ipngwg-ipv6-spec-02.txt, June
    1995.

[3] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai.  VIP: A Protocol



Teraoka                  Expires: 29 December 1995                [Page 14]


draft-teraoka-ipv6-mobility-sup-01.txt                         29 June 1995


    Providing Host Mobility.  in CACM, Vol. 37, No. 8, Aug. 1994.

[4] R. Hinden and S. Deering.  IP Version 6 Addressing Architecture.
    Internet-Draft draft-ietf-ipngwg-addr-arch-03.txt, June 1995.

[5] R. Atkinson.  IPv6 Authentication Header.  Internet-Draft draft-ietf-
    ipngwg-auth-00.txt, February 1995.















































Teraoka                  Expires: 29 December 1995                [Page 15]


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