Internet Engineering Task Force Fumio Teraoka INTERNET DRAFT Sony CSL 15 April 1996 Mobility Support in IPv6 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 (home addresses) and addresses (temporary 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: 15 October 1996 [Page 1] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 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 (home addresses) and addresses (temporary 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 three new destination options to support mobility: `source ID', `source ID for authentication', and `destination ID'. 2. Terminology This memo uses the following terms: node: The general term for both a host and a router. mobile node (MN): A node that changes the point of attachment to the Internet. stationary node (SN): A node that does not changes the point of attachment to the Internet. A stationary node also understands the mobility support protocol. correspondent node (CN): A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary. identifier: Teraoka Expires: 15 October 1996 [Page 2] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 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 to the Internet. The identifier has the same format of the address and can be used as the default address of the node. home address: The identifier of a node can be thought of as the `home address', according to the document[5]. 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. temporary address: Since the address of a node changes when the node moves to another subnet, an address can be called a `temporary address' of a node. A temporary address is similar to a care-of address in the document[5]. home subnet: The subnet indicated by the identifier (home address) of a mobile node. address resolution: A function that maps an identifier (home address) to the address (temporary 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. correspondent node list (CNL): A list that consists of entries, each of which holds the ID (Home Address) of a CN. A CNL on a MN includes entries for CNs that have the AMT entry for the MN, that is, when a MN receives a packet with the Destination ID option defined in this document from a CN, the MN adds an entry for the CN to its CNL. Teraoka Expires: 15 October 1996 [Page 3] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 primary address resolver (PAR): An address resolver is a node that performs address resolution. 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 advertises 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. home agent (HA): The primary address resolver is similar to the home agent (HA) in the document[5]. 3. Protocol Overview The protocol defined in this document has two types of packet formats: the data packet and the control packet (AMT update packet). The data packet is used to carry an upper layer PDU, while the AMT update packet is used to update an AMT on the correspondent node when a MN moves to another subnet. When a MN moves to a subnet, it obtains a temporary address by some method such as DHCPv6[6], while its identifier (home address) remains unchanged. The MN transmits an AMT update packet to its Primary Address Resolver (home agent). Since the AMT update packet has the Authentication Header, the Primary Address Resolver can have an authentic AMT entry for the MN. When a CN not having an AMT entry for a MN transmits a packet, the packet reaches the home agent of the MN, and then the packet is forwarded to the temporary address of the MN by tunneling. A packet transmitted by the MN contains MN's temporary address and the identifier (home address) in the IPv6 base header and the Source ID option in the Destination Options Header, respectively. If the CNL (Correspondent Nodes List) of the MN does not have an entry for the CN, the MN also adds the Authentication Header to create an authentic AMT entry on the CN. If the CNL of the MN has the entry for the CN, the MN may use a packet without the Authentication Header to reduce processing overhead due to authentication. Once the CN has an AMT entry for the MN, it sets the temporary address of the MN in the IPv6 base header and adds the Destination ID option in the Destination Options header to specify the identifier (home address) of the MN. Therefore, this packet is forwarded to the MN on the optimal route. When the MN receives this packet, the MN adds an entry for the Teraoka Expires: 15 October 1996 [Page 4] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 CN to its CNL since the MN knows that the CN has the AMT entry for the MN. When the MN moves again, it transmits an AMT update packet to each CN in its CNL as well as its Home Agent. 4. Option Formats This protocol introduces the `Source ID' option, the `Source ID for Authentication' (`Source ID-A', in short) option, and the `Destination ID' option as destination options. 4.1. Destination ID Option Format The destination ID option specifies the identifier (home address) of the final destination node of a packet. The format of the destination ID option is depicted in Figure 1. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Destination ID option (destination option) Option Type: The value is 0x0?, which indicates that this option is included in integrity assurance computation of the Authentication Header[7]. Option Data Length: The length is 16 octets. 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 base header. Teraoka Expires: 15 October 1996 [Page 5] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 4.2. Source ID Option Format The source ID option specifies the identifier (home address) of the source node of a packet. The format of the source ID option is depicted in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: source ID 1 option (destination 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 16 octets. 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. 4.3. Source ID for Authentication (Source ID-A) Option Format The source ID-A option specifies the identifier (home address) 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. Teraoka Expires: 15 October 1996 [Page 6] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Opt Data Len=28| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: source ID-A option (destination 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. 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 Teraoka Expires: 15 October 1996 [Page 7] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 regardless of the location, ie., regardless of the Source Address in the IPv6 Header. 5. Packet Formats There are two packet types: the data packet and the control packet (AMT update packet). The data packet is used to carry an upper layer PDU. The AMT update packet is used to update the AMT entry for the source node on the destination node. 5.1. Data Packet Formats The formats of the data packet are depicted in Figure 4. There are four types of header formats. Figure 1-(a) depicts the general format, which consists of the IPv6 Header, the Destination Options Header consisting of the Source ID-A option and the Destination ID option, the Authentication Header, and an upper layer PDU. A CN receiving this packet can authenticate the source MN and create an authentic AMT entry for the MN. The packet depicted in Figure 1-(b) is used when a SN (stationary node) knows the temporary address of the destination MN. The Source ID option is not included in this format because the address of a SN is equal to its identifier (home address). The Destination ID option is included to specify the identifier (home address) of the destination node. If the source SN does not know the temporary address of the destination node, the Destination Address field of the base header is assigned the identifier (home address) of the destination node, and the Destination Options Header is omitted. The packet depicted in Figure 1-(c) is used when a source MN does not know the temporary address of the destination node. The Source ID Option is included in this format to specify the ID of the source MN. The temporary address of the source MN is included in the base header. The packet depicted in Figure 1-(d) is used when the source MN knows the temporary address of the destination MN. The temporary addresses of the source and the destination nodes are set in the base header, while their identifiers are set in the Destination Options Header by using the Source ID Option and the Destination ID Option, respectively. Teraoka Expires: 15 October 1996 [Page 8] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 +----------------------------+ +----------------------------+ | IPv6 Header | | IPv6 Header | +----------------------------+ +----------------------------+ | Destination Options Header | | Destination Options Header | | | | | | | +============================+ +----------------------------+ | Transport Layer Header | | Authentication Header | | and | +============================+ | User Data | | Transport Layer Header | +----------------------------+ | and | (b) from a SN to a MN | User Data | +----------------------------+ (a) general packet format +----------------------------+ +----------------------------+ | IPv6 Header | | IPv6 Header | +----------------------------+ +----------------------------+ | Destination Options Header | | Destination Options Header | | | | | +============================+ | | | Transport Layer Header | +============================+ | and | | Transport Layer Header | | User Data | | and | +----------------------------+ | User Data | (c) from a MN to a SN +----------------------------+ (d) from a NM to a NM Figure 4: Data packet formats 5.2. AMT Update Packet Formats Figure 5 depicts the AMT update packet formats. The AMT update packet has the Source ID-A (Source ID for Authentication) Option in the Destination Options Header and the Authentication Header. The temporary address of the source MN is included in the base header, while its identifier (home address) is included in the Source ID-A Option. The Authentication Header is used to authenticate the source MN and to guarantee the integrity of this packet. There are two format types. The packet depicted in Figure 5-(a) is used when a source MN does not know the temporary address of the destination node. The packet depicted in Figure 5-(b) is used when a source MN knows the temporary address of the destination node. Teraoka Expires: 15 October 1996 [Page 9] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 +----------------------------+ +----------------------------+ | IPv6 Header | | IPv6 Header | +----------------------------+ +----------------------------+ | Destination Options Header | | Destination Options Header | | | | | +----------------------------+ | | | Authentication Header | +----------------------------+ +----------------------------+ | Authentication Header | (a) from a MN to its HA +----------------------------+ (b) from a MN to a MN Figure 5: AMT update packet formats 6. 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-A option, it creates or updates the AMT entry for the node specified by the Source Identifier field of the source ID-A option. When a node transmits a packet, it executes address resolution (i.e., the source node can use the packet depicted in Figure-(b) or (d)) if it has an AMT entry for the destination node. A typical format of the AMT entry is depicted in Figure 6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Address mapping table entry format Teraoka Expires: 15 October 1996 [Page 10] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 Address Version: The address version of the identifier/address pair. Timestamp: 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. (the home address) Address: The current address of the node specified by the Identifier field. 7. CNL Entry Format Each MN has a CNL (correspondent node list) to cache the identifier (home address) of CNs that have the AMT entry for the MN. If the destination node is included in the CNL, the MN uses the packet depicted in Figure 1-(c), that is, authentication procedures are omitted both on the source and destination node. A typical format of a CNL entry is depicted in Figure 7. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Identifier + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Correspondent node list entry format Identifier Teraoka Expires: 15 October 1996 [Page 11] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 The identifier (home address) of the CN. Holding Time The value of this field is periodically decremented. This CNL entry is deleted when the value becomes zero. 8. Procedures in Connecting to a Subnet When a MN connects to a subnet, it obtains a temporary address by some method such as DHCPv6[6] and increments its address version. Again, the identifier (home address) of the MN remains unchanged. 8.1. Procedures on a MN The MN transmits an AMT update packet depicted in Figure 5-(a) to its home agent. The fields in the IPv6 base header are set as follows: Source Address The temporary address of the MN. Destination Address The address of MN's home agent. The fields in the Source ID-A option are set as follows: Source Address Version The version number that specifies the version of the MN's identifier (home address)/temporary address pair. When a MN obtains a new temporary address, it increments its address version. Timestamp The time in second at which the MN transmits this packet. This field is used to prevent replay attack. Holding Time The time in second for which MN's home agent should keep the AMT entry for the MN. Source Identifier The identifier (home address) of the MN. Teraoka Expires: 15 October 1996 [Page 12] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 Next, the MN transmits an AMT update packet to each CN listed in its CNL. The packet depicted in Figure 5-(a) is used if an AMT entry for the destination CN does not exist. If the AMT entry exists, the packet depicted in Figure 5-(b) is used. 8.2. Procedures on Receiving an AMT Update Packet First, when a home agent or a CN receives an AMT update packet, it authenticates the packet. If authentication failed, the packet is discarded. Next, the receiving node searches its AMT for the entry for the source MN. A new entry is created if an AMT entry for the MN does not exist. When the AMT entry exists, the Source Address Version field of the AMT update packet is compared with the Address Version field of the AMT entry. The existing AMT entry is modified if the AMT update packet has newer information than the AMT entry. When an AMT entry is created or updated, each field is set as follows: Address Version The value in the Source Address Version field of the Source ID-A option in the AMT update packet. Timestamp The value in the Timestamp field of the Source ID-A option in the AMT update packet. Holding Time The value in the Holding Time field of the Source ID-A option in the AMT update packet. Identifier The value in the Source Identifier field of the Source ID-A option in the AMT update packet. Address The value in the Source Address field of the IPv6 base header in the AMT update packet. If the AMT entry exists and the Source Address Version field of the Source ID-A option is equal to the Address Version field of the AMT entry, only the Timestamp field and the Holding Time field of the AMT entry are updated. Teraoka Expires: 15 October 1996 [Page 13] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 9. Procedures in Data Communication The home agent of a MN advertises the routing information for the home addresses of MNs it manages. Assume that the home agent of a MN has the AMT entry for the MN. 9.1. From a CN to a MN If the source CN does not have an AMT entry for the destination MN, only the IPv6 base header is used. The identifier (home address) of the MN is set in the Destination Address field. This packet reaches the home agent of the MN. The home agent encapsulates the packet and forwards it to the MN. The temporary address of the MN is assigned to the Destination Address field of the outer header. If a CN has the AMT entry for the destination MN, the packet depicted in Figure 4-(b) is used. The temporary address of the MN is assigned to the Destination Address field of the IPv6 base header. The identifier (home address) of the MN is included in the Destination ID option. This packet is forwarded through the optimal route to the MN. When the MN receives this packet, an entry for the source CN is added to the CNL on the MN. 9.2. From a MN to a CN If the source MN does not have a CNL entry for the destination CN, the packet depicted in Figure 4-(a) is used. The temporary address of the MN is assigned to the Source Address field of the IPv6 base header. The Source ID-A option includes the identifier (home address) of the MN and data for authentication. If the MN holds the AMT entry for the CN, the temporary address of the CN is assigned to the Destination Address field of the IPv6 base header and the identifier (home address) of the CN is included in the Destination ID option. If the MN does not have an AMT entry for the CN, the Destination ID option is omitted. The Authentication Header guarantees authenticity of the MN and integrity of the packet. When the CN receives this packet, an authentic AMT entry for the MN is created or updated. If the source MN has the CNL entry for the destination CN, the packet depicted in Figure 4-(b) or (d) is used. If the MN does not have an AMT entry for the CN, (b) is used. If the MN has the AMT entry for the CN, (d) is used. Note that the Authentication Header is usually omitted in data communication. Once a CN creates the AMT entry for a MN, the CN uses the packet depicted in Figure 4-(b) or (d). The MN learns that the CN has the correct AMT entry when the MN receives such a packet. Teraoka Expires: 15 October 1996 [Page 14] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 10. Timer Driven Procedures The value in the Holding Time field of an AMT entry is decremented every second. The entry is deleted when the value reaches zero. The value in the Holding Time field of an CNL entry is also decremented every second. The entry is deleted when the value reaches zero. 11. Consideration on draft-ietf-mobileip-ipv6-00.txt In draft-ietf-mobileip-ipv6-00.txt, a MN usually transmits a packet depicted in Figure 8. Figure 8-(a) is used if the MN does not have a binding cache for the CN. Figure 8-(b) is used if the MN has the binding cache for the CN. +-------------------------+ +----------------------------+ | | | | | SrcAddr: MN's home addr | | SrcAddr: MN's home addr | | DstAddr: CN's addr | | DstAddr: CN's Care-of addr | +=========================+ +----------------------------+ | | | | | data | | CN's home addr | | | +============================+ +-------------------------+ | | (a) | data | | | +----------------------------+ (b) Figure 8. Packet formats in draft-ietf-mobileip-ipv6-00.txt One of the most important problems of draft-ietf-mobileip-ipv6-00.txt is that the value in the Source Address field of the IPv6 base header does not specify MN's correct location in the internet when the MN is away from its home subnet. This causes the following problems: - The MN cannot transmits multicast packets if reverse path forwarding is used for multicast routing. Since reverse path forwarding uses the source address for packet forwarding, the source address must specify the correct location of the source node. - Firewalls that filter packets with illegal source address might discard packets transmitted by a MN. Consider that a MN is visiting a foreign site and transmits a packet to its home site. A firewall at the foreign site sees an outgoing packet with a source address specifying the outside. The firewall might discard Teraoka Expires: 15 October 1996 [Page 15] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 the packet. Even if this packet passes the firewall at the foreign site, since a firewall at the home site sees an incoming packet with a source address specifying the inside, the firewall must discard the packet. In the protocol described in this document, the Source Address field of the IPv6 base header specifies the correct location of the source node. Therefore, the protocol in this document basically does not have these problems. One of the authors of draft-ietf-mobileip-ipv6-00.txt says that a manager might configure a firewall to discard packets with options described in this documents. However, it is sophistic. In draft-ietf-mobileip-ipv6- 00.txt, a firewall cannot distinguish a packet transmitted by a MN from a packet from an attacker using source routing. In the protocol described in this document, a firewall can distinguish a packet transmitted by a MN and know the correct location of the source node. If the Authentication Header is added, a firewall can authenticate the identifier (home address) and the current address of the sender. Thus, the basic problem in draft-ietf-mobileip-ipv6-00.txt comes from abuse of mechanisms designed not for position independent communication. 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-15.txt, February 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] C. Perkins and D. Johnson. Mobility Support in IPv6. Internet-Draft draft-ietf-mobileip-ipv6-00.txt, January 1996. [6] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet-draft draft-ietf-dhc-dhcpv6-04.txt, February 1996. Teraoka Expires: 15 October 1996 [Page 16] draft-teraoka-ipv6-mobility-sup-03.txt 15 April 1996 [7] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. Teraoka Expires: 15 October 1996 [Page 17]