Network Working Group C. Vogt, Ed.
Internet-Draft R. Bless
Expires: August 4, 2004 M. Doll
T. Kfner
Univ. of Karlsruhe, Germany
February 4, 2004
Early Binding Updates for Mobile IPv6
draft-vogt-mip6-early-binding-updates-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The long latency associated with Mobile IPv6's home-address and
care-of-address tests can significantly impact delay-sensitive
applications. We propose a modified binding-update procedure that
evades the latency of both address tests. The modified binding update
runs in half, or less, of the time that a standard binding update
takes. Moreover, the modified binding update is nearly equivalent to
the standard procedure with respect to security, and it increases the
resources required at the correspondent node only marginally. The
modification is realized as an optional, and fully
backward-compatible, extension to Mobile IPv6.
Vogt, Ed., et al. Expires August 4, 2004 [Page 1]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Standard Binding Updates . . . . . . . . . . . . . . . . . . . 6
4. Early Binding Updates . . . . . . . . . . . . . . . . . . . . 9
4.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . 10
4.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 14
4.3 Initial Care-of Address Registration . . . . . . . . . . . . . 15
5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 16
5.1 Standard Binding Updates . . . . . . . . . . . . . . . . . . . 16
5.2 Early Binding Updates . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1 Decoupled Address Tests . . . . . . . . . . . . . . . . . . . 21
6.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 23
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Protocol Configuration Variables . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 27
Vogt, Ed., et al. Expires August 4, 2004 [Page 2]
Internet-Draft Early Binding Updates February 2004
1. Introduction
Mobility Support for IPv6 [1], or Mobile IPv6, allows a mobile node
to change its point of network attachment without loosing
higher-level communications connections. A mobile node has a
preferably permanent "home address", by means of which the mobile
node can be identified. In addition, the mobile node has a "care-of
address", which is a topologically correct IP address at the mobile
node's current location. The care-of address changes whenever the
mobile node moves to a different location. If a mobile node and a
correspondent node use route optimization, the correspondent node
maintains a "binding" between the mobile node's home address and
current care-of address. When the mobile node attaches to a different
network, it initiates a "binding update", i.e., it signals to the
correspondent node its new care-of address. We assume the application
of route optimization in this document.
Mobile IPv6 uses a "return routability" procedure to verify a binding
update with respect to authenticity and validity. The return
routability encompasses two tests: A home-address test authenticates
the mobile node. It provides reasonable assurance to the
correspondent node that the mobile node is the legitimate owner of
the IP address which the mobile node claims to own as its home
address. A care-of-address test checks the validity of the new
care-of address. It provides reasonable assurance to the
correspondent node that the mobile node is reachable through the IP
address which the mobile node wishes to register as its care-of
address.
The return routability requires a minimum of processing resources and
state at both the mobile node and the correspondent node.
Furthermore, it does not depend on a trusted infrastructure, which
would be expensive to build and maintain. A shortfall, however, is
that the two address tests, though typically performed in parallel,
constitute a considerable fraction of the binding-update latency.
Both tests are potentially run over very long distances. This makes
it difficult for delay-sensitive applications to hold up service
quality when the mobile node changes its point of network attachment.
In this document, we propose a strategy, Early Binding Updates, to
move both address tests out of the critical period during which a new
care-of address cannot yet be used. We find that an Early Binding
Update runs in half, or less, of the time that a binding update
defined in [1] takes. Moreover, we show that an Early Binding Update
is nearly equivalent to the standard procedure with respect to
security, and that it increases the resources required at the
correspondent node only marginally. To facilitate differentiation, we
will henceforth call the binding update defined in [1] a "standard
Vogt, Ed., et al. Expires August 4, 2004 [Page 3]
Internet-Draft Early Binding Updates February 2004
binding update".
Early Binding Updates are a minor extension to standard binding
updates. They are fully compatible to the binding-update procedure
defined in [1], in particular with the return routability. Early
Binding Updates use two new messages, both of which have no effect if
either communication end-point does not support them. All messages
related to standard binding updates remain unchanged and retain their
original meaning. We are currently working on a more detailed
specification of Early Binding Updates including message formats and
additions to [1]. The specification will be published in a future
version of this Internet Draft.
Section 2 provides a brief overview on Early Binding Updates. The
overview is assumed to be sufficient for a hurried reader who does
not want to read the in-depth discussion of the subsequent sections.
Section 3 is a recap on the standard binding-update procedure defined
in [1]. Section 4 provides the details of Early Binding Updates. We
analyze the efficiency of Early Binding Updates in Section 5.
Implications on security are examined in Section 6. We conclude in
Section 7.
2. Overview
In this section, we briefly describe Early Binding Updates. This
section is assumed to be a sufficient survey for a hurried reader. We
refer to Section 4 for more details on Early Binding Updates. Section
3 provides a recap on standard binding updates.
Early Binding Updates are a strategy to move both address test out of
the critical period during which a new care-of address cannot yet be
used. With Early Binding Updates, a mobile node executes a
home-address test whenever a handover is imminent. If handovers
cannot be anticipated, the mobile node may periodically repeat the
home-address test. Either way, the mobile node has at hand a fresh
Home Keygen Token when it changes its point of network attachment,
and it does not need to wait for a lengthy home-address test during
the binding update. Furthermore, the care-of-address test is executed
in parallel with sending data to and from the new care-of address.
This way, the mobile node does not need to wait for a lengthy
care-of-address test during the binding update either. Note that [1]
suggests running both address tests after a handover. However, the
mobile node may trigger a home-address test before it moves without
violating the protocol procedure.
We introduce two new messages: an Early Binding Update message and an
Vogt, Ed., et al. Expires August 4, 2004 [Page 4]
Internet-Draft Early Binding Updates February 2004
Early Binding Acknowledgement message. When the mobile node detects
that it has moved to a different network, it configures a new care-of
address. The mobile node then sends to the correspondent node an
Early Binding Update message in order to tentatively register the new
care-of address with the correspondent node. The mobile node just
needs a Home Keygen Token to authenticate the Early Binding Update
message. The mobile node may request the correspondent node to return
an Early Binding Acknowledgement message by raising a flag in the
Early Binding Update message. A conservative mobile node would wait
for the Early Binding Acknowledgement message before using its new
care-of address. An optimistic mobile node would start using its new
care-of address as soon as having dispatched the Early Binding Update
message. Whether conservative or optimistic, with Early Binding
Updates, the mobile node can use its new care-of address about one
round-trip time sooner than with standard binding updates.
Having sent the Early Binding Update message, the mobile node
initiates a care-of-address test as defined in [1]. When the
care-of-address test completes, the mobile node sends to the
correspondent node a standard Binding Update message as defined in
[1]. The Binding Update message is to have the correspondent node
change the status of the care-of-address registration from tentative
to regular.
When the correspondent node receives the Early Binding Update message
from the mobile node, it creates a tentative binding-cache entry with
the mobile node's new care-of address. The correspondent node uses
the mobile node's new care-of address as soon as the binding-cache
entry is in place. Thus, with Early Binding Updates, the
correspondent node can use the mobile node's new care-of address
about one round-trip time sooner than with standard binding updates.
A tentative binding-cache entry's lifetime is limited to a few
seconds, within which the correspondent node expects the mobile node
to run a successful care-of-address test. When the correspondent node
receives the Binding Update message, it extends the lifetime of the
mobile node's tentative binding-cache entry to the regular lifetime
proposed in [1]. The tentative binding-cache entry will be deleted,
if the Binding Update message fails to be delivered to the
correspondent node during the binding-cache entry's lifetime - which
clearly is the case if the mobile node fails to run a successful
care-of-address test. Further data packets will then be sent via the
mobile node's home agent.
Early Binding Updates are a fully backward-compatible extension to
the binding-update procedure defined in [1]. All messages related to
standard binding updates remain unchanged and retain their original
meaning. Moreover, a mobile node may initiate an Early Binding Update
without knowing whether or not this optimization is supported by the
Vogt, Ed., et al. Expires August 4, 2004 [Page 5]
Internet-Draft Early Binding Updates February 2004
correspondent node. If the correspondent node does not support Early
Binding Updates, the mobile node's Early Binding Update message has
no effect, and the binding-update procedure is automatically reduced
to the standard procedure.
3. Standard Binding Updates
This section is a recap on the standard binding-update procedure,
which allows a mobile node to register its care-of address with a
correspondent node. The procedure is depicted in Figure 1. The
complete definition can be found in [1].
Mobile Node Home Agent Correspondent Node
~~~~~ [Handover]
Binding Update (1)
|-------------------->|
Home Test Init (2)
|-------------------->|-------------------->|
Care-of Test Init (3)
|------------------------------------------>|
Binding Acknowledgement (4)
|<--------------------|
Home Test (5)
|<--------------------|<--------------------|
Care-of Test (6)
|<------------------------------------------|
Binding Update (7)
|------------------------------------------>|
Binding Acknowledgement (8)
|<------------------------------------------|
Figure 1: Standard Binding Update
When the mobile node detects that it has moved to a different
network, it configures a new care-of address. The mobile node then
Vogt, Ed., et al. Expires August 4, 2004 [Page 6]
Internet-Draft Early Binding Updates February 2004
sends to its home agent a Binding Update message (1). The Binding
Update message informs the home agent about the mobile node's new
care-of address. It is authenticated by means of an IPsec security
association between the mobile node and the home agent.
After this, the mobile node sends to the correspondent node two
messages in parallel: a Home Test Init message and a Care-of Test
Init message. The Home Test Init message (2) is tunneled to the
mobile node's home agent, and forwarded on to the correspondent node.
The Home Test Init message includes a random Home Init Cookie. The
Home Init Cookie will be returned by the correspondent node in the
Home Test message. Both the Home Test Init message and the Home Test
message are protected by IPsec on the path between the mobile node
and the mobile node's home agent. They are unprotected on the path
between the mobile node's home agent and the correspondent node. On
the latter path, a malicious node may potentially eavesdrop on the
Home Init Cookie and return it in a spoofed Home Test message. For
this reason, having to return the cookie restricts the sender of the
Home Test message to the path between the mobile node's home agent
and the correspondent node. The mobile node considers this a
sufficient proof that the Home Test message was generated by the
correspondent node itself.
The Care-of Test Init message (3) does not go through the mobile
node's home agent. It takes the direct path to the correspondent
node. The Care-of Test Init message includes a random Care-of Init
Cookie. The Care-of Init Cookie will be returned by the correspondent
node in the Care-of Test message. Both the Care-of Test Init and the
Care-of Test messages are not protected by IPsec. A malicious node
may potentially eavesdrop on the Care-of Init Cookie and return it in
a spoofed Care-of Test message. For this reason, having to return the
cookie restricts the sender of the Care-of Test message to the path
between the mobile node and the correspondent node. The mobile node
considers this a sufficient proof that the Care-of Test message was
generated by the correspondent node itself.
When the home agent receives the Binding Update message, it registers
the mobile node's new care-of address. If the home agent maintains an
IPsec tunnel to the mobile node, it also updates the corresponding
security association to the new care-of address [2]. The home agent
sends back to the mobile node a Binding Acknowledgement message (4)
to indicate successful care-of-address registration. The Binding
Acknowledgement message is authenticated by means of an IPsec
security association between the mobile node and the home agent.
When the correspondent node receives the Home Test Init message, it
sends back to the mobile node a Home Test message (5). The Home Test
message is directed to the mobile node's home address, hence passes
Vogt, Ed., et al. Expires August 4, 2004 [Page 7]
Internet-Draft Early Binding Updates February 2004
the mobile node's home agent. The Home Test message contains a Home
Keygen Token, a Home Nonce Index, and the Home Init Cookie copied
from the Home Test Init message. The Home Keygen Token will be used
by the mobile node when producing the Binding Management Key, as
described below. The Home Nonce Index identifies a random value based
on which the correspondent node has computed the Home Keygen Token.
The mobile node will include the Home Nonce Index in the subsequent
Binding Update message to allow the correspondent node to reproduce
the Home Keygen Token.
Likewise, upon receiving the Care-of Test Init message, the
correspondent node sends back to the mobile node a Care-of Test
message (6). The Care-of Test message is directed to the mobile
node's new care-of address, hence does not pass the mobile node's
home agent. The Care-of Test message contains a Care-of Keygen Token,
a Care-of Nonce Index, and the Care-of Init Cookie copied from the
Care-of Test Init message. The Care-of Keygen Token will be used by
the mobile node when producing the Binding Management Key, as
described below. The Care-of Nonce Index identifies a random value
based on which the correspondent node has computed the Care-of Keygen
Token. The mobile node will include the Care-of Nonce Index in the
subsequent Binding Update message to allow the correspondent node to
reproduce the Care-of Keygen Token.
The mobile node uses the Home Keygen Token and the Care-of Keygen
Token to produce a secret key, the Binding Management Key, shared
with the correspondent node. The Binding Management Key is a one-way
hash on the concatenation of the Home Keygen Token and the Care-of
Keygen Token.
The mobile node then generates a Binding Update message (7) to be
sent to the correspondent node. The Binding Update message contains a
message-authentication code produced with the Binding Management Key.
It also contains the Home Nonce Index and the Care-of Nonce Index.
The mobile node may request the correspondent node to return a
Binding Acknowledgement message by raising the A-flag in the Binding
Update message. A conservative mobile node would wait for the Binding
Acknowledgement message before using its new care-of address. An
optimistic mobile node would start using its new care-of address as
soon as having dispatched the Binding Update message.
When the correspondent node receives the Binding Update message, it
can reproduce the Home Keygen Token and the Care-of Keygen Token with
the help of the two nonce indices. The tokens, in turn, allow the
correspondent node to reproduce the Binding Management Key. The
correspondent node can then compute what the message-authentication
code in the Binding Update message should look like. If the result
matches the message-authentication code in the Binding Update
Vogt, Ed., et al. Expires August 4, 2004 [Page 8]
Internet-Draft Early Binding Updates February 2004
message, the correspondent node can assume two things. First, the
mobile node must have received the Home Keygen Token in order to
construct the Binding Management Key with which the
message-authentication code was produced. Therefore, the mobile node
is the legitimate owner of the home address with high probability,
since the Home Keygen Token was sent, as part of the Home Test
message, to the mobile node's home address. Second, the mobile node
must have received the Care-of Keygen Token in order to construct the
Binding Management Key. Hence, the mobile node is apparently
reachable through the new care-of address, since the Care-of Keygen
Token was sent, as part of the Care-of Test message, to the mobile
node's care-of address. Beyond this, the message-authentication code
validates the Binding Update message's integrity.
Provided that the message-authentication code coming along with the
Binding Update message is correct, the correspondent node creates a
binding-cache entry with the mobile node's new care-of address. The
correspondent node uses the mobile node's new care-of address as soon
as the binding-cache entry is in place. In case the A-flag in the
Binding Update message is set, the correspondent node sends back to
the mobile node a Binding Acknowledgement message (8) to indicate
successful care-of-address registration.
4. Early Binding Updates
In this section, we specify the procedure of Early Binding Updates,
our proposed modification of the standard binding-update procedure.
Early Binding Updates evade the latency of the two address tests
associated with a standard binding update. For this, the two address
tests are temporally decoupled. A mobile node executes a home-address
test whenever a handover is imminent. If handovers cannot be
anticipated, the mobile node may periodically repeat the home-address
test. Either way, the mobile node has at hand a fresh Home Keygen
Token when it changes its point of network attachment, and it does
not need to wait for a lengthy home-address test during the binding
update. The care-of-address test is performed after having signaled
the new care-of address to the correspondent node, and in parallel
with sending data to and from the new care-of address. [1] suggests
running both tests in parallel and after a handover. However, the
mobile node may trigger a home-address test before it moves without
violating the protocol procedure.
We introduce two new messages: an Early Binding Update message and an
Early Binding Acknowledgement message. The mobile node sends to the
correspondent node an Early Binding Update message when it wants to
Vogt, Ed., et al. Expires August 4, 2004 [Page 9]
Internet-Draft Early Binding Updates February 2004
register a new care-of address without yet having accomplished a
care-of-address test. The mobile node may request the correspondent
node to return an Early Binding Acknowledgement message. All messages
of the standard binding-update procedure remain unchanged and retain
their original meaning. Hence, a mobile node may initiate an Early
Binding Update without knowledge of whether or not the correspondent
node supports this. In case the correspondent node does not support
Early Binding Updates, the binding update is automatically reduced to
the standard procedure.
We provide a detailed specification of Early Binding Updates in
Section 4.1. We elaborate on the concurrent care-of-address test in
Section 4.2. In Section 4.3, we discuss the special case of
registering a care-of address without having done a home-address test
in advance.
4.1 Protocol Specification
This section provides a detailed specification of Early Binding
Updates. The procedure is summarized in Figure 2.
A mobile node triggers a home-address test, steps (1) and (2) in
Figure 2, whenever a handover is imminent. If handovers cannot be
anticipated, the mobile node may periodically repeat the home-address
test. Either way, the mobile node has at hand a fresh Home Keygen
Token when it changes its point of network attachment. The Home Test
Init and Home Test messages used for an Early Binding Update are the
same as the ones used for a standard binding update.
The time after which the mobile node repeats the home-address test
should be conservatively determined as the minimum time,
MAX_TOKEN_LIFETIME [1], a token is expected to be valid.
Alternatively, one might consider adding a Lifetime option to the
Home Test message to explicitly indicate the time after which the
Home Keygen Token becomes expired. The Lifetime option could help the
mobile node determine when to initiate the next home-address test.
The introduction of a new option would not interfere with Mobile IPv6
implementations that do not support Early Binding Updates. The new
option would simply be ignored and skipped by a node that does not
recognize the option. See section 6.1.5 of [1] for details on this.
The Home Test Init and Home Test messages are typically protected by
an IPsec tunnel between the home agent and the mobile node [2]. The
home agent must update the corresponding security association to the
mobile node's new care-of address when the mobile node changes its
point of network attachment. With Early Binding Updates, the
care-of-address change does not affect a home-address test, because
Vogt, Ed., et al. Expires August 4, 2004 [Page 10]
Internet-Draft Early Binding Updates February 2004
the home-address test is performed before the mobile node moves. This
is a difference to a standard binding update, where a home agent must
update the security association when it receives a Binding Update
message from the mobile node. Otherwise, the Home Test message could
not be delivered back to the mobile node through the IPsec tunnel
[2].
Mobile Node Home Agent Correspondent Node
Home Test Init (1)
|-------------------->|-------------------->|
Home Test (2)
|<--------------------|<--------------------|
~~~~~ [Handover]
Binding Update (3)
|-------------------->|
Early Binding Update (4)
|------------------------------------------>|
Care-of Test Init (5)
|------------------------------------------>|
Binding Acknowledgement (6)
|<--------------------|
Early Binding Acknowledgement (7)
|<------------------------------------------|
Care-of Test (8)
|<------------------------------------------|
Binding Update (9)
|------------------------------------------>|
Binding Acknowledgement (10)
|<------------------------------------------|
Figure 2: Early Binding Update
When the mobile node detects that it has moved to a different
network, it configures a new care-of address. The mobile node then
sends to its home agent a Binding Update message (3). The Binding
Vogt, Ed., et al. Expires August 4, 2004 [Page 11]
Internet-Draft Early Binding Updates February 2004
Update message informs the home agent about the mobile node's new
care-of address. It is authenticated by means of an IPsec security
association between the mobile node and the home agent.
Having sent the Binding Update message to its home agent, the mobile
node produces an Early Binding Management Key, which is a one-way
hash on the Home Keygen Token from the most recently received Home
Test message. The mobile node then generates an Early Binding Update
message (4) to be sent to the correspondent node and to be
authenticated with the Early Binding Management Key. The Early
Binding Management Key does not incorporate a Care-of Keygen Token as
the Binding Management Key used for a standard binding update does.
However, since the Care-of Keygen Token is irrelevant for
"authentication" purposes, but proves that some node can be reached
given its care-of address, it stands to reason that the Early Binding
Management Key is sufficient for authenticating the Early Binding
Update message. The mobile node will provide proof of its
reachability at the new care-of address at a later stage, when it
sends to the correspondent node a standard Binding Update message.
The mobile node will then need to generate an additional, standard
Binding Management Key on the basis of both the Home Keygen Token and
the Care-of Keygen Token. Note that [1] uses a key equivalent to the
Early Binding Management Key when deleting an existing binding-cache
entry. See section 5.2.5 of [1] for details on this.
The Early Binding Update message contains a message-authentication
code and the Home Nonce Index copied from the most recently received
Home Test message. There are two differences between the Early
Binding Update message and the Binding Update message used during a
standard binding update. First, the message-authentication code in
the Early Binding Update message is produced with the Early Binding
Management Key, which does not incorporate a Care-of Keygen Token.
Second, the Early Binding Update message does not contain a Care-of
Nonce Index. Note that [1] uses a message similar to the Early
Binding Update message when deleting an existing binding-cache entry.
See sections 6.1.7 and 6.2.6 of [1] for details on this. The mobile
node may request the correspondent node to return an Early Binding
Acknowledgement message by raising the A-flag in the Early Binding
Update message. A conservative mobile node would wait for the Early
Binding Acknowledgement message before using its new care-of address.
An optimistic mobile node would start using its new care-of address
as soon as having dispatched the Early Binding Update message.
Assuming that no packet reordering occurs on the path between the
mobile node and the correspondent node, the Early Binding Update
message will come in at the correspondent node ahead of all data
packets which the mobile node has sent from its new care-of address.
Whether conservative or optimistic, with Early Binding Updates, the
mobile node can use its new care-of address about one round-trip time
Vogt, Ed., et al. Expires August 4, 2004 [Page 12]
Internet-Draft Early Binding Updates February 2004
sooner than with standard binding updates. See Section 5 for an
efficiency analysis.
The mobile node sends to the correspondent node a Care-of Test Init
message (5) in parallel with sending the Early Binding Update
message. The Care-of Test Init message used for an Early Binding
Update is the same as the one used for a standard binding update.
When the home agent receives the Binding Update message, it registers
the mobile node's new care-of address. If the home agent maintains an
IPsec tunnel to the mobile node, it also updates the corresponding
security association to the new care-of address [2]. The home agent
sends back to the mobile node a Binding Acknowledgement message (6)
to indicate successful care-of-address registration. The Binding
Acknowledgement message is authenticated by means of an IPsec
security association between the mobile node and the home agent.
When the correspondent node receives the Early Binding Update
message, it can reproduce the Home Keygen Token with the help of the
Home Nonce Index. The token, in turn, allows the correspondent node
to reproduce the Early Binding Management Key. The correspondent node
can then compute what the message-authentication code in the Early
Binding Update message should look like. If the result matches the
message-authentication code in the Early Binding Update message, the
mobile node must have received the Home Keygen Token in order to
construct the Early Binding Management Key with which the
message-authentication code was produced. Therefore, the
correspondent node can assume that the mobile node is the legitimate
owner of the home address, since the Home Keygen Token was sent, as
part of the Home Test message, to the mobile node's home address.
Beyond this, the message-authentication code validates the Early
Binding Update message's integrity.
Provided that the message-authentication code coming along with the
Early Binding Update message is correct, the correspondent node
creates a tentative binding-cache entry with the mobile node's new
care-of address. The correspondent node uses the mobile node's new
care-of address as soon as the binding-cache entry is in place. Thus,
with Early Binding Updates, the correspondent node can use the mobile
node's new care-of address about one round-trip time sooner than with
standard binding updates. See Section 5 for an efficiency analysis.
Since a care-of-address test still has to be performed for the mobile
node's new care-of address, the lifetime of the new binding-cache
entry is limited to TENTATIVE_BINDING_LIFETIME. The lifetime will be
extended when the correspondent node receives a standard Binding
Update message from the mobile node. See Section 4.2 for details on
the concurrent care-of-address test. In case the A-flag in the Early
Vogt, Ed., et al. Expires August 4, 2004 [Page 13]
Internet-Draft Early Binding Updates February 2004
Binding Update message is set, the correspondent node sends back to
the mobile node an Early Binding Acknowledgement message (7) to
indicate tentative care-of-address registration.
When the correspondent node receives the Care-of Test Init message,
it sends to the mobile node a Care-of Test message (8). The Care-of
Test message used for an Early Binding Update is the same as the one
used for a standard binding update.
The Care-of Test message delivers to the mobile node a Care-of Keygen
Token. The mobile node uses this Care-of Keygen Token together with
the Home Keygen Token from the most recently received Home Test
message to produce a standard Binding Management Key. This Binding
Management Key is a one-way hash on the concatenation of the Home
Keygen Token and the Care-of Keygen Token. It is equivalent to the
Binding Management Key used for a standard binding update.
The mobile node then generates a standard Binding Update message (9)
to be sent to the correspondent node. This Binding Update message
contains a message-authentication code produced with the Binding
Management Key. It is equivalent to the Binding Update message used
for a standard binding update. The mobile node may request the
correspondent node to return a Binding Acknowledgement message by
raising the A-flag in the Binding Update message.
When the correspondent node receives the Binding Update message, it
checks the message's authenticity as described in Section 3. Provided
that the Binding Update message is properly authenticated, the
correspondent node extends the lifetime of the mobile node's
tentative binding-cache entry to the regular lifetime proposed in
[1]. In case the A-flag in the Binding Update message is set, the
correspondent node sends back to the mobile node a standard Binding
Acknowledgement message (10) to indicate successful care-of-address
registration. This Binding Acknowledgement message is equivalent to
the one used for a standard binding update.
4.2 Concurrent Care-of Address Tests
In this section, we elaborate on the concurrent care-of-address test.
A concurrent care-of-address test is performed after a mobile node
has signaled to the correspondent node a new care-of address. It runs
in parallel with sending data to and from the new care-of address.
The concurrent care-of-address test facilitates data transfer while
testing a mobile node's reachability. It requires the correspondent
node to create a tentative binding-cache entry with the mobile node's
new care-of address before a care-of-address test has been
accomplished.
Vogt, Ed., et al. Expires August 4, 2004 [Page 14]
Internet-Draft Early Binding Updates February 2004
Data transfer to and from a yet-unverified care-of address is limited
to a tentative binding-cache entry's lifetime,
TENTATIVE_BINDING_LIFETIME. On one hand, this lifetime is thought to
be long enough to outlast the care-of-address test to be performed
during that time. On the other hand, the lifetime is thought to be
short enough to discourage the exploitation of concurrent
care-of-address tests for flooding attacks.
When the correspondent node receives a properly authenticated Binding
Update message from the mobile node, it extends the lifetime of the
tentative binding-cache entry to the regular lifetime proposed in
[1]. If the Binding Update message arrives before the binding-cache
entry expires, data transfer can continue without disruption. If the
Binding Update message fails to arrive before the binding-cache entry
expires, the correspondent node must stop sending further data
packets to the mobile node's new care-of address. Subsequent data
packets will then be sent to the mobile node's home address. See
Section 6.2 for a discussion on why this is a feasible modus
operandi.
4.3 Initial Care-of Address Registration
In Section 4.1, a mobile node is expected to have acquired a valid
Home Keygen Token prior to changing its point of network attachment.
There are scenarios, however, in which this is not a feasible
assumption. For example, the mobile may be connected to its home link
before changing its point of network attachment. At home, the mobile
node does not use Mobile IPv6. It hence does not run a home-address
test, and it does not acquire a Home Keygen Token, before it moves to
a foreign link. Also, when the mobile node powers on at a foreign
link, it does not have a valid Home Keygen Token either. The mobile
node may even be offline for a while and unable to run the
home-address test. Any previously obtained Home Keygen Token is
likely to be expired when the mobile node reconnects to a foreign
link.
One may consider letting the mobile node perform a home-address test
even while being at home. This could accelerate handovers from the
home link to a foreign link. The Home Test Init and Home Test
messages would continue to obey to the rules defined in sections 9.4
and 11.6 of [1], except that they would not have to be tunneled
between the mobile node and its home agent. Nonetheless, performing a
home-address test from the home network does not help when a mobile
node reconnects to a foreign network after an offline period or after
booting up. Obviously, the mobile node must have a chance to register
a care-of address with its correspondent node without having acquired
a Home Keygen Token beforehand.
Vogt, Ed., et al. Expires August 4, 2004 [Page 15]
Internet-Draft Early Binding Updates February 2004
These observations lead to the following exception: When a mobile
node wants to register a new care-of address with a correspondent
node, and the mobile node does not yet know a valid Home Keygen
Token, the mobile node runs a standard binding update instead of an
Early Binding Update. When the standard binding update is complete,
the mobile node can communicate through its new care-of address. The
mobile node will henceforth trigger a home-address test whenever a
handover is imminent. If handovers cannot be anticipated, the mobile
node may periodically repeat the home-address test. Either way, the
mobile node will have available a fresh Home Keygen Token when it
changes its point of network attachment the next time so as to apply
an Early Binding Update then.
5. Efficiency Considerations
In this section, we consider the impact on efficiency that a binding
update may have. We examine standard binding updates in Section 5.1,
and we analyze Early Binding Updates in Section 5.2.
5.1 Standard Binding Updates
When the mobile node detects that it has moved to a different
network, it configures a new care-of address. [1] defines that a
mobile node must do the following steps before it can use the new
care-of address: First, the mobile node must register the new care-of
address with its home agent. Second, the home-address test and,
third, the care-of-address test must be executed. Fourth, the mobile
node must register the new care-of address with its correspondent
node.
Registering the new care-of address with the home agent is a two-way
message exchange between the mobile node and the mobile node's home
agent. It consists of a Binding Update message and a Binding
Acknowledgement message. Let RTT_HA be the round-trip time for the
Binding Update and Binding Acknowledgement messages. Here, HA means
"home agent".
The home-address test is a two-way message exchange between the
mobile node and the correspondent node. It consists of a Home Test
Init message and a Home Test message, both of which are tunneled
between the mobile node and the mobile node's home agent. Let the
round-trip time for the Home Test Init and Home Test messages be
RTT_BT. Here, BT means "bidirectional tunneling".
The care-of-address test is a two-way message exchange between the
Vogt, Ed., et al. Expires August 4, 2004 [Page 16]
Internet-Draft Early Binding Updates February 2004
mobile node and the correspondent node. It consists of a Care-of Test
Init message and a Care-of Test message, both of which are relayed on
the direct path between the mobile node and the correspondent node.
They do not pass the mobile node's home agent. Let the round-trip
time for the Care-of Test Init and Care-of Test messages be RTT_RO.
Here, RO means "route optimization".
The mobile node may dispatch the Home Test Init and Care-of Test Init
messages at any time after having sent the Binding Update message to
the home agent. The mobile node may thus send out all three messages
virtually in parallel. It takes approximately RTT_HA time until the
mobile node receives the Binding Acknowledgement message from its
home agent. The time until the mobile node receives the Home Test
message from the correspondent node is approximately RTT_BT. Finally,
it takes approximately RTT_RO time until the Care-of Test message
arrives at the mobile node. The mobile node must wait for all three
messages before it can register its new care-of address with the
correspondent node.
Registering the new care-of address with the correspondent node is a
one-way or two-way message exchange between the mobile node and the
correspondent node. It consists of a Binding Update message and an
optional Binding Acknowledgement message. The mobile node may request
the correspondent node to return a Binding Acknowledgement message by
raising a flag in the Binding Update message. A conservative mobile
node would wait for the Binding Acknowledgement message before using
its new care-of address. An optimistic mobile node would start using
its new care-of address as soon as having dispatched the Binding
Update message.
All things considered, a standard binding update's total latency with
respect to sending data from a new care-of address can be
approximated by
STD_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO
STD_LATENCY_SEND_OPTIMST = Max (RTT_HA, RTT_BT, RTT_RO)
Here, STD_LATENCY_SEND_CONSERV pertains to a conservative mobile
node, which waits for the returning Binding Acknowledgement message
before it uses its new care-of address. STD_LATENCY_SEND_OPTIMST
pertains to an optimistic mobile node, which uses its new care-of
address as soon as having dispatched the Binding Update message.
Whether or not the mobile node waits for the returning Binding
Acknowledgement message, the correspondent node starts using the
mobile node's new care-of address upon receiving the mobile node's
Binding Update message. When the correspondent node switches to the
new care-of address, it takes another 0.5 RTT_RO time until the first
Vogt, Ed., et al. Expires August 4, 2004 [Page 17]
Internet-Draft Early Binding Updates February 2004
data packets arrive at the mobile node's new care-of address. Thus, a
standard binding update's total latency with respect to receiving
data at a new care-of address can be approximated by
STD_LATENCY_RECV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO
If the mobile node has already recently changed its point of network
attachment, it may reuse its previously acquired Home Keygen Token
without running another home-address test. In this situation, RTT_BT
reduces to zero, and Max (RTT_HA, RTT_BT, RTT_RO) = Max (RTT_HA,
RTT_RO).
5.2 Early Binding Updates
Moving from one point of network attachment to another involves a
handover and a binding update. During the handover, the mobile node
attaches to a new access point, re-authenticates itself, discovers a
new default router, and configures a new care-of address. During the
binding update, the mobile node signals to its correspondent node and
its home agent the new care-of address. More specifically, the mobile
node runs a home-address test and a care-of-address test, and it
sends a Binding Update message to both its correspondent node and its
home agent.
One might consider three candidate periods during which to execute
the home-address test and the care-of address test. These candidate
periods are as follows.
(1) Before handover
(2) After handover, but before binding update
(3) After binding update
The home-address test is intended to authenticate a node's home
address. For this reason, the home-address test must be performed at
either (1) or (2), but cannot be performed at (3). In [1], the
home-address test is preferably done at (2), but it may also take
place at (1). Technically, there is nothing that prevents a mobile
node from initiating the home-address test at (1). The mobile node
just needs to make sure that the Home Keygen Token from the
home-address test is still valid at the time the binding update is
done.
The care-of-address test is intended to prove that the mobile node is
reachable at its new care-of address. Therefore, the care-of-address
test obviously cannot be done at (1). In [1], the care-of-address
test is done at (2), i.e., it runs in parallel with the home-address
test. We claim that testing the mobile node's reachability at its new
Vogt, Ed., et al. Expires August 4, 2004 [Page 18]
Internet-Draft Early Binding Updates February 2004
care-of address may also be done at (3). Data transmission to and
from the new care-of address may wait or, as with Early Binding
Updates, start with appropriate restrictions until the mobile node
has provided proof to the correspondent node that it is reachable at
its new care-of address.
With Early Binding Updates, the home-address test is moved to (1),
and the care-of-address test is moved to (3). The home-address test
does no longer delay the binding update, because it runs while the
mobile node still uses a functioning, fully registered care-of
address. The care-of-address test does no longer delay the binding
update either, because it runs while the mobile node uses a new,
tentatively registered care-of address. There are two things that
remain to be done after a handover: First, the mobile node must
register the new care-of address with its home agent. Second, the
mobile node must tentatively register the new care-of address with
the correspondent node.
Registering the new care-of address with the home agent is a two-way
message exchange between the mobile node and the mobile node's home
agent. It consists of a Binding Update message and a Binding
Acknowledgement message. Let RTT_HA be the round-trip time for the
Binding Update and Binding Acknowledgement messages. Here, HA means
"home agent".
Tentatively registering the new care-of address with the
correspondent node is a one-way or two-way message exchange between
the mobile node and the correspondent node. It consists of an Early
Binding Update message and an optional Early Binding Acknowledgement
message. The mobile node may request the correspondent node to return
an Early Binding Acknowledgement message by raising a flag in the
Early Binding Update message. Let the round-trip time for the Early
Binding Update and Early Binding Acknowledgement messages be RTT_RO.
Here, RO means "route optimization".
A conservative mobile node would wait for both the Binding
Acknowledgement message from its home agent and the Early Binding
Acknowledgement from its correspondent node before using its new
care-of address. An optimistic mobile node would start using its new
care-of address as soon as having dispatched the Binding Update and
Early Binding Update messages.
All things considered, an Early Binding Update's total latency with
respect to sending data from a new care-of address can be
approximated by
NEW_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_RO)
Vogt, Ed., et al. Expires August 4, 2004 [Page 19]
Internet-Draft Early Binding Updates February 2004
NEW_LATENCY_SEND_OPTIMST = 0
Here, NEW_LATENCY_SEND_CONSERV pertains to a conservative mobile
node, which waits for both the Binding Acknowledgement message
returning from its home agent and the Early Binding Acknowledgement
returning from its correspondent node before it uses its new care-of
address. NEW_LATENCY_SEND_OPTIMST pertains to an optimistic mobile
node, which uses its new care-of address as soon as having dispatched
the Binding Update and Early Binding Update messages.
Whether or not the mobile node waits for the returning Binding
Acknowledgement and Early Binding Acknowledgement messages, the
correspondent node starts using the mobile node's new care-of address
upon receiving the mobile node's Early Binding Update message. When
the correspondent node switches to the new care-of address, it takes
another 0.5 RTT_RO time until the first data packets arrive at the
mobile node's new care-of address. Thus, an Early Binding Update's
total latency with respect to receiving data can be approximated by
NEW_LATENCY_RECV = RTT_RO
This evaluation shows that an Early Binding Update is about a
round-trip time faster than a standard binding update. This is true
even if the mobile node is able to reuse a previously acquired Home
Keygen Token without running another home-address test. The new
responsiveness to mobility will be of true benefit for
delay-sensitive applications.
Section 4.3 discusses the initial care-of-address registration,
during which the mobile node does not yet know a valid Home Keygen
Token. In this situation, the mobile node must perform a standard
binding update, and there is no efficiency improvement. However, we
point out that having to resort to a standard binding update is
limited to only very few scenarios and will rather be an exception.
6. Security Considerations
In this section, we elaborate on security implications that come
along with using Early Binding Updates instead of standard binding
updates. There are two conceptual differences between an Early
Binding Update and a standard binding update. First, with the Early
Binding Update, the home-address test is decoupled from the
care-of-address test, and the Early Binding Management Key used to
authenticate an Early Binding Update message is produced with the
Home Keygen Token only. In contrast, the Binding Management Key used
for a standard binding update is produced with both the Home Keygen
Vogt, Ed., et al. Expires August 4, 2004 [Page 20]
Internet-Draft Early Binding Updates February 2004
Token and the Care-of Keygen Token. We discuss this matter in Section
6.1. Second, we propose to execute the care-of-address test in
parallel with sending data to and from the new care-of address. A
malicious - yet properly authenticated - node can so wage a flooding
attack for a limited time. We analyze this issue in Section 6.2. We
also propose precautions against a flooding attack.
For a comprehensive taxonomy of mobility-related attacks, we refer to
the Mobile IPv6 Route Optimization Security Design Background [3].
The document provides a thorough understanding of what has guided the
design of the standard binding-update procedure.
6.1 Decoupled Address Tests
During a standard binding update, a mobile node must accomplish both
the home-address test and the care-of-address test before it can
signal to its correspondent node a new care-of address. During an
Early Binding Update, the home-address test is sufficient to let the
correspondent node tentatively register a new care-of address. The
tentative registration becomes a regular one once the mobile node has
provided proof to the correspondent node that it is reachable at its
new care-of address.
Temporally decoupling the home-address test from the care-of-address
test means separating an authenticity check from a validity check.
The authenticity check indicates that the mobile node is the
legitimate owner of the IP address which the mobile node claims to
own as its home address. The validity check indicates that the mobile
node is reachable through the IP address which the mobile node wishes
to register as its care-of address.
The consequence is this: During the standard binding update, when a
mobile node's Binding Update message arrives at a correspondent node,
the correspondent node knows that the message is authentic and that
the mobile node is reachable through its new care-of address. During
the Early Binding Update, when a mobile node's Early Binding Update
message arrives at a correspondent node, the correspondent node can
trust in the message's authenticity, but it must wait until
completion of the care-of-address test before it can assume that the
mobile node is reachable through its new care-of address. The maximum
time of uncertainty can be configured by the
TENTATIVE_BINDING_LIFETIME protocol-configuration variable.
The question is whether separating the two address tests makes
authentication of binding updates less secure or not. Recall that an
Early Binding Update message requires only a Home Keygen Token to be
authenticated, whereas a Binding Update message requires both a Home
Vogt, Ed., et al. Expires August 4, 2004 [Page 21]
Internet-Draft Early Binding Updates February 2004
Keygen Token and a Care-of Keygen Token. The Home Keygen Token and
the Care-of Keygen Token are likely to arrive at the mobile node via
disjoint paths: The former passes through the mobile node's home
agent, the latter does not. An attacker will thus have a hard time to
capture both tokens. One might wonder whether the simpler
authentication of an Early Binding Update message makes Early Binding
Updates open to eavesdropping and man-in-the-middle attacks. Next, we
argue that this is not the case.
Consider an attacker who intends to exploit Early Binding Updates.
The attacker may want to impersonate the mobile node or the
correspondent node, sending messages on behalf of one or both of
them. The attacker may also want to eavesdrop on signaling messages
in order to gather the information it needs for a later strike. In
either case, the attacker will have to get active on the home-address
test, because the home-address test is decisive for the mobile node's
authenticity. For this, the mobile node needs to be located on the
path between the mobile node's home agent and the correspondent node,
because data on the path between the mobile node and its home agent
is protected by IPsec. The attacker thus has to be somewhere within
the fixed Internet. Having to tamper with static infrastructure,
however, is assumed to be an obstacle significant enough to prevent
many such attacks [3].
Suppose that, in spite of hurdles, there is an attacker which has
access to the path between the mobile node's home agent and the
correspondent node. This attacker is in a position to listen to or
intercept the Home Test Init and Home Test messages as well as to
spoof these and other Mobile IPv6 messages. The likely purpose behind
such an attack is to impersonate the mobile node, to install a false
binding on behalf of the mobile node, and to divert the mobile node's
data to an arbitrary location. The point is that, due to the
attacker's position, such an attack can be accomplished even with the
standard binding-update procedure. For this, the attacker listens to
the Home Test message on its way from the correspondent node to the
mobile node's home agent. It may also send to the correspondent node
a spoofed Home Test Init message and intercept the returning Home
Test message. The attacker then sends to the correspondent node a
spoofed Care-of Test Init message. The attacker will probably use a
care-of address through which it is reachable, for instance, its own
current care-of address or its home address. This way, the attacker
makes sure that it receives the returning Care-of Test message. The
Care-of Test Init message can be sent from anywhere in the Internet
unless prevented by ingress filtering. Since ingress filtering is not
universally employed, sending the spoofed Care-of Test Init message
is not difficult. Having the Home Test message and the Care-of Test
message, the attacker can authenticate a fraud Binding Update
message.
Vogt, Ed., et al. Expires August 4, 2004 [Page 22]
Internet-Draft Early Binding Updates February 2004
This discussion shows that eavesdropping and impersonation is not
prevented by taking the disjoint-paths approach of the standard
binding-update procedure. Instead, access to a particular path within
the fixed Internet is already enough. We hence believe that an Early
Binding Update is equally secure than a standard binding update with
respect to these attacks.
6.2 Concurrent Care-of Address Tests
A successful care-of-address test provides reasonable assurance to
the correspondent node that the mobile node is reachable through the
IP address which the mobile node wishes to register as its care-of
address. This assurance is a necessary precaution against flooding
attacks. If no care-of-address test was performed, a malicious mobile
node could start downloading large volumes of data from multiple
correspondent nodes and direct these data flows to an arbitrary IP
address.
Early Binding Updates allow a mobile node to use a new care-of
address while the care-of-address test is in progress. This strategy
reduces the latency associated with a binding update. Concerning
security against flooding attacks, Early Binding Updates are at a
minor disadvantage with standard binding updates, because a malicious
node may exploit the time window during which a correspondent node
sends data to a yet-unverified care-of address. We propose two ways
to mitigate this threat.
One way is to properly configure the lifetime of a tentative
binding-cache entry. We propose the value,
TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where
flooding attacks cannot be ruled out, one should appropriately reduce
TENTATIVE_BINDING_LIFETIME.
Another way to mitigate the threat of flooding attacks is to grant
Early Binding Updates to trusted nodes only. Recall that the
correspondent node can authenticate a mobile node at the time it
receives an Early Binding Update message from the mobile node. In
other words, the correspondent node can assume that the mobile node
is the legitimate owner of the IP address which the mobile node uses
as its home address. This, in turn, allows the correspondent node to
use the mobile node's home address as a criterion for deciding
whether or not to install a tentative binding-cache entry with the
mobile node's new care-of address. For instance, the correspondent
node may be a corporate server which grants Early Binding Updates to
mobile nodes from the corporate network only.
Due to the ability to configure, and selectively apply, Early Binding
Vogt, Ed., et al. Expires August 4, 2004 [Page 23]
Internet-Draft Early Binding Updates February 2004
Updates, we believe that the optimization's disadvantage concerning
security against flooding attacks is negligible in most practical
scenarios.
7. Conclusion
Mobile IPv6 defines two address tests that must be performed before a
mobile node can register a new care-of address with its correspondent
node: a home-address test and a care-of-address test. The long
latency associated with the address tests makes it difficult for
delay-sensitive applications to hold up service quality during a
binding update.
We propose a strategy, Early Binding Updates, to move both address
test out of the critical period during which a new care-of address
cannot yet be used. We perform the home-address test before the
mobile node changes its point of network attachment. We execute the
care-of-address test in parallel with sending data to and from the
new care-of address.
We evaluate Early Binding Updates with respect to the standard
binding-update procedure. We find that an Early Binding Update can be
accomplished in half, or less, of the time that a standard binding
update takes. Moreover, we show that an Early Binding Update is
nearly equivalent to a standard binding update with respect to
security, and that it marginally increases the resources required at
the correspondent node.
Early Binding Updates are realized as an optional, and fully
backward-compatible, extension to Mobile IPv6. Early Binding Updates
use two new messages, both of which have no effect if either
communication end-point does not support them.
8. Protocol Configuration Variables
TENTATIVE_BINDING_LIFETIME 3 seconds (default)
References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June
2003.
Vogt, Ed., et al. Expires August 4, 2004 [Page 24]
Internet-Draft Early Binding Updates February 2004
[2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in
progress), July 2003.
[3] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work
in progress), December 2003.
Authors' Addresses
Christian Vogt (Editor and Contact Person)
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-8282
Fax: +49-721-388-097
EMail: chvogt@tm.uka.de
URI: http://www.tm.uka.de/~chvogt/
Roland Bless
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-6413
Fax: +49-721-388-097
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
Vogt, Ed., et al. Expires August 4, 2004 [Page 25]
Internet-Draft Early Binding Updates February 2004
Mark Doll
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-6403
Fax: +49-721-388-097
EMail: doll@tm.uka.de
URI: http://www.tm.uka.de/~doll/
Tobias Kfner
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Phone: +49-721-608-8282
Fax: +49-721-388-097
EMail: kuefner@tm.uka.de
URI: http://www.tm.uka.de/~kuefner/
Vogt, Ed., et al. Expires August 4, 2004 [Page 26]
Internet-Draft Early Binding Updates February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Vogt, Ed., et al. Expires August 4, 2004 [Page 27]
Internet-Draft Early Binding Updates February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vogt, Ed., et al. Expires August 4, 2004 [Page 28]