IPv6 Working Group Charles Perkins
INTERNET DRAFT IBM Corporation
David B. Johnson
Carnegie Mellon University
26 January 1996
Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-00.txt>
Abstract
This document specifies mobility messages that allow transparent
routing of IP datagrams to mobile nodes in the Internet. Each
mobile node is always identified by its home address, regardless of
its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a
care-of address, which provides information about its current
point of attachment to the Internet. The protocol provides for
notifying the mobile node's home agent, and any other interested IPv6
addressable entities, about the care-of address of the mobile node.
When necessary, the home agent sends packets destined for the mobile
node through a tunnel to the care-of address. After arriving at the
end of the tunnel, the packets are then delivered to the mobile node.
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).
Perkins, Johnson Expires 26 July 1996 [Page i]
Internet Draft Mobility Support in IPv6 26 January 1996
1. Introduction
A new version of the Internet Protocol, IPv6, is being developed with
128-bit addresses, which remedies perceived flaws with the existing
version (that is, IPv4). This document specifies messages and a
simple protocol for the operation of mobile computers for IPv6.
Mobile computers are likely to account for a substantial fraction of
the population of the Internet during the lifetime of IPv6.
The development of IPv6 presents a rare opportunity, in that there
is no existing installed base of IPv6 hosts or routers with which
compatibility must be maintained, and all IPv6 nodes may be assumed
to perform the few operations needed to support Internet-wide
mobility. The most important function needed to support mobility
is the reliable and timely notification of a mobile node's current
location those other nodes that need it. The home agent needs this
location information in order to forward intercepted packets from the
home network to the mobile node, and correspondent nodes need this
information in order to send their own packets directly to the mobile
node.
In this document, we specify the way that the mobile node can notify
other nodes about its current whereabouts, using a Destination option
which fits naturally in IPv6. We describe the mechanism by which a
routing header can be used to deliver packets to the mobile node at
its current whereabouts. All IPv6 nodes and routers are assumed to
perform the few operations required for mobility, since doing so adds
little additional overhead. This leads to dramatic simplifications
in the required protocols, compared to the methods required for IPv4.
2. Basic Operation
From the model of operation developed for enabling mobile networking
for IPv4, we borrow the concepts of home network, home address,
home agent, care-of address, and binding. Mobile computers will
have assigned to their interface(s) (at least) two IPv6 addresses
whenever they are roaming away from their home network. One (the
home address) is permanent; the other (the IPv6 link-local address)
is used temporarily. In addition, the mobile node will typically
autoconfigure a globally-routable address at each new point of
attachment [12]. Every IPv6 router supports encapsulation, so every
router is capable of serving as a home agent on the network(s) to
which it is attached.
In brief, using the IPv4 language, we have a basic model of operation
in which a mobile node can always be reached by sending packets
to its home (permanent) address. Assuming the mobile node is not
Perkins, Johnson Expires 26 July 1996 [Page 1]
Internet Draft Mobility Support in IPv6 26 January 1996
present on its home network, packets arriving for it there will be
intercepted by the home agent, and tunneled to a care-of address.
Care-of addresses can be constructed by the mobile node using
the methods of automatic address configuration [12]. If the
mobile node receives router advertisments, it MUST use automatic
address configuration to construct a globally unique, routable
address. This routable address can be used by the mobile node as its
care-of address. After determining its care-of address, a mobile
node must send a binding update containing that care-of address
to the home agent (and any other correspondent nodes that may
have out-of-date bindings in their binding cache). By default,
correspondent nodes send packets to mobile nodes by using routing
headers instead of encapsulation. As detailed in the next section,
correspondent nodes are usually expected to deliver packets directly
to the mobile node's care-of address, so that the home agent is
rarely involved with packet transmission to the mobile node.
It is essential for scalability and minimizing network load that
correspondent nodes be able to learn the care-of address of a mobile
node, and to be able to cache this information for use in sending
future packets to the mobile node's care-of address. By caching the
care-of address of a mobile node, optimal routing of packets can be
achieved between the correspondent node and the mobile node. Routing
packets directly to the mobile node's care-of address also eliminates
congestion at the home agent and thus contributes significantly to
the overall health of the Internet. Moreover, many communications
between the mobile nodes and its correspondent nodes can be carried
out with no assistance from the home agent. Thus, the impact
of failure at the home agent can be drastically reduced; this is
important because many administrative domains will have a single home
agent to serve a particular home network, and thus a single point of
failure for communications to nodes using that home agent. Besides
that, communications between the home agent and a mobile node may
depend on a number of intervening networks; thus, there are many more
ways that packets can fail to reach a mobile node when the home agent
is required as an intermediate node. This would be particularly
relevant on, say, trans-oceanic links between home agent and mobile
node. Caching the binding of a mobile node at the correspondent node
enables communication with the mobile nodes even if the home agent
fails or is difficult to contact over the Internet.
In the typical case when a mobile node has configured its
care-of address at one of its own interfaces, transferring data to
the mobile node means no more work for routers on link at its current
point of attachment, than transferring data to any other node on that
link. This affords another substantial performance improvement in
the typical case.
Perkins, Johnson Expires 26 July 1996 [Page 2]
Internet Draft Mobility Support in IPv6 26 January 1996
3. Terminology
Mobile IPv6 defines these terms:
Binding
The association of a home address with a care-of address, along
with the remaining lifetime of that association.
Care-of Address
The care-of address is the termination point of a tunnel toward
a mobile node that is away from its home network.
Correspondent
A peer with which a mobile node is communicating. The
correspondent may be either mobile or stationary.
Foreign Network
Any network other than the mobile node's Home Network.
Home Address
An IPv6 address that is assigned for an extended period of time
to a mobile node. It remains unchanged regardless of where the
node is attached to the Internet.
Home Agent
A router on a mobile node's home network which tunnels packets
for delivery to the mobile node when it is away from home, and
maintains current location information for the mobile node.
Home Network
A network, possibly virtual, having a network prefix matching
that of a mobile node's home address. Note that standard IP
routing mechanisms will deliver packets destined to a mobile
node's Home Address to the mobile node's Home Network.
Link
A facility or medium over which nodes can communicate at the
link layer. A link underlies the network layer.
Perkins, Johnson Expires 26 July 1996 [Page 3]
Internet Draft Mobility Support in IPv6 26 January 1996
Mobile Node
A host or router that changes its point of attachment from one
network or subnetwork to another. A mobile node may change its
location without losing connectivity and without changing its
IPv6 address.
Node
A host or a router.
Tunnel
The path followed by a packet while it is encapsulated. The
model is that, while it is encapsulated, a packet is routed
to a knowledgeable decapsulating agent, which decapsulates
the packet and then correctly delivers it to its ultimate
destination.
4. Binding Updates
In IPv6, all IPv6 nodes must be capable of caching the care-of
address of mobile nodes with which they want to communicate. This
cached address information can be integrated with the node's
Destination Cache [9]. Binding updates should be considered a
form of routing updates; thus, handled incorrectly, they could
be a source of security problems and routing loops. Therefore,
packets which include binding updates MUST also include an IPv6
authentication header [1]; replay protection is then achieved by use
of the Identification field in the binding update.
4.1. Binding Update Option Format
The Binding Update Option is an option within the Destination
Header [5].
A mobile node uses the Binding Update destination option to notify
another node (e.g., correspondent node or home agent) of its current
care-of address. The binding update should be placed in the IPv6
packet after any routing header, since the binding update should
only be processed by the destination node rather than by each hop
along the path. The binding update is encoded as destination option
type 16 (TBD). By encoding the binding update in this way, it can
be included in any normal data packet or can be sent in a separate
packet containing no data. The binding update contains the mobile
node's care-of address, an identification for the update (to protect
Perkins, Johnson Expires 26 July 1996 [Page 4]
Internet Draft Mobility Support in IPv6 26 January 1996
against attempts to replay it), and a lifetime for the binding.
This option format is adapted from that used in the IPv4 Route
Optimization [7]. Note that the home address MUST be the source
address of the IPv6 packet containing the binding update, and thus is
not required to be located within the data of the destination option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|C|I|E|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Care-of Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of option. The first three bits
of the option are 000, indicating first that a node receiving
the option may discard the option and still process the rest
of the packet, and second that the option may not be modified
enroute.
Option Length
8-bit unsigned integer. Length of the Option Data field of
this option, in octets.
Acknowledge (A)
The Acknowledge (A) bit is set by a node if it wants a a
Binding Acknowledge message to be returned upon receipt of the
Binding Update Option.
Co-location (C)
The mobile node is itself the agent receiving datagrams at the
care-of address.
Perkins, Johnson Expires 26 July 1996 [Page 5]
Internet Draft Mobility Support in IPv6 26 January 1996
Identification Present (I)
The (I) bit is set by the node sending the Binding Update
option to indicate whether or not the Identification field is
present.
Encapsulation (E)
The (E) bit is set by the mobile node to request that the
receiving node use IPv6-within-IPv6 encapsulation when sending
any future packets to the mobile node's care-of address,
instead of packets containing the care-of address in a routing
header. See subsection 7.
"All-Nodes Multicast" (B)
The (B) bit is set by the mobile node to request that the home
agent encapsulate and send "all-nodes multicast" packets to the
mobile node at its care-of address. The (B) bit must only be
used when sending binding updates to the home agent. Note that
the home agent may be manually configured to send only a subset
of such packets to the mobile node -- for instance, the home
agent may inspect the port number of UDP packets, or the ICMP
packet type, to determine whether or not the packet should be
forwarded to the mobile node.
Reserved
Sent as 0; ignored on reception.
Lifetime
The number of seconds remaining before the binding must be
considered expired. A value of all ones indicates infinity.
A value of zero indicates that the indicated binding (or
route table entry, in the case of a mobile node's previous
router) for the mobile node should be deleted. The lifetime is
typically equal to the remaining lifetime of the mobile node's
binding with its care-of address.
Care-of Address
The current care-of address of the mobile node. When set equal
to the home address of the mobile node, the Binding Update
option instead indicates that any existing binding for the
mobile node should be deleted; no binding for the mobile node
should be created.
Perkins, Johnson Expires 26 July 1996 [Page 6]
Internet Draft Mobility Support in IPv6 26 January 1996
Identification
If present, a 64-bit number used to protect against replay
attacks.
The receiver of this message must be able to determine that the
mobile node is truly the agent which has generated the binding
update, by verifying a subsequent IPv6 authentication header [1]
within the packet.
Extensions to the Binding Update Options format may be included after
the fixed portion of the Binding Update option. The presence of such
extensions will be indicated by the option length field. When the
option length is greater than the size of the fixed fields of the
Binding Update Option, the remainder is interpreted as extensions.
Currently no extensions have been defined.
Perkins, Johnson Expires 26 July 1996 [Page 7]
Internet Draft Mobility Support in IPv6 26 January 1996
5. Sending Binding Updates
After moving away from its home network to a new location (see
subsection 5.1), the mobile node registers its new binding with
its home agent by sending a packet containing a binding update to
its home agent. This binding update MUST have the (A) bit set,
instructing the home agent to send an acknowledgement. If not
already doing so, the home agent must send out onto the Home Network
a proxy Neighbor Advertisment on behalf of the mobile node, with the
Override flag set [9]. This will ensure that other nodes on the home
network are able to send packets to the mobile node by using the
services of the home agent.
In the case when the mobile node is returning to its home network,
the binding update sent to its home agent MUST contain the mobile
node's home address in place of any care-of address. The mobile node
MUST also send out the appropriate Neighbor Advertisment packets with
the Override flag set, so that its neighbors on its home network will
update the relevant information for the mobile node in their Neighbor
Caches. This Neighbor Advertisement packet can be repeated a small
number of times to guard against occasional loss of packets on the
home network.
A binding update may also be included, whenever necessary, in
a normal data packet sent to a correspondent node. For each
correspondent node, information is kept by the mobile node to
determine whether or not the correspondent node has been sent a
fresh binding update since the last time any movement by the mobile
node to a new care-of address has occurred. When a packet is to be
sent to a correspondent node which hasn't been sent a fresh binding
update, the mobile node SHOULD include the update within the packet,
and indicate that the update has been sent. Thus, correspondent
nodes are generally kept updated and can send almost all data packets
directly to the mobile node. Such binding updates are not generally
required to be acknowledged. However, if the mobile node wants to be
sure, an acknowledgment can be requested.
The binding update can also be sent in an otherwise empty packet
whenever the mobile node wishes to update its correspondents. This
is normally done only if the mobile suspects that its home agent is
not operational, too far away, a correspondent node is not sending
the traffic to the proper care-of address, or there is an immediate
need for the correspondent node to obtain the binding. The mobile
node must not send binding updates more often than MAX_UPDATE_RATE to
any correspondent host, since it is not allowed to change its point
of attachment more often than MAX_UPDATE_RATE. A mobile node can
detect that a correspondent node is not sending packets to the proper
care-of address because in that case the packets arrive at the mobile
Perkins, Johnson Expires 26 July 1996 [Page 8]
Internet Draft Mobility Support in IPv6 26 January 1996
node's care-of address by encapsulation instead by inclusion in a
routing header within the packet.
The mobile node may choose to keep its location private from certain
correspondent nodes. The mobile node need not send binding updates
to those correspondents. No other IPv6 nodes are authorized to send
binding updates on behalf of the mobile node.
When sending binding updates, a mobile node uses the Identification
field of the destination option, in conjunction with the IPv6
Authentication Header, to protect against replays. One style
of replay protection involves the use of a timestamp as the
Identification data. The result would be that the mobile node and
the target of its binding update would have to roughly agree on
the current time, and that stale binding updates would have to be
rejected. The exact mechanisms by which the Identification field is
created and interpreted by the sending and receiving parties depends
on the Security Association existing between them. This subject is
discussed thoroughly in the mobile-IPv4 specification [6].
5.1. Detecting movement
A mobile node may detect that it has changed its point of attachment
to the Internet by several means. The usual method involves
reception of router advertisements from previously undetected
routers. This may also be augmented by a determination that a
previously accessible router is no longer accessible (using Neighbor
Unreachability Detection (NUD) as specified in [9]).
It is also possible that indications about changes of point of
attachment can be obtained from lower-level protocol or device driver
software.
6. Binding Acknowledgement Message
A Binding Acknowledge message is used to acknowledge acceptance
of a Binding Update (section 4.1) option, if that option has the
Acknowledge (A) bit set. Binding Acknowledgement messages should be
sent addressed to the mobile node originating the Binding Update,
using if necessary a routing header containing the care-of address
given in the Binding Update.
Since the Binding Acknowledgement is mostly used by home agents
and is not associated with any transmission of data packets, it is
specified here as an informational ICMP message to the mobile node.
However, all of the error conditions specified in the Registration
Perkins, Johnson Expires 26 July 1996 [Page 9]
Internet Draft Mobility Support in IPv6 26 January 1996
Reply message of the IPv4 mobile-IP protocol may apply, so the
general format and codes of that message are adapted here to fit the
ICMP packet layout for IPv6 [4].
The acknowledgement message contains the necessary codes to inform
the mobile node about the status of its binding. Additionally, the
home agent MAY shorten the lifetime to be smaller than indicated
in the original binding update. When the lifetime of the reply is
greater than what was contained in the binding update, the excess
time MUST be ignored. When the lifetime of the reply is smaller than
the original request, another binding update SHOULD be sent before
the lifetime expires.
If a mobile node fails to receive an acceptable Binding
Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds after
transmitting the binding update, it must retransmit the binding
update with the same identification, and begin an exponential
back-off process of retransmission. The time-out period is doubled
upon each retransmission until the target of the binding update
sends an acknowledgement, or the time-out period reaches the value
MAX_BINDACK_TIMEOUT.
The ICMP Binding Acknowledgment packet has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 192 (TBD)
Code One of the following codes:
0 service will be provided
128 service denied: reason unspecified
129 service denied: administratively prohibited
130 service denied: insufficient resources
133 service denied: identification mismatch
134 service denied: poorly formed request
136 service denied: unknown home agent address
Perkins, Johnson Expires 26 July 1996 [Page 10]
Internet Draft Mobility Support in IPv6 26 January 1996
Lifetime The seconds remaining before the binding is
considered expired. A value of zero indicates
removal of a binding. A value of all ones
indicates infinity.
Identification The acknowledgment identification is derived
from the binding update message, for use by the
mobile node in matching the acknowledgment with
an outstanding Binding Update.
Up-to-date values of the Code field are to be specified in the most
recent "Assigned Numbers" [10].
7. Delivering Packets to a Mobile Node
If a routing header is not present, the routing infrastructure will
route packets addressed to a mobile node to its home network. Since
the mobile node's location is known on the home network (namely, by
the home agent), packets can be addressed to the mobile node and
intercepted by the home agent without the sender knowing that the
node is mobile.
Correspondent nodes that have accepted a binding update for a
mobile node, can send packets directly to that mobile node's current
care-of address by including a routing header in them. To use
the routing header for delivery of packets to a mobile node, a
correspondent host just specifies the care-of address as the (last)
intermediate routing point and the mobile node as the destination.
When the packet arrives at the care-of address, normal processing of
the routing header will ensure delivery to the mobile node. IPv6
routing headers do not carry the semantics which require reversal of
source routes.
Home agents cannot use routing headers to deliver packets to the
mobile node, because they can't modify the packet and add to it in
flight. They must always use encapsulation [3] for this purpose
(section 8).
If a packet to the mobile node is encapsulated, it uses the care-of
address as the destination address in the outer IPv6 header. Then,
when the the encapsulated packet arrives at the care-of address,
the encapsulation is stripped away and the packet delivered (if
possible) to the mobile node. Of course, if the mobile node is
itself receiving packets at the care-of address, the delivery path is
trivial.
Perkins, Johnson Expires 26 July 1996 [Page 11]
Internet Draft Mobility Support in IPv6 26 January 1996
If a correspondent node receives ICMP Host Unreachable or Network
Unreachable after sending a packet to a mobile node using its cached
care-of address, it SHOULD delete the cache entry until information
about the mobile node's current care-of address becomes available
(via a binding update).
7.1. Smooth Handoffs
If a mobile node obtains a new care-of address from an stateful
address allocation authority (e.g, [2]), it should soon explicitly
deallocate the previous care-of address. For smooth handoffs, a
mobile client may still accept packets at both addresses for a short
time after configuring its newly allocated IPv6 address. If the
previous address is allocated by such a stateful address server, then
such a mobile client may not wish to release the address immediately
upon acquisition of a new care-of address. The stateful address
server will allow mobile clients to acquire new addresses while still
using previously allocated addresses.
Routers must (just as any IPv6 node) be able to accept authenticated
binding updates for the mobile node and, subsequently, act on the
cached binding by encapsulating packets for intermediate delivery
to the care-of address specified in the binding. In cases where
a mobile node moves from one care-of address to another with no
delay, but without being able to maintain simultaneous connectivity
at both care-of addresses, it SHOULD send a binding update to the
router servicing the previous care-of address, so that packets
for the mobile node can be delivered to the new care-of address
immediately. For example, a mobile node may move from one radio link
to another on a different channel, and be unable to monitor packets
delivered over two channels at once. In this example, the mobile
node should send a binding update to the entity delivering packets
over the previous radio channel so that those packets will instead be
delivered via a new care-of address. This binding update associates
the mobile node's previous care-of address to the mobile node's new
care-of address, and is authenticated using the IPv6 Authentication
Header with whatever security association the previous router had
with the mobile node's previous care-of address.
For this purpose, the mobile node must have some security association
with the entity serving the previous care-of address. In the typical
case specified within this document, a mobile node has obtained a
care-of address via autoconfiguration and is receiving tunneled
packets at that care-of address. When the mobile node moves, routers
serving the link at its previous point of attachment may find that
the mobile node's previous care-of address has become inaccessible.
Perkins, Johnson Expires 26 July 1996 [Page 12]
Internet Draft Mobility Support in IPv6 26 January 1996
Note that the previous router does not necessarily know anything
about the mobile node's home address as part of this sequence of
events; the routers may only know about things associated with the
(e.g., autoconfigured) care-of addresses used by the mobile node at
the previous and current points of attachment.
Since only one binding update is expected to be sent to the previous
router, the mobile node MAY elect to omit the Identification field.
If the mobile node omits the Identification field from the binding
update, there is no replay protection and the security association
with the previous router can only be used one time. In this case,
the router should only accept the binding update if the mobile node's
care-of address is still present in its Neighbor Cache. In this
situation, the mobile node SHOULD request an acknowledgment for the
binding update. Thus, the previous router should keep the security
association around for the mobile node's previous care-of address in
case the mobile node loses the acknowledgment and retransmits the
binding update (with the same new care-of address).
The previous router then operates the same way as when the mobile
node's home agent receives a binding update from the mobile node.
That is, the previous router must inspect packets, and redirect the
packets destined for the care-of address indicated in the binding
update. Packets which need to be redirected to the mobile node's new
care-of address are encapsulated and sent to the new care-of address.
In fact, the previous router is temporarily acting as a home agent
for the mobile node's previous care-of address. In particular,
the previous router does not use any routing header to effect the
redirected delivery. Moreover, the previous router should issue
Neighbor Advertisement packets for the previous care-of address, so
that on-link neighbors will send packets destined to the mobile node
to the previous router for encapsulation and further delivery to the
new care-of address.
Once the mobile node receives the encapsulated packet, it can then
typically follow the routing header contained in the decapsulated
packet and deliver the final payload to internal protocol handling
using its IPv6 home address. The mobile node must ensure that a
binding update is sent to each source of such packets so that the
previous router is relieved of its duties at the earliest possible
moment.
8. Home Agent Considerations
When the home agent, or any other routing agent, receives a packet
destined to a mobile node for which it has a binding cached,
it encapsulates the packet for delivery to the mobile node's
Perkins, Johnson Expires 26 July 1996 [Page 13]
Internet Draft Mobility Support in IPv6 26 January 1996
care-of address. The agent cannot insert a routing header, or
modify the destination address of the mobile node, because of IPv6
authentication mechanisms [1]. Moreover, the home agent is expected
to be involved only rarely with the transmission of data to the
mobile node, because the mobile node will send binding updates as
soon as possible to its correspondent hosts.
It is useful to be able to send a packet to a mobile node's home
agent without explicitly knowing the home agent's address. For
example, a mobile node must communicate with its home agent to
send it a binding update; but since the mobile node was last at
home, it may have become necessary to replace the node serving as
its home agent due to the failure of the original node or due to
reconfiguration of the home network. It thus may not always be
possible or convenient for a mobile node to know the exact address of
its own home agent.
Mobile nodes can dynamically discover the address of a home agent
by sending a binding update to the anycast address on their home
network. Each router on the home network which receives this binding
update MUST reject the binding update and include its address in the
Binding Acknowledgement packet indicating the rejection. The mobile
node is assumed to know a proper anycast address on its home network
before making use of this method for determining a particular home
agent's address.
Other routers on the home network must be instructed to forward
packets to the current router which is serving as the mobile node's
home agent. This can be done using the same proxy mechanisms
already made available in Neighbor Discovery. The current home agent
multicasts the equivalent of a Proxy ARP onto the home network, and
subsequently the other routers on the home network will forward
packets destined to the mobile node to the particular router which is
serving as the home agent for that mobile node.
8.1. Renumbering the Home Network
Neighbor Discovery [9] specifies a mechanism by which all nodes on a
network can gracefully autoconfigure new addresses, say by combining
a new routing prefix with their existing MAC address. As currently
specified, this mechanism works when the nodes are on the same link
as the router issuing the necessary multicast packets to advertise
the new routing prefix(es) appropriate for the link.
However, for mobile nodes not currently attached to the same link
as their home agent, special care must be taken to allow the mobile
nodes to renumber gracefully. The most direct method of insuring
Perkins, Johnson Expires 26 July 1996 [Page 14]
Internet Draft Mobility Support in IPv6 26 January 1996
this is for the home agent to tunnel the multicast packets to the
care-of address of the mobile node as necessary. The rules for this
are as follows:
- A mobile node assumes that its routing prefix has not changes
unless it receives authenticated router advertisement messages
from its home agent that the prefix has changed.
- When the mobile node is at home, the home agent does not tunnel
router advertisements to it.
- When a home network prefix changes, the home agent tunnels router
advertisement packets to each mobile node which is currently
away from home and using a home address with the affected
routing prefix. Such tunneled router advertisements MUST be
authenticated [1].
- When a mobile node receives a tunneled router advertisement
containing a new routing prefix, it must perform the standard
autoconfiguration operation to create its new address
- When a mobile node returns to its home network, it must again
perform Duplicate Address Detection at the earliest possible
moment after it has registered with its home agent.
- A mobile node may send a router solicitation to its home agent at
any time, within the constraints imposed by rate control in the
Neighbor Discovery specification [9]
Note that a mobile node is guaranteed that its home address is unique
and used by no other mobile node. However, in some circumstances it
may nevertheless be true that other nodes on its home network form
the same link-local address as the mobile node during the time when
the mobile node is away from its home network. Thus, there is the
requirement above that the mobile node perform Duplicate Address
Detection when it returns again to its home network.
9. Multicast Packet Routing
A mobile node that is connected to its home network functions just
like any other (stationary) host or router. Thus, when it is at
home, a mobile node functions identically to other multicast senders
and receivers. This section therefore describes the behavior of a
mobile node that is not on its home network.
In order receive multicasts, a mobile node must join the multicast
group. Mobile nodes MAY join multicast groups in order to receive
Perkins, Johnson Expires 26 July 1996 [Page 15]
Internet Draft Mobility Support in IPv6 26 January 1996
transmissions in one of two ways. First, they MAY join the group
via a (local) multicast router on the visited subnet. This option
assumes that there is a multicast router present on the visited
subnet. The mobile node SHOULD use its dynamically acquired care-of
address (if it has acquired one) as the source IP address of its
multicast group membership control message packets. Otherwise, it
MAY use its home address.
Alternatively, a mobile node which wishes to receive multicasts can
join groups via a bi-directional tunnel to its home agent, assuming
that its home agent is a multicast router. The mobile node tunnels
the appropriate multicast group membership control packets to its
home agent and the home agent forwards multicast packets down the
tunnel to the mobile node. The home agent must tunnel the packet
directly to the mobile node's dynamically acquired care-of address,
or, the packet must be tunneled first to the mobile node's home
address and then recursively tunneled to the mobile node's care-of
address.
A mobile node which wishes to send packets to a multicast group
also has two options: (1) send directly on the visited network; or
(2) send via a tunnel to its home agent. Because multicast routing
in general depends upon the IP source address, a mobile node which
sends multicast packets directly on the visited network MUST use
a dynamically acquired care-of address as the IP source address.
Similarly, a mobile node which tunnels a multicast packet to its home
agent MUST use its home address as the IP source address of both the
(inner) multicast packet and the (outer) encapsulating packet. This
second option assumes that the home agent is a multicast router.
10. Compatibility with ICMP
When sending a packet to a mobile node, it is important to correctly
return to the original sender any ICMP error messages generated by
this packet. Since in most cases such packets use a routing header
containing the care-of address, this is usually not a problem.
However, when a packet encapsulated at the home agent encounters such
an error condition, ICMP error messages are returned to the sender as
specified in [3]. ICMP for IP version 6 has been specified to return
as much of the original packet as will fit in the ICMP error message
without the ICMP packet exceeding 576 octets [4]. This size should
be sufficient for correctly returning ICMP error messages backwards
along the tunnel.
Perkins, Johnson Expires 26 July 1996 [Page 16]
Internet Draft Mobility Support in IPv6 26 January 1996
11. Protocol Requirements
This section summarizes the requirements introduced by the above
protocol operations for IPv6 nodes and for routers.
11.1. Requirements for IPv6 Nodes
Every IPv6 node must be able to interpret Binding Update packets.
Every IPv6 node must be able to maintain Security Associations for
use in IPv6 Authentication Headers [1] which are used to authenticate
Binding Updates and protect against replay attacks. Every IPv6
node must be able to associate care-of addresses with IPv6 target
addresses, and use routing headers to deliver packets to IPv6 target
addresses (e.g., mobile node addresses) using the care-of address as
an intermediate router address.
11.2. Requirements for IPv6 Mobile Nodes
Every IPv6 mobile node must be able to perform IPv6 decapsulation.
Every mobile node must be able to send Binding Updates as outlined
above, and receive Binding Acknowledgements from routers. Every IPv6
mobile node must keep track of which other IPv6 nodes may need to
receive Binding Updates as a result of recent movement by the mobile
node. In particular, every IPv6 mobile node must be able to send
Binding Updates when a packet is received that does not use a routing
header to specify its care-of address.
11.3. Requirements for IPv6 Routers
Every IPv6 router must perform the mobility-related functions listed
in the previous subsection (11.1) for IPv6 nodes, but not necessarily
the functions for mobile nodes.
Every IPv6 router must be able to issue Binding Acknowledgements in
response to Binding Updates received and accepted from a mobile node.
Every IPv6 router must be able to encapsulate packets in order to
tunnel them to a care-of address known for a mobile node from which
it has received a binding update. Every IPv6 router must be able to
maintain security associations for the mobile nodes from which it
will accept binding updates.
Perkins, Johnson Expires 26 July 1996 [Page 17]
Internet Draft Mobility Support in IPv6 26 January 1996
A. Constants
INITIAL_BINDACK_TIMEOUT == 1 second
MAX_BINDACK_TIMEOUT == 256 seconds
MAX_UPDATE_RATE == 1 per second
B. Open issues
B.1. Using Encapsulation Protocols
Should alternative encapsulation techniques be defined for use with
these protocols? Should a minimal encapsulation be defined and
specified as the default?
There is only one possible advantage afforded by the use of
encapsulation, compared to the use of the existing routing header
defined for IPv6, and it only occurs when a mobile node uses a
care-of address associated with a router attached to the same link as
the mobile node's point of attachment as in B.3. If a mobile node
has a link to a router over a low speed wireless link, and the router
receives encapsulated packets for the mobile node, the encapsulation
is stripped away before final delivery is made to the mobile node.
In that case, fewer bytes are transmitted over the low-speed link,
than would be the case for a normally processed routing header
specifying the care-of address. Perhaps this would be better taken
care of by defining something like TCP header compression over the
link from the router to the mobile node. Such a compression scheme
would eliminate the need to include the routing header information in
every packet delivered over a slow-speed connection between a router
and a mobile node.
Another alternative would be to provide another type of routing
header (routing type == 2, say) which would allow an intermediate
node to delete itself from the list instead of just rearranging the
list. This would completely eliminate the need for encapsulation for
normal datagrams from correspondent host to mobile node. However,
having routers remove addresses to shrink the packet size may be a
slow operation (relatively speaking).
B.2. Session keys with local routers
In the IPv4 route optimization proposal, a mechanism is outlined
whereby a session key can be established between foreign agents
and mobile clients, without requiring any pre-established security
Perkins, Johnson Expires 26 July 1996 [Page 18]
Internet Draft Mobility Support in IPv6 26 January 1996
relationship between them. A similar mechanism should be defined for
IPv6, to avoid the need for a possibly time-consuming negotiation
between routers and mobile nodes for the purpose of obtaining the
session key, which under many circumstances would only be used once.
This mechanism, if needed, can be specified completely outside the
mobile-IPv6 protocol and would amount to a way of creating a dynamic
SPI between two nodes which do not share a trust relationship, but
which need to agree on a key for some particular purpose (here,
allowing the future authentication of a binding update). Hopefully,
Photuris [8] will allow this function to be performed appropriately
for mobile nodes, say by a Diffie-Hellman key exchange.
B.3. Local Router Considerations
In previous versions of this specification, routers local to the
current point of attachment of the mobile node ("local routers")
were expected to offer services to mobile nodes. That is still
quite feasible, and requires only that the routers support the
decapsulation procedure required to extract the packet for final
delivery to the mobile node. If every router supports decapsulation
(in addition to the operations required from every IPv6 router and
IPv6 node), then addresses formed using any prefix advertised by
the router could be used as a care-of address except the router's
link-local address. Enabling this style of care-of address
acquisition will likely require some straightforward enhancements
to the IPv6 Neighbor Discovery packet formats. In particular, a
Router Advertisement should probably define another per-prefix bit
to specify whether the prefix is available to the mobile nodes for
constructing a care-of address. For stateful address configuration,
an option could be defined to allow the stateful server to notify a
mobile node of a legitimate care-of address appropriate for use at
the new point of attachment.
Many other operations, related to registration of the mobile node in
a new service area, are likely to become important as mobile nodes
become more prevalent. For instance, it may be required to:
- authenticate the identity of mobile clients
- charge for connection services
- produce or share a session key for use by new mobile clients
(say, for encryption)
- negotiate a compression algorithm
- manage the resources of router's communications devices
Perkins, Johnson Expires 26 July 1996 [Page 19]
Internet Draft Mobility Support in IPv6 26 January 1996
B.4. Source Address Filtering by Firewalls
The current specification does nothing to permit mobile nodes to
send their packets through firewalls which filter out packets with
the "wrong" source IPv6 addresses in the IPv6 packet header. The
mobile node's home address may be unlikely to fall within the ranges
required to satisfy the firewall's criteria for further delivery.
This subject needs serious discussion soon. As indicated by
recent discussion, such firewalls are unlikely to disappear. Any
standardized solution [11] to the firewall problem based on hiding
the non-local source address outside the source addres field
of the IPv6 header is likely to fail. Any vendor or facilities
administrator wanting to filter based on the address in the IPv6
source address field would also quickly begin filtering on hidden
source addresses.
C. Acknowledgments
Thanks to Thomas Narten for contributing valuable discussion and
reviewing this draft, as well as helping to shape some recent changes
relevant to the operation of Neighbor Discovery.
Perkins, Johnson Expires 26 July 1996 [Page 20]
Internet Draft Mobility Support in IPv6 26 January 1996
References
[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[2] J. Bound. Dynamic Host Configuration Protocol for IPv6.
draft-ietf-dhc-dhcpv6-03.txt -- work in progress, November 1995.
[3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6.
draft-ietf-ipngwg-ipv6-tunnel-00.txt - work in progress,
November 1995.
[4] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995.
[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995.
[6] IETF Mobile-IP Working Group. IPv4 Mobility Support.
ietf-draft-mobileip-protocol-12.txt - work in progress,
September 1995.
[7] David B. Johnson and Charles E. Perkins. Route Optimization
in Mobile-IP. draft-ietf-mobileip-optim-03.txt -- work in
progress, November 1995.
[8] P. Karn and B. Simpson. draft-ietf-ipsec-photuris-08.txt.
Internet Draft -- work in progress, November 1995.
[9] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor
Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in
progress, November 1995.
[10] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October
1994.
[11] Fumio Teraoka. draft-teraoka-ipv6-mobility-sup-02.txt.
Internet Draft -- work in progress, January 1996.
[12] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt
- work in progress, November 1995.
Perkins, Johnson Expires 26 July 1996 [Page 21]
Internet Draft Mobility Support in IPv6 26 January 1996
Authors' Addresses
Charles Perkins
Room J1-A25
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1 914 789-7350
Fax: +1 914 784-7007
E-mail: perk@watson.ibm.com
David B. Johnson
Computer Science Department
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213-3891
Work: +1 412 268-7399
Fax: +1 412 268-5576
E-mail: dbj@cs.cmu.edu
Perkins, Johnson Expires 26 July 1996 [Page 22]
