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]