[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 01 02 03 04
Internet Engineering Task Force Fumio Teraoka
INTERNET DRAFT Sony CSL
15 April 1996
Mobility Support in IPv6
<draft-teraoka-ipv6-mobility-sup-03.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 (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 |
| <Source ID-A Option> | | <Destination ID Option> |
| <Destination ID Option> | +============================+
+----------------------------+ | 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 |
| <Source ID Option> | | <Source ID Option> |
+============================+ | <Destination ID Option> |
| 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 |
| <Source ID-A Option> | | <Source ID-A Option> |
+----------------------------+ | <Destination ID Option> |
| 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.
+-------------------------+ +----------------------------+
| <IPv6 base header> | | <IPv6 base header> |
| SrcAddr: MN's home addr | | SrcAddr: MN's home addr |
| DstAddr: CN's addr | | DstAddr: CN's Care-of addr |
+=========================+ +----------------------------+
| | | <Routing Header: Type = 0> |
| 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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/