[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01                                                            
Internet Engineering Task Force                            Fumio Teraoka
INTERNET DRAFT                                                   SonyCSL
                                                        December 1, 1995


                Virtual Internet Protocol version 2 (VIPv2)
                     draft-teraoka-mobileip-vip-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 Virtual Internet Protocol version 2 (VIPv2), a
   protocol for mobility support in IPv4.  The basic concept of VIP 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.


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 mechanism called tunneling to forward packets to mobile nodes.
   However, tunneling has several problems in terms of network architecture
   as well as network management.

   VIP[1] is another protocol to support mobility in IPv4.  The basic
   concept of VIP is separation of identifiers and addresses.  The
   identifier of a mobile node never changes regardless of the point of



Teraoka                    Expires: June 1, 1996                   [Page 1]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   attachment to the Internet, while the address of a mobile node changes
   when it moves to another subnet.  The conventional IP address is the
   address of a mobile node.  VIP introduces "VIP address" as the
   identifier of a mobile node.  The VIP address and the IP address have
   the same format.  TCP/UDP uses the VIP address to specify the target
   node.  The VIP address is mapped to the IP address, and then the packet
   is routed in accordance with the IP address.

   For efficient mapping from the VIP address to the IP address, VIP nodes
   (including end nodes and routers) have a cache called "AMT (Address
   Mapping Table)".  The AMT consists of authentic entries, each of which
   holds the relation between the VIP address and the IP address of a
   mobile node.  The AMT allows routing optimization for packets destined
   to mobile nodes.  It also provides fault tolerance of network
   partitioning.


1.1.  Assumptions

   VIPv2 requires a mechanism for secret key distribution among nodes.
   VIPv2 itself does not include any protocols for key distribution.  It is
   assumed that some key distribution mechanisms (including off-line
   distribution) are available.


1.2.  Terminology

   This memo uses the following terms.

   IP Address

      The IP address of a mobile node specifies its current point of
      attachment to the Internet.  In other words, the IP address is the
      "locator" of a mobile node.  When a mobile node moves to another
      subnet, it obtains an IP address by some methods such as DHCP[2].

   VIP Address

      The VIP address is the "identifier" of a mobile node.  It never
      changes even if a mobile node moves in the Internet.  The VIP address
      has the same format as the IP address.  TCP/UDP uses the VIP address
      to specify the target node.  The VIP address can be used as the
      "default locator" of a mobile node.

   Home Subnet

      The subnet specified by the VIP address of a mobile node.  Each
      mobile node has its home subnet.  The IP address of a mobile node
      becomes equal to its VIP address in its home subnet.

   Home Router



Teraoka                    Expires: June 1, 1996                   [Page 2]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


      The router connected to the home subnet of a mobile node.  Each
      mobile node has its home router(s).  The home router maintains the
      relation between the VIP addresses and the IP addresses of mobile
      nodes it manages.  The home router also advertises routing
      information for the VIP addresses of mobile nodes it manages.  The
      home router catches a packet destined to the VIP address of a mobile
      node, resolves the destination VIP address into the destination IP
      address, and then forwards the packet.

   Address Resolution

      Address resolution is a process to map a VIP address to an IP
      address.

   Address Mapping Table (AMT)

      The AMT consists of authentic entries, each of which holds relation
      between a VIP address and an IP address.  Each node (including an end
      node and a router) holds an AMT for address resolution.

   Address Resolver

      The address resolver is a node (including an end node and a router)
      that executes address resolution.  The home router of a mobile node
      is an address resolver for the mobile node.  A router becomes an
      address resolver for a mobile node if it holds an AMT entry for the
      mobile node.


2.  Packet Format

2.1.  Data Packet Header Format

   Figure 1 depicts the header format of the VIPv2 data packet.  First 20
   octets are the basic IP header followed by the VIP header as an IP
   option.  In a VIPv2 packet, no other IP options can be included in the
   IP header because the VIP header occupies the whole space (40 octets)
   for IP options.
















Teraoka                    Expires: June 1, 1996                   [Page 3]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver = 4|IHL=0xf|      TOS      |         Total Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Identification         |Flags|     Fragment Offset     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TTL      |    Protocol   |        Header Checksum        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source VIP Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination IP Address                    |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |OptType = 0x8c | OptLen = 0x28 |ver = 2| rsvd  |     Flags     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source IP Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source Address Version                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination VIP Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination Address Version                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Resolver IP Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Authentication Data                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1. VIPv2 data packet header format



        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
      |1/0| 0 | 0 |1/0| 0 |1/0|1/0|1/0|
      +---+---+---+---+---+---+---+---+
        ^           ^       ^   ^   ^
        |           |       |   |   |
        |           |       |   |   +-- don't cache
        |           |       |   +------ don't resolve
        |           |       +---------- keyed MD5 included
        |           +------------------ control(1)/data(0)
        +------------------------------ RSA digital signature appended

                               Figure 2. Flags



Teraoka                    Expires: June 1, 1996                   [Page 4]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   Source VIP Address

      This field specifies the identifier (the VIP address) of the source
      node.  In IP, this field is used as the Source IP Address field.  For
      backward compatibility with IP, this field is used as the Source VIP
      Address field in VIPv2.

   Destination IP address

      This field specifies the location of the destination node.  This
      field will be rewritten by address resolution.

   Option Type (OptType)

      This field specifies that this IP option is the VIP header.  The
      value is 0x8c (140), which means this option will be copied into
      every fragment when fragmentation occurs.  Currently, this value is
      unofficial.

   Option Length (OptLen)

      This field specifies the length of the VIP header as an IP option.
      The value is 0x28 (40 octets).

   Version (ver)

      This field specifies the VIP version.  The current version is 2.

   Flags

      Figure 2 depicts the format of the Flags field.

      don't cache

         If this flag is on, nodes other than the home router of the source
         node do not create an AMT entry for the source node.

      don't resolve

         If this flag is on, nodes other than the home router of the
         destination node do not execute address resolution for the
         destination node.

      keyed MD5 included

         If this flag is on, authentication data based on keyed MD5 is
         included in this packet.

      control/data

         If this flag is on, this packet is the VIP control packet.  If



Teraoka                    Expires: June 1, 1996                   [Page 5]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


         this flag is off, this packet is a VIP data packet.

      RSA digital signature appended

         If both of this flag and the control flag are on, this control
         packet includes authentication data based on RSA digital signature
         in the data part.


   Source IP Address

      This field specifies the location of the source node.  For
      compatibility with IP, the Source IP Address field is placed in the
      VIP header.

   Source Address Version

      This field specifies the version number of the relation between the
      source VIP address and the source IP address.

   Destination VIP address

      This field specifies the identifier (the VIP address) of the
      destination node.

   Destination Address Version

      This field specifies the version number of the relation between the
      destination VIP address and the destination IP address.  This field
      will be rewritten by address resolution.

   Resolver IP address

      This field specifies the IP address of the node that executed address
      resolution for this packet.  This field will be rewritten by address
      resolution.

   Holding Time

      When this packet causes creation or update of an AMT entry on a node,
      this field specifies the time in second for which the node should
      keep this AMT entry.

   Timestamp

      This field specifies the time at which the source node transmits this
      packet.  This field will be used to prevent "replay attack".

   Authentication Data

      The data for source node authentication.  Keyed MD5 is used to



Teraoka                    Expires: June 1, 1996                   [Page 6]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


      calculate this data.  The source node shares a secret key with each
      destination node.  On the source node, the authentication data is
      calculated as follows.  MD5 is calculated over the following five
      fields followed by the secret key: Source VIP Address, Source IP
      Address, Source Address Version, Holding Time, and Timestamp.  The
      length of the Authentication Data is 8 octets due to the limit of IP
      option length although MD5 generates a 16-octet message digest.  The
      first 8-octet and the last 8-octet of the message digest are xor'ed
      to generate 8-octet data.


2.2.  Control Packet Header Format

   The VIPv2 control packet is used for AMT update, e.g., to notify the
   current IP address to the home router.  Figure 3 depicts the format of
   the VIPv2 control packet.






































Teraoka                    Expires: June 1, 1996                   [Page 7]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver = 4|IHL=0xf|      TOS      |         Total Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Identification         |Flags|     Fragment Offset     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TTL      |    Protocol   |        Header Checksum        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source VIP address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination IP address                    |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |OptType = 0x8c | OptLen = 0x28 |ver = 2| rsvd  |     Flags     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source IP Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source Address Version                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          VIP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Authentication Data                      +
      |                                                               |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |                       (Data Part of IP)                       |
      |                                                               |
      |                      Authentication Data                      |
      |                    (RSA digital signature)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3. Control packet header format



   The meanings of the following eight fields are the same as those of the
   VIPv2 data packet header: Source VIP Address, Destination IP Address,
   Option Type, Option Length, Version, Flags, Source IP Address, and
   Source Address Version.

   VIP Address

      This field specifies the VIP address for AMT update.



Teraoka                    Expires: June 1, 1996                   [Page 8]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   IP Address

      This field specifies the IP address corresponding to the VIP Address
      field.

   Address Version

      This field specifies the version number of the relation between the
      VIP Address field and the IP Address field.

   Holding Time

      When this packet causes creation or update of an AMT entry on a node,
      this field specifies the time in second for which the node should
      keep this AMT entry.

   Timestamp

      This field specifies the time at which the source node transmits this
      packet.  This field will be used to prevent "replay attack".

   Authentication Data

      the data for authentication of the VIP Address field.  Keyed MD5 is
      used to calculate this data.  The source node shares a secret key
      with each destination node.  On the source node, the authentication
      data is calculated as follows.  MD5 is calculated over the following
      five fields followed by the secret key: VIP Address, IP Address,
      Address Version, Holding Time, and Timestamp.  The length of the
      Authentication Data is 8 octets due to the limit of IP option length
      although MD5 generates a 16-octet message digest.  The first 8-octet
      and the last 8-octet of the message digest are xor'ed to generate 8-
      octet data.

   Authentication Data (RSA digital signature)

      This field is in the data part of the IP packet, not in the IP
      header.  The source node may append this field to create or update
      the AMT entry on intermediate routers.


3.  AMT Entry Format

   Since the AMT is node-local data, there is no standard format of the AMT
   entry.  Figure 4 depicts an example of an AMT entry format.  The
   meanings of the following six fields are obvious: VIP Address, IP
   Address, Address Version, Holding Time, Timestamp, and Authentication
   Data.






Teraoka                    Expires: June 1, 1996                   [Page 9]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          VIP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Version                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Holding Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Flags                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timer                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 4. AMT entry format


   Flags

      invalid

         If this flag is on, this AMT entry has invalid data.  An invalid
         AMT entry is used to detect a packet having obsolete mapping
         between the destination VIP address and the destination IP
         address.

      home

         If a node has an AMT entry in which this flag is on, this node is
         connected to the home subnet of the mobile node specified by this
         AMT entry.  If this node is a router, it is one of home routers of
         the mobile node.

      local

         If a node has an AMT entry in which this flag is on, this node is
         connected to the subnet to which the mobile node specified by this
         AMT entry is connected.


   Timer

      The value in this field is decremented every second.  When the value
      becomes zero, this entry is deleted.






Teraoka                    Expires: June 1, 1996                  [Page 10]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


4.  Procedures on a Mobile Node

4.1.  Procedures upon Connecting to a Subnet

   When a mobile node moves to a subnet, it obtains an IP address in that
   subnet by some methods such as DHCP.  The mobile node transmits a VIPv2
   control packet to its home router.

   If a mobile node is connected to its home subnet, its IP address becomes
   equal to its VIP address.  The mobile node broadcasts a VIPv2 control
   packet in the home subnet if the home subnet is a broadcast-type subnet
   such as an Ethernet.

   Each field of the control packet is set as follows:

      Source VIP Address       the VIP address of the mobile node.

      Destination IP Address   the IP address of the home router. The
                               VIP address of the mobile node can be used.

      Flags                    "control", "don't cache", and "don't
                               resolve" flags are on.

      Source IP Address        the obtained IP address.

      Source Address Version   the address version of the current IP
                               address.

      VIP Address              the VIP address of the mobile node.

      IP Address               the obtained IP address.

      Address Version          the address version of the current IP
                               address.

      Holding Time             a certain value.

      Timestamp                the current time at which this packet is
                               created.

      Authentication Data      keyed MD5 calculated over the above five
                               fields followed by the shared key with
                               the home router.

   The mobile node periodically transmits the control packet to its home
   subnet while it is connected to the Internet.


4.2.  Procedures upon Data Packet Transmission

   When a node transmits a data packet, each field of the header is set as



Teraoka                    Expires: June 1, 1996                  [Page 11]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   follows:

      Source VIP Address            the VIP address of the node.

      Destination IP Address        if the node holds an AMT entry for the
                                    target node, the IP address in the
                                    entry is set. If not, the VIP address
                                    of the target node is set.

      Flags                         none of flags are usually set.

      Source IP Address             the current IP address of the node.

      Source Address Version        the address version of the node.

      Destination VIP Address       the VIP address of the target node.

      Destination Address Version   If the node holds an AMT entry for the
                                    target node, the address version in the
                                    entry is set. If not, zero is set.

      Resolver IP Address           If the node executes address
                                    resolution, the IP address of the node
                                    is set. If not, zero is set.

      Holding Time                  a certain value

      Timestamp                     the current time at which this packet
                                    is created.

      Authentication Data           keyed MD5 calculated over the following
                                    five fields followed by the shared key
                                    with the target node: Source VIP
                                    Address, Source IP Address, Source
                                    Address Version, Holding Time, and
                                    Timestamp.


4.3.  Procedures upon Data Packet Reception

   When a node receives a VIPv2 data packet, it compares its IP address
   with the destination IP address in the packet header, and then compares
   its VIP address with the destination VIP address in the packet header.
   If both addresses are the same, the received packet is passed to the
   upper layer.

   At the same time, the node checks the Authentication Data field.  If the
   node has the shared key with the source node of the packet, it
   calculates keyed MD5 in the same way as the source node.  If the
   calculation result is equal to the value in the Authentication Data
   field, the node updates its AMT based on the information in the received



Teraoka                    Expires: June 1, 1996                  [Page 12]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   packet header as described below.


From Mobile Node Away from its Home

   If the node does not have an AMT entry for the source node and the
   source IP address and the source VIP address of the packet header are
   different, then a new AMT entry for the source node is created.  Each
   field of the AMT entry is set as follows:

      VIP Address       the Source VIP Address field of the packet.

      IP Address        the Source IP Address field of the packet.

      Address Version   the Source Address Version field of the packet.

      Holding Time      the Holding Time field of the packet.

      Timestamp         the Timestamp field of the packet.

      Timer             the Timestamp field of the packet.


   If the node has an AMT entry for the source node and the Version field
   of the AMT entry is older than the Source Address Version field of the
   packet header, then the AMT entry is updated by modifying all the fields
   except the VIP address field.

   If the node has an AMT entry for the source node with the same version
   number and the Timestamp field of the AMT entry is older than the
   Timestamp field of the packet header, then the AMT entry is updated by
   modifying the Timestamp field and the Timer field.

   If the node has an AMT entry for the source node with the same version
   number and the same timestamp, then the Timer field of the AMT entry is
   re-initialized with the value in the Holding Time field.


From Mobile Node in its Home

   If the node has an AMT entry for the source node, the Version field of
   the AMT entry is older than the Source Address Version field of the
   packet header, and the Source VIP Address field and the Source IP
   Address field of the packet header are the same, then the node set the
   Invalid flag in the Flags field of the AMT entry, instead of deleting
   the AMT entry.


5.  Procedures on a Home Router





Teraoka                    Expires: June 1, 1996                  [Page 13]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


5.1.  Procedures upon Control Packet Reception

   When a home router receives a VIPv2 control packet, it examines whether
   it is the home router of the source node of the packet, and whether the
   authentication data is correct.  If both checks succeed, the home router
   updates its AMT as described below.


From Mobile Node Away from its Home

   If the home router does not have an AMT entry for the source node, and
   the source IP address and the source VIP address of the packet header
   are different, then a new AMT entry for the source node is created.
   Each field of the AMT entry is set as follows:

      VIP Address       the VIP Address field of the packet.

      IP Address        the IP Address field of the packet.

      Address Version   the Address Version field of the packet.

      Holding Time      the Holding Time field of the packet.

      Timestamp         the Timestamp field of the packet.

      Timer             the Timestamp field of the packet.


   If the home router has an AMT entry for the source node and the Version
   field of the AMT entry is older than the Source Address Version field of
   the packet header, then the AMT entry is updated by modifying all the
   fields except the VIP address field.  The home router also transmits a
   VIPv2 control packet to the subnet specified by the IP address field of
   the old AMT entry.  This control packet has the same VIPv2 header as the
   received packet.

   If the home router has an AMT entry for the source node with the same
   version number and the Timestamp field of the AMT entry is older than
   the Timestamp field of the packet header, then the AMT entry is updated
   by modifying the Timestamp field and the Timer field.

   If the home router has an AMT entry for the source node with the same
   version number and the same timestamp, then the Timer field of the AMT
   entry is re-initialized with the value in the Holding Time field.

   In any case, when a home router receives a VIPv2 control packet from a
   mobile node it manages, it broadcasts the received control packet in the
   home subnet if the home subnet is a broadcast-type subnet such as an
   Ethernet.





Teraoka                    Expires: June 1, 1996                  [Page 14]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


From Mobile Node in its Home

   If the home router has an AMT entry for the source node, the Version
   field of the AMT entry is older than the Source Address Version field of
   the packet header, and the Source VIP Address field and the Source IP
   Address field of the packet header are the same, then the home router
   set the Invalid flag in the Flags field of the AMT entry, instead of
   deleting the AMT entry.  The home router also transmits a VIP control
   packet to the subnet specified by the IP address field of the old AMT
   entry.  This control packet has the same VIP header as the received
   packet.


5.2.  Procedures on Data Packet Reception

   The Destination IP Address field of the basic IP header contains the VIP
   address of the destination node if the source node does not have an AMT
   entry for the destination node.  This packet reaches the home router of
   the destination node because the home router advertises the routing
   information for the destination node.

   If the home router has an AMT entry for the destination node, it
   executes address resolution and forwards the packet.  In address
   resolution, the following fields in the packet header are modified.

   Destination IP Address        the IP Address field of the AMT entry.

   Destination Address Version   the Address Version field of the AMT
                                 entry.

   If the packet is an IP packet, not a VIP packet, the home router convert
   the IP packet into a VIP packet and forwards it.


6.  Procedures on an Router in the Previous Subnet

   When a mobile node leaves a subnet and enters a new subnet, the home
   router of the mobile node may transmit a VIPv2 control packet to the
   router in the previous subnet.  This router updates its AMT if it has
   the key used for the authentication data in the packet.

   The router also broadcasts the received packet if the subnet is a
   broadcast-type subnet such as an Ethernet.


7.  Procedures on an Intermediate Router

7.1.  Procedures upon Control Packet Forwarding

   When a router forwards a VIPv2 control packet, if it has the key used
   for the authentication data in the packet header, it updates its AMT.



Teraoka                    Expires: June 1, 1996                  [Page 15]


draft-teraoka-mobileip-vip-01.txt                          December 1, 1995


   The router can also use the RSA digital signature included in the data
   part of the control packet to authenticate the mapping information in
   the packet header.  A public key is used to authenticate a digital
   signature.  Since distribution of public keys is easier than that of
   secret keys, digital signature is useful to create AMT entries for
   mobile nodes on intermediate routers for the sake of routing
   optimization and fault tolerance of network partitioning.


7.2.  Procedures upon Data Packet Forwarding

   When a router forwards a VIPv2 data packet, it searches for an AMT entry
   for the destination node.  If it has a valid AMT entry and the Version
   field of the AMT entry is newer than the Destination Address Version
   field of the packet header, the router executes address resolution.

   If the router has an invalid AMT entry and the Version field of the AMT
   entry is equal to or newer than the Destination Address Version field of
   the packet header, it modifies the packet header as follows and then
   forwards it.

      Destination IP Address        the Destination VIP Address of the
                                    header.

      Destination Address Version   0

   At the same time, if the router has the key used for the authentication
   data calculation in the packet, it updates its AMT.


Author's Address

   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. Teraoka, K. Uehara, H. Sunahara, and J. Murai.  VIP: A Protocol
    Providing Host Mobility.  CACM, Vol. 37, No. 8, Aug. 1994.

[2] R. Droms.  Dynamic Host Configuration Protocol.  RFC 1541, October
    1993.








Teraoka                    Expires: June 1, 1996                  [Page 16]