draft-ietf-mext-rfc3775bis-06.txt   draft-ietf-mext-rfc3775bis-07.txt 
IETF Mobile IP Working Group C. Perkins (Ed.) IETF Mobile IP Working Group C. Perkins (Ed.)
Internet-Draft Tellabs Inc. Internet-Draft Tellabs Inc.
Obsoletes: 3775 (if approved) D. Johnson Obsoletes: 3775 (if approved) D. Johnson
Expires: January 13, 2011 Rice University Expires: April 7, 2011 Rice University
J. Arkko J. Arkko
Ericsson Ericsson
July 12, 2010 Oct 04, 2010
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-06.txt draft-ietf-mext-rfc3775bis-07.txt
Abstract Abstract
This document specifies a protocol which allows nodes to remain This document specifies Mobile IPv6, a protocol which allows nodes to
reachable while moving around in the IPv6 Internet. Each mobile node remain reachable while moving around in the IPv6 Internet. Each
is always identified by its home address, regardless of its current mobile node is always identified by its home address, regardless of
point of attachment to the Internet. While situated away from its its current point of attachment to the Internet. While situated away
home, a mobile node is also associated with a care-of address, which from its home, a mobile node is also associated with a care-of
provides information about the mobile node's current location. IPv6 address, which provides information about the mobile node's current
packets addressed to a mobile node's home address are transparently location. IPv6 packets addressed to a mobile node's home address are
routed to its care-of address. The protocol enables IPv6 nodes to transparently routed to its care-of address. The protocol enables
cache the binding of a mobile node's home address with its care-of IPv6 nodes to cache the binding of a mobile node's home address with
address, and to then send any packets destined for the mobile node its care-of address, and to then send any packets destined for the
directly to it at this care-of address. To support this operation, mobile node directly to it at this care-of address. To support this
Mobile IPv6 defines a new IPv6 protocol and a new destination option. operation, Mobile IPv6 defines a new IPv6 protocol and a new
All IPv6 nodes, whether mobile or stationary, can communicate with destination option. All IPv6 nodes, whether mobile or stationary,
mobile nodes. can communicate with mobile nodes. This document obsoletes RFC 3775.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on April 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 5, line 40 skipping to change at page 5, line 40
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 166 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 166
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 167 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 167
18.1. Normative References . . . . . . . . . . . . . . . . . . 167 18.1. Normative References . . . . . . . . . . . . . . . . . . 167
18.2. Informative References . . . . . . . . . . . . . . . . . 168 18.2. Informative References . . . . . . . . . . . . . . . . . 168
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 171 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 171
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 171 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 171
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 171 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 171
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 171 A.3. New Authorization Methods . . . . . . . . . . . . . . . . 171
A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 171 A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 171
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173 Appendix B. Changes since RFC 3775 . . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175
1. Introduction 1. Introduction
This document specifies a protocol which allows nodes to remain This document specifies a protocol which allows nodes to remain
reachable while moving around in the IPv6 Internet. Without specific reachable while moving around in the IPv6 Internet. Without specific
support for mobility in IPv6 [5], packets destined to a mobile node support for mobility in IPv6 [5], packets destined to a mobile node
would not be able to reach it while the mobile node is away from its would not be able to reach it while the mobile node is away from its
home link. In order to continue communication in spite of its home link. In order to continue communication in spite of its
movement, a mobile node could change its IP address each time it movement, a mobile node could change its IP address each time it
moves to a new link, but the mobile node would then not be able to moves to a new link, but the mobile node would then not be able to
skipping to change at page 8, line 5 skipping to change at page 7, line 19
o Assistance for adaptive applications. o Assistance for adaptive applications.
o Mobile routers. o Mobile routers.
o Service Discovery. o Service Discovery.
o Distinguishing between packets lost due to bit errors vs. network o Distinguishing between packets lost due to bit errors vs. network
congestion. congestion.
This document obsoletes RFC 3775. Issues with the original document
have been observed during integration, testing and deployment of RFC
3775. A more detailed list of the changes since RFC 3775 may be
found in Appendix B.
2. Comparison with Mobile IP for IPv4 2. Comparison with Mobile IP for IPv4
The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both
from the experiences gained from the development of Mobile IP support from the experiences gained from the development of Mobile IP support
in IPv4 (Mobile IPv4) [30] [24] [25], and from the opportunities in IPv4 (Mobile IPv4) [30] [24] [25], and from the opportunities
provided by IPv6. Mobile IPv6 thus shares many features with Mobile provided by IPv6. Mobile IPv6 thus shares many features with Mobile
IPv4, but is integrated into IPv6 and offers many other improvements. IPv4, but is integrated into IPv6 and offers many other improvements.
This section summarizes the major differences between Mobile IPv4 and This section summarizes the major differences between Mobile IPv4 and
Mobile IPv6: Mobile IPv6:
skipping to change at page 17, line 47 skipping to change at page 17, line 47
A Binding Update is used by a mobile node to notify a A Binding Update is used by a mobile node to notify a
correspondent node or the mobile node's home agent of its current correspondent node or the mobile node's home agent of its current
binding. The Binding Update sent to the mobile node's home agent binding. The Binding Update sent to the mobile node's home agent
to register its primary care-of address is marked as a "home to register its primary care-of address is marked as a "home
registration". registration".
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement is used to acknowledge receipt of a A Binding Acknowledgement is used to acknowledge receipt of a
Binding Update, if an acknowledgement was requested in the Binding Binding Update, if an acknowledgement was requested in the Binding
Update (e.g., the binding update was sent to a home agent), or an Update (e.g., the Binding Update was sent to a home agent), or an
error occurred. error occurred.
Binding Refresh Request Binding Refresh Request
A Binding Refresh Request is used by a correspondent node to A Binding Refresh Request is used by a correspondent node to
request that a mobile node re-establish its binding with the request that a mobile node re-establish its binding with the
correspondent node. This message is typically used when the correspondent node. This message is typically used when the
cached binding is in active use but the binding's lifetime is cached binding is in active use but the binding's lifetime is
close to expiration. The correspondent node may use, for close to expiration. The correspondent node may use, for
instance, recent traffic and open transport layer connections as instance, recent traffic and open transport layer connections as
skipping to change at page 21, line 47 skipping to change at page 21, line 47
its security association to send a Binding Update on behalf of its security association to send a Binding Update on behalf of
another mobile node using the same home agent. This MUST be achieved another mobile node using the same home agent. This MUST be achieved
by having the home agent check that the given home address has been by having the home agent check that the given home address has been
used with the right security association. Such a check is provided used with the right security association. Such a check is provided
in the IPsec processing, by having the security policy database in the IPsec processing, by having the security policy database
entries unequivocally identify a single security association for entries unequivocally identify a single security association for
protecting Binding Updates between any given home address and home protecting Binding Updates between any given home address and home
agent. In order to make this possible, it is necessary that the home agent. In order to make this possible, it is necessary that the home
address of the mobile node is visible in the Binding Updates and address of the mobile node is visible in the Binding Updates and
Acknowledgements. The home address is used in these packets as a Acknowledgements. The home address is used in these packets as a
source or destination, or in the Home Address Destination option or source or destination, or in the Home Address destination option or
the type 2 routing header. the type 2 routing header.
As with all IPsec security associations in this specification, manual As with all IPsec security associations in this specification, manual
configuration of security associations MUST be supported. The shared configuration of security associations MUST be supported. The shared
secrets used MUST be random and unique for different mobile nodes, secrets used MUST be random and unique for different mobile nodes,
and MUST be distributed off-line to the mobile nodes. Automatic key and MUST be distributed off-line to the mobile nodes. Automatic key
management with IKEv2 [41] MAY be supported as described in [42]. management with IKEv2 [41] MAY be supported as described in [42].
Section 11.3.2 discusses how IKEv2 connections to the home agent need Section 11.3.2 discusses how IKEv2 connections to the home agent need
a careful treatment of the addresses used for transporting IKEv2. a careful treatment of the addresses used for transporting IKEv2.
skipping to change at page 22, line 35 skipping to change at page 22, line 35
who are on the path between the home network and the correspondent who are on the path between the home network and the correspondent
node. However, attackers in such a location are capable of node. However, attackers in such a location are capable of
performing the same attacks even without Mobile IPv6. The main performing the same attacks even without Mobile IPv6. The main
advantage of the return routability procedure is that it limits the advantage of the return routability procedure is that it limits the
potential attackers to those having an access to one specific path in potential attackers to those having an access to one specific path in
the Internet, and avoids forged Binding Updates from anywhere else in the Internet, and avoids forged Binding Updates from anywhere else in
the Internet. For a more in depth explanation of the security the Internet. For a more in depth explanation of the security
properties of the return routability procedure, see Section 15. properties of the return routability procedure, see Section 15.
Also, consult [40] Also, consult [40]
The integrity and authenticity of the Binding Updates messages to The integrity and authenticity of the Binding Update messages to
correspondent nodes is protected by using a keyed-hash algorithm. correspondent nodes is protected by using a keyed-hash algorithm.
The binding management key, Kbm, is used to key the hash algorithm The binding management key, Kbm, is used to key the hash algorithm
for this purpose. Kbm is established using data exchanged during the for this purpose. Kbm is established using data exchanged during the
return routability procedure. The data exchange is accomplished by return routability procedure. The data exchange is accomplished by
use of node keys, nonces, cookies, tokens, and certain cryptographic use of node keys, nonces, cookies, tokens, and certain cryptographic
functions. Section 5.2.5 outlines the basic return routability functions. Section 5.2.5 outlines the basic return routability
procedure. Section 5.2.6 shows how the results of this procedure are procedure. Section 5.2.6 shows how the results of this procedure are
used to authorize a Binding Update to a correspondent node. used to authorize a Binding Update to a correspondent node.
5.2.1. Node Keys 5.2.1. Node Keys
skipping to change at page 66, line 35 skipping to change at page 66, line 35
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [17]: specified for Neighbor Discovery [17]:
Router Address (R) Router Address (R)
1-bit router address flag. When set, indicates that the Prefix 1-bit router address flag. When set, indicates that the Prefix
field contains a complete IP address assigned to the sending field contains a complete IP address assigned to the sending
router. The indicated prefix is the first Prefix Length bits of router. The indicated prefix is given by the first Prefix Length
the Prefix field. The router IP address has the same scope and bits of the Prefix field. The router IP address has the same
conforms to the same lifetime values as the advertised prefix. scope and conforms to the same lifetime values as the advertised
This use of the Prefix field is compatible with its use in prefix. This use of the Prefix field is compatible with its use
advertising the prefix itself, since Prefix Advertisement uses in advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits. Autonomous Address-Configuration (A) flag bits.
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit. addition of the above bit.
In a Router Advertisement, a home agent MUST, and all other routers In a Router Advertisement, a home agent MUST, and all other routers
skipping to change at page 94, line 23 skipping to change at page 94, line 23
o The lifetime for the Binding Cache entry MUST NOT be greater than o The lifetime for the Binding Cache entry MUST NOT be greater than
the Lifetime value specified in the Binding Update. the Lifetime value specified in the Binding Update.
o The lifetime for the Binding Cache entry MUST NOT be greater than o The lifetime for the Binding Cache entry MUST NOT be greater than
the remaining valid lifetime for the subnet prefix in the mobile the remaining valid lifetime for the subnet prefix in the mobile
node's home address specified with the Binding Update. The node's home address specified with the Binding Update. The
remaining valid lifetime for this prefix is determined by the home remaining valid lifetime for this prefix is determined by the home
agent based on its own Prefix List entry [17]. agent based on its own Prefix List entry [17].
The remaining preferred lifetime SHOULD NOT have any impact on the The remaining preferred lifetime SHOULD NOT have any impact on the
lifetime for the binding cache entry. lifetime for the Binding Cache entry.
The home agent MUST remove a binding when the valid lifetime of The home agent MUST remove a binding when the valid lifetime of
the prefix associated with it expires. the prefix associated with it expires.
o The home agent MAY further decrease the specified lifetime for the o The home agent MAY further decrease the specified lifetime for the
binding, for example based on a local policy. The resulting binding, for example based on a local policy. The resulting
lifetime is stored by the home agent in the Binding Cache entry, lifetime is stored by the home agent in the Binding Cache entry,
and this Binding Cache entry MUST be deleted by the home agent and this Binding Cache entry MUST be deleted by the home agent
after the expiration of this lifetime. after the expiration of this lifetime.
skipping to change at page 97, line 21 skipping to change at page 97, line 21
The rules for selecting the Destination IP address (and, if required, The rules for selecting the Destination IP address (and, if required,
routing header construction) for the Binding Acknowledgement to the routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in the previous section. When the Status mobile node are the same as in the previous section. When the Status
field in the Binding Acknowledgement is greater than or equal to 128 field in the Binding Acknowledgement is greater than or equal to 128
and the Source Address of the Binding Update is on the home link, and and the Source Address of the Binding Update is on the home link, and
the Binding Update came from a mobile node on the same link, the home the Binding Update came from a mobile node on the same link, the home
agent MUST send it to the mobile node's link layer address (retrieved agent MUST send it to the mobile node's link layer address (retrieved
either from the Binding Update or through Neighbor Solicitation). either from the Binding Update or through Neighbor Solicitation).
When a mobile node sends a binding update to refresh the binding from When a mobile node sends a Binding Update to refresh the binding from
the visited link and soon after moves to the home link and sends a the visited link and soon after moves to the home link and sends a
de-registration binding update, a race condition can happen if the de-registration Binding Update, a race condition can happen if the
first binding update gets delayed. The delayed binding update can first Binding Update gets delayed. The delayed Binding Update can
cause the home agent to create a new binding cache entry for a mobile cause the home agent to create a new Binding Cache entry for a mobile
node that had just attached to the home link and successfully deleted node that had just attached to the home link and successfully deleted
the binding. This would prevent the mobile node from using its home the binding. This would prevent the mobile node from using its home
address from the home link. address from the home link.
In order to prevent this, the home agent SHOULD NOT remove the In order to prevent this, the home agent SHOULD NOT remove the
binding cache entry immediately after receiving the deregistration Binding Cache entry immediately after receiving the deregistration
binding update from the mobile node. It SHOULD mark the binding Binding Update from the mobile node. It SHOULD mark the Binding
cache entry as invalid, and MUST stop intercepting packets on the Cache entry as invalid, and MUST stop intercepting packets on the
mobile node's home link that are addressed to the mobile node mobile node's home link that are addressed to the mobile node
(Section 10.4.1). The home agent should wait for (Section 10.4.1). The home agent should wait for
MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the
binding cache entry completely. In the scenario described above, if Binding Cache entry completely. In the scenario described above, if
the home agent receives the delayed binding update that the mobile the home agent receives the delayed Binding Update that the mobile
node sent from the visited link, it would reject the message since node sent from the visited link, it would reject the message since
the sequence number would be less than the last received the sequence number would be less than the last received
deregistration binding update from the home link. The home agent deregistration Binding Update from the home link. The home agent
would then send a Binding Acknowledgment with status '135' (Sequence would then send a Binding Acknowledgment with status '135' (Sequence
number out of window) to the care of address on the visited link. number out of window) to the care of address on the visited link.
The mobile node can continue using the home address from the home The mobile node can continue using the home address from the home
link. link.
10.4. Packet Processing 10.4. Packet Processing
10.4.1. Intercepting Packets for a Mobile Node 10.4.1. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for a mobile node it MUST While a node is serving as the home agent for a mobile node it MUST
skipping to change at page 106, line 13 skipping to change at page 106, line 13
Packet Too Big message [16]). Packet Too Big message [16]).
10.6. Sending Prefix Information to the Mobile Node 10.6. Sending Prefix Information to the Mobile Node
10.6.1. List of Home Network Prefixes 10.6.1. List of Home Network Prefixes
Mobile IPv6 arranges to propagate relevant prefix information to the Mobile IPv6 arranges to propagate relevant prefix information to the
mobile node when it is away from home, so that it may be used in mobile node when it is away from home, so that it may be used in
mobile node home address configuration and in network renumbering. mobile node home address configuration and in network renumbering.
In this mechanism, mobile nodes away from home receive Mobile Prefix In this mechanism, mobile nodes away from home receive Mobile Prefix
Advertisements messages. These messages include Prefix Information Advertisement messages. These messages include Prefix Information
Options for the prefixes configured on the home subnet interface(s) Options for the prefixes configured on the home subnet interface(s)
of the home agent. of the home agent.
If there are multiple home agents, differences in the advertisements If there are multiple home agents, differences in the advertisements
sent by different home agents can lead to an inability to use a sent by different home agents can lead to an inability to use a
particular home address when changing to another home agent. In particular home address when changing to another home agent. In
order to ensure that the mobile nodes get the same information from order to ensure that the mobile nodes get the same information from
different home agents, it is preferred that all of the home agents on different home agents, it is preferred that all of the home agents on
the same link be configured in the same manner. the same link be configured in the same manner.
skipping to change at page 139, line 44 skipping to change at page 139, line 44
correspondent registration, as well as any retransmissions that may correspondent registration, as well as any retransmissions that may
be needed (subject to the rate limitation defined in Section 11.8). be needed (subject to the rate limitation defined in Section 11.8).
11.7.3. Receiving Binding Acknowledgements 11.7.3. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests: node MUST validate the packet according to the following tests:
o The packet meets the authentication requirements for Binding o The packet meets the authentication requirements for Binding
Acknowledgements defined in Section 6.1.8 and Section 5. That is, Acknowledgements defined in Section 6.1.8 and Section 5. That is,
if the Binding Update was sent to the home agent, underlying IPsec if the Binding Update was sent to the home agent, the underlying
protection is used. If the Binding Update was sent to the IPsec protection is used. If the Binding Update was sent to the
correspondent node, the Binding Authorization Data mobility option correspondent node, the Binding Authorization Data mobility option
MUST be present and have a valid value. MUST be present and have a valid value.
o The Binding Authorization Data mobility option, if present, MUST o The Binding Authorization Data mobility option, if present, MUST
be the last option and MUST NOT have trailing padding. be the last option and MUST NOT have trailing padding.
o The Sequence Number field matches the Sequence Number sent by the o The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding mobile node to this destination address in an outstanding Binding
Update, and the Status field is not 135. Update, and the Status field is not 135.
skipping to change at page 141, line 46 skipping to change at page 141, line 46
If this bit is set, the mobile node SHOULD move its own endpoint in If this bit is set, the mobile node SHOULD move its own endpoint in
the key management protocol connections to the home agent, if any. the key management protocol connections to the home agent, if any.
The mobile node's new endpoint should be the new care-of address. The mobile node's new endpoint should be the new care-of address.
11.7.4. Receiving Binding Refresh Requests 11.7.4. Receiving Binding Refresh Requests
When a mobile node receives a packet containing a Binding Refresh When a mobile node receives a packet containing a Binding Refresh
Request message, if the mobile node has a Binding Update List entry Request message, if the mobile node has a Binding Update List entry
for the source of the Binding Refresh Request, and the mobile node for the source of the Binding Refresh Request, and the mobile node
wants to retain its binding cache entry at the correspondent node, wants to retain its Binding Cache entry at the correspondent node,
then the mobile node should start a return routability procedure. If then the mobile node should start a return routability procedure. If
the mobile node wants to have its binding cache entry removed, it can the mobile node wants to have its Binding Cache entry removed, it can
either ignore the Binding Refresh Request and wait for the binding to either ignore the Binding Refresh Request and wait for the binding to
time out, or at any time, it can delete its binding from a time out, or at any time, it can delete its binding from a
correspondent node with an explicit binding update with a zero correspondent node with an explicit Binding Update with a zero
lifetime and the care-of address set to the home address. If the lifetime and the care-of address set to the home address. If the
mobile node does not know if it needs the binding cache entry, it can mobile node does not know if it needs the Binding Cache entry, it can
make the decision in an implementation dependent manner, such as make the decision in an implementation dependent manner, such as
based on available resources. based on available resources.
Note that the mobile node should be careful to not respond to Binding Note that the mobile node should be careful to not respond to Binding
Refresh Requests for addresses not in the Binding Update List to Refresh Requests for addresses not in the Binding Update List to
avoid being subjected to a denial of service attack. avoid being subjected to a denial of service attack.
If the return routability procedure completes successfully, a Binding If the return routability procedure completes successfully, a Binding
Update message SHOULD be sent, as described in Section 11.7.2. The Update message SHOULD be sent, as described in Section 11.7.2. The
Lifetime field in this Binding Update SHOULD be set to a new Lifetime field in this Binding Update SHOULD be set to a new
skipping to change at page 173, line 5 skipping to change at page 173, line 5
every time the mobile node moves on to new links will need to be every time the mobile node moves on to new links will need to be
examined. Improvements in this area are, however, generally examined. Improvements in this area are, however, generally
applicable and progress independently from the Mobile IPv6 applicable and progress independently from the Mobile IPv6
specification. specification.
Future functional improvements may also be relevant for Mobile IPv6 Future functional improvements may also be relevant for Mobile IPv6
and other applications. For instance, mechanisms that would allow and other applications. For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be useful recovery from a Duplicate Address Detection collision would be useful
for link-local, care-of, and home addresses. for link-local, care-of, and home addresses.
Appendix B. Changes since RFC 3775
The following issues were identified during the evolution of the
current document. Discussion about the issues can be found on the
[mext] working group page
http://trac.tools.ietf.org/wg/mext/trac/report/6
Issue #1 Last Accepted SQN [Ahmad Muhanna]
Solution: specify that the mobile node update its binding sequence
number to match the sequence number given in the Binding
Acknowledgement (if the Binding Acknowledgement correctly passes
authentication and the status is 135 (Sequence Number out of
window). See Section 11.7.3.
Issue #4 Remove references to site-local addresses [George
Tsirtsis].
Fixed.
Issue #5 Wrong protocol number (2 instead of 135) used in discussion
about checksum pseudo-header.
Fixed. See Section 6.1.1.
Issue #8 Application using the care-of address [Julien Laganier]
Cite IPv6 Socket API for Source Address Selection specification
[21]. See Section 11.3.4.
Issue #10 The usage of "HA lifetime" [Ryuji Wakikawa]
The mobile node SHOULD store the list of home agents for later use
in case the home agent currently managing the mobile node's
care-of address forwarding should become unavailable. See
Section 11.4.1.
Issue #11 De-registration when returning home [Vijay Devarapalli]
To be able to send and receive packets using its home address from
the home link, the mobile node MUST send a Binding Update to its
home agent to instruct its home agent to no longer intercept or
tunnel packets for it. Until the mobile node sends such a de-
registration Binding Update, it MUST NOT attempt to send and
receive packets using its home address from the home link. See
Section 11.5.5.
Issue #12 BErr sent by HA too, not only by CN [Alexandru Petrescu]
Fixed. See Section 4.2.
Issue #13 Home Link Detection [Suresh Krishnan]
Proposal: add Section 11.5.2 for Home Link Detection, drawing on
Internet Draft draft-krishnan-mext-hld.
Issue #14 References to Bootstrapping [Vijay Devarapalli]
Cite "Mobile IPv6 Bootstrapping in Split Scenario" [22] and "MIP6
bootstrapping for the Integrated Scenario" [34]. See Section 4.1.
Issue #17 Multi-homed mobile node can cause routing loop between
home agents [Benjamin Lim]
Added security advisory in Section 15.1, to highlight risk of
routing loop among HAs (e.g., in 3GPP):
A malicious mobile node associated to multiple home agents could
create a routing loop amongst them. This would happen when a
mobile node binds one home address located on a first home agent
to another home address on a second home agent.
Issue #18 Subject: Issues regarding Home Address Option and ICMP /
Binding Errors [Fabian Mauchle]
Proposal: Use the value in the Next Header field {50 (ESP), 51
(AH), 135 (Mobility Header)} to determine, if a Binding Cache
entry is required. See Section 9.3.1.
Proposal: If the Binding Error Message was sent by the Home Agent,
the Mobile Node SHOULD send a Binding Update to the Home Agent
according to Section 11.7.1. See Section 11.3.6.
Issue #19 BU de-registration race condition [Kilian Weniger]
Problem arises if de-registration arrives at Home Agent before an
immediately preceding Binding Update.
Solution: Home Agent defers BCE removal after sending the Binding
Acknowledgement. See Section 10.3.2.
Issue #6 Minor editorial corrections and updates
Authors' Addresses Authors' Addresses
Charles E. Perkins Charles E. Perkins
Tellabs Inc. Tellabs Inc.
3590 N. 1st Street, Suite 300 3590 N. 1st Street, Suite 300
San Jose CA 95134 San Jose CA 95134
USA USA
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 24 change blocks. 
45 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/