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]