Network Working Group C. Vogt
Internet-Draft Universitaet Karlsruhe (TH)
Expires: August 31, 2006 February 27, 2006
Early Binding Updates for Mobile IPv6
draft-vogt-mobopts-simple-ebu-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile IPv6 defines a return-routability procedure for secure use of
route optimization between unacquainted nodes. Unfortunately, this
procedure is known to have undesired impacts on handoff latency.
This document specifies extensions to Mobile IPv6 that eliminate the
latency of the return-routability procedure. The extensions thus
provide a basis for more efficient reactive as well as proactive
handoff management. They are optional and fully backward-compatible.
Vogt Expires August 31, 2006 [Page 1]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Reactive Registration Procedure . . . . . . . . . . . . . 5
3.2 Proactive Registration Procedure . . . . . . . . . . . . . 8
4. Handling Unverified Care-of Addresses . . . . . . . . . . . . 11
5. Modifications to RFC 3775 . . . . . . . . . . . . . . . . . . 13
5.1 Overview of Mobile IPv6 Security (Section 5) . . . . . . . 13
5.2 Correspondent Node Operation (Section 9) . . . . . . . . . 18
5.3 Home Agent Operation (Section 10) . . . . . . . . . . . . 23
5.4 Mobile Node Operation (Section 11) . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Reachability . . . . . . . . . . . . . . . . . . . . . . . 36
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1 Normative References . . . . . . . . . . . . . . . . . . . 37
8.2 Informational References . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 38
A. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . 39
Vogt Expires August 31, 2006 [Page 2]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
1. Introduction
Mobile IPv6 [RFC3775] specifies a mode for route optimization,
enabling mobile nodes to register their current logical position in
the Internet with correspondent nodes. Peers can thus communicate
along a direct path in addition to sending their packets via a
stationary proxy of the mobile node, the mobile node's home agent.
Due to the typical absence of a pre-configured security context
between arbitrary Internet nodes, route optimization must be
protected in an ad-hoc manner against various types of impersonation,
denial-of-service, and flooding threats [RFC4225]. Specifically,
correspondent nodes verify a mobile node's reachability at its IP
addresses, both periodically and when the mobile node undergoes a
change in IP attachment. This is called the "return-routability
procedure"
Unfortunately, the return-routability procedure defined in [RFC3775]
does not permit mobile nodes to communicate with their peers while it
is being accomplished. This can have detrimental impacts on handoff
latencies and cause adverse behavior of delay-sensitive applications.
This document specifies optional and fully backward-compatible
extensions to Mobile IPv6 route optimization that allow for smoother
reactive handoffs. The extensions can also be used for proactive
handoff management where mobile nodes have the capabilities to
anticipate movements.
The extensions specified in this document where first proposed at the
59th IETF meeting in Seoul, Republic of Korea, in February 2004.
They have since been discussed within IETF MIP6 working group and the
IRTF MobOpts research group.
2. Terminology
Unverified care-of address
A care-of address registered by means of a tentative correspondent
registration. A mobile node's reachability at an unverified
care-of address is not known to a correspondent node, because no
care-of-address test has (yet) been accomplished.
Vogt Expires August 31, 2006 [Page 3]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Verified care-of address
A care-of address registered by means of a standard correspondent
registration. A mobile node's reachability at a verified care-of
address has been determined through a care-of-address test.
Active care-of address
The care-of address currently registered by a home agent or
correspondent node. The unqualified term "care-of address" refers
to the active care-of address unless otherwise specified. A home
agent or correspondent node sends packets for a mobile node to the
the active care-of address of that mobile node.
Previous care-of address
The care-of address that was replaced by the active care-of
address during the last home or correspondent registration. After
a home registration, the home agent continues for a short period
to accept packets that arrive from the mobile node's previous
care-of address. Likewise, after a correspondent registration,
the correspondent node continues for a while to accept packets
with a Home Address destination option that have been sent from
the previous care-of address.
Tentative correspondent registration
A correspondent registration with limited lifetime, which a mobile
node can request before it has obtained a care-of keygen token. A
tentative correspondent registration provides evidence to a
correspondent node that the mobile node is reachable at the home
address, but it does not prove the mobile node's reachability at
the claimed care-of address.
Standard correspondent registration
A correspondent registration as specified in [RFC3775]. The term
is used for differentiation from a tentative correspondent
registration. A standard correspondent registration provides
evidence to a correspondent node that the mobile node is reachable
at both the home address and the claimed care-of address.
Early Binding Update message
Vogt Expires August 31, 2006 [Page 4]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
A Binding Update message sent by a mobile node to request a
tentative correspondent registration for a new care-of address.
The early Binding Update message does not contain a proof of the
mobile node's reachability at that care-of address. The Care-of
Nonce Index field in the Nonce Indices mobility option following
an early Binding Update message is set to zero, indicating that
the Authenticator field in the Binding Authorization Data mobility
option was calculated without a care-of keygen token.
Standard Binding Update message
A Binding Update message sent by a mobile node to request a
standard correspondent registration for a new care-of address, as
specified in [RFC3775]. The term is used for differentiation from
an early Binding Update message.
Proactive home-address test
The exchange of a pair of Home Test Init and Home Test messages,
initiated by a mobile node in order to acquire a valid home keygen
token in preparation for a future handoff.
Concurrent care-of address test
The exchange of a pair of Care-of Test Init and Care-of Test
messages for an unverified care-of address, executed subsequent to
a tentative correspondent registration. The unverified care-of
address is already in use during the concurrent care-of-address
test.
3. Protocol Overview
The Mobile IPv6 extensions specified in this document allow for
efficient reactive or proactive handoff management. Reactive and
proactive registration procedures are described separately in the
following. For the sake of simplicity, it is assumed that the mobile
node communicates with a single correspondent node. If the mobile
node communicates with more than one correspondent node at a time, it
needs to run a separate correspondent registration with each of the
correspondent node.
3.1 Reactive Registration Procedure
Figure 1 illustrates the reactive Mobile IPv6 registration procedure
when early Binding Updates are used.
Vogt Expires August 31, 2006 [Page 5]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
mobile node home agent correspondent node
| | |
|=Home Test Init===>|-Home Test Init--->|
| | |
|<========Home Test=|<--------Home Test-|
| | |
handoff ~ | |
| | |
use new |-Binding Update--->| |
c/o address |-early Binding Update----------------->| c/o address
|-Care-of Test Init-------------------->| unverified
| | |
|<------Binding Ack-| |
|<--------------------early-Binding Ack-|
|<-------------------------Care-of Test-|
| | |
|-Binding Update----------------------->| c/o address
| | | verified
|<--------------------------Binding Ack-|
| | |
Figure 1: Reactive registration procedure with early Binding Updates
The mobile node sends a Home Test Init message prior to handoff in
order to proactively elicit a Home Test message from the
correspondent node with a fresh home keygen token. The Home Test
Init message may be sent periodically whenever the current home
keygen token is about to expire. Tokens are valid for
MAX_TOKEN_LIFETIME [RFC3775], so the interval between successive Home
Test Init messages should be a little bit less. Alternatively, the
mobile node's local link layer may provide a trigger announcing
imminent handoff. The mobile node may send the Home Test Init
message right in time in this case. The Home Test Init and Home Test
messages have the same syntax, and are processed in the same way, as
specified in [RFC3775].
When the mobile node detects that it has moved to a different link,
it configures a new care-of address. The mobile node then sends
three messages back to back: a Binding Update message to its home
agent, and early Binding Update and a Care-of Test Init messages to
the correspondent node. The Binding Update for the home agent is the
same as specified in [RFC3775]. The early Binding Update for the
correspondent node is a request to cache a tentative binding. It has
the same syntax as a standard Binding Update message, but the
Authenticator value in the Binding Authorization Data mobility option
is calculated only with a proactively obtained home keygen token.
The Care-of Nonce Index field in the Nonce Indices mobility option is
Vogt Expires August 31, 2006 [Page 6]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
set to zero. The early Binding Update is hence similar to a standard
Binding Update that the mobile node sends to a correspondent node for
the purpose of de-registration when returning to the home link. The
Care-of Test Init message elicits a Care-of Test message from the
correspondent node with a fresh care-of keygen token. Data packets
may already be exchanged through the new care-of address during this
handshake. The Care-of Test Init and Care-of Test messages have the
same syntax, and are processed in the same way, as specified in
[RFC3775].
The home agent processes a received Binding Update according to the
rules specified in [RFC3775]. The home agent then sends a Binding
Acknowledgment message back to the mobile node.
When the correspondent node receives the early Binding Update
message, it tentatively binds the mobile node's home address to the
new care-of address. It sets the new care-of address to UNVERIFIED
state, because the early Binding Update message does not show whether
the mobile node is indeed reachable at this address. If the
Acknowledge (A) flag is set in the early Binding Update message, the
correspondent node sends a Binding Acknowledgment message back to the
mobile node.
The correspondent node may send route-optimized data packets to the
unverified care-of address from this time on. Whether or not it does
so depends on its local policies. Section 4 discusses various
policies that the correspondent node may apply. In any case, the
correspondent node should not send any further packets to the
previous care-of address of the mobile node.
[RFC3775] requires that the requested lifetime for a correspondent
registration must be less than or equal to the remaining lifetime of
the current home registration. However, the home agent defines the
lifetime of the home registration in its Binding Acknowledgment
message, so the mobile node does not know the home-registration
lifetime at the time it sends an early Binding Update message. The
lifetime requested in the early Binding Update message must therefore
not exceed TENTATIVE_RR_BINDING_LIFETIME.
After a successful Binding Acknowledgment message has been received
from the home agent, and after a fresh care-of keygen token has been
obtained from the correspondent node, the mobile node sends a
standard Binding Update message to the correspondent node. As
specified in [RFC3775], the Authenticator value of the Binding
Authorization Data mobility option is calculated with the care-of
keygen token from the received Care-of Test message and the home
keygen token from the most recently received Home Test message. The
nonce indices in the Nonce Indices mobility option are set
Vogt Expires August 31, 2006 [Page 7]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
appropriately.
When the correspondent node receives the standard Binding Update
message to the correspondent node, it sets the lifetime of the mobile
node's binding as specified in [RFC3775]. This extends the lifetime
from its tentative value. The correspondent node also changes the
state of the care-of address from UNVERIFIED to VERIFIED. If the
Acknowledge (A) flag in the received Binding Update message is set,
the correspondent node sends a Binding Acknowledgment message back to
the mobile node.
If the mobile node sets the Acknowledge (A) flag in the early Binding
Update message, but fails to receive a corresponding Binding
Acknowledgment message within appropriate time, it may retransmit the
early Binding Update message every INITIAL_BINDACK_TIMEOUT [RFC3775]
up to EARLY_BINDING_UPDATE_RETRIES times until it either receives an
acknowledgment for the early Binding Update message or meets the
preconditions to send a standard Binding Update message. When the
mobile node can be sure that the correspondent node has received its
early Binding Update message, it may periodically refresh the
tentative registration until it can be sure that the correspondent
node has received its standard Binding Update message. The mobile
node resends the standard Binding Update message according to rules
specified in [RFC3775] until it can be sure that the correspondent
node has successfully processed the message.
Handoff efficiency is highest when the correspondent node sends
packets to a care-of address in UNVERIFIED state directly, but the
correspondent node may choose to send them to the home address until
the state of the care-of address changes to VERIFIED (cf. Section 4).
The mobile node must expect to receive the correspondent node's
packets encapsulated by its home agent from the time it sends the
early Binding Update message up to a short period of time after it
has sent the standard Binding Update message to the correspondent
node. The mobile node should not consider the encapsulated packets
as an indication of a failed correspondent registration. Moreover,
the mobile node may route-optimize its packets for the correspondent
node rather than reverse-tunneling them through the home agent. The
correspondent node accepts these packets due to the tentative binding
between the home address and the unverified care-of address.
3.2 Proactive Registration Procedure
A mobile node may be able to anticipate movements and acquire the
prefixes of its prospective next default router by some external
means. The mobile node MAY then proactively form a new care-of
address and register this with its home agent while still connected
Vogt Expires August 31, 2006 [Page 8]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
to the old link. For a mobile node to anticipate movements and
schedule handoff-related activities accordingly, the IP layer must be
able to issue commands to the link layer and receive events as well
as anticipatory information from the link layer. This calls for a
bidirectional interface between these layers, the specification of
which is outside the scope of this document.
mobile node home agent correspondent node
| | |
L2-triggered |=Home Test Init===>|-Home Test Init--->|
notification | | |
|<========Home Test=|<--------Home Test-|
| | |
|-Binding Update--->| |
|-early Binding Update----------------->| c/o address
| | | unverified
L3-triggered |<------Binding Ack-| |
handoff ~ X <----------------early Binding Ack-|
| | |
use new |-early Binding Update----------------->|
c/o address |-Care-of Test Init-------------------->|
| | |
|<--------------------early-Binding Ack-|
|<-------------------------Care-of Test-|
| | |
|-Binding Update----------------------->| c/o address
| | | verified
|<--------------------------Binding Ack-|
| | |
Figure 2: Proactive registration procedure with early Binding Updates
Figure 2 illustrates the proactive registration procedure. At some
point, the mobile node receives a link-layer notification indicating
that the signal strength for its current link attachment has dropped
below a certain threshold. This causes the mobile node to send a
Home Test Init message and acquire a home keygen token from its
correspondent node. Depending on how long the mobile node remains in
this pre-handoff stage, it may have to resend the Home Test Init
message in order to refresh the token. Should a later notification
tell that the signal quality has again increased, the periodic tests
can be stopped. However, if the signal quality falls further, the
mobile node will at some point receive a link-layer notification
indicating that a change in link-layer attachment is due. This
includes the link-layer address of the prospectively new access
point, which the mobile node resolves to the set of prefixes in use
on the target link.
Vogt Expires August 31, 2006 [Page 9]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Based on a prefix from the target link, the mobile node configures a
new care-of address. The mobile node MUST set the address to
Optimistic state [ODAD] and use Optimistic Duplicate Address
Detection [ODAD] for verifying uniqueness of the address when it
arrives on the new link. The mobile node then sends a Binding Update
message to the home agent and an early Binding Update message to the
correspondent node. Since these messages are sent from the old link,
and the IPv6 Source Address field does not contain the new care-of
address as it usually does, Alternate Care-of Address mobility
options are added to the messages to hold the new care-of address.
The Acknowledge (A) flag is set in both messages. The mobile node
uses its old care-of address until it has actually moved to the new
link.
When the home agent receives the Binding Update message, it registers
the new care-of address, but continues for a period of
PREVIOUS_CAREOF_ADDRESS_LIFETIME time to also accept packets that the
mobile node may send from the old care-of address before moving to
the new link [PETANDER05]. Likewise, the correspondent node
registers the new care-of address upon receipt of an early Binding
Update message, but continues for a period of
PREVIOUS_CAREOF_ADDRESS_LIFETIME time to also accept packets from the
old care-of address.
The home agent and the correspondent node return their
acknowledgments to the old care-of address, but direct subsequent
packets to the new care-of address. One of these acknowledgments
will cause the mobile node to instruct its link layer to switch to
the newly discovered access point. The mobile node implements its
own policy as to which acknowledgment it uses for this purpose. When
the mobile node eventually arrives on the new link, it begins
Optimistic Duplicate Address Detection signaling [ODAD] and sends
subsequent data packets via the new care-of address. Some of the
acknowledgments are usually lost on the old link, so the mobile node
cannot tell whether all registrations were successful. It hence
retransmits Binding Update and early Binding Update messages for any
unconfirmed registrations. In Figure 2, the registration with the
only correspondent node remains unacknowledged on the old link, so
the mobile node resends the early Binding Update message from the new
link.
Incoming packets may already be queued at the new access router when
the mobile node arrives on the new link, or they arrive shortly, as
the home agent and the correspondent node should already be using the
new care-of address. The mobile node sends a Care-of Test Init
message to the correspondent node in order to elicit a Care-of Test
message from the correspondent node with a fresh care-of keygen
token. Data packets may already be exchanged through the new care-of
Vogt Expires August 31, 2006 [Page 10]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
address during this handshake.
After a successful Binding Acknowledgment message has been received
from the home agent, either on the old or on the new link, and after
a fresh care-of keygen token has been obtained from the correspondent
node, the mobile node sends a standard Binding Update message to the
correspondent node. The correspondent node returns a Binding
Acknowledgment message in case the Acknowledge (A) flag is set in the
Binding Update message.
4. Handling Unverified Care-of Addresses
The correspondent node stops sending further packets to an old
care-of address once the mobile node has tentatively registered a
new, unverified care-of address. It accepts route-optimized packets
that the mobile node sends from the unverified care-of address from
that time on. However, whether or not the correspondent node sends
data packets to the unverified care-of address depends on its local
policies. Several approaches are conceivable:
Dropping Packets
Local policies may prohibit the correspondent node to send data
packets to an unverified care-of address. The correspondent node
may simply drop such packets. It may rely on protocols at stack
layers above IP to retransmit the lost packets when the care-of
address becomes verified.
Buffering Packets
The correspondent node may buffer packets for a mobile node whoose
care-of address is unverified. It can send these packets as soon
as the care-of address gets verified. However, packet buffering
makes the correspondent node susceptible to memory-overflow
attacks and may represent a denial-of-service vulnerability on its
own. It should hence be limited to scenarios where the
correspondent node can identify a trustworthy mobile node based on
the home address, and the mobile node's reachability at the home
address has been verified.
Diverted Routing
Vogt Expires August 31, 2006 [Page 11]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
The correspondent node may choose to send packets for a mobile
node to the home address while the care-of address is unverified.
The mobile node may still send route-optimized packets for the
correspondent node directly instead of reverse-tunneling them
through the home agent. It may reverse-tunnel the packets,
however, if latency differences between packets routed through the
home agent and those sent directly would otherwise cause
disruption to the application.
Heuristics
A rigid lifetime limit for tentative correspondent registrations
supplemented with a heuristic for misuse detection can be a
sufficient discouragement of malicious packet redirection. Mobile
nodes have to authenticate their home addresses during a tentative
correspondent registration, so an attacker can always be
identified by means of its home address.
Trusted Communities
The correspondent node may use the home address as a criterion for
deciding whether a particular mobile node belongs to a trusted
community. If it can rely on the mobile node's trustworthiness,
it can send packets to an unverified care-of address of this
mobile node. This strategy could be used by a corporate server
which trusts mobile nodes only if they are affiliated to its own
company.
Credit-Based Authorization
Redirection-based flooding attacks are a particular threat due to
their potential for high amplification. Credit-Based
Authorization [CBA] prevents such amplification, discouraging
malicious packet redirection in the first place. This is
accomplished by limiting the data that a correspondent node can
send to an unverified care-of address of a mobile node by the data
that the correspondent node has recently received from that mobile
node. A redirection-based flooding attack thus becomes no more
attractive than pure direct flooding, where the attacker itself
sends bogus packets to the victim. It is actually less attractive
given that the attacker needs to maintain a context for mobility
management in order to coordinate the redirection.
Vogt Expires August 31, 2006 [Page 12]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
5. Modifications to RFC 3775
The Mobile IPv6 extensions set forth in this document are most
precisely specified as the set of changes to RFC 3775 that they
require. These changes are listed in the following, giving
implementors a step-by-step guide on how to modify RFC-3775-conform
software so as to support Early Binding Updates.
5.1 Overview of Mobile IPv6 Security (Section 5)
Modifications to Section 5.2.5, "Return Routability Procedure":
- Original text
The Return Routability Procedure enables the correspondent node to
obtain some reasonable assurance that the mobile node is in fact
addressable at its claimed care-of address as well as at its home
address. Only with this assurance is the correspondent node able
to accept Binding Updates from the mobile node which would then
instruct the correspondent node to direct that mobile node's data
traffic to its claimed care-of address.
+ New text
The Return Routability Procedure enables the correspondent node to
obtain some reasonable assurance that the mobile node is in fact
addressable at its claimed care-of address as well as at its home
address. The correspondent node may (tentatively) accept Binding
Update messages based only on the knowledge that the mobile node
is addressable at its home address if additional protection
against false care-of addresses is provided (see Section 4). The
correspondent node can then temporarily direct the mobile node's
data traffic to the claimed care-of address while the validity of
the care-of address is being verified. However, in the regular
case, or if no additional protection against false care-of
addresses exists, a Binding Update can only be accepted with the
assurance that the mobile node's home address and care-of address
are both correct.
- Original text
The Home and Care-of Test Init messages are sent at the same time.
The procedure requires very little processing at the correspondent
node, and the Home and Care-of Test messages can be returned
quickly. These four messages form the return routability
procedure.
Vogt Expires August 31, 2006 [Page 13]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
+ New text
The Home and Care-of Test Init messages can be sent at the same
time or separately. The procedure requires very little processing
at the correspondent node, and the Home and Care-of Test messages
can be returned quickly, possibly nearly simultaneously. These
four messages form the return routability procedure.
- Original text
When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a
result of the procedure, the mobile node has the data it needs to
send a Binding Update to the correspondent node. The mobile node
hashes the tokens together to form a 20 octet binding key Kbm:
Kbm = SHA1 (home keygen token | care-of keygen token)
+ New text
When the mobile node has received the Home Test messages, it has
the data required to send an early Binding Update message to the
correspondent node. The mobile node hashes the home keygen token
to form a 20 octet binding key Kbm:
Kbm = SHA1 (home keygen token)
When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a
result of the procedure, the mobile node has the data it needs to
send a standard Binding Update message to the correspondent node.
The mobile node now hashes both tokens together to form a new 20
octet binding key Kbm:
Kbm = SHA1 (home keygen token | care-of keygen token)
Modifications to Section 5.2.6, "Authorizing Binding Management
Messages":
- Original text
Binding Update
Vogt Expires August 31, 2006 [Page 14]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
To authorize a Binding Update, the mobile node creates a binding
management key Kbm from the keygen tokens as described in the
previous section. The contents of the Binding Update include the
following:
* Source Address = care-of address
* Destination Address = correspondent
* Parameters
+ home address (within the Home Address destination option if
different from the Source Address)
+ sequence number (within the Binding Update message header)
+ home nonce index (within the Nonce Indices option)
+ care-of nonce index (within the Nonce Indices option)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
+ New text
Binding Update
To authorize an early Binding Update message, the mobile node
creates a binding management key Kbm from the home keygen token as
described in the previous section. The contents of the early
Binding Update message include the following:
* Source Address = care-of address
* Destination Address = correspondent
* Parameters
+ home address (within the Home Address destination option if
different from the Source Address)
+ sequence number (within the Binding Update message header)
+ home nonce index (within the Nonce Indices option)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
To authorize a standard Binding Update message, the mobile node
creates a binding management key Kbm from both keygen tokens as
described in the previous section. The contents of the standard
Binding Update message include the following:
* Source Address = care-of address
* Destination Address = correspondent
* Parameters
+ home address (within the Home Address destination option if
different from the Source Address)
+ sequence number (within the Binding Update message header)
Vogt Expires August 31, 2006 [Page 15]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
+ home nonce index (within the Nonce Indices option)
+ care-of nonce index (within the Nonce Indices option)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
- Original text
The Binding Update contains a Nonce Indices option, indicating to
the correspondent node which home and care-of nonces to use to
recompute Kbm, the binding management key. The MAC is computed as
described in Section 6.2.7, using the correspondent node's address
as the destination address and the Binding Update message itself
("BU" above) as the MH Data.
+ New text
The Binding Update message contains a Nonce Indices option,
indicating to the correspondent node which home and care-of nonces
to use to recompute Kbm, the binding management key. For an early
Binding Update message, the Care-of Nonce Index field in this
option is set to zero. The MAC is computed as described in
Section 6.2.7, using the correspondent node's address as the
destination address and the Binding Update message itself ("BU"
above) as the MH Data.
- Original text
Binding Acknowledgement
The Binding Update is in some cases acknowledged by the
correspondent node. The contents of the message are as follows:
* Source Address = correspondent
* Destination Address = care-of address
* Parameters:
+ sequence number (within the Binding Update message header)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
+ New text
Binding Acknowledgement
The Binding Update is in some cases acknowledged by the
correspondent node. The contents of the message are as follows:
Vogt Expires August 31, 2006 [Page 16]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
* Source Address = correspondent
* Destination Address = care-of address
* Parameters:
+ sequence number (within the Binding Update message header)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
The binding management key, Kbm, used to authenticate the Binding
Acknowledgment message is the same Kbm that was used to
authenticate the corresponding Binding Update message. I.e., if
the Binding Acknowledgment message is sent in response to an early
Binding Update message, only a home keygen token is required to
compute the Kbm. If the Binding Acknowledgment message is sent in
response to a standard Binding Update message, the Kbm is based on
a home and a care-of keygen token.
- Original text
Bindings established with correspondent nodes using keys created
by way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFETIME seconds (see Section 12).
+ New text
Bindings established with correspondent nodes using keys created
by way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFETIME seconds (see Section 12) when registered
with a standard Binding Update message. When registered with an
early Binding Update message, the bindings MUST NOT exceed
TENTATIVE_RR_BINDING_LIFETIME seconds (see Section 12).
- Original text
Binding Updates may also be sent to delete a previously
established binding. In this case, generation of the binding
management key depends exclusively on the home keygen token and
the care-of nonce index is ignored.
+ New text
If the Care-of Nonce Index field in the Nonce Indices option of a
received Binding Update message is zero, the message is considered
an early Binding Update message. In this case, generation of the
binding management key depends exclusively on the home keygen
token and the care-of nonce index is ignored. Likewise, the
care-of nonce index is ignored for Binding Update messages that
are sent to delete a previously established binding, and the
binding management key again depends exclusively on the home
Vogt Expires August 31, 2006 [Page 17]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
keygen token.
5.2 Correspondent Node Operation (Section 9)
Modifications to Section 9.1, "Conceptual Data Structures":
- Original text
Each Binding Cache entry conceptually contains the following
fields:
o The home address of the mobile node for which this is the
Binding Cache entry. This field is used as the key for
searching the Binding Cache for the destination address of a
packet being sent.'
o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry.
o A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from
the Lifetime field in the Binding Update that created or last
modified this Binding Cache entry.
+ New text
Each Binding Cache entry conceptually contains the following
fields:
o The home address of the mobile node for which this is the
Binding Cache entry. This field is used as the key for
searching the Binding Cache for the destination address of a
packet being sent.'
o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry.
o The previous care-of address that was replaced by the currently
registered, active care-of address. The previous care-of
address is needed for proactive handoff support, which may
require a correspondent node to receive packets from the
previous care-of address for a short period, even though a new
active care-of address has already been (proactively)
registered [PETANDER05]. Packets that the correspondent node
sends always use the currently active care-of address, however.
The previous care-of address is copied from the currently
Vogt Expires August 31, 2006 [Page 18]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
active care-of address during a correspondent registration.
o A lifetime value that indicates the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from
the Lifetime field in the Binding Update that created or last
modified this Binding Cache entry.
o A lifetime value that indicates the remaining lifetime for the
previous care-of address. The lifetime of the previous care-of
address is initialized to the minimum of
PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the
currently active care-of address just before this active
care-of address is replaced and becomes the previous care-of
address.
Modifications to Section 9.3.1, "Receiving Packets with Home Address
Option":
- Original text
Mobile nodes can include a Home Address destination option in a
packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. Packets containing a
Home Address option MUST be dropped if there is no corresponding
Binding Cache entry. A corresponding Binding Cache entry MUST
have the same home address as appears in the Home Address
destination option, and the currently registered care-of address
MUST be equal to the source address of the packet. These tests
MUST NOT be done for packets that contain a Home Address option
and a Binding Update.
- New text
Mobile nodes can include a Home Address destination option in a
packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. When processing an
incoming packet that contains a Home Address destination option,
the correspondent node verifies whether it has a Binding Cache
entry with (i) the same home address as appears in the Home
Address destination option of the incoming packet and (ii) either
the currently registered care-of address or the previous care-of
address MUST be equal to the source address of the packet. In
addition, the correspondent node ensures that, if the packet's
source address is equal to the previous care-of address in the
Binding Cache entry, the remaining lifetime for that previous
care-of address is not yet expired. These tests MUST NOT be done
for packets that contain a Home Address option and a Binding
Vogt Expires August 31, 2006 [Page 19]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Update.
Modifications to Section 9.3.4, "Receiving ICMP Error Messages":
- Original text
Thus, in all cases, any meaningful ICMP error messages caused by
packets from a correspondent node to a mobile node will be
returned to the correspondent node. If the correspondent node
receives persistent ICMP Destination Unreachable messages after
sending packets to a mobile node based on an entry in its Binding
Cache, the correspondent node SHOULD delete this Binding Cache
entry. Note that if the mobile node continues to send packets
with the Home Address destination option to this correspondent
node, they will be dropped due to the lack of a binding. For this
reason it is important that only persistent ICMP messages lead to
the deletion of the Binding Cache entry.
+ New text
Thus, in all cases, any meaningful ICMP error messages caused by
packets from a correspondent node to a mobile node will be
returned to the correspondent node. If the correspondent node
receives persistent ICMP Destination Unreachable messages after
sending packets to a mobile node based on an entry in its Binding
Cache, the correspondent node SHOULD delete this Binding Cache
entry. Note that if the mobile node continues to send packets
with the Home Address destination option to this correspondent
node, they will be dropped due to the lack of a binding. For this
reason it is important that only persistent ICMP messages lead to
the deletion of the Binding Cache entry. In particular, packets
in flight from the correspondent node to an old location of the
mobile node may elicit ICMP Destination Unreachable messages from
an access router after the mobile node has changed IP
connectivity. The correspondent node may also receive ICMP
Destination Unreachable messages, shortly after the correspondent
registration for a proactive handoff, for packets that arrive at
the mobile node's prospective access router before the mobile node
attaches itself. The actual number of ICMP Destination
Unreachable messages depends on topological properties of the
involved routing paths, the eagerness of the prospective access
router in sending ICMP messages, as well as the time needed by the
mobile node to connect to the new link. The correspondent node
ought to accept a small number of these messages without assuming
the Binding Cache entry being incorrect.
Vogt Expires August 31, 2006 [Page 20]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Modifications to Section 9.5.1, "Receiving Binding Updates":
- Original text
A Nonce Indices mobility option MUST be present, and the Home and
Care-of Nonce Index values in this option MUST be recent enough to
be recognized by the correspondent node. (Care-of Nonce Index
values are not inspected for requests to delete a binding.)
+ New text
A Nonce Indices mobility option MUST be present, and the Home
Nonce Index value in this option MUST be recent enough to be
recognized by the correspondent node. If the received Binding
Update message is not a request to delete a binding, and if the
Care-of Nonce Index value in the option is non-zero, the Care-of
Nonce Index value MUST also be recent enough to be recognized by
the correspondent node.
- Original text
The correspondent node MUST re-generate the home keygen token and
the care-of keygen token from the information contained in the
packet. It then generates the binding management key Kbm and uses
it to verify the authenticator field in the Binding Update as
specified in Section 6.1.7.
+ New text
The correspondent node MUST re-generate the home keygen token and,
if needed, the care-of keygen token from the information contained
in the packet. It then generates the binding management key Kbm
and uses it to verify the authenticator field in the Binding
Update as specified in Section 6.1.7.
Modifications to Section 9.5.2, "Requests to Cache a Binding":
- Original text
In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this home address, or update its existing
Binding Cache entry for this home address, if such an entry
already exists. The lifetime for the Binding Cache entry is
initialized from the Lifetime field specified in the Binding
Update, although this lifetime MAY be reduced by the node caching
the binding; the lifetime for the Binding Cache entry MUST NOT be
greater than the Lifetime value specified in the Binding Update.
Vogt Expires August 31, 2006 [Page 21]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
+ New text
In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this home address, or update its existing
Binding Cache entry for this home address, if such an entry
already exists. The previous care-of address in the Binding Cache
entry is set to the currently active care-of address, if any, and
its lifetime is initialized to the minimum of
PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the currently
active care-of address. The currently active care-of address is
then replaced by the new care-of address indicated in the Binding
Update message.
The lifetime for the Binding Cache entry is usually initialized
from the Lifetime field specified in the received Binding Update
message. The lifetime MAY be reduced by the node caching the
binding, but it MUST NOT be greater than the Lifetime value
specified in the Binding Update message. Furthermore, in case of
a standard Binding Update message, the lifetime MUST NOT be
greater than MAX_RR_BINDING_LIFETIME, and in case of an early
Binding Update message, it MUST NOT be greater than
TENTATIVE_RR_BINDING_LIFETIME.
Modifications to Section 9.5.3, "Requests to Delete a Binding":
- Original text
If the Binding Cache entry was created by use of return
routability nonces, the correspondent node MUST ensure that the
same nonces are not used again with the particular home and
care-of address. If both nonces are still valid, the
correspondent node has to remember the particular combination of
nonce indexes, addresses, and sequence number as illegal until at
least one of the nonces has become too old.
+ New text
If the Binding Cache entry was created by use of return
routability nonces, the correspondent node MUST ensure that the
same nonces are not used again with the particular home and
care-of address. If both nonces are still valid, the
correspondent node has to remember the particular combination of
nonce indexes, addresses, and the sequence number used in this
Binding Update message as illegal until at least one of the nonces
has become too old. In addition, if the home nonce is still
valid, the correspondent node has to remember the combination of
home nonce index, addresses, and the sequence number used in the
Vogt Expires August 31, 2006 [Page 22]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
previous early Binding Update message as illegal until the home
nonce has become too old.
Modifications to Section 9.5.5, "Sending Binding Refresh Requests":
- Original text
If the sender knows that the Binding Cache entry is still in
active use, it MAY send a Binding Refresh Request message to the
mobile node in an attempt to avoid this overhead and latency due
to deleting and recreating the Binding Cache entry. This message
is always sent to the home address of the mobile node.
+ New text
If the sender knows that the Binding Cache entry is still in
active use, and if the registered care-of address is not in
UNVERIFIED state, the sender MAY send a Binding Refresh Request
message to the mobile node in an attempt to avoid this overhead
and latency due to deleting and recreating the Binding Cache
entry. This message is always sent to the home address of the
mobile node. The Binding Refresh Request message SHOULD NOT be
sent if the registered care-of address is in UNVERIFIED state
because the binding lifetime is very limited in this case anyway.
5.3 Home Agent Operation (Section 10)
Modifications to Section 10.3.1, "Primary Care-of Address
Registration":
- Original text
If home agent accepts the Binding Update, it MUST then create a
new entry in its Binding Cache for this mobile node or update its
existing Binding Cache entry, if such an entry already exists.
The Home Address field as received in the Home Address option
provides the home address of the mobile node.
+ New text
If home agent accepts the Binding Update, it MUST then create a
new entry in its Binding Cache for this mobile node or update its
existing Binding Cache entry, if such an entry already exists.
The Home Address field as received in the Home Address option
provides the home address of the mobile node. The previous
Vogt Expires August 31, 2006 [Page 23]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
care-of address in the Binding Cache entry as well as the lifetime
of the previous care-of address are set as described in section
9.5.2.
- Original text
If the home agent does not reject the Binding Update as described
above, then it MUST delete any existing entry in its Binding Cache
for this mobile node. Then, the home agent MUST return a Binding
Acknowledgement to the mobile node, constructed as follows:
+ New text
If the home agent does not reject the Binding Update as described
above, then it MUST deactivate any existing entry in its Binding
Cache for this mobile node as follows: The previous care-of
address in the Binding Cache entry is set to the currently active
care-of address, and its lifetime is initialized to the minimum of
PREVIOUS_CAREOF_ADDRESS_LIFETIME and the lifetime of the active
care-of address. The active care-of address is then set to the
mobile node's home address, indicating that packets for the mobile
node are henceforth to be delivered directly, i.e., without the
addition of a type-2 routing header. The lifetime of the active
care-of address is set to the same value as the lifetime of the
previous care-of address.
The home agent SHOULD continue to accept encapsulated packets that
arrive from the previous care-of address, decapsulate them, and
forward them to the respective destination, until the lifetime of
the previous care-of address expires. This is necessary for the
support of proactive handoffs, during which the mobile node may
send packets from its old location for a while before it moves to
the home network [PETANDER05]. The Binding Cache entry MUST be
deleted when this lifetime expires.
When the home agent has updated the previous and active care-of
addresses, it MUST return a Binding Acknowledgement to the mobile
node, constructed as follows:
Modifications to Section 10.4.5, "Handling Reverse Tunneled Packets":
- Original text
Vogt Expires August 31, 2006 [Page 24]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Unless a binding has been established between the mobile node and
a correspondent node, traffic from the mobile node to the
correspondent node goes through a reverse tunnel. Home agents
MUST support reverse tunneling as follows:
+ New text
Unless a binding has been established between the mobile node and
a correspondent node, traffic from the mobile node to the
correspondent node goes through a reverse tunnel. Packets
reveived through the tunnel interface typically use the mobile
node's primary care-of address as the source address in the outer
IPv6 header. However, it is RECOMMENDED that the home agent in
addition accepts packets on the tunnel interface that use the
previous care-of address, stored in the mobile node's Binding
Cache entry, as long as the lifetime of that care-of address has
not yet expired. This is necessary for the support of proactive
handoffs, as described in section 10.3.2. Home agents MUST
support reverse tunneling as follows:
- Original text
o Otherwise, when a home agent decapsulates a tunneled packet
from the mobile node, the home agent MUST verify that the
Source Address in the tunnel IP header is the mobile node's
primary care-of address. Otherwise, any node in the Internet
could send traffic through the home agent and escape ingress
filtering limitations. This simple check forces the attacker
to know the current location of the real mobile node and be
able to defeat ingress filtering. This check is not necessary
if the reverse- tunneled packet is protected by ESP in tunnel
mode.
+ New text
o Otherwise, when a home agent decapsulates a tunneled packet
from the mobile node, the home agent MUST verify that the
Source Address in the tunnel IP header is correct. At a
minimum, the home agent MUST accept packets from the mobile
node's primary care-of address, but it SHOULD also accept
packets from the mobile node's previous care-of address, as
stored in the Binding Cache entry. Any packet not from either
the primary care-of address or the previous care-of address
MUST be discarded. If the Source Address in the tunnel IP
header is the previous care-of address, then the home agent
MUST in addition verify that the lifetime for this address has
not yet expired. Without these checks, any node in the
Internet could send traffic through the home agent and escape
Vogt Expires August 31, 2006 [Page 25]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
ingress filtering limitations. The checks force the attacker
to know the current location of the real mobile node and be
able to defeat ingress filtering. They are not necessary if
the reverse-tunneled packet is protected by ESP in tunnel mode.
5.4 Mobile Node Operation (Section 11)
Modifications to Section 11.1, "Conceptual Data Structures":
- Original text
The Binding Update List records information for each Binding
Update sent by this mobile node, in which the lifetime of the
binding has not yet expired. The Binding Update List includes all
bindings sent by the mobile node either to its home agent or
correspondent nodes. It also contains Binding Updates which are
waiting for the completion of the return routability procedure
before they can be sent. However, for multiple Binding Updates
sent to the same destination address, the Binding Update List
contains only the most recent Binding Update (i.e., with the
greatest Sequence Number value) sent to that destination. The
Binding Update List MAY be implemented in any manner consistent
with the external behavior described in this document.
+ New text
The Binding Update List records information for each Binding
Update sent by this mobile node, in which the lifetime of the
binding has not yet expired. The Binding Update List includes all
bindings sent by the mobile node either to its home agent or
correspondent nodes. It also contains Binding Updates which are
waiting for the completion of the return routability procedure
before they can be sent. However, for multiple Binding Updates
sent to the same destination address, the Binding Update List
contains only the most recent early Binding Update and the most
recent standard Binding Update (i.e., the respective messages with
the greatest Sequence Number values) sent to that destination.
The Binding Update List MAY be implemented in any manner
consistent with the external behavior described in this document.
- Original text
Vogt Expires August 31, 2006 [Page 26]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Each Binding Update List entry conceptually contains the following
fields:
o The IP address of the node to which a Binding Update was sent.
o The home address for which that Binding Update was sent.
o The care-of address sent in that Binding Update. This value is
necessary for the mobile node to determine if it has sent a
Binding Update while giving its new care-of address to this
destination after changing its care-of address.
o The initial value of the Lifetime field sent in that Binding
Update.
o The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding Update
and is decremented until it reaches zero, at which time this
entry MUST be deleted from the Binding Update List.
o The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination. The Sequence Number field
is 16 bits long and all comparisons between Sequence Number
values MUST be performed modulo 2**16 (see Section 9.5.1).
o The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting
restriction for sending Binding Updates.
o The state of any retransmissions needed for this Binding
Update. This state includes the time remaining until the next
retransmission attempt for the Binding Update and the current
state of the exponential back-off mechanism for
retransmissions.
o A flag specifying whether or not future Binding Updates should
be sent to this destination. The mobile node sets this flag in
the Binding Update List entry when it receives an ICMP
Parameter Problem, Code 1, error message in response to a
return routability message or Binding Update sent to that
destination, as described in Section 11.3.5.
- New text
Each Binding Update List entry conceptually contains the following
fields:
o The IP address of the node to which a Binding Update was sent.
o The home address for which that Binding Update was sent.
o The care-of address sent in that Binding Update. This value is
necessary for the mobile node to determine if it has sent a
Binding Update while giving its new care-of address to this
destination after changing its care-of address.
Vogt Expires August 31, 2006 [Page 27]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
o The initial value of the Lifetime field sent in that Binding
Update.
o The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding Update
and is decremented until it reaches zero, at which time this
entry MUST be deleted from the Binding Update List.
o The maximum value of the Sequence Number field sent in previous
standard Binding Updates to this destination. The Sequence
Number field is 16 bits long and all comparisons between
Sequence Number values MUST be performed modulo 2**16 (see
Section 9.5.1).
o The maximum value of the Sequence Number field sent in previous
early Binding Updates to this destination. The Sequence Number
field is 16 bits long and all comparisons between Sequence
Number values MUST be performed modulo 2**16.
o The time at which a standard Binding Update was last sent to
this destination, as needed to implement the rate limiting
restriction for sending standard Binding Updates.
o The time at which an early Binding Update was last sent to this
destination, as needed to implement the rate limiting
restriction for sending early Binding Updates.
o The state of any retransmissions needed for the last standard
Binding Update. This state includes the time remaining until
the next retransmission attempt for the standard Binding Update
and the current state of the exponential back-off mechanism for
retransmissions.
o The state of any retransmissions needed for the last early
Binding Update. This state includes the time remaining until
the next retransmission attempt for the early Binding Update
and the current state of the exponential back-off mechanism for
retransmissions.
o A flag specifying whether or not future standard Binding
Updates should be sent to this destination. The mobile node
sets this flag in the Binding Update List entry when it
receives an ICMP Parameter Problem, Code 1, error message in
response to a return routability message or Binding Update sent
to that destination, as described in Section 11.3.5.
o A flag specifying whether or not future early Binding Updates
should be sent to this destination. The mobile node sets this
flag in the Binding Update List entry, as described in Section
TODO, when it determines that the correspondent node supports
regular Mobile IPv6 route optimization, but does not recognize
early Binding Updates.
Modifications to Section 11.3.1, "Sending Packets While Away from
Home":
Vogt Expires August 31, 2006 [Page 28]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
- Original text
* The entry indicates that a binding has been successfully
created.
+ New text
* The entry indicates that a regular or tentative binding has
been successfully created.
New Section 11.5.5, "Movement Anticipation and Proactive Handoff
Management":
+ New text
A mobile node may be able to anticipate movements and acquire the
prefixes of its prospective next default router by some external
means. The mobile node MAY then proactively form a new care-of
address and register this with its home agent while still
connected to the old link. The Binding Update MUST then have the
currently active care-of address in the IPv6 header's Source
Address field, and it MUST carry the home address in a Home
Address destination option and the new care-of address in an
Alternate Care-of Address mobility option. Furthermore, the Home
Registration (H) and Acknowledge (A) bits MUST be set.
The mobile node implements its own policy as to when it initiates
the link-layer handoff to the new link. In a typical case, the
mobile node waits for a Binding Acknowledgment on the old link.
This can be the Binding Acknowledgment from the home agent or one
from a correspondent node (see Section 11.7.2). Signal conditions
on the old link may force the mobile node to move to the new link
at an earlier time, however.
Furthermore, the mobile node MAY proactively send a Binding Update
from the home link shortly before it leaves the home link and
moves to a different link. This Binding Update has the home
address in the IPv6 header's Source Address field and the new
care-of address in an Alternate Care-of Address mobility option.
The Home Registration (H) and Acknowledge (A) bits MUST be set.
The Binding Update SHOULD also include a Home Address destination
option. Since the mobile node may not know the IP address of a
home agent to which it could send the Binding Update, the mobile
node may have to anycast an ICMPv6 Dynamic Home Agent Address
Discovery Request message on the home link. Home agents SHOULD be
prepared to receive such a message on an interface attaching to
the home link.
Vogt Expires August 31, 2006 [Page 29]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
The mobile node MAY also proactively send a Binding Update for de-
registration shortly before it returns to its home link after a
period of roaming. This Binding Update MUST have the currently
active care-of address in the IPv6 header's Source Address field,
and it MUST carry the home address in both a Home Address
destination option as well as an Alternate Care-of Address
mobility option. The Home Registration (H) and Acknowledge (A)
bits MUST be set, and the Lifetime field MUST be set to zero.
In all of the cases described above, the mobile node sends the
Binding Update on a link that it will soon leave. The new care-of
address, or home address if returning home, hence cannot yet be
configured on the interface undergoing handoff at that time.
Instead, the mobile node configures the new care-of address or
home address as soon as it attaches to the new link, e.g., in
response to a link-layer notification indicating link
establishment. Unless the mobile node returns to its home link
prior to the expiration of the current binding at the home agent,
the mobile node MUST set the address to Optimistic state [ODAD]
and use Optimistic Duplicate Address Detection [ODAD] for
verifying uniqueness of the address on the new link.
A simple mechanism to obtain the prefixes that can be used in the
proactive construction of a new care-of address is the following:
The mobile node maintains a least-recently-used cache to map the
link-layer addresses of a visited access point onto the set of
prefixes advertised by routers on the link to which this access
point connects. This allows the mobile node to proactively
resolve these prefixes during future handoffs to that link. The
technique performs well in scenarios where mobile nodes tend to
revisit a rather stable set of access points, e.g., at home or
office environments, campuses, conferences, and local shopping
centers. More sophisticated mechanisms, which may also allow
prefix resolution for previously unvisited links, are beyond the
scope of this document, however.
New Section 11.7.1, "Sending Binding Updates to the Home Agent":
- Original text
After deciding to change its primary care-of address as described
in Section 11.5.1 and Section 11.5.2, a mobile node MUST register
this care-of address with its home agent in order to make this its
primary care-of address.
Vogt Expires August 31, 2006 [Page 30]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
+ New text
After deciding to change its primary care-of address as described
in Section 11.5.1, Section 11.5.2, or Section 11.5.5, a mobile
node MUST register this care-of address with its home agent in
order to make this its primary care-of address.
New Section 11.7.2, "Correspondent Registration":
- Original text
Upon successfully completing the return routability procedure, and
after receiving a successful Binding Acknowledgement from the Home
Agent, a Binding Update MAY be sent to the correspondent node.
In any Binding Update sent by a mobile node, the care-of address
(either the Source Address in the packet's IPv6 header or the
Care-of Address in the Alternate Care-of Address mobility option
of the Binding Update) MUST be set to one of the care-of addresses
currently in use by the mobile node or to the mobile node's home
address. A mobile node MAY set the care-of address differently
for sending Binding Updates to different correspondent nodes.
A mobile node MAY also send a Binding Update to such a
correspondent node, instructing it to delete any existing binding
for the mobile node from its Binding Cache, as described in
Section 6.1.7. Even in this case a successful completion of the
return routability procedure is required first.
If the care-of address is not set to the mobile node's home
address, the Binding Update requests that the correspondent node
create or update an entry for the mobile node in the correspondent
node's Binding Cache. This is done in order to record a care-of
address for use in sending future packets to the mobile node. In
this case, the value specified in the Lifetime field sent in the
Binding Update SHOULD be less than or equal to the remaining
lifetime of the home registration and the care-of address
specified for the binding. The care-of address given in the
Binding Update MAY differ from the mobile node's primary care-of
address.
If the Binding Update is sent to the correspondent node,
requesting the deletion of any existing Binding Cache entry it has
for the mobile node, the care-of address is set to the mobile
node's home address and the Lifetime field set to zero. In this
case, generation of the binding management key depends exclusively
on the home keygen token (Section 5.2.5). The care-of nonce index
Vogt Expires August 31, 2006 [Page 31]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
SHOULD be set to zero in this case. In keeping with the Binding
Update creation rules below, the care-of address MUST be set to
the home address if the mobile node is at home, or to the current
care-of address if it is away from home.
+ New text
After a home keygen token has been obtained through the return
routability procedure, an early Binding Update or a Binding Update
for de-registration MAY be sent to the correspondent node. An
early Binding Update requests the correspondent node to create or
update an entry for the mobile node in the correspondent node's
Binding Cache. This is done in order to record a care-of address
for use in sending future packets to the mobile node. A Binding
Update for de-registration requests the correspondent node to
delete any existing Binding Cache entry it has for the mobile
node, as described in Section 6.1.7. In both cases, generation of
the binding management key depends exclusively on the home keygen
token (Section 5.2.5), and the Care-of Nonce Index field in the
Nonce Indices mobility option MUST be set to zero.
An early Binding Update MAY already be sent in a proactive manner
if the mobile node is able to anticipate movements and acquire the
prefixes of its prospective next default router while still
connected to the old link (see Section 11.5.5). The mobile node
can then form a new care-of address prior to handoff. The early
Binding Update MUST have the currently active care-of address in
the IPv6 header's Source Address field, and it MUST carry the home
address in a Home Address destination option and the new care-of
address in an Alternate Care-of Address mobility option.
The mobile node MAY also proactively send an early Binding Update
from the home link shortly before it leaves the home link and
moves to a different link. This early Binding Update has the home
address in the IPv6 header's Source Address field and the new
care-of address in an Alternate Care-of Address mobility option.
The Binding Update SHOULD also include a Home Address destination
option.
Furthermore, the mobile node MAY proactively send a Binding Update
for de-registration shortly before it returns to its home link
after a period of roaming. This Binding Update MUST have the
currently active care-of address in the IPv6 header's Source
Address field, and it MUST carry the home address in both a Home
Address destination option as well as an Alternate Care-of Address
mobility option.
Vogt Expires August 31, 2006 [Page 32]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
The Lifetime field in an early Binding Update MUST be set to a
value less than or equal to TENTATIVE_RR_BINDING_LIFETIME; the
Lifetime field in a Binding Update for de-registration MUST be set
to zero.
If an early Binding Update is sent before a Binding Acknowledgment
has been received from the home agent for the same pair of home
and care-of addresses, the mobile node MUST be prepared to
immediately delete the new binding at the correspondent node
should the home registration fail. The overhead associated with
such premature correspondent registrations can be avoided if the
mobile node waits for a successful Binding Acknowledgment from the
home agent before it sends the early Binding Update to the
correspondent node. This may come at the cost of increased
handoff latency, however.
After obtaining a home keygen token and a care-of keygen token
through the return routability procedure, and after receiving a
successful Binding Acknowledgment from the home agent, a standard
Binding Update MAY be sent to the correspondent node. This
standard Binding Update SHOULD be sent if an early Binding Update
has already been sent to the correspondent node during the same
registration process. The Lifetime field in the Binding Update
SHOULD be set to a value less than or equal to the remaining
lifetime of the home registration and the care-of address
specified in the message. The care-of address given in the
Binding Update MAY differ from the mobile node's primary care-of
address.
Unless a Binding Update is sent for de-registration, the care-of
address (either the Source Address in the packet's IPv6 header or
the Care-of Address in the Alternate Care-of Address mobility
option of the Binding Update) MUST be set to one of the care-of
addresses currently in use by the mobile node. A mobile node MAY
set the care-of address differently for sending Binding Updates to
different correspondent nodes. If the Binding Update is sent for
de-registration, in keeping with the Binding Update creation rules
below, the care-of address MUST be set to the home address if the
mobile node is at home, or to the current care-of address if it is
away from home.
- Original text
If the mobile node wants to ensure that its new care-of address
has been entered into a correspondent node's Binding Cache, the
mobile node needs to request an acknowledgement by setting the
Acknowledge (A) bit in the Binding Update.
Vogt Expires August 31, 2006 [Page 33]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
+ New text
If the mobile node wants to ensure that its new care-of address
has been entered into a correspondent node's Binding Cache, the
mobile node needs to request an acknowledgment by setting the
Acknowledge (A) bit in the Binding Update. The Acknowledge bit
MUST be set if the Binding Update is proactively sent before the
mobile node has actually moved to the link to which the new
care-of address (or home address, in case of a proactive de-
registration) belongs. The mobile node can then attempt to defer
the link-layer handoff to the new link until it receives a Binding
Acknowledgment from this correspondent node. If the mobile node
moves to a new link before it has received a Binding
Acknowledgment from a correspondent node to which it proactively
sent a Binding Update from the previous link, it MUST resend the
Binding Update from the new link.
- Original text
Each Binding Update MUST have a Sequence Number greater than the
Sequence Number value sent in the previous Binding Update to the
same destination address (if any). The sequence numbers are
compared modulo 2**16, as described in Section 9.5.1. There is no
requirement, however, that the Sequence Number value strictly
increase by 1 with each new Binding Update sent or received, as
long as the value stays within the window. The last Sequence
Number value sent to a destination in a Binding Update is stored
by the mobile node in its Binding Update List entry for that
destination. If the sending mobile node has no Binding Update
List entry, the Sequence Number SHOULD start at a random value.
The mobile node MUST NOT use the same Sequence Number in two
different Binding Updates to the same correspondent node, even if
the Binding Updates provide different care-of addresses.
+ New text
Each Binding Update MUST have a Sequence Number greater than the
Sequence Number value sent in the previous Binding Update to the
same destination address (if any). The sequence numbers are
compared modulo 2**16, as described in Section 9.5.1. There is no
requirement, however, that the Sequence Number value strictly
increase by 1 with each new Binding Update sent or received, as
long as the value stays within the window. The last Sequence
Number value sent to a destination in a standard Binding Update as
well as the last Sequence Number value sent to the same
destination in an early Binding Update are stored by the mobile
node in its Binding Update List entry for that destination. If
the sending mobile node has no Binding Update List entry, the
Vogt Expires August 31, 2006 [Page 34]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Sequence Number SHOULD start at a random value. The mobile node
MUST NOT use the same Sequence Number in two different Binding
Updates to the same correspondent node, even if the Binding
Updates provide different care-of addresses.
New Section 11.7.3, "Receiving Binding Acknowledgements":
- Original text
o The Sequence Number field matches the Sequence Number sent by
the mobile node to this destination address in an outstanding
Binding Update.
+ New text
o The Sequence Number field matches the Sequence Number sent by
the mobile node to this destination address in an outstanding
Binding Update. Note that, for Binding Acknowledgments
reveived from a correspondent node, the mobile node needs to
compare the Sequence Number value of the Binding Acknowledgment
to the right value in its Binding Update List entry, depending
on whether the Binding Acknowledgment corresponds to a standard
Binding Update or to an early Binding Update.
6. Security Considerations
The Mobile IPv6 extensions specified in this document differ from
standard Mobile IPv6 in the way a mobile node authenticates itself to
a correspondent node, and when it provides evidence of its
reachability at the claimed care-of address. According to [RFC3775],
a mobile node must have acquired valid home and care-of keygen tokens
before it can initiate a correspondent registration. This requires
the mobile node to be reachable at both its home and claimed care-of
address.
The extensions defined in this document relax this rule in that they
allow introduce an early Binding Update message that can be
authenticated with a home keygen token alone. This implies two
questions: First, does lack of a care-of-address test render
authentication through early Binding Update messages less secure than
authentication through standard Binding Update messages? Second,
inhowfar can early Binding Update messages be misused to register a
spoofed care-of address and effect malicious packet redirection? The
following elaborates on both of these questions.
Vogt Expires August 31, 2006 [Page 35]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
6.1 Authentication
At first glance, it may seem that authentication for early Binding
Update messages is weaker than that for standard Binding Update
messages: A standard Binding Update message is authenticated based
on two tokens transmitted via separate paths, so whoever generates it
must be on the intersection of both paths. The paths are in some
sense independent even if they happen to coincide topologically,
because only one of the paths is IPsec-protected between the mobile
node and the home agent. However, only the home keygen token can
prove the mobile node's identity; an attacker can generate a care-of
keygen token for any address through which it is itself reachable.
The attacker can consequently acquire both tokens once it is in a
position to intercept a Home Test message that a correspondent node
has sent to the mobile node's home address. Due to the IPsec tunnel
between the mobile node and the home agent, this position can only be
somewhere on the path between the correspondent node and the home
agent. In summary, the care-of keygen token does not strengthen the
authentication capability of a standard Binding Update message. An
early Binding Update is therefore as secure as a standard Binding
Update message with respect to authentication. It is worthwhile
emphasizing that the early Binding Update message is authenticated in
just the same way as a standard Binding Update message for de-
registration.
6.2 Reachability
A mobile node can use an early Binding Update message to register a
new care-of address without yet having shown that it is reachable at
that address. To prevent misuse of this feature for the purpose of
redirection-based flooding attacks, appropriate protection must be
provided. The specific protection mechanism is at the discretion of
the correspondent node. Section 4 discusses some approaches that
correspondent nodes may follow. It depends on the particular
deployment scenario which of these strategies applies best.
Ingress filtering [RFC2827] is usually considered an alternative
solution to the reachability problem. If deployed close to the
mobile node's IP attachment, ingress filtering can provide reasonable
insurance that an unverified care-of address is correct. The
technique has two disadvantages, however. One is that it can provide
full protection against address spoofing only if it is deployed
universally. As long as some operators do not use it, redirection
attacks can originate from their networks. Another disadvantage is
that ingress filtering evaluates only a packet's IP source address.
As a consequence, ingress filtering fails when an early or standard
Binding Update message contains the care-of address within an
Vogt Expires August 31, 2006 [Page 36]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Alternate Care-of Address mobility option. Ingress filtering hence
cannot protect a proactive registration procedure.
7. Protocol Constants
Section 12 of [RFC3775] defines a set of protocol constants. The
Mobile IPv6 extensions specified in this document require the
following additional protocol constants.
TENTATIVE_RR_BINDING_LIFETIME 10 seconds
PREVIOUS_CAREOF_ADDRESS_LIFETIME 10 seconds
EARLY_BINDING_UPDATE_RETRIES 3 retransmissions
8. References
8.1 Normative References
[CBA] Vogt, C. and J. Arkko, "Credit-Based Authorization for
Concurrent Reachability Verification", IETF Internet Draft
draft-vogt-mobopts-simple-cba-00.txt (work in progress),
February 2006.
[ODAD] Moore, N., "Optimistic Duplicate Address Detection for
IPv6", IETF Internet Draft
draft-ietf-ipv6-optimistic-dad-07.txt (work in progress),
December 2005.
[RFC3775] Johnson, D., E., C., and J. Arkko, "Mobility Support in
IPv6", IETF Request for Comments 3775, June 2004.
8.2 Informational References
[PETANDER05]
Petander, H. and E. Perera, "Improved Binding Management
for Make Before Break Handoffs in Mobile IPv6",
IETF Internet Draft draft-petander-mip6-mbb-00.txt (work
in progress), October 2005.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2827, May 2000.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Vogt Expires August 31, 2006 [Page 37]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", IETF Request for Comments 4225,
December 2005.
Author's Address
Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Email: chvogt@tm.uka.de
Appendix A. Acknowledgment
For their interest and valuable feedback, the authors thank the MIP6
and MOBOPTS communities, in particular Ralf Beck, Roland Bless, Mark
Doll, Francis Dupont, Gregory Daley, Lars Eggert, Daniel Jungbluth,
James Kempf, Rajeev Koodli, Tobias Kuefner, Max Laier, Marco Liebsch,
Gabriel Montenegro, Nick (Sharkey) Moore, Pekka Nikander, Erik
Nordmark, Charles Perkins, Constantin Schimmel, and Kilian Weniger
(listed in alphabetical order). Thanks are also due to the
development team of the Kame-Shisa Mobile IPv6 implementation.
Vogt Expires August 31, 2006 [Page 38]
Internet-Draft Early Binding Updates for Mobile IPv6 February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vogt Expires August 31, 2006 [Page 39]