Internet Engineering Task Force Fumio Teraoka INTERNET DRAFT Sony CSL 29 June 1995 Options for Mobility Support in IPv6 draft-teraoka-ipv6-mobility-sup-01.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes a protocol for mobility support in IPv6. This protocol is based on the same concept of VIP, a protocol for mobility support in IPv4. The basic concept is separation of identifiers and addresses. TCP/UDP uses the identifier. The identifier is mapped to an address, and then the packet is routed in accordance with the address. End nodes as well as intermediate routers can have authentic mapping information for routing optimization and fault tolerance. Since the source address field in the IPv6 header indicates the actual address of the source node, there is no problem on source address spoofing. 1. Introduction A mobility support protocol in IPv4 (Mobile-IP) is under development in IETF. For compatibility with the existing Internet, Mobile-IP makes use of a technique called tunneling to forward packets to mobile nodes. However, tunneling has several problems in terms of network architecture as well as network management. Since mobility support is a requirement for IPv6[1], it must be designed with careful consideration of network Teraoka Expires: 29 December 1995 [Page 1] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 architecture. This memo describes a protocol for mobility support in IPv6[2]. This protocol is based on the same concept of VIP[3], a protocol for mobility support in IPv4. The basic concept is separation of identifiers and addresses. Both the identifier and the address have the same format. The identifier of a mobile node never changes no matter where it moves. The address of a mobile node specifies the point of attachment to the Internet. The address is used only for packet routing, not for identifying the node. The identifier of a mobile node is the address in its `home subnet' so that it can also be used as the default address of the mobile node. TCP/UDP specifies a node with the identifier, not with the address. For routing optimization and fault tolerance of network partitioning, each node can have a cache called Address Mapping Table (AMT). AMT entries can be created or updated upon receiving or forwarding packets transmitted by mobile nodes. This protocol introduces five new options to support mobility: `source ID', `registration request', and `registration acknowledgment' options as destination options, and `destination ID' and `mapping information' options as hop-by-hop-options. 2. Terminology This memo uses the following terms: o node. The general term for both a host and a router. o mobile node. A node that changes the point of attachment to the Internet. o address. A number that specifies the point of attachment to the Internet. An address is assigned to each network interface of a node. In IPv6, a 128-bit number is used as the address[4]. The address of an interface changes when the node moves to another subnet. The node must obtain an address by some method when it is connected to a subnet. o identifier. A number that uniquely identifies a node. Each node has one identifier regardless of the number of network interfaces it has. The identifier is immutable no matter where the node is connected in the Internet. The identifier has the same format of the address and can be used as the default address of the node. o home subnet. The subnet indicated by the identifier of a mobile node. o address resolution. A function that maps an identifier to the Teraoka Expires: 29 December 1995 [Page 2] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 address. o address mapping table (AMT): A table that consists of entries, each of which holds the mapping information between an identifier and an address. Each node should have an AMT for address resolution and fault tolerance of network partitioning. o address resolver. A node that performs address resolution. There are two types of address resolvers for a mobile node: - primary resolver. An address resolver connected to the home subnet of a mobile node. A primary resolver advertizes routing information of the home subnet. A mobile node notifies its primary resolver(s) of its identifier and the current address when its address changes. A primary resolver may be a router connected to the home subnet. A primary resolver may also be a host that has a `pseudo' network interface connected to the `pseudo' home subnet. - cache resolver. An address resolver not connected to the home subnet of a mobile node. A cache resolver creates or updates its AMT upon forwarding a packet with the mapping information option or upon receiving a packet with the source ID option. 3. Formats This protocol introduces the `source ID' option as a destination option and the `destination ID' option as a hop-by-hop option for a packet carrying an upper layer PDU. The `registration request' and `registration acknowledgment' options are introduced as destination options for a mobile node to register its current address with its primary resolver(s). The `mapping information' option as a hop-by-hop option is also used with the registration request option. The reason why the registration request packet has the mapping information option as a hop-by-hop option is to create or update AMT entries on every node along the packet forwarding path. 3.1. Data Packet Format The entire format of a packet carrying an upper layer PDU is depicted in Figure 1. The packet consists of the IPv6 Header, the Hop-by-Hop Options Header, the Authentication Header, the Destination Options Header, and an upper layer PDU. Teraoka Expires: 29 December 1995 [Page 3] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Options Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Options Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Layer Header and User Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IPv6 packet carrying an upper layer PDU 3.1.1. Destination ID Option Format The destination ID option as a hop-by-hop option specifies the identifier of the final destination node of a packet. It also specifies the version number of the identifier/address pair of the final destination node. This option is examined on every node along the forwarding path for address resolution of the final destination node, i.e., the Destination Address field of the IPv6 Header will be modified on the router that has newer mapping information for the final destination node. The format of the destination ID option is depicted in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=20| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: destination ID option (hop-by-hop option) o Option Type. The value is 0x2?, which indicates that this option is excluded from integrity assurance computation of the Authentication Header[5]. o Option Data Length. The length is 20 octets. Teraoka Expires: 29 December 1995 [Page 4] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 o Destination Address Version. A 32-bit number that specifies the version of the destination identifier/address pair. The value in this field changes when address resolution occurs along the forwarding path. o Destination Identifier. A 128-bit number that uniquely identifies the final destination node regardless of the location, ie., regardless of the Destination Address in the IPv6 Header. 3.1.2. Source ID Option Format The source ID option as a destination option specifies the identifier of the source node of a packet. It also specifies the version number of the identifier/address pair of the source node. It is examined only on the final destination node. This option with the Authentication Header allows the destination node to create or update an authentic AMT entry for the source node. The format of the source ID option is depicted in Figure 3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: source ID option (destination option) o Option Type. The value is 0x0?, which indicates that this option is included in integrity assurance computation of the Authentication Header. o Option Data Length. The length is 28 octets. o Source Address Version. A 32-bit number that specifies the version of the source identifier/address pair. This number must be incremented monotonously when a new address is assigned. Teraoka Expires: 29 December 1995 [Page 5] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 o Timestamp. A 32-bit number that specifies the time in second when the source node transmits this packet. This field is used to prevent replay attack. o Holding Time. A 32-bit number that specifies the time in second for which a node should keep the AMT entry for the source node of this packet. o Source Identifier. A 128-bit number that uniquely identifies the source node regardless of the location, ie., regardless of the Source Address in the IPv6 Header. 3.2. Registration Request Packet Format The entire format of a registration request packet is depicted in Figure 4. A registration request packet consists of the IPv6 Header, the Hop- by-Hop Options Header, and the Destination Options Header. It may have the Authentication Header. The registration request packet should not have an upper layer PDU. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Options Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Options Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Registration request packet format 3.2.1. Mapping Information Option Format The mapping information option as a hop-by-hop option specifies an authentic identifier/address pair and its holding time. This option allows a forwarding node to create or update the authentic AMT entry on the node. The format of the mapping information option is depicted in Figure 5. Teraoka Expires: 29 December 1995 [Page 6] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |OptData Len=108| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data | | (RSA digital signature: 64 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: mapping information option (hop-by-hop option) o Option Type. The value is 0x0?, which indicates that this option is included in integrity assurance computation of the Authentication Header. o Option Data Length. The length is 108 octets. o Address Version. A 32-bit number that specifies the version of the identifier/address pair. o Timestamp. A 32-bit number that specifies the time in second when the source node transmits this packet. This field is used to prevent replay attack. o Holding Time. A 32-bit number that specifies the time in second for which a node should keep the AMT entry for the node specified by the Identifier field. Teraoka Expires: 29 December 1995 [Page 7] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 o Identifier. A 128-bit number that uniquely identifies the node whose AMT entry should be created or updated. o Address. An IPv6 address of the node whose AMT entry should be created or updated. o Authentication Data. RSA digital signature. A 64-octets number that authenticates and guarantees the integrity of the option data. 3.2.2. Registration Request Option Format The registration request option indicates some control information upon registration of the current location of a mobile node. This option is examined only on the final destination node, i.e., the primary resolver of the mobile node transmitting the registration request packet. The format of the registration request option is depicted in Figure 6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len= 4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Registration request option in the Destination Options Header o Option Type. The value is 0x0?, which indicates that this option is included in integrity assurance computation of the Authentication Header. o Flags. Currently, only one flag `A' is defined. If `A' flag is set in the registration request packet, the registration acknowledgment packet must be returned. 3.3. Registration Acknowledgment Packet The entire format of a registration acknowledgment packet is depicted in Figure 7. A registration acknowledgment packet consists of the IPv6 Header, the Authentication Header, and the Destination Options Header. The registration acknowledgment packet should not have an upper layer PDU. Teraoka Expires: 29 December 1995 [Page 8] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Options Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Registration acknowledgment packet format 3.3.1. Registration Acknowledgment Option Format The registration acknowledgment option as a destination option indicates the identifier and the identifier/address version number to be acknowledged for registration. This option is examined only on the final destination node, i.e., the mobile node that transmitted the registration request packet. The format of the registration acknowledgment option is depicted in Figure 8. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=20| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: registration acknowledgment option (destination option) o Option Type. The value is 0x0?, which indicates that this option is included in integrity assurance computation. o Address Version. The address version in the registration request packet. o Identifier. The Identifier in the registration request packet. 4. AMT Entry Format Each node should have an Address Mapping Table (AMT) for address Teraoka Expires: 29 December 1995 [Page 9] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 resolution and fault tolerance of network partitioning. When a node receives a packet with the source ID option, it creates or updates the AMT entry for the node specified by the Source Identifier field of the source ID option. When a node receives or forwards a packet with the mapping information option, it creates or updates the AMT entry for the node specified by the Identifier field of the mapping information option. If a node has an appropriate AMT entry, it executes address resolution for the destination address when it transmits or forwards a packet. The format of the AMT entry is depicted in Figure 9. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | status | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Address mapping table entry format o Status. Flags that show the status of this entry. There are three flags as follows: - invalid: if this flag is set, this entry is invalid. The reason why an invalid AMT entry exists is to detect a stale AMT entry for another node. - home: if this flag is set, the node that holds this AMT entry is connected to the home subnet of the node specified by this AMT entry. Teraoka Expires: 29 December 1995 [Page 10] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 - local: if this flag is set, the node specified by this AMT entry is connected to the same subnet. o Address Version. The address version of the identifier/address pair. o Timestamp. The timestamp of the source ID option or the mapping information option that created or updated this entry. o Holding Time. The value of this field is periodically decremented. This entry is deleted when the value becomes zero. o Identifier. The key of this entry. o Address. The current address of the node specified by the Identifier field. 5. Authentication A packet carrying an upper layer PDU has the Authentication Header to guarantee the integrity of the packet. The source ID option is included in integrity assurance computation. A node receiving a packet with the source ID option can authenticate the source node and create an authentic AMT entry for the source node. The algorithm used in the Authentication Header is beyond the scope of this memo. The registration request packet has the mapping information option. Since the mapping information option includes RSA digital signature as authentication data, forwarding nodes as well as the destination node of a registration request packet can authenticate the mapping information and create an authentic AMT entry. The following fields are included in calculation of authentication data in the mapping information option: Address Version, Timestamp, Holding Time, Identifier, and Address. The key is 512 bits in length. Protocols for public key distribution is beyond the scope of this memo. 6. Connecting to a Subnet When a mobile node is connected to a subnet, it obtains a temporary IPv6 address in the subnet by some means such as Address Auto-configuration. Again, the identifier of the mobile node never changes. The mobile node transmits a registration request packet to the anycast address specifying its home subnet. On the forwarding path of this packet, authentic AMT entries for the mobile node is created or updated on intermediate nodes as well as the primary resolver(s) in the home subnet. Teraoka Expires: 29 December 1995 [Page 11] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 6.1. Procedures on a Mobile Node The registration request packet has the mapping information option in the Hop-by-Hop Options Header and the registration request option in the Destination Options Header. Each field of the mapping information option is set as follows: o Address Version: the version number of the pair of the temporary IPv6 address and the identifier. o Timestamp: the current time at which this packet is transmitted. o Holding Time: the time in second for which the AMT entry for this mobile node should be kept. o Identifier: the identifier of the mobile node. o Address: the temporary IPv6 address of the interface to be used. o Authentication Data: RSA digital signature which covers the above five fields. The mobile node may set the `A' flag in the Flags field of the registration request option in the registration request packet if it wants to receive the registration acknowledgment packet from its primary resolver. The mobile node retransmits the registration request packet if the waiting timer of the registration acknowledgment packet expires. The mobile node specifies the holding time of the AMT entry by the Holding Time field in the mapping information option in the registration request packet. To refresh the AMT entry on the primary resolver, the mobile node periodically transmits the registration request packet in a certain interval of time, e.g., half of the holding time. 6.2. Procedures on an Intermediate Node When an intermediate node forwards the registration request packet, it may execute the following procedures. 1. Authentication: the intermediate node authenticates the mapping information option if it has the public key of the mobile node specified by the Identifier field of the option. If the authentication succeeded, AMT modification is executed. 2. AMT modification: the intermediate node creates an AMT entry for the mobile node specified by the Identifier field of the mapping information option if it does not have the entry for the mobile node, or it updates the existing AMT entry if it has an obsolete AMT entry, ie., the Address Version in the mapping information option is newer (larger) than that of the AMT entry. Teraoka Expires: 29 December 1995 [Page 12] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 When an intermediate node has an obsolete AMT entry exists, it may broadcast the received packet to all the interfaces it has. This broadcast stops at the node that does not have a related AMT entry. 6.3. Procedures on a Primary Resolver in the Home Subnet When a primary resolver in the home subnet receives the registration request packet, it executes the authentication procedure and the AMT modification procedure described above, and then broadcasts this registration request packet within the home subnet if the subnet is of broadcast-type. If the primary resolver had an obsolete AMT entry, it also transmits this registration request packet to the address specified by the Address field of the obsolete AMT entry. If the `A' flag is set in the Flags field of the registration request option, the primary resolver returns the registration acknowledgment packet to the mobile node. Each field of the registration acknowledgment option in the registration acknowledgment packet is set as follows: o Address Version: the value in the Address Version field of the mapping information option in the related registration request packet. o Identification: the value in the Identifier field of the mapping information option in the related registration request packet. The Destination Address field of the IPv6 Header is assigned the value in the Address field of the mapping information option in the related registration request packet. 7. Data Communication TCP/UDP specifies the destination node with the identifier. Address resolution for the destination node is executed on the source node, an intermediate node, or a primary resolver in the home subnet of the destination node, and then the packet is routed to the destination node. 7.1. Procedures on the Source Node The source node creates an IPv6 packet with the destination ID option, the source ID option, and the Authentication Header. A transmission request from the TCP/UDP layer specifies the destination node with the identifier, not the address. This destination identifier is assigned to the Identifier field of the Destination ID option. The source node attempts to resolve the destination identifier into an address by accessing the AMT. If the AMT entry for the destination node Teraoka Expires: 29 December 1995 [Page 13] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 exists, the values in the Address field and the Address Version field of the entry are assigned to the Destination Address field of the IPv6 Header and the Destination Address Version field of the Destination ID option, respectively. If not, the Destination Address field of the IPv6 Header is also assigned the identifier of the destination node, and the Destination Address Version field is assigned zero. The fields in the source ID option (Source Identifier, Source Address Version, Holding Time, and Timestamp) are filled with appropriate values, and then integrity computation of the Authentication Header is executed. 7.2. Procedures on an Intermediate Node An intermediate node may execute address resolution upon forwarding a packet with the Destination ID option. In address resolution, the Destination Address field in the IPv6 Header and the Destination Address Version field of the Destination ID option will be modified. If the AMT entry for the destination node of the packet exists, the Destination Address Version field of the Destination ID option is compared with the Address Version field of the entry. If the entry has newer information, the Destination Address field of the IPv6 Header and the Destination Address Version field of the Destination ID option are modified in accordance with the entry. 7.3. Procedures on the Destination Node The destination node executes the AMT modification procedure described above, and then it notifies the upper layer of the receipt of a packet with the identifier of the source node, not the address. Author's Address: o Fumio Teraoka Sony Computer Science Laboratory Inc. 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141, Japan. Phone: +81-3-5448-4380 Email: tera@csl.sony.co.jp References [1] F. Kastenholz and C. Partridge. Technical Criteria for Choosing IP:The Next Generation (IPng). RFC 1726, December 1994. [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet-Draft draft-ietf-ipngwg-ipv6-spec-02.txt, June 1995. [3] F. Teraoka, K. Uehara, H. Sunahara, and J. Murai. VIP: A Protocol Teraoka Expires: 29 December 1995 [Page 14] draft-teraoka-ipv6-mobility-sup-01.txt 29 June 1995 Providing Host Mobility. in CACM, Vol. 37, No. 8, Aug. 1994. [4] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. Internet-Draft draft-ietf-ipngwg-addr-arch-03.txt, June 1995. [5] R. Atkinson. IPv6 Authentication Header. Internet-Draft draft-ietf- ipngwg-auth-00.txt, February 1995. Teraoka Expires: 29 December 1995 [Page 15]