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

Versions: 01 02 03 04

Internet Engineering Task Force                              Fumio Teraoka
INTERNET DRAFT                                                    Sony CSL
                                                           16 January 1996


                   Options for Mobility Support in IPv6
                  draft-teraoka-ipv6-mobility-sup-02.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.  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 can have authentic
   mapping information for routing optimization.  Since the source address
   field in the IPv6 header indicates the actual location of the source
   node, multicast routing based on reverse path forwarding can be applied
   to multicast packets sent by a mobile node, and there is no problem on
   source address spoofing.


1.  Introduction

   A mobility support protocol in IPv4 (Mobile-IP)[1] makes use of
   tunneling to forward packets to mobile nodes.  In Mobile-IP, mobile
   nodes usually connect to subnets served by FAs (Foreign Agents).
   Communication between a mobile node and a FA is based on a data link
   communication mechanism, not on an IP routing since Mobile-IP violates
   the subnet model.  Tunneling also has several problems in terms of



Teraoka                    Expires: 16 July 1996                   [Page 1]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


   network architecture as well as network management.  Since mobility
   support is a requirement for IPv6[2], it must be designed with careful
   consideration of network architecture.

   This memo describes a protocol for mobility support in IPv6[3].  This
   protocol is based on the same concept of VIP[4], 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 packets transmitted by mobile
   nodes.

   This protocol introduces four new destination options to support
   mobility: `source ID', `destination ID', `registration request', and
   `registration acknowledgment'.


2.  Terminology

   This memo uses the following terms:

      node:

         The general term for both a host and a router.

      mobile node:

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

      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 means when it is connected to
         a subnet.

      identifier:

         A number that uniquely identifies a node.  Each node has one
         identifier regardless of the number of network interfaces it has.



Teraoka                    Expires: 16 July 1996                   [Page 2]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


         The identifier is immutable no matter where the node is connected
         to the Internet.  The identifier has the same format of the
         address and can be used as the default address of the node.

      home subnet:

         The subnet indicated by the identifier of a mobile node.

      address resolution:

         A function that maps an identifier to the address.

      address mapping table (AMT):

         A table that consists of entries, each of which holds the mapping
         information between an identifier and an address of a mobile node.
         Each node should have an AMT for address resolution.

      primary address resolver (PAR):

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


3.  Formats

   This protocol introduces the `source ID' option and the `destination ID'
   option as destination options 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 address resolver(s).


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 Authentication
   Header, the Destination Options Header, and an upper layer PDU.









Teraoka                    Expires: 16 July 1996                   [Page 3]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


                      +--------------------------------+
                      |          IPv6 Header           |
                      +--------------------------------+
                      |   Destination Options Header   |
                      |    (Destination ID Option)     |
                      |       (Source ID Option)       |
                      +--------------------------------+
                      |     Authentication 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 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 by the final destination node and its primary address
   resolver.  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 (destination option)



      Option Type:

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




Teraoka                    Expires: 16 July 1996                   [Page 4]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


      Option Data Length:

         The length is 20 octets.

      Destination Address Version:

         A 32-bit number that specifies the version of the destination
         identifier/address pair.  The value in this field will change when
         address resolution occurs on the primary address resolver of the
         destination node.

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



      Option Type.



Teraoka                    Expires: 16 July 1996                   [Page 5]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


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

      Option Data Length.

         The length is 28 octets.

      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.

      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.

      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.

      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/Acknowledgment 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.
















Teraoka                    Expires: 16 July 1996                   [Page 6]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


                   +--------------------------------------+
                   |              IPv6 Header             |
                   +--------------------------------------+
                   |      Destination Options Header      |
                   |                                      |
                   |    (Registration Request Option)     |
                   |                  or                  |
                   | (Registration Acknowledgment Option) |
                   +--------------------------------------+
                   |        Authentication Header         |
                   +--------------------------------------+

         Figure 4: Registration request/acknowledgment packet format


3.2.1.  Registration Request Option Format

   The registration request option indicates some control information for
   registration of the current location of a mobile node.  This option is
   examined only on the final destination node, i.e., the primary address
   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=44|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                          Identifier                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                           Address                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Teraoka                    Expires: 16 July 1996                   [Page 7]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


                    Figure 6: Registration request option



      Option Type:

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

      Option Data Length:

         The length is 28 octets.

      Address Version:

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

      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.

      Holding Time:

         A 32-bit number that specifies the time in second for which the
         primary address resolver of the source node should keep the AMT
         entry.

      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.

      Address:

         A 128-bit number that specifies the point of attachment to the
         internet.


3.2.2.  Registration Acknowledgment Option Format

   The registration acknowledgment 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.



Teraoka                    Expires: 16 July 1996                   [Page 8]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


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

                 Figure 8: Registration acknowledgment option



      Option Type:

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

      Address Version:

         The address version in the registration request packet.

      Identifier:

         The Identifier in the registration request packet.


4.  AMT Entry Format

   Each node should have an Address Mapping Table (AMT) for routing
   optimization 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 transmits a packet, it executes address
   resolution if it has an AMT entry for the destination node.  The format
   of the AMT entry is depicted in Figure 9.













Teraoka                    Expires: 16 July 1996                   [Page 9]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


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

                 Figure 9: Address mapping table entry format



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

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

      Address Version:

         The address version of the identifier/address pair.

      Timestamp:



Teraoka                    Expires: 16 July 1996                  [Page 10]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


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

      Holding Time:

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

      Identifier:

         The key of this entry.

      Address:

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


5.  Authentication

   Both the source ID option and the registration request option are
   included in integrity assurance computation of the Authentication
   Header.  When a node receives a data packet from a mobile node, the
   receiving node can authenticate the mobile node and create an authentic
   AMT entry.  Similary, when the primary address resolver of a mobile node
   receives a registration request packet, the primary address resolver can
   authenticate the mobile node and create an authentic AMT entry.

   The algorithm used in the Authentication Header is beyond the scope of
   this memo.


6.  Connecting to a Subnet


6.1.  Procedures on a Mobile Node

   When a mobile node is connected to a subnet, it obtains a temporary IPv6
   address in the subnet by some means such as DHCPv6.  Again, the
   identifier of the mobile node never changes.  The mobile node transmits
   a registration request packet to the anycast address specifying its
   primary address resolver(s).  Each field of the registration request
   packet is set as follows:

      Address Version:

         the version number of the pair of the temporary IPv6 address and
         the identifier.

      Timestamp:

         the current time at which this packet is transmitted.



Teraoka                    Expires: 16 July 1996                  [Page 11]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


      Holding Time:

         the time in second for which the AMT entry for this mobile node
         should be kept.

      Identifier:

         the identifier of the mobile node.

      Address:

         the temporary IPv6 address of the interface to be used.



6.2.  Procedures on a Primary Address Resolver

   When the primary address resolver in the home subnet receives the
   registration request packet, it authenticates the registration request
   option.  If the authentication succeeds, the primary address resolver
   modifies its AMT as follows.  A new AMT entry is created if the primary
   address resolver does not have an AMT entry for the source mobile node,
   or an existin AMT entry is modified if the Address Version field of the
   entry is older than that of the registration request option.

   Next, the primary address resolver broadcasts the received registration
   request packet within the home subnet if the home subnet is of
   broadcast-type.  If the primary address resolver had an obsolete AMT
   entry, it also transmits the received registration request packet to the
   address specified by the Address field of the obsolete AMT entry.

   Next, the primary address resolver returns a registration acknowledgment
   packet to the mobile node.  Each field of the registration
   acknowledgment option in the registration acknowledgment packet is set
   as follows:

      Address Version:

         the value in the Address Version field of the received
         registration request option.

      Identification:

         the value in the Identifier field of the received registration
         request option.

   The Destination Address field of the IPv6 Header is assigned the value
   in the Address field of the registration request option in the received
   registration request option.





Teraoka                    Expires: 16 July 1996                  [Page 12]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


7.  Data Communication

   TCP/UDP specifies the destination node with the identifier.  Address
   resolution for the destination node is executed on the source 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
   exists, the values in the Address field and the Address Version field of
   the AMT 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 the Destination Node

   The destination node authenticates the source ID option of the received
   packet.  If the authentication succeeds, the destination node modifies
   its AMT as described above, and then the destination node 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] C. Perkins.  IP Mobility Support.  Internet-Draft draft-ietf-mobileip-
    protocol-14.txt, December 1995.



Teraoka                    Expires: 16 July 1996                  [Page 13]


draft-teraoka-ipv6-mobility-sup-02.txt                      16 January 1996


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

[3] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
    Specification.  RFC 1883, December 1995.

[4] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai.  VIP: A Protocol
    Providing Host Mobility.  CACM, Vol. 37, No. 8, Aug. 1994.

[5] R. Atkinson.  IP Authentication Header.  RFC 1826, August 1995.












































Teraoka                    Expires: 16 July 1996                  [Page 14]


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