HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:48:40 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 20 Jan 1995 23:00:00 GMT ETag: "3ddad4-6f0c-2f204070" Accept-Ranges: bytes Content-Length: 28428 Connection: close Content-Type: text/plain Internet Engineering Task Force Fumio Teraoka INTERNET DRAFT Sony CSL Keisuke Uehara University of Electro-Comm. 20 January 1995 Options for Mobility Support in IPv6 draft-teraoka-ipv6-mobility-suport-00.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[1]. This protocol is based on the same concept of VIP[2], a protocol for mobility support in IPv4. The basic concept in this memo is to separate identifiers and addresses. A cache mechanism is employed for mapping between an identifier and an address so that most packets travel the optimal route. TCP/UDP communicates with other hosts by specifying the identifiers. Two options are added in the Hop-by-Hop Options Header to support mobility. One option is used for data communication while another for control. Each message has authentication data to prevent impersonation and guarantee the integrity of the mobile option headers. Teraoka Expires: 20 July 1995 [Page 1] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 1. Introduction The basic concept for mobility support in this memo is to separate 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 can also be used as the default address. Two options are added in the Hop-by-Hop Options Header to support mobility. One option is used for data communication while another for control. TCP/UDP specifies a node with the identifier, not with the address. For routing optimization, each node has a cache called Address Mapping Table (AMT). IPv6 resolves the identifier into the address by accessing AMT, and then forwards the packet based on the address. AMT entries are created/updated upon receiving/forwarding a packet with the mobility option after authenticating the packet, ie., AMT entries propagate along the communication path. Since a node creates the AMT entry for the correspondent host once it receives a packet, most packets travel the optimal route. 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[3]. 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. Teraoka Expires: 20 July 1995 [Page 2] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 o home subnet. The subnet indicated by the identifier of a mobile node. o address resolution. A function that maps an identifier to the corresponding address. 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 mobile node notifies its primary resolver(s) of its identifier and the current address when its address changes. A mobile node also periodically notifies the current address to its primary resolver(s). - temporary resolver. An address resolver not connected to the home subnet of a mobile node. A temporary resolver creates/updates its AMT upon receiving/forwarding a packet with the mobile option. 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. 3. Mobility Option Formats There are two options for mobility support in the Hop-by-Hop Options Header of IPv6. The reason why these options are included in the Hop-by-Hop Options Header is to create or update AMT entries on every node along the packet forwarding path. 3.1. Mobility Option for User Data The format of the mobility option for user data is depicted in Figure 1. This option is included in all IPv6 packets carrying an upper layer PDU. Teraoka Expires: 20 July 1995 [Page 3] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=64| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authentication Data | + (keyed MD5) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Mobility option for user data (Hop-by-Hop Option) o Option Type. The value is 0x2?, which means that this option is excluded from integrity computation of the authetication header[4] because the option data may change along the path. o Option Data Length. The length is 64 octets. 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. Teraoka Expires: 20 July 1995 [Page 4] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 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. o Holding Time. A 32-bit number that specifies the time in second a node should keep the AMT entry for the source node of this packet. 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 Authentication Data. The result of keyed MD5 calculation. A 128- bit number that authenticates the source node of this packet and guarantees the integrity of the option data. 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. o Destination Address Version. A 32-bit number that specifies the version of the destination identifier/address pair. 3.2. Mobility Option for Control The format of the mobility option for control is depicted in Figure 2. This option is included only in the control packet. The control packet should not include an upper layer PDU. Teraoka Expires: 20 July 1995 [Page 5] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |OptDataLen=108 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Authentication Data | | (RSA digital signature and/or keyed MD5) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Mobility option for control (Hop-by-Hop option) o Option Type. The value is 0x0?, which means that this option is included in integrity computation. o Option Data Length. The length is 108 octets. o Identifier. A 128-bit number that uniquely identifies the node whose AMT entry should be created/updated. o Address. An IPv6 address of the node whose AMT entry should be created/updated. o Address Version. A 32-bit number that specifies the version of Teraoka Expires: 20 July 1995 [Page 6] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 the Identifier/Address pair. o Holding Time. A 32-bit number that specifies the time in second a node should keep the AMT entry for the node specified by the Identifier field. 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 Authentication Data. RSA digital signature. A 64-octets number that authenticates and guarantees the integrity of the option data. 4. AMT Entry Format Each node should have an Address Mapping Table (AMT) for address resolution. When a packet with the mobility option is received/forwarded, an AMT entry for the node specified by the Source Identifier field (in case of a packet with the mobility option for user data) or the Identifier field (in case of a packet with mobility option for control) is created/update. When a packet is transmitted/forwarded, the destination address is modified if an appropriate AMT entry for the destination node exists. The format of the AMT entry is depicted in Figure 3. Teraoka Expires: 20 July 1995 [Page 7] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | status | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Authentication Data | | (RSA digital signature and/or keyed MD5) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Address mapping table entry format o Status. The flags that show the status of this entry. There are three flags as follows: - invalid: this entry is invalid if this flag is on. The reason why the invalid AMT entry exists is to detect a stale AMT entry on another node. - home: the node that holds this AMT entry is connected to the home subnet of the node specified by this AMT entry. - local: the node specified by this AMT entry is connected to the same subnet if this flag is on. Teraoka Expires: 20 July 1995 [Page 8] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 o Identifier. The key of this entry. o Address. The current address of the node specified by the Identifier field. o Address Version. The address version of the Identifier/Address pair. o Holding Time. The value of this field is periodically decremented. This entry is deleted when the value becomes zero. o Timestamp. The timestamp of the mobility option that created/updated this entry. o Authentication Data. The authentication data of the mobility option that created/updated this entry. 5. Authentication Methods The mobility options use two authentication methods, keyed MD5 and RSA digital signature. Keyed MD5 is used for end-to-end authentication of a packet with the mobility option for user data since it requires to share a secret common key between the authenticating node and the authenticated node. RSA digital signature is used for authentication on intermediate nodes upon forwarding a packet with the mobility option for control. In the mobility option for user data, MD5 calculation covers the following fields: Source Address (in the IPv6 header), Source Identifier, Source Address Version, Holding Time, and Timestamp. The key size is 128 bits. In the mobility option for control, digital signature calculation covers the following fields: Identifier, Address, Address Version, Holding Time, and Timestamp. The key size is 512 bits. Protocols for 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 Address Auto-configuration. Again, the identifier of the mobile node never changes. The mobile node transmits an IPv6 packet with the mobility option for control to its home subnet. Teraoka Expires: 20 July 1995 [Page 9] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 On the path of this packet, AMT entries for the mobile node is created/updated on intermediate nodes as well as the nodes in the home subnet. 6.1. Procedures on a Mobile Node When a mobile node is connected to a subnet, it transmits an IPv6 packet with the mobility option for control to its home subnet. This packet should not include an upper layer PDU. Each field is assigned as follows: o Identifier: the identifier of the mobile node. o Address: the temporary IPv6 address of the interface to be used. o Address Version: the version number of the temporary IPv6 address/identifier pair. o Holding Time: the time in second for which the AMT entry for this mobile node should be kept. o Timestamp: the current time at which this packet is transmitted. o Authentication Data: RSA digital signature which covers the above five fields. 6.2. Procedures on an Intermediate Node When an intermediate node receives a packet with the mobility option for control, it may execute the following procedures before/after forwarding the packet. 1. Authentication: the intermediate node authenticates the packet if it has the public key of the mobile node specified by the Identifier field of the mobility 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 mobility 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 of the mobility option is newer (larger) than that of the AMT entry. In case that an obsolete AMT entry exists, the intermediate node Teraoka Expires: 20 July 1995 [Page 10] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 may broadcast the received packet to all interfaces it has. 6.3. Procedures on a Boundary Node of the Home Subnet When a packet with the mobility option for control is received, a boundary node of the home subnet of the mobile node specified by the Identifier field of the option executes the authentication procedure and the AMT modification procedure described above, and then broadcasts the packet within the home subnet if it is a broadcast-type subnet. If the boundary node had an obsolete AMT entry, it also transmits the packet to the address specified by the Address field of the obsolete AMT entry. 7. Data Communication In data communication, the mobility option for user data is included in every IPv6 packet. 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 node 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 mobility option for user data. In the option, the fields related to the source node (Source Identifier, Source Address Version, Holding Time, and Timestamp) are filled with appropriate values, and then authentication data is calculated and assigned to the Authentication Data field. A transmission request from the upper layer specifies the destination node with the identifier, not the address. This destination identifier is assigned to the Destination Identifier field. The source node attempts to resolve the destination identifier into the address by accessing the AMT. If the AMT entry for the destination node exists, the address and the address version in the entry are assigned to the Destination Address field of the IPv6 header and the Destination Address Version field of the 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. Teraoka Expires: 20 July 1995 [Page 11] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 7.2. Procedures on an Intermediate Node There are two procedures on an intermediate node upon forwarding a packet with the mobility option for user data, AMT modification and address resolution. In AMT modification, the AMT entry for the mobile node specified by the Source Identifier field of the option may be created/modified. First, the intermediate node authenticates the packet if it has the common key of the source node. If the authentication succeeded, the following procedures are executed. If an AMT entry for the mobile node specified by the Source Identifier field of the option does not exist, it is created. If there is an AMT entry holding obsolete information, it is modified in accordance with the values in the option. In address resolution, the Destination Address in the IPv6 header and the Destination Address Version field of the option may be modified. If the AMT entry for the destination node of the packet exists, the Destination Address Version field of the packet 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 option are modified in accordance with the entry. Note that the information related to the source node of the packet is used in the AMT modification procedure while the information related to the destination node of the packet is used/modified in the address resolution procedure. 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 o Keisuke Uehara University of Electro-Communications. Teraoka Expires: 20 July 1995 [Page 12] draft-teraoka-ipv6-mobility-suport-00.txt 20 January 1995 1-5-1 Chofugaoka, Chofu, Tokyo 182, Japan. Phone: +81-424-83-2161, ext. 4122 Email: kei@cs.uec.ac.jp References [1] S. Deering. "Simple Internet Protocol Plus (SIPP) Specification (128-bit address version)," Internet-Draft draft-ietf-sipp-spec- 01.txt, Jul. 1994. [2] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai. "VIP: A Protocol Providing Host Mobility," in CACM, Vol. 37, No. 8, Aug. 1994. [3] P. Francis, S. Deering, R. Hinden, and R. Govindan. "Simple Internet Protocol Plus (SIPP): Addressing Architecture," Internet- Draft draft-ietf-sipp-routing-addr-02.txt, Jul. 1994. [4] R. Atkinson. "IPv6 Authentication Header," Internet-Draft draft- ietf-sipp-ap-04.txt, Aug. 1994. Teraoka Expires: 20 July 1995 [Page 13]