Internet DRAFT - draft-teraoka-ipv6-mobility-support
draft-teraoka-ipv6-mobility-support
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 11:48:42 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 20 Jan 1995 23:00:00 GMT
ETag: "3ddad5-6f0f-2f204070"
Accept-Ranges: bytes
Content-Length: 28431
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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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-support-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]
