draft-ietf-mext-rfc3775bis-04.txt   draft-ietf-mext-rfc3775bis-05.txt 
IETF Mobile IP Working Group D. Johnson IETF Mobile IP Working Group D. Johnson
Internet-Draft Rice University Internet-Draft Rice University
Obsoletes: 3775 (if approved) C. Perkins (Ed.) Obsoletes: 3775 (if approved) C. Perkins (Ed.)
Expires: January 14, 2010 WiChorus Inc. Expires: April 22, 2010 WiChorus Inc.
J. Arkko J. Arkko
Ericsson Ericsson
July 13, 2009 October 19, 2009
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-04.txt draft-ietf-mext-rfc3775bis-05.txt
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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on April 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 25 skipping to change at page 6, line 25
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 165 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168
18.1. Normative References . . . . . . . . . . . . . . . . . . 168 18.1. Normative References . . . . . . . . . . . . . . . . . . 168
18.2. Informative References . . . . . . . . . . . . . . . . . 169 18.2. Informative References . . . . . . . . . . . . . . . . . 169
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 172 A.3. New Authorization Methods . . . . . . . . . . . . . . . . 172
A.4. Dynamically Generated Home Addresses . . . . . . . . . . 172 A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 172
A.5. Remote Home Address Configuration . . . . . . . . . . . . 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
A.6. Neighbor Discovery Extensions . . . . . . . . . . . . . . 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 [8], packets destined to a mobile node support for mobility in IPv6 [8], 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 12, line 20 skipping to change at page 12, line 20
followed by all of the octets of the datum B. followed by all of the octets of the datum B.
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
3.2. Mobile IPv6 Terms 3.2. Mobile IPv6 Terms
These terms are intended to be compatible with the definitions given
in RFC 3753[40]. However, if there is any conflict, the definitions
given here should be considered to supersede those in RFC 3753.
home address home address
A unicast routable address assigned to a mobile node, used as the A unicast routable address assigned to a mobile node, used as the
permanent address of the mobile node. This address is within the permanent address of the mobile node. This address is within the
mobile node's home link. Standard IP routing mechanisms will mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its deliver packets destined for a mobile node's home address to its
home link. Mobile nodes can have multiple home addresses, for home link. Mobile nodes can have multiple home addresses, for
instance when there are multiple home prefixes on the home link. instance when there are multiple home prefixes on the home link.
home subnet prefix home subnet prefix
skipping to change at page 13, line 9 skipping to change at page 13, line 9
A change in a mobile node's point of attachment to the Internet A change in a mobile node's point of attachment to the Internet
such that it is no longer connected to the same link as it was such that it is no longer connected to the same link as it was
previously. If a mobile node is not currently attached to its previously. If a mobile node is not currently attached to its
home link, the mobile node is said to be "away from home". home link, the mobile node is said to be "away from home".
L2 handover L2 handover
A process by which the mobile node changes from one link-layer A process by which the mobile node changes from one link-layer
connection to another. For example, a change of wireless access connection to another. For example, a change of wireless access
point is an L2 handover. point is a L2 handover.
L3 handover L3 handover
Subsequent to an L2 handover, a mobile node detects a change in an Subsequent to a L2 handover, a mobile node detects a change in an
on-link subnet prefix that would require a change in the primary on-link subnet prefix that would require a change in the primary
care-of address. For example, a change of access router care-of address. For example, a change of access router
subsequent to a change of wireless access point typically results subsequent to a change of wireless access point typically results
in an L3 handover. in an L3 handover.
correspondent node correspondent node
A peer node with which a mobile node is communicating. The A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary. correspondent node may be either mobile or stationary.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
of the mobile node. When sending a packet to any IPv6 destination, of the mobile node. When sending a packet to any IPv6 destination,
the correspondent node checks its cached bindings for an entry for the correspondent node checks its cached bindings for an entry for
the packet's destination address. If a cached binding for this the packet's destination address. If a cached binding for this
destination address is found, the node uses a new type of IPv6 destination address is found, the node uses a new type of IPv6
routing header [8] (see Section 6.4) to route the packet to the routing header [8] (see Section 6.4) to route the packet to the
mobile node by way of the care-of address indicated in this binding. mobile node by way of the care-of address indicated in this binding.
Routing packets directly to the mobile node's care-of address allows Routing packets directly to the mobile node's care-of address allows
the shortest communications path to be used. It also eliminates the shortest communications path to be used. It also eliminates
congestion at the mobile node's home agent and home link. In congestion at the mobile node's home agent and home link. In
addition, the impact of any possible failure of the home agent or addition, the impact of temporary failures of the home agent or
networks on the path to or from it is reduced. networks on the path to or from the home agent is reduced.
When routing packets directly to the mobile node, the correspondent When routing packets directly to the mobile node, the correspondent
node sets the Destination Address in the IPv6 header to the care-of node sets the Destination Address in the IPv6 header to the care-of
address of the mobile node. A new type of IPv6 routing header (see address of the mobile node. A new type of IPv6 routing header (see
Section 6.4) is also added to the packet to carry the desired home Section 6.4) is also added to the packet to carry the desired home
address. Similarly, the mobile node sets the Source Address in the address. Similarly, the mobile node sets the Source Address in the
packet's IPv6 header to its current care-of addresses. The mobile packet's IPv6 header to its current care-of addresses. The mobile
node adds a new IPv6 "Home Address" destination option (see node adds a new IPv6 "Home Address" destination option (see
Section 6.3) to carry its home address. The inclusion of home Section 6.3) to carry its home address. The inclusion of home
addresses in these packets makes the use of the care-of address addresses in these packets makes the use of the care-of address
skipping to change at page 18, line 47 skipping to change at page 18, 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, the binding update was sent to a home agent, or an error Update (e.g., the binding update was sent to a home agent), or an
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 a mobile node to 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
an indication of active use. an indication of active use.
Binding Error Binding Error
The Binding Error is used by the correspondent node or the home The Binding Error is used by the correspondent node to signal an
agent to signal an error related to mobility, such as an error related to mobility, such as an inappropriate attempt to use
inappropriate attempt to use the Home Address destination option the Home Address destination option without an existing binding.
without an existing binding, or when an unrecognized Mobility The Binding Error message is also used by the Home Agent to signal
Header is received. an error to the mobile node, if it receives an unrecognized
Mobility Header Message Type from the mobile node.
4.3. New IPv6 Destination Option 4.3. New IPv6 Destination Option
Mobile IPv6 defines a new IPv6 destination option, the Home Address Mobile IPv6 defines a new IPv6 destination option, the Home Address
destination option. This option is described in detail in destination option. This option is described in detail in
Section 6.3. Section 6.3.
4.4. New IPv6 ICMP Messages 4.4. New IPv6 ICMP Messages
Mobile IPv6 also introduces four new ICMP message types, two for use Mobile IPv6 also introduces four new ICMP message types, two for use
skipping to change at page 20, line 38 skipping to change at page 20, line 38
Home agents need to know which other home agents are on the same Home agents need to know which other home agents are on the same
link. This information is stored in the Home Agents List, as link. This information is stored in the Home Agents List, as
described in more detail in Section 10.1. The list is used for described in more detail in Section 10.1. The list is used for
informing mobile nodes during dynamic home agent address informing mobile nodes during dynamic home agent address
discovery. discovery.
4.6. Unique-Local Addressability 4.6. Unique-Local Addressability
This specification requires that home and care-of addresses MUST be This specification requires that home and care-of addresses MUST be
unicast routable addresses. Unique-local IPv6 unicast addresses unicast routable addresses. Unique-local IPv6 unicast addresses
RFC4193 [22] may be usable on networks that use such non-globaly (ULAs) RFC4193 [22] may be usable on networks that use such non-
routable addresses but this specification does not define when such globally routable addresses but this specification does not define
usage is safe and when it is not. Mobile nodes may not be aware of when such usage is safe and when it is not. Mobile nodes may not be
which site they are currently making it hard to prevent accidental able to distinguish between their home site and the site at which
attachment to other sites, resulting in possible unrechability they are currently located. This can make it hard to prevent
between the MN and the HA, when unique-local IPv6 routable addresses accidental attachment to other sites, because the mobile node might
are used as care-of addresses. Also, CNs outside the MN's own site use the ULA at another site, which could not be used to successfully
are not going to be reachable when unique-local IPv6 routable send packets to the mobile node's HA. This would result in
addresses are used as home addresses. Therefore, unique-local IPv6 unreachability between the MN and the HA, when unique-local IPv6
unicast addresses SHOULD NOT be used as home or care-of addresses. routable addresses are used as care-of addresses. Similarly, CNs
If such addresses are used, however, according to RFC4193 [22], they outside the MN's own site will not be reachable when ULAs are used as
are treated as any global unicast IPv6 address so, for the remainder home addresses. Therefore, unique-local IPv6 unicast addresses
of this specification, use of unique-local IPv6 unicast addresses is SHOULD NOT be used as home or care-of addresses when other address
not differentiated from other globally unique IPv6 addresses. choices are available. If such addresses are used, however,
according to RFC4193 [22], they are treated as any global unicast
IPv6 address so, for the remainder of this specification, use of
unique-local IPv6 unicast addresses is not differentiated from other
globally unique IPv6 addresses.
5. Overview of Mobile IPv6 Security 5. Overview of Mobile IPv6 Security
This specification provides a number of security features. These This specification provides a number of security features. These
include the protection of Binding Updates both to home agents and include the protection of Binding Updates both to home agents and
correspondent nodes, the protection of mobile prefix discovery, and correspondent nodes, the protection of mobile prefix discovery, and
the protection of the mechanisms that Mobile IPv6 uses for the protection of the mechanisms that Mobile IPv6 uses for
transporting data packets. transporting data packets.
Binding Updates are protected by the use of IPsec extension headers, Binding Updates are protected by the use of IPsec extension headers,
skipping to change at page 23, line 6 skipping to change at page 23, line 6
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 used configuration of security associations MUST be supported. The used
shared secrets MUST be random and unique for different mobile nodes, shared secrets MUST be random and unique for different mobile nodes,
and MUST be distributed off-line to the mobile nodes. and MUST be distributed off-line to the mobile nodes.
Automatic key management with IKE [7] MAY be supported. When IKE is Automatic key management with IKE [7] or IKEv2 [44] MAY be supported.
used, either the security policy database entries or the Mobile IPv6 When IKE is used, either the security policy database entries or the
processing MUST unequivocally identify the IKE phase 1 credentials Mobile IPv6 processing MUST unequivocally identify the IKE phase 1
which can be used to authorize the creation of security associations credentials which can be used to authorize the creation of security
for protecting Binding Updates for a particular home address. How associations for protecting Binding Updates for a particular home
these mappings are maintained is outside the scope of this address. How these mappings are maintained is outside the scope of
specification, but they may be maintained, for instance, as a locally this specification, but they may be maintained, for instance, as a
administered table in the home agent. If the phase 1 identity is a locally administered table in the home agent. If the phase 1
Fully Qualified Domain Name (FQDN), secure forms of DNS may also be identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS
used. may also be used.
Section 11.3.2 discusses how IKE connections to the home agent need a Section 11.3.2 discusses how IKE connections to the home agent need a
careful treatment of the addresses used for transporting IKE. This careful treatment of the addresses used for transporting IKE. This
is necessary to ensure that a Binding Update is not needed before the is necessary to ensure that a Binding Update is not needed before the
IKE exchange which is needed for securing the Binding Update. IKE exchange which is needed for securing the Binding Update.
When IKE version 1 is used with preshared secret authentication When IKE version 1 is used with preshared secret authentication
between the mobile node and the home agent, aggressive mode MUST be between the mobile node and the home agent, aggressive mode MUST be
used. used.
The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1. The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.
Reference [15] contains a more detailed description and examples on References [15] and [45] contain more detailed descriptions and
using IPsec to protect the communications between the mobile node and examples on using IPsec to protect the communications between the
the home agent. mobile node and the home agent.
5.2. Binding Updates to Correspondent Nodes 5.2. Binding Updates to Correspondent Nodes
The protection of Binding Updates sent to correspondent nodes does The protection of Binding Updates sent to correspondent nodes does
not require the configuration of security associations or the not require the configuration of security associations or the
existence of an authentication infrastructure between the mobile existence of an authentication infrastructure between the mobile
nodes and correspondent nodes. Instead, a method called the return nodes and correspondent nodes. Instead, a method called the return
routability procedure is used to assure that the right mobile node is routability procedure is used to assure that the right mobile node is
sending the message. This method does not protect against attackers sending the message. This method does not protect against attackers
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 [43]
The integrity and authenticity of the Binding Updates messages to The integrity and authenticity of the Binding Updates 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 28, line 28 skipping to change at page 28, line 28
it generates a home keygen token as follows: it generates a home keygen token as follows:
home keygen token := home keygen token :=
First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
where | denotes concatenation. The final "0" inside the HMAC_SHA1 where | denotes concatenation. The final "0" inside the HMAC_SHA1
function is a single zero octet, used to distinguish home and function is a single zero octet, used to distinguish home and
care-of cookies from each other. care-of cookies from each other.
The home keygen token is formed from the first 64 bits of the MAC. The home keygen token is formed from the first 64 bits of the MAC.
The home keygen token tests that the mobile node can receive were The home keygen token tests that the mobile node can receive
messages sent to its home address. Kcn is used in the production messages sent to its home address. Kcn is used in the production
of home keygen token in order to allow the correspondent node to of home keygen token in order to allow the correspondent node to
verify that it generated the home and care-of nonces, without verify that it generated the home and care-of nonces, without
forcing the correspondent node to remember a list of all tokens it forcing the correspondent node to remember a list of all tokens it
has handed out. has handed out.
The Home Test message is sent to the mobile node via the home The Home Test message is sent to the mobile node via the home
network, where it is presumed that the home agent will tunnel the network, where it is presumed that the home agent will tunnel the
message to the mobile node. This means that the mobile node needs message to the mobile node. This means that the mobile node needs
to already have sent a Binding Update to the home agent, so that to already have sent a Binding Update to the home agent, so that
skipping to change at page 29, line 31 skipping to change at page 29, line 31
+ care-of init cookie + care-of init cookie
+ care-of keygen token + care-of keygen token
+ care-of nonce index + care-of nonce index
When the correspondent node receives the Care-of Test Init When the correspondent node receives the Care-of Test Init
message, it generates a care-of keygen token as follows: message, it generates a care-of keygen token as follows:
care-of keygen token := care-of keygen token :=
First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1))) First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))
Here, the final "1" inside the HMAC_SHA1 function is a single Here, the final "1" inside the HMAC_SHA1 function is a single
octet containing the hex value 0x01, and is used to distinguish octet containing the hex value 0x01, and is used to distinguish
home and care-of cookies from each other. The keygen token is home and care-of cookies from each other. The keygen token is
formed from the first 64 bits of the MAC, and sent directly to the formed from the first 64 bits of the MAC, and sent directly to the
mobile node at its care-of address. The care-of init cookie from mobile node at its care-of address. The care-of init cookie from
the Care-of Test Init message is returned to ensure that the the Care-of Test Init message is returned to ensure that the
message comes from a node on the route to the correspondent node. message comes from a node on the route to the correspondent node.
The care-of nonce index is provided to identify the nonce used for The care-of nonce index is provided to identify the nonce used for
skipping to change at page 34, line 24 skipping to change at page 34, line 24
The return routability procedure may be triggered by movement of the The return routability procedure may be triggered by movement of the
mobile node or by sustained loss of end-to-end communication with a mobile node or by sustained loss of end-to-end communication with a
correspondent node (e.g. based on indications from upper-layers) that correspondent node (e.g. based on indications from upper-layers) that
has been using a route optimised connection to the mobile node. If has been using a route optimised connection to the mobile node. If
such indications are received, the mobile node MAY revert to bi- such indications are received, the mobile node MAY revert to bi-
directional tunnelling while re-starting the return routability directional tunnelling while re-starting the return routability
procedure. procedure.
5.3. Dynamic Home Agent Address Discovery 5.3. Dynamic Home Agent Address Discovery
No security is required for dynamic home agent address discovery. Dynamic home agent address discovery has been designed for use in
deployments where security is not needed. For this reason, no
security solution is provided in this document for dynamic home agent
address discovery.
5.4. Mobile Prefix Discovery 5.4. Mobile Prefix Discovery
The mobile node and the home agent SHOULD use an IPsec security The mobile node and the home agent SHOULD use an IPsec security
association to protect the integrity and authenticity of the Mobile association to protect the integrity and authenticity of the Mobile
Prefix Solicitations and Advertisements. Both the mobile nodes and Prefix Solicitations and Advertisements. Both the mobile nodes and
the home agents MUST support and SHOULD use the Encapsulating the home agents MUST support and SHOULD use the Encapsulating
Security Payload (ESP) header in transport mode with a non-NULL Security Payload (ESP) header in transport mode with a non-NULL
payload authentication algorithm to provide data origin payload authentication algorithm to provide data origin
authentication, connectionless integrity and optional anti-replay authentication, connectionless integrity and optional anti-replay
skipping to change at page 34, line 51 skipping to change at page 35, line 5
However, Mobile IPv6 introduces the Home Address destination option, However, Mobile IPv6 introduces the Home Address destination option,
a routing header, and tunneling headers in the payload packets. In a routing header, and tunneling headers in the payload packets. In
the following we define the security measures taken to protect these, the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties. and to prevent their use in attacks against other parties.
This specification limits the use of the Home Address destination This specification limits the use of the Home Address destination
option to the situation where the correspondent node already has a option to the situation where the correspondent node already has a
Binding Cache entry for the given home address. This avoids the use Binding Cache entry for the given home address. This avoids the use
of the Home Address option in attacks described in Section 15.1. of the Home Address option in attacks described in Section 15.1.
Mobile IPv6 uses a Mobile IPv6 specific type of a routing header. Mobile IPv6 uses a type of routing header specific to Mobile IPv6.
This type provides the necessary functionality but does not open This type provides the necessary functionality but does not open
vulnerabilities discussed in Section 15.1. vulnerabilities discussed in Section 15.1 and RFC 5095 [46].
Tunnels between the mobile node and the home agent are protected by Tunnels between the mobile node and the home agent are protected by
ensuring proper use of source addresses, and optional cryptographic ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node verifies that the outer IP address protection. The mobile node verifies that the outer IP address
corresponds to its home agent. The home agent verifies that the corresponds to its home agent. The home agent verifies that the
outer IP address corresponds to the current location of the mobile outer IP address corresponds to the current location of the mobile
node (Binding Updates sent to the home agents are secure). The home node (Binding Updates sent to the home agents are secure). The home
agent identifies the mobile node through the source address of the agent identifies the mobile node through the source address of the
inner packet. (Typically, this is the home address of the mobile inner packet. (Typically, this is the home address of the mobile
node, but it can also be a link-local address, as discussed in node, but it can also be a link-local address, as discussed in
skipping to change at page 47, line 17 skipping to change at page 47, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Management Mobility Capability (K)
If this bit is cleared, the protocol used by the home agent for
establishing the IPsec security associations between the mobile
node and the home agent does not survive movements. It may then
have to be rerun. (Note that the IPsec security associations
themselves are expected to survive movements.)
Correspondent nodes MUST set the K bit to 0.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Status Status
8-bit unsigned integer indicating the disposition of the Binding 8-bit unsigned integer indicating the disposition of the Binding
Update. Values of the Status field less than 128 indicate that Update. Values of the Status field less than 128 indicate that
the Binding Update was accepted by the receiving node. Values the Binding Update was accepted by the receiving node. Values
greater than or equal to 128 indicate that the Binding Update was greater than or equal to 128 indicate that the Binding Update was
rejected by the receiving node. The following Status values are rejected by the receiving node. The following Status values are
currently defined: currently defined:
0 Binding Update accepted 0 Binding Update accepted
skipping to change at page 48, line 17 skipping to change at page 48, line 4
133 Not home agent for this mobile node 133 Not home agent for this mobile node
134 Duplicate Address Detection failed 134 Duplicate Address Detection failed
135 Sequence number out of window 135 Sequence number out of window
136 Expired home nonce index 136 Expired home nonce index
137 Expired care-of nonce index 137 Expired care-of nonce index
138 Expired nonces 138 Expired nonces
139 Registration type change disallowed 139 Registration type change disallowed
Up-to-date values of the Status field are to be specified in the Up-to-date values of the Status field are to be specified in the
IANA registry of assigned numbers [13]. IANA registry of assigned numbers [13].
Key Management Mobility Capability (K)
If this bit is cleared, the protocol used by the home agent for
establishing the IPsec security associations between the mobile
node and the home agent does not survive movements. It may then
have to be rerun. (Note that the IPsec security associations
themselves are expected to survive movements.)
Correspondent nodes MUST set the K bit to 0.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence # Sequence #
The Sequence Number in the Binding Acknowledgement is copied from The Sequence Number in the Binding Acknowledgement is copied from
the Sequence Number field in the Binding Update. It is used by the Sequence Number field in the Binding Update. It is used by
the mobile node in matching this Binding Acknowledgement with an the mobile node in matching this Binding Acknowledgement with an
outstanding Binding Update. outstanding Binding Update.
Lifetime Lifetime
The granted lifetime, in time units of 4 seconds, for which this The granted lifetime, in time units of 4 seconds, for which this
skipping to change at page 50, line 32 skipping to change at page 50, line 32
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options which it does not understand. MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this Binding There MAY be additional information, associated with this Binding
Error message that need not be present in all Binding Error Error message that need not be present in all Binding Error
messages sent. Mobility options allow future extensions to the messages sent. Mobility options allow future extensions to the
format of the format of the Binding Error message to be defined. format of the Binding Error message to be defined. The encoding
The encoding and format of defined options are described in and format of defined options are described in Section 6.2. This
Section 6.2. This specification does not define any options valid specification does not define any options valid for the Binding
for the Binding Error message. Error message.
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 2. necessary and the Header Len field will be set to 2.
6.2. Mobility Options 6.2. Mobility Options
Mobility messages can include zero or more mobility options. This Mobility messages can include zero or more mobility options. This
allows optional fields that may not be needed in every use of a allows optional fields that may not be needed in every use of a
particular Mobility Header, as well as future extensions to the particular Mobility Header, as well as future extensions to the
format of the messages. Such options are included in the Message format of the messages. Such options are included in the Message
skipping to change at page 59, line 9 skipping to change at page 59, line 9
The Home Address of the destination Mobile Node. The Home Address of the destination Mobile Node.
For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments
Left value describes the number of route segments remaining; i.e., Left value describes the number of route segments remaining; i.e.,
number of explicitly listed intermediate nodes still to be visited number of explicitly listed intermediate nodes still to be visited
before reaching the final destination. Segments Left MUST be 1. The before reaching the final destination. Segments Left MUST be 1. The
ordering rules for extension headers in an IPv6 packet are described ordering rules for extension headers in an IPv6 packet are described
in Section 4.1 of RFC 2460 [8]. The type 2 routing header defined in Section 4.1 of RFC 2460 [8]. The type 2 routing header defined
for Mobile IPv6 follows the same ordering as other routing headers. for Mobile IPv6 follows the same ordering as other routing headers.
If both a type 0 and a type 2 routing header are present, the type 2 If another routing header is present along with a type 2 routing
routing header should follow the other routing header. A packet header, the type 2 routing header should follow the other routing
containing such nested encapsulation should be created as if the header. A packet containing such nested encapsulation should be
inner (type 2) routing header was constructed first and then treated created as if the inner (type 2) routing header was constructed first
as an original packet by the outer (type 0) routing header and then treated as an original packet by header construction process
construction process. for the other routing header.
In addition, the general procedures defined by IPv6 for routing In addition, the general procedures defined by IPv6 for routing
headers suggest that a received routing header MAY be automatically headers suggest that a received routing header MAY be automatically
"reversed" to construct a routing header for use in any response "reversed" to construct a routing header for use in any response
packets sent by upper-layer protocols, if the received packet is packets sent by upper-layer protocols, if the received packet is
authenticated [6]. This MUST NOT be done automatically for type 2 authenticated [6]. This MUST NOT be done automatically for type 2
routing headers. routing headers.
6.5. ICMP Home Agent Address Discovery Request Message 6.5. ICMP Home Agent Address Discovery Request Message
skipping to change at page 63, line 11 skipping to change at page 63, line 6
An identifier to aid in matching a future Mobile Prefix An identifier to aid in matching a future Mobile Prefix
Advertisement to this Mobile Prefix Solicitation. Advertisement to this Mobile Prefix Solicitation.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Mobile Prefix Solicitation messages may have options. These The Mobile Prefix Solicitation messages may have options. These
options MUST use the option format defined in RFC 4861 [20]. This options MUST use the option format defined in Neighbor Discovery (RFC
document does not define any option types for the Mobile Prefix 4861 [20]). This document does not define any option types for the
Solicitation message, but future documents may define new options. Mobile Prefix Solicitation message, but future documents may define
Home agents MUST silently ignore any options they do not recognize new options. Home agents MUST silently ignore any options they do
and continue processing the message. not recognize and continue processing the message.
6.8. ICMP Mobile Prefix Advertisement Message Format 6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement to a mobile node A home agent will send a Mobile Prefix Advertisement to a mobile node
to distribute prefix information about the home link while the mobile to distribute prefix information about the home link while the mobile
node is traveling away from the home network. This will occur in node is traveling away from the home network. This will occur in
response to a Mobile Prefix Solicitation with an Advertisement, or by response to a Mobile Prefix Solicitation with an Advertisement, or by
an unsolicited Advertisement sent according to the rules in an unsolicited Advertisement sent according to the rules in
Section 10.6. Section 10.6.
skipping to change at page 65, line 11 skipping to change at page 64, line 50
administered (stateful) protocol for autoconfiguration of other administered (stateful) protocol for autoconfiguration of other
(non-address) information. The use of this flag is described in (non-address) information. The use of this flag is described in
[20] [21]. [20] [21].
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Mobile Prefix Advertisement messages may have options. These The Mobile Prefix Advertisement messages may have options. These
options MUST use the option format defined in RFC 4861 [20]. This options MUST use the option format defined in Neighbor Discovery (RFC
document defines one option which may be carried in a Mobile Prefix 4861 [20]). This document defines one option which may be carried in
Advertisement message, but future documents may define new options. a Mobile Prefix Advertisement message, but future documents may
Mobile nodes MUST silently ignore any options they do not recognize define new options. Mobile nodes MUST silently ignore any options
and continue processing the message. they do not recognize and continue processing the message.
Prefix Information Prefix Information
Each message contains one or more Prefix Information options. Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should use Each option carries the prefix(es) that the mobile node should use
to configure its home address(es). Section 10.6 describes which to configure its home address(es). Section 10.6 describes which
prefixes should be advertised to the mobile node. prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2 of RFC The Prefix Information option is defined in Section 4.6.2 of
4861 [20], with modifications defined in Section 7.2 of this Neighbor Discovery (RFC 4861 [20]), with modifications defined in
specification. The home agent MUST use this modified Prefix Section 7.2 of this specification. The home agent MUST use this
Information option to send home network prefixes as defined in modified Prefix Information option to send home network prefixes
Section 10.6.1. as defined in Section 10.6.1.
If the Advertisement is sent in response to a Mobile Prefix If the Advertisement is sent in response to a Mobile Prefix
Solicitation, the home agent MUST copy the Identifier value from that Solicitation, the home agent MUST copy the Identifier value from that
message into the Identifier field of the Advertisement. message into the Identifier field of the Advertisement.
The home agent MUST NOT send more than one Mobile Prefix The home agent MUST NOT send more than one Mobile Prefix
Advertisement message per second to any mobile node. Advertisement message per second to any mobile node.
The M and O bits MUST be cleared if the Home Agent DHCPv6 support is The M and O bits MUST be cleared if the Home Agent DHCPv6 support is
not provided. If such support is provided then they are set in not provided. If such support is provided then they are set in
skipping to change at page 67, line 51 skipping to change at page 67, line 51
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
MAY, include at least one Prefix Information option with the Router MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery specifies that, if including Address (R) bit set. Neighbor Discovery (RFC 4861 [20]) specifies
all options in a Router Advertisement causes the size of the that, when including all options in a Router Advertisement causes the
Advertisement to exceed the link MTU, multiple Advertisements can be size of the Advertisement to exceed the link MTU, multiple
sent, each containing a subset of the options [20]. Also, when Advertisements can be sent, each containing a subset of the Neighbor
sending unsolicited multicast Router Advertisements more frequently Discovery options. Also, when sending unsolicited multicast Router
than the limit specified in RFC 4861 [20], the sending router need Advertisements more frequently than the limit specified in RFC 4861,
not include all options in each of these Advertisements. However, in the sending router need not include all options in each of these
both of these cases the router SHOULD include at least one Prefix Advertisements. However, in both of these cases the router SHOULD
Information option with the Router Address (R) bit set in each such include at least one Prefix Information option with the Router
advertisement, if this bit is set in some advertisement sent by the Address (R) bit set in each such advertisement, if this bit is set in
router. some advertisement sent by the router.
In addition, the following requirement can assist mobile nodes in In addition, the following requirement can assist mobile nodes in
movement detection. Barring changes in the prefixes for the link, movement detection. Barring changes in the prefixes for the link,
routers that send multiple Router Advertisements with the Router routers that send multiple Router Advertisements with the Router
Address (R) bit set in some of the included Prefix Information Address (R) bit set in some of the included Prefix Information
options SHOULD provide at least one option and router address which options SHOULD provide at least one option and router address which
stays the same in all of the Advertisements. stays the same in all of the Advertisements.
7.3. New Advertisement Interval Option Format 7.3. New Advertisement Interval Option Format
skipping to change at page 72, line 12 skipping to change at page 72, line 12
o MinRtrAdvInterval 0.03 seconds o MinRtrAdvInterval 0.03 seconds
o MaxRtrAdvInterval 0.07 seconds o MaxRtrAdvInterval 0.07 seconds
In the case where the minimum intervals and delays are used, the mean In the case where the minimum intervals and delays are used, the mean
time between unsolicited multicast router advertisements is 50ms. time between unsolicited multicast router advertisements is 50ms.
Use of these modified limits MUST be configurable (see also the Use of these modified limits MUST be configurable (see also the
configuration variable MinDelayBetweenRas in Section 13 which may configuration variable MinDelayBetweenRas in Section 13 which may
also have to be modified accordingly). Systems where these values also have to be modified accordingly). Systems where these values
are available MUST NOT default to them, and SHOULD default to values are available MUST NOT default to them, and SHOULD default to values
specified in RFC 4861. Knowledge of the type of network interface specified in Neighbor Discovery (RFC 4861 [20]). Knowledge of the
and operating environment SHOULD be taken into account in configuring type of network interface and operating environment SHOULD be taken
these limits for each network interface. This is important with some into account in configuring these limits for each network interface.
wireless links, where increasing the frequency of multicast beacons This is important with some wireless links, where increasing the
can cause considerable overhead. Routers SHOULD adhere to the frequency of multicast beacons can cause considerable overhead.
intervals specified in RFC 4861 [20], if this overhead is likely to Routers SHOULD adhere to the intervals specified in RFC 4861 [20], if
cause service degradation. this overhead is likely to cause service degradation.
Additionally, the possible low values of MaxRtrAdvInterval may cause Additionally, the possible low values of MaxRtrAdvInterval may cause
some problems with movement detection in some mobile nodes. To some problems with movement detection in some mobile nodes. To
ensure that this is not a problem, Routers SHOULD add 20ms to any ensure that this is not a problem, Routers SHOULD add 20ms to any
Advertisement Intervals sent in RAs, which are below 200 ms, in order Advertisement Intervals sent in RAs, which are below 200 ms, in order
to account for scheduling granularities on both the MN and the to account for scheduling granularities on both the MN and the
Router. Router.
Note that multicast Router Advertisements are not always required in Note that multicast Router Advertisements are not always required in
certain wireless networks that have limited bandwidth. Mobility certain wireless networks that have limited bandwidth. Mobility
skipping to change at page 72, line 40 skipping to change at page 72, line 40
layers. Router advertisements in such networks SHOULD be sent only layers. Router advertisements in such networks SHOULD be sent only
when solicited. In such networks it SHOULD be possible to disable when solicited. In such networks it SHOULD be possible to disable
unsolicited multicast Router Advertisements on specific interfaces. unsolicited multicast Router Advertisements on specific interfaces.
The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
to some high values. to some high values.
Home agents MUST include the Source Link-Layer Address option in all Home agents MUST include the Source Link-Layer Address option in all
Router Advertisements they send. This simplifies the process of Router Advertisements they send. This simplifies the process of
returning home, as discussed in Section 11.5.5. returning home, as discussed in Section 11.5.5.
Note that according to RFC 4861 [20], AdvDefaultLifetime is by Note that according to Neighbor Discovery (RFC 4861 [20]),
default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime AdvDefaultLifetime is by default based on the value of
is used in the Router Lifetime field of Router Advertisements. Given MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime
that this field is expressed in seconds, a small MaxRtrAdvInterval field of Router Advertisements. Given that this field is expressed
value can result in a zero value for this field. To prevent this, in seconds, a small MaxRtrAdvInterval value can result in a zero
routers SHOULD keep AdvDefaultLifetime in at least one second, even value for this field. To prevent this, routers SHOULD keep
if the use of MaxRtrAdvInterval would result in a smaller value. AdvDefaultLifetime in at least one second, even if the use of
MaxRtrAdvInterval would result in a smaller value.
8. Requirements for Types of IPv6 Nodes 8. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions Mobile IPv6 places some special requirements on the functions
provided by different types of IPv6 nodes. This section summarizes provided by different types of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement is those requirements, identifying the functionality each requirement is
intended to support. intended to support.
The requirements are set for the following groups of nodes: The requirements are set for the following groups of nodes:
skipping to change at page 79, line 31 skipping to change at page 79, line 31
o The home address of the mobile node for which this is the Binding 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 Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent. Binding Cache for the destination address of a packet being sent.
o The care-of address for the mobile node indicated by the home o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry. address field in this Binding Cache entry.
o A lifetime value, indicating the remaining lifetime for this o A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from the Binding Cache entry. The lifetime value is initialized from the
Lifetime field in the Binding Update that created or last modified Lifetime field in the Binding Update that created or last modified
this Binding Cache entry. this Binding Cache entry. A correspondent node MAY select a
smaller lifetime for the Binding Cache entry, and supply that
value to the mobile node in the Binding Acknowledgment message.
o A flag indicating whether or not this Binding Cache entry is a o A flag indicating whether or not this Binding Cache entry is a
home registration entry (applicable only on nodes which support home registration entry (applicable only on nodes which support
home agent functionality). home agent functionality).
o The maximum value of the Sequence Number field received in o The maximum value of the Sequence Number field received in
previous Binding Updates for this home address. The Sequence previous Binding Updates for this home address. The Sequence
Number field is 16 bits long. Sequence Number values MUST be Number field is 16 bits long. Sequence Number values MUST be
compared modulo 2**16 as explained in Section 9.5.1. compared modulo 2**16 as explained in Section 9.5.1.
skipping to change at page 80, line 11 skipping to change at page 80, line 13
but SHOULD NOT be unnecessarily deleted. The Binding Cache for any but SHOULD NOT be unnecessarily deleted. The Binding Cache for any
one of a node's IPv6 addresses may contain at most one entry for each one of a node's IPv6 addresses may contain at most one entry for each
mobile node home address. The contents of a node's Binding Cache mobile node home address. The contents of a node's Binding Cache
MUST NOT be changed in response to a Home Address option in a MUST NOT be changed in response to a Home Address option in a
received packet. received packet.
9.2. Processing Mobility Headers 9.2. Processing Mobility Headers
Mobility Header processing MUST observe the following rules: Mobility Header processing MUST observe the following rules:
o The checksum must be verified as per Section 6.1. Otherwise, the o The checksum must be verified as per Section 6.1. If invalid, the
node MUST silently discard the message. node MUST silently discard the message.
o The MH Type field MUST have a known value (Section 6.1.1). o The MH Type field MUST have a known value (Section 6.1.1).
Otherwise, the node MUST discard the message and issue a Binding Otherwise, the node MUST discard the message and issue a Binding
Error message as described in Section 9.3.3, with Status field set Error message as described in Section 9.3.3, with Status field set
to 2 (unrecognized MH Type value). to 2 (unrecognized MH Type value).
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem, Code 0, directly to the Source Address of the Parameter Problem, Code 0, directly to the Source Address of the
skipping to change at page 81, line 9 skipping to change at page 81, line 11
packet if they believe the correspondent node has a Binding Cache packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. If the Next Header entry for the home address of a mobile node. If the Next Header
value of the Destination Option is one of the following: {50 (ESP), value of the Destination Option is one of the following: {50 (ESP),
51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
normally. Otherwise, the packet MUST be dropped if there is no normally. Otherwise, the packet MUST be dropped if there is no
corresponding Binding Cache entry. A corresponding Binding Cache corresponding Binding Cache entry. A corresponding Binding Cache
entry MUST have the same home address as appears in the Home Address entry MUST have the same home address as appears in the Home Address
destination option, and the currently registered care-of address MUST destination option, and the currently registered care-of address MUST
be equal to the source address of the packet. be equal to the source address of the packet.
If the packet is dropped due the above tests, the correspondent node If the packet is dropped due to the above tests, the correspondent
MUST send the Binding Error message as described in Section 9.3.3. node MUST send the Binding Error message as described in
The Status field in this message should be set to 1 (unknown binding Section 9.3.3. The Status field in this message should be set to 1
for Home Address destination option). (unknown binding for Home Address destination option).
The correspondent node MUST process the option in a manner consistent The correspondent node MUST process the option in a manner consistent
with exchanging the Home Address field from the Home Address option with exchanging the Home Address field from the Home Address option
into the IPv6 header and replacing the original value of the Source into the IPv6 header and replacing the original value of the Source
Address field there. After all IPv6 options have been processed, it Address field there. After all IPv6 options have been processed, it
MUST be possible for upper layers to process the packet without the MUST be possible for upper layers to process the packet without the
knowledge that it came originally from a care-of address or that a knowledge that it came originally from a care-of address or that a
Home Address option was used. Home Address option was used.
The use of IPsec Authentication Header (AH) for the Home Address The use of IPsec Authentication Header (AH) for the Home Address
skipping to change at page 84, line 28 skipping to change at page 84, line 28
during the return routability procedure. during the return routability procedure.
9.4.1. Receiving Home Test Init Messages 9.4.1. Receiving Home Test Init Messages
Upon receiving a Home Test Init message, the correspondent node Upon receiving a Home Test Init message, the correspondent node
verifies the following: verifies the following:
o The packet MUST NOT include a Home Address destination option. o The packet MUST NOT include a Home Address destination option.
Any packet carrying a Home Test Init message which fails to satisfy Any packet carrying a Home Test Init message which fails to satisfy
all of these tests MUST be silently ignored. this test MUST be silently ignored.
Otherwise, in preparation for sending the corresponding Home Test Otherwise, in preparation for sending the corresponding Home Test
Message, the correspondent node checks that it has the necessary Message, the correspondent node checks that it has the necessary
material to engage in a return routability procedure, as specified in material to engage in a return routability procedure, as specified in
Section 5.2. The correspondent node MUST have a secret Kcn and a Section 5.2. The correspondent node MUST have a secret Kcn and a
nonce. If it does not have this material yet, it MUST produce it nonce. If it does not have this material yet, it MUST produce it
before continuing with the return routability procedure. before continuing with the return routability procedure.
Section 9.4.3 specifies further processing. Section 9.4.3 specifies further processing.
9.4.2. Receiving Care-of Test Init Messages 9.4.2. Receiving Care-of Test Init Messages
Upon receiving a Care-of Test Init message, the correspondent node Upon receiving a Care-of Test Init message, the correspondent node
verifies the following: verifies the following:
o The packet MUST NOT include a Home Address destination option. o The packet MUST NOT include a Home Address destination option.
Any packet carrying a Care-of Test Init message which fails to Any packet carrying a Care-of Test Init message which fails to
satisfy all of these tests MUST be silently ignored. satisfy this test MUST be silently ignored.
Otherwise, in preparation for sending the corresponding Care-of Test Otherwise, in preparation for sending the corresponding Care-of Test
Message, the correspondent node checks that it has the necessary Message, the correspondent node checks that it has the necessary
material to engage in a return routability procedure in the manner material to engage in a return routability procedure in the manner
described in Section 9.4.1. described in Section 9.4.1.
Section 9.4.4 specifies further processing. Section 9.4.4 specifies further processing.
9.4.3. Sending Home Test Messages 9.4.3. Sending Home Test Messages
skipping to change at page 87, line 26 skipping to change at page 87, line 26
registration type change, or expired nonce index values, MUST be registration type change, or expired nonce index values, MUST be
silently discarded. silently discarded.
If the Binding Update is valid according to the tests above, then the If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows: Binding Update is processed further as follows:
o The Sequence Number value received from a mobile node in a Binding o The Sequence Number value received from a mobile node in a Binding
Update is stored by the receiving node in its Binding Cache entry Update is stored by the receiving node in its Binding Cache entry
for the given home address. for the given home address.
o If the Lifetime specified in the Binding Update is zero, then this o If the Lifetime specified in the Binding Update is not zero, then
is a request to delete the cached binding for the home address. this is a request to cache a binding for the home address. If the
If the Home Registration (H) bit is set in the Binding Update, the Home Registration (H) bit is set in the Binding Update, the
Binding Update is processed according to the procedure specified Binding Update is processed according to the procedure specified
in Section 10.3.1; otherwise, it is processed according to the in Section 10.3.1; otherwise, it is processed according to the
procedure specified in Section 9.5.2. procedure specified in Section 9.5.2.
o If the Lifetime specified in the Binding Update is zero or the o If the Lifetime specified in the Binding Update is zero or the
specified care-of address matches the home address for the specified care-of address matches the home address for the
binding, then this is a request to delete the cached binding for binding, then this is a request to delete the cached binding for
the home address. In this case, the Binding Update MUST include a the home address. In this case, the Binding Update MUST include a
valid home nonce index, and the care-of nonce index MUST be valid home nonce index, and the care-of nonce index MUST be
ignored by the correspondent node. The generation of the binding ignored by the correspondent node. The generation of the binding
skipping to change at page 89, line 22 skipping to change at page 89, line 22
9.5.4. Sending Binding Acknowledgements 9.5.4. Sending Binding Acknowledgements
A Binding Acknowledgement may be sent to indicate receipt of a A Binding Acknowledgement may be sent to indicate receipt of a
Binding Update as follows: Binding Update as follows:
o If the Binding Update was discarded as described in Section 9.2 or o If the Binding Update was discarded as described in Section 9.2 or
Section 9.5.1, a Binding Acknowledgement MUST NOT be sent. Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
Otherwise the treatment depends on the following rules. Otherwise the treatment depends on the following rules.
o If the Acknowledge (A) bit set is set in the Binding Update, a o If the Acknowledge (A) bit is set in the Binding Update, a Binding
Binding Acknowledgement MUST be sent. Otherwise, the treatment Acknowledgement MUST be sent. Otherwise, the treatment depends on
depends on the below rule. the next rule.
o If the node rejects the Binding Update due to an expired nonce o If the node rejects the Binding Update due to an expired nonce
index, sequence number being out of window (Section 9.5.1), or index, sequence number being out of window (Section 9.5.1), or
insufficiency of resources (Section 9.5.2), a Binding insufficiency of resources (Section 9.5.2), a Binding
Acknowledgement MUST be sent. If the node accepts the Binding Acknowledgement MUST be sent. If the node accepts the Binding
Update, the Binding Acknowledgement SHOULD NOT be sent. Update, the Binding Acknowledgement SHOULD NOT be sent.
If the node accepts the Binding Update and creates or updates an If the node accepts the Binding Update and creates or updates an
entry for this binding, the Status field in the Binding entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value less than 128. Otherwise, the Acknowledgement MUST be set to a value less than 128. Otherwise, the
skipping to change at page 98, line 28 skipping to change at page 98, line 28
given in the Binding Update. given in the Binding Update.
o The Lifetime field MUST be set to zero. o The Lifetime field MUST be set to zero.
o The Binding Refresh Advice mobility option MUST be omitted. o The Binding Refresh Advice mobility option MUST be omitted.
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, the and the Source Address of the Binding Update is on the home link, and
home agent MUST send it to the mobile node's link layer address the Binding Update came from a mobile node on the same link, the home
(retrieved either from the Binding Update or through Neighbor agent MUST send it to the mobile node's link layer address (retrieved
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 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 Section 12) seconds before removing MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the
the binding cache entry completely. In the scenario described above, binding cache entry completely. In the scenario described above, if
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 mobile node it MUST While a node is serving as the home agent for a mobile node it MUST
attempt to intercept packets on the mobile node's home link that are attempt to intercept packets on the mobile node's home link that are
addressed to the mobile node. addressed to the mobile node.
In order to do this, when a node begins serving as the home agent it In order to do this, when a node begins serving as the home agent it
MUST multicast onto the home link a Neighbor Advertisement message MUST have performed Duplicate Address Detection (as specified in
[20] on behalf of the mobile node. For the home address specified in Section 10.3.1), and subsequently it MUST multicast onto the home
the Binding Update, the home agent sends a Neighbor Advertisement link a Neighbor Advertisement message [20] on behalf of the mobile
message [20] to the all-nodes multicast address on the home link to node. For the home address specified in the Binding Update, the home
advertise the home agent's own link-layer address for this IP address agent sends a Neighbor Advertisement message [20] to the all-nodes
on behalf of the mobile node. If the Link-Layer Address multicast address on the home link to advertise the home agent's own
Compatibility (L) flag has been specified in the Binding Update, the link-layer address for this IP address on behalf of the mobile node.
home agent MUST do the same for the link-local address of the mobile If the Link-Layer Address Compatibility (L) flag has been specified
node. in the Binding Update, the home agent MUST do the same for the link-
local address of the mobile node.
All fields in each Neighbor Advertisement message SHOULD be set in All fields in each Neighbor Advertisement message SHOULD be set in
the same way they would be set by the mobile node if it was sending the same way they would be set by the mobile node if it was sending
this Neighbor Advertisement [20] while at home, with the following this Neighbor Advertisement [20] while at home, with the following
exceptions: exceptions:
o The Target Address in the Neighbor Advertisement MUST be set to o The Target Address in the Neighbor Advertisement MUST be set to
the specific IP address for the mobile node. the specific IP address for the mobile node.
o The Advertisement MUST include a Target Link-layer Address option o The Advertisement MUST include a Target Link-layer Address option
skipping to change at page 102, line 5 skipping to change at page 102, line 7
forwarding, described in the previous section. If this support is forwarding, described in the previous section. If this support is
not provided, multicast group membership control messages are not provided, multicast group membership control messages are
silently ignored. silently ignored.
In order to forward multicast data packets from the home network to In order to forward multicast data packets from the home network to
all the proper mobile nodes, the home agent SHOULD be capable of all the proper mobile nodes, the home agent SHOULD be capable of
receiving tunneled multicast group membership control information receiving tunneled multicast group membership control information
from the mobile node in order to determine which groups the mobile from the mobile node in order to determine which groups the mobile
node has subscribed to. These multicast group membership messages node has subscribed to. These multicast group membership messages
are Listener Report messages specified in MLD [11] or in other are Listener Report messages specified in MLD [11] or in other
protocols such as [40]. protocols such as [41].
The messages are issued by the mobile node, but sent through the The messages are issued by the mobile node, but sent through the
reverse tunnel to the home agent. These messages are issued whenever reverse tunnel to the home agent. These messages are issued whenever
the mobile node decides to enable reception of packets for a the mobile node decides to enable reception of packets for a
multicast group or in response to an MLD Query from the home agent. multicast group or in response to an MLD Query from the home agent.
The mobile node will also issue multicast group control messages to The mobile node will also issue multicast group control messages to
disable reception of multicast packets when it is no longer disable reception of multicast packets when it is no longer
interested in receiving multicasts for a particular group. interested in receiving multicasts for a particular group.
To obtain the mobile node's current multicast group membership the To obtain the mobile node's current multicast group membership the
skipping to change at page 107, line 33 skipping to change at page 107, line 33
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.
To support this, the home agent monitors prefixes advertised by To support this, the home agent monitors prefixes advertised by
itself and other home agents on the home link. In RFC 4861 [20] it itself and other home agents on the home link. In Neighbor Discovery
is acceptable for two routers to advertise different sets of prefixes (RFC 4861 [20]) it is acceptable for two routers to advertise
on the same link. For home agents, the differences should be different sets of prefixes on the same link. For home agents, the
detected for a given home address because the mobile node differences should be detected for a given home address because the
communicates only with one home agent at a time and the mobile node mobile node communicates only with one home agent at a time and the
needs to know the full set of prefixes assigned to the home link. mobile node needs to know the full set of prefixes assigned to the
All other comparisons of Router Advertisements are as specified in home link. All other comparisons of Router Advertisements are as
Section 6.2.7 of RFC 4861. specified in Section 6.2.7 of RFC 4861.
10.6.2. Scheduling Prefix Deliveries 10.6.2. Scheduling Prefix Deliveries
A home agent serving a mobile node will schedule the delivery of the A home agent serving a mobile node will schedule the delivery of the
new prefix information to that mobile node when any of the following new prefix information to that mobile node when any of the following
conditions occur: conditions occur:
MUST: MUST:
o The state of the flags changes for the prefix of the mobile node's o The state of the flags changes for the prefix of the mobile node's
skipping to change at page 113, line 16 skipping to change at page 113, line 16
11.3.1. Sending Packets While Away from Home 11.3.1. Sending Packets While Away from Home
While a mobile node is away from home, it continues to use its home While a mobile node is away from home, it continues to use its home
address, as well as also using one or more care-of addresses. When address, as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node MAY choose among sending a packet while away from home, a mobile node MAY choose among
these in selecting the address that it will use as the source of the these in selecting the address that it will use as the source of the
packet, as follows: packet, as follows:
o Protocols layered over IP will generally treat the mobile node's o Protocols layered over IP will generally treat the mobile node's
home address as its IP address for most packets. For packets sent home address as its IP source address for most packets. For
that are part of transport-level connections established while the packets sent that are part of transport-level connections
mobile node was at home, the mobile node MUST use its home established while the mobile node was at home, the mobile node
address. Likewise, for packets sent that are part of transport- MUST use its home address. Likewise, for packets sent that are
level connections that the mobile node may still be using after part of transport-level connections that the mobile node may still
moving to a new location, the mobile node SHOULD use its home be using after moving to a new location, the mobile node SHOULD
address in this way. If a binding exists, the mobile node SHOULD use its home address in this way. If a binding exists, the mobile
send the packets directly to the correspondent node. Otherwise, node SHOULD send the packets directly to the correspondent node.
if a binding does not exist, the mobile node MUST use reverse Otherwise, if a binding does not exist, the mobile node MUST use
tunneling. reverse tunneling.
o The mobile node MAY choose to directly use one of its care-of o The mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, not requiring the use of a addresses as the source of the packet, not requiring the use of a
Home Address option in the packet. This is particularly useful Home Address option in the packet. This is particularly useful
for short-term communication that may easily be retried if it for short-term communication that may easily be retried if it
fails. Using the mobile node's care-of address as the source for fails. Using the mobile node's care-of address as the source for
such queries will generally have a lower overhead than using the such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need be used in mobile node's home address, since no extra options need to be used
either the query or its reply. Such packets can be routed in either the query or its reply. Such packets can be routed
normally, directly between their source and destination without normally, directly between their source and destination without
relying on Mobile IPv6. If application running on the mobile node relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile within this general type of communication, however, the mobile
node should not use its care-of address as the source of the node should not use its care-of address as the source of the
packet in this way. packet in this way.
The choice of the most efficient communications method is The choice of the most efficient communications method is
application specific, and outside the scope of this specification. application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of The APIs necessary for controlling the choice are also out of
skipping to change at page 120, line 6 skipping to change at page 120, line 6
In order to receive packets sent to some multicast group, a mobile In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method, in which a mobile node must join that multicast group. One method, in which a mobile
node MAY join the group, is via a (local) multicast router on the node MAY join the group, is via a (local) multicast router on the
foreign link being visited. In this case, the mobile node MUST use foreign link being visited. In this case, the mobile node MUST use
its care-of address and MUST NOT use the Home Address destination its care-of address and MUST NOT use the Home Address destination
option when sending MLD packets [11]. option when sending MLD packets [11].
Alternatively, a mobile node MAY join multicast groups via a bi- Alternatively, a mobile node MAY join multicast groups via a bi-
directional tunnel to its home agent. The mobile node tunnels its directional tunnel to its home agent. The mobile node tunnels its
multicast group membership control packets (such as those defined in multicast group membership control packets (such as those defined in
[11] or in [40]) to its home agent, and the home agent forwards [11] or in [41]) to its home agent, and the home agent forwards
multicast packets down the tunnel to the mobile node. A mobile node multicast packets down the tunnel to the mobile node. A mobile node
MUST NOT tunnel multicast group membership control packets until (1) MUST NOT tunnel multicast group membership control packets until (1)
the mobile node has a binding in place at the home agent, and (2) the the mobile node has a binding in place at the home agent, and (2) the
latter sends at least one multicast group membership control packet latter sends at least one multicast group membership control packet
via the tunnel. Once this condition is true, the mobile node SHOULD via the tunnel. Once this condition is true, the mobile node SHOULD
assume it does not change as long as the binding does not expire. assume it does not change as long as the binding does not expire.
A mobile node that wishes to send packets to a multicast group also A mobile node that wishes to send packets to a multicast group also
has two options: has two options:
1. Send directly on the foreign link being visited. 1. Send directly on the foreign link being visited.
The application uses the care-of address as a source address for To do this, the application uses the care-of address as a source
multicast traffic, just like it would use a stationary address. address for multicast traffic, just as it would use a stationary
This requires that the application either knows the care-of address. This requires that the application either knows the
address, or uses an API such as the IPv6 Socket API for Source care-of address, or uses an API such as the IPv6 Socket API for
Address Selection specification [24]. to request the stack to use Source Address Selection specification [24] to request that the
the care-of address as a source address in sent packets. The care-of address be used as the source address in transmitted
mobile node MUST NOT use Home Address destination option in such packets. The mobile node MUST NOT use Home Address destination
traffic. option in such traffic.
2. Send via a tunnel to its home agent. 2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST use node that tunnels a multicast packet to its home agent MUST use
its home address as the IPv6 Source Address of the inner its home address as the IPv6 Source Address of the inner
multicast packet. multicast packet.
Note that direct sending from the foreign link is only applicable Note that direct sending from the foreign link is only applicable
skipping to change at page 122, line 4 skipping to change at page 122, line 4
the mobile node does not have such an entry, it MUST ignore the the mobile node does not have such an entry, it MUST ignore the
message. This is necessary to prevent a waste of resources on, e.g., message. This is necessary to prevent a waste of resources on, e.g.,
return routability procedure due to spoofed Binding Error messages. return routability procedure due to spoofed Binding Error messages.
Otherwise, if the message Status field was 1 (unknown binding for Otherwise, if the message Status field was 1 (unknown binding for
Home Address destination option), the mobile node should perform one Home Address destination option), the mobile node should perform one
of the following three actions: of the following three actions:
o If the Binding Error Message was sent by the Home Agent, the o If the Binding Error Message was sent by the Home Agent, the
Mobile Node SHOULD send a Binding Update to the Home Agent Mobile Node SHOULD send a Binding Update to the Home Agent
according to Section Section 11.7.1. according to Section 11.7.1.
o If the mobile node has recent upper layer progress information, o If the mobile node has recent upper layer progress information,
which indicates that communications with the correspondent node which indicates that communications with the correspondent node
are progressing, it MAY ignore the message. This can be done in are progressing, it MAY ignore the message. This can be done in
order to limit the damage that spoofed Binding Error messages can order to limit the damage that spoofed Binding Error messages can
cause to ongoing communications. cause to ongoing communications.
o If the mobile node has no upper layer progress information, it o If the mobile node has no upper layer progress information, it
MUST remove the entry and route further communications through the MUST remove the entry and route further communications through the
home agent. It MAY also optionally start a return routability home agent. It MAY also optionally start a return routability
skipping to change at page 125, line 32 skipping to change at page 125, line 32
link. (This specification does not, however, describe how to acquire link. (This specification does not, however, describe how to acquire
home addresses through stateful protocols.) Such processing may home addresses through stateful protocols.) Such processing may
result in the mobile node configuring a new home address, although result in the mobile node configuring a new home address, although
due to separation between preferred lifetime and valid lifetime, such due to separation between preferred lifetime and valid lifetime, such
changes should not affect most communications by the mobile node, in changes should not affect most communications by the mobile node, in
the same way as for nodes that are at home. the same way as for nodes that are at home.
This specification assumes that any security associations and This specification assumes that any security associations and
security policy entries that may be needed for new prefixes have been security policy entries that may be needed for new prefixes have been
pre-configured in the mobile node. Note that while dynamic key pre-configured in the mobile node. Note that while dynamic key
management avoids the need to create new security associations, it is management avoids the need to configure new security associations, it
still necessary to add policy entries to protect the communications is still necessary to add policy entries to protect the
involving the home address(es). Mechanisms for automatic set-up of communications involving the home address(es). Mechanisms for
these entries are outside the scope of this specification. setting up these entries are outside the scope of this specification.
11.5. Movement 11.5. Movement
11.5.1. Movement Detection 11.5.1. Movement Detection
The primary goal of movement detection is to detect L3 handovers. The primary goal of movement detection is to detect L3 handovers.
This section does not attempt to specify a fast movement detection This section does not attempt to specify a fast movement detection
algorithm which will function optimally for all types of algorithm which will function optimally for all types of
applications, link-layers and deployment scenarios; instead, it applications, link-layers and deployment scenarios; instead, it
describes a generic method that uses the facilities of IPv6 Neighbor describes a generic method that uses the facilities of IPv6 Neighbor
skipping to change at page 127, line 11 skipping to change at page 127, line 11
receive Router Advertisements with the same link-local source receive Router Advertisements with the same link-local source
address. This might be common if routers use the same link-local address. This might be common if routers use the same link-local
address on multiple interfaces. This issue can be avoided when address on multiple interfaces. This issue can be avoided when
routers use the Router Address (R) bit, since that provides a routers use the Router Address (R) bit, since that provides a
global address of the router. global address of the router.
In addition, the mobile node should consider the following events as In addition, the mobile node should consider the following events as
indications that an L3 handover may have occurred. Upon receiving indications that an L3 handover may have occurred. Upon receiving
such indications, the mobile node needs to perform Router Discovery such indications, the mobile node needs to perform Router Discovery
to discover routers and prefixes on the new link, as described in to discover routers and prefixes on the new link, as described in
Section 6.3.7 of RFC 4861 [20]. Section 6.3.7 of Neighbor Discovery (RFC 4861 [20]).
o If Router Advertisements that the mobile node receives include an o If Router Advertisements that the mobile node receives include an
Advertisement Interval option, the mobile node may use its Advertisement Interval option, the mobile node may use its
Advertisement Interval field as an indication of the frequency Advertisement Interval field as an indication of the frequency
with which it should expect to continue to receive future with which it should expect to continue to receive future
Advertisements from that router. This field specifies the minimum Advertisements from that router. This field specifies the minimum
rate (the maximum amount of time between successive rate (the maximum amount of time between successive
Advertisements) that the mobile node should expect. If this Advertisements) that the mobile node should expect. If this
amount of time elapses without the mobile node receiving any amount of time elapses without the mobile node receiving any
Advertisement from this router, the mobile node can be sure that Advertisement from this router, the mobile node can be sure that
at least one Advertisement sent by the router has been lost. The at least one Advertisement sent by the router has been lost. The
mobile node can then implement its own policy to determine how mobile node can then implement its own policy to determine how
many lost Advertisements from its current default router many lost Advertisements from its current default router
constitute an L3 handover indication. constitute an L3 handover indication.
o Neighbor Unreachability Detection determines that the default o Neighbor Unreachability Detection determines that the default
router is no longer reachable. router is no longer reachable.
o With some types of networks, notification that an L2 handover has o With some types of networks, notification that a L2 handover has
occurred might be obtained from lower layer protocols or device occurred might be obtained from lower layer protocols or device
driver software within the mobile node. While further details driver software within the mobile node. While further details
around handling L2 indications as movement hints is an item for around handling L2 indications as movement hints is an item for
further study, at the time of writing this specification the further study, at the time of writing this specification the
following is considered reasonable: following is considered reasonable:
An L2 handover indication may or may not imply L2 movement and L2 A L2 handover indication may or may not imply L2 movement and L2
movement may or may not imply L3 movement; the correlations might movement may or may not imply L3 movement; the correlations might
be a function of the type of L2 but might also be a function of be a function of the type of L2 but might also be a function of
actual deployment of the wireless topology. actual deployment of the wireless topology.
Unless it is well-known that an L2 handover indication is likely Unless it is well-known that a L2 handover indication is likely to
to imply L3 movement, instead of immediately multicasting a router imply L3 movement, instead of immediately multicasting a router
solicitation it may be better to attempt to verify whether the solicitation it may be better to attempt to verify whether the
default router is still bi-directionally reachable. This can be default router is still bi-directionally reachable. This can be
accomplished by sending a unicast Neighbor Solicitation and accomplished by sending a unicast Neighbor Solicitation and
waiting for a Neighbor Advertisement with the solicited flag set. waiting for a Neighbor Advertisement with the solicited flag set.
Note that this is similar to Neighbor Unreachability detection but Note that this is similar to Neighbor Unreachability detection but
it does not have the same state machine, such as the STALE state. it does not have the same state machine, such as the STALE state.
If the default router does not respond to the Neighbor If the default router does not respond to the Neighbor
Solicitation it makes sense to proceed to multicasting a Router Solicitation it makes sense to proceed to multicasting a Router
Solicitation. Solicitation.
11.5.2. Home Link Detection 11.5.2. Home Link Detection
When an MN detects that it has arrived on a new link using the When an MN detects that it has arrived on a new link using the
movement detection algorithm in use (Section Section 11.5.1,) it movement detection algorithm in use (Section 11.5.1,) or on
performs the following steps to determine if it is on the home link. bootstrapping, it performs the following steps to determine if it is
on the home link.
o The MN performs the procedure described in Section 11.5.2x and o The MN performs the procedure described in Section 11.5.3 and
configures an address. It also keeps track of all the on-link configures an address. It also keeps track of all the on-link
prefix(es) received in the RA along with their prefix lengths. prefix(es) received in the RA along with their prefix lengths.
o If the home prefix has not been statically configured the MN uses o If the home prefix has not been statically configured the MN uses
some form of bootstrapping procedure (e.g. RFC5026 [25]) to some form of bootstrapping procedure (e.g. RFC5026 [25]) to
determine the home prefix. determine the home prefix.
o Given the availability of the home prefix, the MN checks whether o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it has returned home. RA. If it does, the MN concludes that it is connected to the home
link.
11.5.3. Forming New Care-of Addresses 11.5.3. Forming New Care-of Addresses
After detecting that it has moved a mobile node SHOULD generate a new After detecting that it has moved a mobile node SHOULD generate a new
primary care-of address using normal IPv6 mechanisms. This SHOULD primary care-of address using normal IPv6 mechanisms. This SHOULD
also be done when the current primary care-of address becomes also be done when the current primary care-of address becomes
deprecated. A mobile node MAY form a new primary care-of address at deprecated. A mobile node MAY form a new primary care-of address at
any time, but a mobile node MUST NOT send a Binding Update about a any time, but a mobile node MUST NOT send a Binding Update about a
new care-of address to its home agent more than MAX_UPDATE_RATE times new care-of address to its home agent more than MAX_UPDATE_RATE times
within a second. within a second.
skipping to change at page 130, line 16 skipping to change at page 130, line 17
A mobile node detects that it has returned to its home link through A mobile node detects that it has returned to its home link through
the movement detection algorithm in use (Section 11.5.2), when the the movement detection algorithm in use (Section 11.5.2), when the
mobile node detects that its home subnet prefix is again on-link. To mobile node detects that its home subnet prefix is again on-link. To
be able to send and receive packets using its home address from the 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 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 agent to instruct its home agent to no longer intercept or tunnel
packets for it. Until the mobile node sends such a de-registration packets for it. Until the mobile node sends such a de-registration
Binding Update, it MUST NOT attempt to send and receive packets using Binding Update, it MUST NOT attempt to send and receive packets using
its home address from the home link. The home agent will continue to its home address from the home link. The home agent will continue to
intercept all packets sent to the mobile's home address and tunnel to intercept all packets sent to the mobile's home address and tunnel
the previously registered care-of address. them to the previously registered care-of address.
In this home registration, the mobile node MUST set the Acknowledge In this home registration, the mobile node MUST set the Acknowledge
(A) and Home Registration (H) bits, set the Lifetime field to zero, (A) and Home Registration (H) bits, set the Lifetime field to zero,
and set the care-of address for the binding to the mobile node's own and set the care-of address for the binding to the mobile node's own
home address. The mobile node MUST use its home address as the home address. The mobile node MUST use its home address as the
source address in the Binding Update. source address in the Binding Update.
When sending this Binding Update to its home agent, the mobile node When sending this Binding Update to its home agent, the mobile node
must be careful in how it uses Neighbor Solicitation [20] (if needed) must be careful in how it uses Neighbor Solicitation [20] (if needed)
to learn the home agent's link-layer address, since the home agent to learn the home agent's link-layer address, since the home agent
will be currently configured to intercept packets to the mobile will be currently configured to intercept packets to the mobile
node's home address using Duplicate Address Detection (DAD). In node's home address using Proxy Neighbor Discovery (Proxy ND). In
particular, the mobile node is unable to use its home address as the particular, the mobile node is unable to use its home address as the
Source Address in the Neighbor Solicitation until the home agent Source Address in the Neighbor Solicitation until the home agent
stops defending the home address. stops defending the home address.
Neighbor Solicitation by the mobile node for the home agent's address Neighbor Solicitation by the mobile node for the home agent's address
will normally not be necessary, since the mobile node has already will normally not be necessary, since the mobile node has already
learned the home agent's link-layer address from a Source Link-Layer learned the home agent's link-layer address from a Source Link-Layer
Address option in a Router Advertisement. However, if there are Address option in a Router Advertisement. However, if there are
multiple home agents it may still be necessary to send a multiple home agents it may still be necessary to send a
solicitation. In this special case of the mobile node returning solicitation. In this special case of the mobile node returning
skipping to change at page 137, line 29 skipping to change at page 137, line 31
possible for another node to autoconfigure the mobile node's home possible for another node to autoconfigure the mobile node's home
address. Therefore, the mobile node MUST treat the creation of a new address. Therefore, the mobile node MUST treat the creation of a new
binding with the home agent using an existing home address, the same binding with the home agent using an existing home address, the same
as creation of a new home address. In the unlikely event that the as creation of a new home address. In the unlikely event that the
mobile node's home address is autoconfigured as the IPv6 address of mobile node's home address is autoconfigured as the IPv6 address of
another network node on the home network, the home agent will reply another network node on the home network, the home agent will reply
to the mobile node's subsequent Binding Update with a Binding to the mobile node's subsequent Binding Update with a Binding
Acknowledgement containing a Status of 134 (Duplicate Address Acknowledgement containing a Status of 134 (Duplicate Address
Detection failed). In this case, the mobile node MUST NOT attempt to Detection failed). In this case, the mobile node MUST NOT attempt to
re-use the same home address. It SHOULD continue to register the re-use the same home address. It SHOULD continue to register the
care-of addresses for its other home addresses, if any. (Mechanisms care-of addresses for its other home addresses, if any. Mechanisms
outlined in Appendix A.5 may in the future allow mobile nodes to outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [25] allow
acquire new home addresses to replace the one for which Status 134 mobile nodes to acquire new home addresses to replace the one for
was received.) which Status 134 was received.
11.7.2. Correspondent Registration 11.7.2. Correspondent Registration
When the mobile node is assured that its home address is valid, it When the mobile node is assured that its home address is valid, it
can initiate a correspondent registration with the purpose of can initiate a correspondent registration with the purpose of
allowing the correspondent node to cache the mobile node's current allowing the correspondent node to cache the mobile node's current
care-of address. This procedure consists of the return routability care-of address. This procedure consists of the return routability
procedure followed by a registration. procedure followed by a registration.
This section defines when the correspondent registration is to be This section defines when the correspondent registration is to be
skipping to change at page 142, line 46 skipping to change at page 142, line 50
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.
For an IKE phase 1 connection, this means that packets sent to this For an IKE phase 1 connection, this means that packets sent to this
address with the original ISAKMP cookies are accepted. address with the original ISAKMP cookies are accepted.
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, the mobile node has a Binding Update List entry for Request message, if the mobile node has a Binding Update List entry
the source of the Binding Refresh Request, and the mobile node wants for the source of the Binding Refresh Request, and the mobile node
to retain its binding cache entry at the correspondent node, then the wants to retain its binding cache entry at the correspondent node,
mobile node should start a return routability procedure. If the then the mobile node should start a return routability procedure. If
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
skipping to change at page 145, line 7 skipping to change at page 145, line 7
of a particular type to a particular correspondent node more than of a particular type to a particular correspondent node more than
MAX_UPDATE_RATE times within a second. MAX_UPDATE_RATE times within a second.
Retransmitted Binding Updates MUST use a Sequence Number value Retransmitted Binding Updates MUST use a Sequence Number value
greater than that used for the previous transmission of this Binding greater than that used for the previous transmission of this Binding
Update. Retransmitted Home Test Init and Care-of Test Init messages Update. Retransmitted Home Test Init and Care-of Test Init messages
MUST use new cookie values. MUST use new cookie values.
12. Protocol Constants 12. Protocol Constants
DHAAD_RETRIES 4 retransmissions DHAAD_RETRIES 4 retransmissions
INITIAL_BINDACK_TIMEOUT 1 second INITIAL_BINDACK_TIMEOUT 1 second
INITIAL_DHAAD_TIMEOUT 3 seconds INITIAL_DHAAD_TIMEOUT 3 seconds
INITIAL_SOLICIT_TIMER 3 seconds INITIAL_SOLICIT_TIMER 3 seconds
MAX_BINDACK_TIMEOUT 32 seconds MAX_BINDACK_TIMEOUT 32 seconds
MAX_DELETE_BCE_TIMEOUT 10 seconds MAX_DELETE_BCE_TIMEOUT 10 seconds
MAX_NONCE_LIFETIME 240 seconds MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds MAX_TOKEN_LIFETIME 210 seconds
MAX_RO_FAILURE 3 retries MAX_RO_FAILURE 3 retries
MAX_RR_BINDING_LIFETIME 420 seconds MAX_RR_BINDING_LIFETIME 420 seconds
MAX_UPDATE_RATE 3 times MAX_UPDATE_RATE 3 times
PREFIX_ADV_RETRIES 3 retransmissions PREFIX_ADV_RETRIES 3 retransmissions
PREFIX_ADV_TIMEOUT 3 seconds PREFIX_ADV_TIMEOUT 3 seconds
13. Protocol Configuration Variables 13. Protocol Configuration Variables
MaxMobPfxAdvInterval Default: 86,400 seconds MaxMobPfxAdvInterval Default: 86,400 seconds
MinDelayBetweenRAs Default: 3 seconds, MinDelayBetweenRAs Default: 3 seconds,
Min: 0.03 seconds Min: 0.03 seconds
MinMobPfxAdvInterval Default: 600 seconds MinMobPfxAdvInterval Default: 600 seconds
InitialBindackTimeoutFirstReg Default: 1.5 seconds InitialBindackTimeoutFirstReg Default: 1.5 seconds
Home agents MUST allow the first three variables to be configured by Home agents MUST allow the first three variables to be configured by
system management, and mobile nodes MUST allow the last variable to system management, and mobile nodes MUST allow the last variable to
be configured by system management. be configured by system management.
The default value for InitialBindackTimeoutFirstReg has been The default value for InitialBindackTimeoutFirstReg has been
calculated as 1.5 times the default value of RetransTimer [20] times calculated as 1.5 times the default value of RetransTimer, as
the default value of DupAddrDetectTransmits [21]. specified in Neighbor Discovery (RFC 4861 [20]) times the default
value of DupAddrDetectTransmits, as specified in Stateless Address
Autoconfiguration (RFC 4862 [21])
The value MinDelayBetweenRAs overrides the value of the protocol The value MinDelayBetweenRAs overrides the value of the protocol
constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 4861 [20]. This constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is (RFC 4861 [20]). This variable SHOULD be set to MinRtrAdvInterval,
less than 3 seconds. if MinRtrAdvInterval is less than 3 seconds.
14. IANA Considerations 14. IANA Considerations
This document defines a new IPv6 protocol, the Mobility Header, This document defines a new IPv6 protocol, the Mobility Header,
described in Section 6.1. This protocol has been assigned protocol described in Section 6.1. This protocol has been assigned protocol
number 135. number 135.
This document also creates a new name space "Mobility Header Type", This document also creates a new name space "Mobility Header Type",
for the MH Type field in the Mobility Header. The current message for the MH Type field in the Mobility Header. The current message
types are described starting from Section 6.1.2, and are the types are described starting from Section 6.1.2, and are the
skipping to change at page 151, line 46 skipping to change at page 151, line 46
Address destination option, a new routing header type (type 2), Address destination option, a new routing header type (type 2),
and uses tunneling headers in the payload packets. The protocol and uses tunneling headers in the payload packets. The protocol
must protect against potential new threats involving the use of must protect against potential new threats involving the use of
these mechanisms. these mechanisms.
Third parties become exposed to a reflection threat via the Home Third parties become exposed to a reflection threat via the Home
Address destination option, unless appropriate security Address destination option, unless appropriate security
precautions are followed. The Home Address destination option precautions are followed. The Home Address destination option
could be used to direct response traffic toward a node whose IP could be used to direct response traffic toward a node whose IP
address appears in the option. In this case, ingress filtering address appears in the option. In this case, ingress filtering
would not catch the forged "return address" [39] [42]. would not catch the forged "return address" [39] [43].
A similar threat exists with the tunnels between the mobile node A similar threat exists with the tunnels between the mobile node
and the home agent. An attacker might forge tunnel packets and the home agent. An attacker might forge tunnel packets
between the mobile node and the home agent, making it appear that between the mobile node and the home agent, making it appear that
the traffic is coming from the mobile node when it is not. Note the traffic is coming from the mobile node when it is not. Note
that an attacker who is able to forge tunnel packets would that an attacker who is able to forge tunnel packets would
typically also be able to forge packets that appear to come typically also be able to forge packets that appear to come
directly from the mobile node. This is not a new threat as such. directly from the mobile node. This is not a new threat as such.
However, it may make it easier for attackers to escape detection However, it may make it easier for attackers to escape detection
by avoiding ingress filtering and packet tracing mechanisms. by avoiding ingress filtering and packet tracing mechanisms.
skipping to change at page 155, line 7 skipping to change at page 155, line 7
prefix. This is because IPsec security associations are bound to the prefix. This is because IPsec security associations are bound to the
used addresses. While certificate-based automatic keying alleviates used addresses. While certificate-based automatic keying alleviates
this problem to an extent, it is still necessary to ensure that a this problem to an extent, it is still necessary to ensure that a
given mobile node cannot send Binding Updates for the address of given mobile node cannot send Binding Updates for the address of
another mobile node. In general, this leads to the inclusion of home another mobile node. In general, this leads to the inclusion of home
addresses in certificates in the Subject AltName field. This again addresses in certificates in the Subject AltName field. This again
limits the introduction of new addresses without either manual or limits the introduction of new addresses without either manual or
automatic procedures to establish new certificates. Therefore, this automatic procedures to establish new certificates. Therefore, this
specification restricts the generation of new home addresses (for any specification restricts the generation of new home addresses (for any
reason) to those situations where a security association or reason) to those situations where a security association or
certificate for the new address already exists. (Appendix A.4 lists certificate for the new address already exists.
the improvement of security for new addresses as one of the future
developments for Mobile IPv6.)
Support for IKE has been specified as optional. The following should Support for IKE has been specified as optional. The following should
be observed about the use of manual keying: be observed about the use of manual keying:
o As discussed above, with manually keyed IPsec, only a limited form o As discussed above, with manually keyed IPsec, only a limited form
of protection exists against replay and reordering attacks. A of protection exists against replay and reordering attacks. A
vulnerability exists if either the sequence number space is cycled vulnerability exists if either the sequence number space is cycled
through, or if the home agent reboots and forgets its sequence through, or if the home agent reboots and forgets its sequence
numbers (and uses volatile memory to store the sequence numbers). numbers (and uses volatile memory to store the sequence numbers).
Assuming the mobile node moves continuously every 10 minutes, it Assuming the mobile node moves continuously every 10 minutes, it
takes roughly 455 days before the sequence number space has been takes roughly 455 days before the sequence number space has been
cycled through. Typical movement patterns rarely reach this high cycled through. Typical movement patterns rarely reach this high
frequency today. frequency today.
o A mobile node and its home agent belong to the same domain. If o A mobile node and its home agent belong to the same domain. If
this were not the case, manual keying would not be possible [41], this were not the case, manual keying would not be possible [42],
but in Mobile IPv6 only these two parties need to know the but in Mobile IPv6 only these two parties need to know the
manually configured keys. Similarly, we note that Mobile IPv6 manually configured keys. Similarly, we note that Mobile IPv6
employs standard block ciphers in IPsec, and is not vulnerable to employs standard block ciphers in IPsec, and is not vulnerable to
problems associated with stream ciphers and manual keying. problems associated with stream ciphers and manual keying.
o It is expected that the owner of the mobile node and the o It is expected that the owner of the mobile node and the
administrator of the home agent agree on the used keys and other administrator of the home agent agree on the used keys and other
parameters with some off-line mechanism. parameters with some off-line mechanism.
The use of IKEv1 with Mobile IPv6 is documented in more detail in The use of IKEv1 with Mobile IPv6 is documented in more detail in
skipping to change at page 156, line 50 skipping to change at page 156, line 49
o Similarly, in some deployment scenarios the number of mobile nodes o Similarly, in some deployment scenarios the number of mobile nodes
may be very large. In these cases, it can be necessary to use may be very large. In these cases, it can be necessary to use
automatic mechanisms to reduce the management effort in the automatic mechanisms to reduce the management effort in the
administration of cryptographic parameters, even if some per- administration of cryptographic parameters, even if some per-
mobile node configuration is always needed. IKE SHOULD also be mobile node configuration is always needed. IKE SHOULD also be
used in such cases. used in such cases.
o Other automatic key management mechanisms exist beyond IKEv1, but o Other automatic key management mechanisms exist beyond IKEv1, but
this document does not address the issues related to them. We this document does not address the issues related to them. We
note, however, that most of the above discussion applies to IKEv2 note, however, that most of the above discussion applies to IKEv2
[43] as well, at least as it is currently specified. [44] as well, at least as it is currently specified.
15.4. Binding Updates to Correspondent Nodes 15.4. Binding Updates to Correspondent Nodes
The motivation for designing the return routability procedure was to The motivation for designing the return routability procedure was to
have sufficient support for Mobile IPv6, without creating significant have sufficient support for Mobile IPv6, without creating significant
new security problems. The goal for this procedure was not to new security problems. The goal for this procedure was not to
protect against attacks that were already possible before the protect against attacks that were already possible before the
introduction of Mobile IPv6. introduction of Mobile IPv6.
The next sections will describe the security properties of the used The next sections will describe the security properties of the used
skipping to change at page 158, line 7 skipping to change at page 158, line 7
available. available.
The resulting level of security is in theory the same even without The resulting level of security is in theory the same even without
this additional protection: the return routability tokens are this additional protection: the return routability tokens are
still exposed only to one path within the whole Internet. still exposed only to one path within the whole Internet.
However, the mobile nodes are often found on an insecure link, However, the mobile nodes are often found on an insecure link,
such as a public access Wireless LAN. Thus, in many cases, this such as a public access Wireless LAN. Thus, in many cases, this
addition makes a practical difference. addition makes a practical difference.
For further information about the design rationale of the return For further information about the design rationale of the return
routability procedure, see [31] [36] [35] [42]. The mechanisms used routability procedure, see [31] [36] [35] [43]. The mechanisms used
have been adopted from these documents. have been adopted from these documents.
15.4.2. Achieved Security Properties 15.4.2. Achieved Security Properties
The return routability procedure protects Binding Updates against all The return routability procedure protects Binding Updates against all
attackers who are unable to monitor the path between the home agent attackers who are unable to monitor the path between the home agent
and the correspondent node. The procedure does not defend against and the correspondent node. The procedure does not defend against
attackers who can monitor this path. Note that such attackers are in attackers who can monitor this path. Note that such attackers are in
any case able to mount an active attack against the mobile node when any case able to mount an active attack against the mobile node when
it is at its home location. The possibility of such attacks is not it is at its home location. The possibility of such attacks is not
skipping to change at page 160, line 32 skipping to change at page 160, line 32
typically easiest to attack on the links at either end, in typically easiest to attack on the links at either end, in
particular if these links are publicly accessible wireless LANs. particular if these links are publicly accessible wireless LANs.
Attacks against the routers or switches on the path are typically Attacks against the routers or switches on the path are typically
harder to accomplish. The security on layer 2 of the links plays harder to accomplish. The security on layer 2 of the links plays
then a major role in the resulting overall network security. then a major role in the resulting overall network security.
Similarly, security of IPv6 Neighbor and Router Discovery on these Similarly, security of IPv6 Neighbor and Router Discovery on these
links has a large impact. If these were secured using some new links has a large impact. If these were secured using some new
technology in the future, this could change the situation technology in the future, this could change the situation
regarding the easiest point of attack. regarding the easiest point of attack.
For a more in-depth discussion of these issues, see [42]. For a more in-depth discussion of these issues, see [43].
15.4.4. Replay Attacks 15.4.4. Replay Attacks
The return routability procedure also protects the participants The return routability procedure also protects the participants
against replayed Binding Updates. The attacker is unable replay the against replayed Binding Updates. The attacker is unable replay the
same message due to the sequence number which is a part of the same message due to the sequence number which is a part of the
Binding Update. It is also unable to modify the Binding Update since Binding Update. It is also unable to modify the Binding Update since
the MAC verification would fail after such a modification. the MAC verification would fail after such a modification.
Care must be taken when removing bindings at the correspondent node, Care must be taken when removing bindings at the correspondent node,
skipping to change at page 163, line 30 skipping to change at page 163, line 30
provided by the DNSSEC [16] framework. The needed pre-configured provided by the DNSSEC [16] framework. The needed pre-configured
data on the mobile node for this mechanism is the domain name of the data on the mobile node for this mechanism is the domain name of the
mobile service provider, which is marginally better than the home mobile service provider, which is marginally better than the home
subnet prefix. For the security, a trust anchor which dominates the subnet prefix. For the security, a trust anchor which dominates the
domain is needed. domain is needed.
15.6. Mobile Prefix Discovery 15.6. Mobile Prefix Discovery
The mobile prefix discovery function may leak interesting information The mobile prefix discovery function may leak interesting information
about network topology and prefix lifetimes to eavesdroppers; for about network topology and prefix lifetimes to eavesdroppers; for
this reason, requests for this information has to be authenticated. this reason, requests for this information have to be authenticated.
Responses and unsolicited prefix information needs to be Responses and unsolicited prefix information needs to be
authenticated to prevent the mobile nodes from being tricked into authenticated to prevent the mobile nodes from being tricked into
believing false information about the prefixes and possibly believing false information about the prefixes and possibly
preventing communications with the existing addresses. Optionally, preventing communications with the existing addresses. Optionally,
encryption may be applied to prevent leakage of the prefix encryption may be applied to prevent leakage of the prefix
information. information.
15.7. Tunneling via the Home Agent 15.7. Tunneling via the Home Agent
Tunnels between the mobile node and the home agent can be protected Tunnels between the mobile node and the home agent can be protected
skipping to change at page 164, line 23 skipping to change at page 164, line 23
does not work if the final destination of the packet is in the home does not work if the final destination of the packet is in the home
network, and some form of perimeter defense is being applied for network, and some form of perimeter defense is being applied for
packets sent to those destinations. In such cases it is recommended packets sent to those destinations. In such cases it is recommended
that either end-to-end security or additional tunnel protection be that either end-to-end security or additional tunnel protection be
applied, as is usual in remote access situations. applied, as is usual in remote access situations.
Home agents and mobile nodes may use IPsec ESP to protect payload Home agents and mobile nodes may use IPsec ESP to protect payload
packets tunneled between themselves. This is useful for protecting packets tunneled between themselves. This is useful for protecting
communications against attackers on the path of the tunnel. communications against attackers on the path of the tunnel.
When site local home addresses are used, reverse tunneling can be When a Unique-Local Address (ULA) RFC4193 [22] is used as a home
used to send site local traffic from another location. address, reverse tunneling can be used to send local traffic from
Administrators should be aware of this when allowing such home another location. Administrators should be aware of this when
addresses. In particular, the outer IP address check described above allowing such home addresses. In particular, the outer IP address
is not sufficient against all attackers. The use of encrypted check described above is not sufficient against all attackers. The
tunnels is particularly useful for these kinds of home addresses. use of encrypted tunnels is particularly useful for these kinds of
home addresses.
15.8. Home Address Option 15.8. Home Address Option
When the mobile node sends packets directly to the correspondent When the mobile node sends packets directly to the correspondent
node, the Source Address field of the packet's IPv6 header is the node, the Source Address field of the packet's IPv6 header is the
care-of address. Therefore, ingress filtering [30] works in the care-of address. Therefore, ingress filtering [30] works in the
usual manner even for mobile nodes, as the Source Address is usual manner even for mobile nodes, as the Source Address is
topologically correct. The Home Address option is used to inform the topologically correct. The Home Address option is used to inform the
correspondent node of the mobile node's home address. correspondent node of the mobile node's home address.
skipping to change at page 166, line 7 skipping to change at page 166, line 7
addresses are the same. addresses are the same.
This implies that a device which implements the filtering of packets This implies that a device which implements the filtering of packets
should be able to distinguish between a type 2 routing header and should be able to distinguish between a type 2 routing header and
other routing headers, as required in Section 8.3. This is necessary other routing headers, as required in Section 8.3. This is necessary
in order to allow Mobile IPv6 traffic while still having the option in order to allow Mobile IPv6 traffic while still having the option
of filtering out other uses of routing headers. of filtering out other uses of routing headers.
16. Contributors 16. Contributors
Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik
and Michael Thomas worked on the return routability protocols Nordmark, and Michael Thomas shaped the return routability protocols
eventually led to the procedures used in this protocol. The described in [36].
procedures described in [36] were adopted in the protocol.
Significant contributions were made by members of the Mobile IPv6 Significant contributions were made by members of the Mobile IPv6
Security Design Team, including (in alphabetical order) Gabriel Security Design Team, including (in alphabetical order) Gabriel
Montenegro, Erik Nordmark and Pekka Nikander. Montenegro, Erik Nordmark and Pekka Nikander.
17. Acknowledgements 17. Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) Fred Baker, Josh particularly like to thank (in alphabetical order) Fred Baker, Josh
Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Jean-Michel Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Jean-Michel
Combes, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont, Combes, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont,
Ashutosh Dutta, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino, Ashutosh Dutta, Arnaud Ebalard, Wesley Eddy, Thomas Eklund, Jun-
Brian Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli, Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James
Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Jiwoong Lee, Kempf, Rajeev Koodli, Suresh Krishnan, Krishna Kumar, T.J. Kniveton,
Benjamin Lim, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn Joe Lau, Aime Le Rouzic, Jiwoong Lee, Benjamin Lim, Vesa-Matti
Morrow, Ahmad Muhanna, Thomas Narten, Karen Nielsen, Simon Nybroe, Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten,
David Oran, Brett Pentland, Lars Henrik Petander, Basavaraj Patil, Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy,
Mohan Parthasarathy, Alexandru Petrescu, Mattias Petterson, Ken Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru
Powell, Phil Roberts, Ed Remmell, Patrice Romand, Luis A. Sanchez, Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts,
Jeff Schiller, Pekka Savola, Arvind Sevalkar, Keiichi Shima, Tom Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind
Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon,
Pascal Thubert, Benny Van Houdt, Jon-Olov Vatn, Ryuji Wakikawa, Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov
Kilian Weniger, Carl E. Williams, Vladislav Yasevich, Alper Yegin, Vatn, Ryuji Wakikawa, Kilian Weniger, Carl E. Williams, Vladislav
and Xinhua Zhao, for their detailed reviews of earlier versions of Yasevich, Alper Yegin, and Xinhua Zhao, for their detailed reviews of
this document. Their suggestions have helped to improve both the earlier versions of this document. Their suggestions have helped to
design and presentation of the protocol. improve both the design and presentation of the protocol.
We would also like to thank the participants of the Mobile IPv6 We would also like to thank the participants of the Mobile IPv6
testing event (1999), implementors who participated in Mobile IPv6 testing event (1999), implementors who participated in Mobile IPv6
interoperability testing at Connectathons (2000, 2001, 2002, and interoperability testing at Connectathons (2000, 2001, 2002, and
2003), and the participants at the ETSI interoperability testing 2003), and the participants at the ETSI interoperability testing
(2000, 2002). Finally, we would like to thank the TAHI project who (2000, 2002). Finally, we would like to thank the TAHI project who
has provided test suites for Mobile IPv6. has provided test suites for Mobile IPv6.
18. References 18. References
skipping to change at page 170, line 45 skipping to change at page 170, line 45
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. progress), April 2008.
[38] Savola, P., "Use of /127 Prefix Length Between Routers [38] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003. Considered Harmful", RFC 3627, September 2003.
[39] Savola, P., "Security of IPv6 Routing Header and Home Address [39] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-02 (work in Options", draft-savola-ipv6-rh-ha-security-02 (work in
progress), March 2002. progress), March 2002.
[40] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [40] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[41] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[41] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key [42] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Management", BCP 107, RFC 4107, June 2005. Management", BCP 107, RFC 4107, June 2005.
[42] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [43] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[43] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [44] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[45] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[46] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of
Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
Appendix A. Future Extensions Appendix A. Future Extensions
A.1. Piggybacking A.1. Piggybacking
This document does not specify how to piggyback payload packets on This document does not specify how to piggyback payload packets on
the binding related messages. However, it is envisioned that this the binding related messages. However, it is envisioned that this
can be specified in a separate document when issues such as the can be specified in a separate document when issues such as the
interaction between piggybacking and IPsec are fully resolved (see interaction between piggybacking and IPsec are fully resolved (see
also Appendix A.3). The return routability messages can indicate also Appendix A.3). The return routability messages can indicate
support for piggybacking with a new mobility option. support for piggybacking with a new mobility option.
skipping to change at page 172, line 42 skipping to change at page 172, line 42
enhancements of IPv6 security may cause a need to also improve the enhancements of IPv6 security may cause a need to also improve the
security of the return routability procedure. Using IPsec as the security of the return routability procedure. Using IPsec as the
sole method for authorizing Binding Updates to correspondent nodes is sole method for authorizing Binding Updates to correspondent nodes is
also possible. The protection of the Mobility Header for this also possible. The protection of the Mobility Header for this
purpose is easy, though one must ensure that the IPsec SA was created purpose is easy, though one must ensure that the IPsec SA was created
with appropriate authorization to use the home address referenced in with appropriate authorization to use the home address referenced in
the Binding Update. For instance, a certificate used by IKE to the Binding Update. For instance, a certificate used by IKE to
create the security association might contain the home address. A create the security association might contain the home address. A
future specification may specify how this is done. future specification may specify how this is done.
A.4. Dynamically Generated Home Addresses A.4. Neighbor Discovery Extensions
A future version of this specification may include functionality that
allows the generation of new home addresses without requiring pre-
arranged security associations or certificates even for the new
addresses.
A.5. Remote Home Address Configuration
The method for initializing a mobile node's home address upon
power-up or after an extended period of being disconnected from the
network is beyond the scope of this specification. Whatever
procedure is used should result in the mobile node having the same
stateless or stateful (e.g., DHCPv6) home address autoconfiguration
information it would have if it were attached to the home network.
Due to the possibility that the home network could be renumbered
while the mobile node is disconnected, a robust mobile node would not
rely solely on storing these addresses locally.
Such a mobile node could be initialized by using the following
procedure:
1. Generate a care-of address.
2. Query DNS for an anycast address associated with the FQDN of the
home agent(s).
3. Perform home agent address discovery, and select a home agent.
4. Configure one home address based on the selected home agent's
subnet prefix and the interface identifier of the mobile node.
5. Create security associations and security policy database entries
for protecting the traffic between the selected home address and
home agent.
6. Perform a home registration on the selected home agent.
7. Perform mobile prefix discovery.
8. Make a decision if further home addresses need to be configured.
This procedure is restricted to those situations where the home
prefix is 64 bits and the mobile node knows its own interface
identifier, which is also 64 bits.
A.6. Neighbor Discovery Extensions
Future specifications may improve the efficiency of Neighbor Future specifications may improve the efficiency of Neighbor
Discovery tasks, which could be helpful for fast movements. One Discovery tasks, which could be helpful for fast movements. One
factor is currently being looked at: the delays caused by the factor is currently being looked at: the delays caused by the
Duplicate Address Detection mechanism. Currently, Duplicate Address Duplicate Address Detection mechanism. Currently, Duplicate Address
Detection needs to be performed for every new care-of address as the Detection needs to be performed for every new care-of address as the
mobile node moves, and for the mobile node's link-local address on mobile node moves, and for the mobile node's link-local address on
every new link. In particular, the need and the trade-offs of re- every new link. In particular, the need and the trade-offs of re-
performing Duplicate Address Detection for the link-local address performing Duplicate Address Detection for the link-local address
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
 End of changes. 83 change blocks. 
314 lines changed or deleted 295 lines changed or added

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