draft-ietf-mobileip-ipv6-22.txt   draft-ietf-mobileip-ipv6-23.txt 
IETF Mobile IP Working Group D. Johnson IETF Mobile IP Working Group D. Johnson
Internet-Draft Rice University Internet-Draft Rice University
Expires: November 24, 2003 C. Perkins Expires: October 30, 2003 C. Perkins
Nokia Research Center Nokia Research Center
J. Arkko J. Arkko
Ericsson Ericsson
May 26, 2003 May 2003
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mobileip-ipv6-22.txt draft-ietf-mobileip-ipv6-23.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other groups may also distribute working documents as
Internet-Drafts. Internet-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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 November 24, 2003. This Internet-Draft will expire on October 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
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. Each mobile node reachable while moving around in the IPv6 Internet. Each mobile node
is always identified by its home address, regardless of its current is always identified by its home address, regardless of its current
skipping to change at page 5, line 12 skipping to change at page 5, line 12
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 141 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 141
13. Protocol Configuration Variables . . . . . . . . . . . . . 142 13. Protocol Configuration Variables . . . . . . . . . . . . . 142
14. IANA Considerations . . . . . . . . . . . . . . . . . . . 143 14. IANA Considerations . . . . . . . . . . . . . . . . . . . 143
15. Security Considerations . . . . . . . . . . . . . . . . . 145 15. Security Considerations . . . . . . . . . . . . . . . . . 145
15.1 Threats . . . . . . . . . . . . . . . . . . . . . .145 15.1 Threats . . . . . . . . . . . . . . . . . . . . . .145
15.2 Features . . . . . . . . . . . . . . . . . . . . . .147 15.2 Features . . . . . . . . . . . . . . . . . . . . . .147
15.3 Binding Updates to Home Agent . . . . . . . . . . .148 15.3 Binding Updates to Home Agent . . . . . . . . . . .148
15.4 Binding Updates to Correspondent Nodes . . . . . . .151 15.4 Binding Updates to Correspondent Nodes . . . . . . .151
15.4.1 Overview . . . . . . . . . . . . . . . . . . 151 15.4.1 Overview . . . . . . . . . . . . . . . . . . 151
15.4.2 Achieved Security Properties . . . . . . . . 152 15.4.2 Achieved Security Properties . . . . . . . . 152
15.4.3 Comparison to Regular IPv6 Communications . 152 15.4.3 Comparison to Regular IPv6 Communications . 153
15.4.4 Replay Attacks . . . . . . . . . . . . . . . 154 15.4.4 Replay Attacks . . . . . . . . . . . . . . . 155
15.4.5 Denial-of-Service Attacks . . . . . . . . . 155 15.4.5 Denial-of-Service Attacks . . . . . . . . . 155
15.4.6 Key Lengths . . . . . . . . . . . . . . . . 156 15.4.6 Key Lengths . . . . . . . . . . . . . . . . 156
15.5 Dynamic Home Agent Address Discovery . . . . . . . .157 15.5 Dynamic Home Agent Address Discovery . . . . . . . .157
15.6 Mobile Prefix Discovery . . . . . . . . . . . . . .157 15.6 Mobile Prefix Discovery . . . . . . . . . . . . . .157
15.7 Tunneling via the Home Agent . . . . . . . . . . . .157 15.7 Tunneling via the Home Agent . . . . . . . . . . . .158
15.8 Home Address Option . . . . . . . . . . . . . . . .158 15.8 Home Address Option . . . . . . . . . . . . . . . .158
15.9 Type 2 Routing Header . . . . . . . . . . . . . . .159 15.9 Type 2 Routing Header . . . . . . . . . . . . . . .159
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 160 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 161
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 161 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 162
Normative References . . . . . . . . . . . . . . . . . . . 162 Normative References . . . . . . . . . . . . . . . . . . . 163
Informative References . . . . . . . . . . . . . . . . . . 164 Informative References . . . . . . . . . . . . . . . . . . 165
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 166
A. Changes from Previous Version of the Draft . . . . . . . . 166 A. Changes from Previous Version of the Draft . . . . . . . . 167
B. Future Extensions . . . . . . . . . . . . . . . . . . . . 169 B. Future Extensions . . . . . . . . . . . . . . . . . . . . 168
B.1 Piggybacking . . . . . . . . . . . . . . . . . . . . . . . 169 B.1 Piggybacking . . . . . . . . . . . . . . . . . . . . . . . 168
B.2 Triangular Routing . . . . . . . . . . . . . . . . . . . . 169 B.2 Triangular Routing . . . . . . . . . . . . . . . . . . . . 168
B.3 New Authorization Methods . . . . . . . . . . . . . . . . 169 B.3 New Authorization Methods . . . . . . . . . . . . . . . . 168
B.4 Dynamically Generated Home Addresses . . . . . . . . . . . 169 B.4 Dynamically Generated Home Addresses . . . . . . . . . . . 168
B.5 Remote Home Address Configuration . . . . . . . . . . . . 169 B.5 Remote Home Address Configuration . . . . . . . . . . . . 168
B.6 Neighbor Discovery Extensions . . . . . . . . . . . . . . 170 B.6 Neighbor Discovery Extensions . . . . . . . . . . . . . . 169
Intellectual Property and Copyright Statements . . . . . . 172 Intellectual Property and Copyright Statements . . . . . . 171
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 [11], packets destined to a mobile node support for mobility in IPv6 [11], 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 29, line 20 skipping to change at page 29, line 20
+ care-of nonce index (within the Nonce Indices option) + care-of nonce index (within the Nonce Indices option)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU))) | BU)))
The Binding Update contains a Nonce Indices option, indicating to The Binding Update contains a Nonce Indices option, indicating to
the correspondent node which home and care-of nonces to use to the correspondent node which home and care-of nonces to use to
recompute Kbm, the binding management key. The MAC is computed as recompute Kbm, the binding management key. The MAC is computed as
described in Section 6.2.7, using the correspondent node's address described in Section 6.2.7, using the correspondent node's address
as the destination address and the Binding Update message itself as the destination address and the Binding Update message itself
("BU" above) as the Mobility Header Data. ("BU" above) as the MH Data.
Once the correspondent node has verified the MAC, it can create a Once the correspondent node has verified the MAC, it can create a
Binding Cache entry for the mobile. Binding Cache entry for the mobile.
Binding Acknowledgement Binding Acknowledgement
The Binding Update is in some cases acknowledged by the The Binding Update is in some cases acknowledged by the
correspondent node. The contents of the message are as follows: correspondent node. The contents of the message are as follows:
* Source Address = correspondent * Source Address = correspondent
skipping to change at page 29, line 44 skipping to change at page 29, line 44
* Parameters: * Parameters:
+ sequence number (within the Binding Update message header) + sequence number (within the Binding Update message header)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA))) | BA)))
The Binding Acknowledgement contains the same sequence number as The Binding Acknowledgement contains the same sequence number as
the Binding Update. The MAC is computed as described in Section the Binding Update. The MAC is computed as described in Section
6.2.7, using the correspondent node's address as the destination 6.2.7, using the correspondent node's address as the destination
address and the message itself ("BA" above) as the Mobility Header address and the message itself ("BA" above) as the MH Data.
Data.
Bindings established with correspondent nodes using keys created by Bindings established with correspondent nodes using keys created by
way of the return routability procedure MUST NOT exceed way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFETIME seconds (see Section 12). MAX_RR_BINDING_LIFETIME seconds (see Section 12).
The value in the Source Address field in the IPv6 header carrying the The value in the Source Address field in the IPv6 header carrying the
Binding Update is normally also the care-of address which is used in Binding Update is normally also the care-of address which is used in
the binding. However, a different care-of address MAY be specified the binding. However, a different care-of address MAY be specified
by including an Alternate Care-of Address mobility option in the by including an Alternate Care-of Address mobility option in the
Binding Update (see Section 6.2.5). When such a message is sent to Binding Update (see Section 6.2.5). When such a message is sent to
skipping to change at page 42, line 5 skipping to change at page 42, line 5
address reported by the mobile node has the same interface address reported by the mobile node has the same interface
identifier as the mobile node's link-local address. identifier as the mobile node's link-local address.
Key Management Mobility Capability (K) Key Management Mobility Capability (K)
If this bit is cleared, the protocol used for establishing the If this bit is cleared, the protocol used for establishing the
IPsec security associations between the mobile node and the home IPsec security associations between the mobile node and the home
agent does not survive movements. It may then have to be rerun. agent does not survive movements. It may then have to be rerun.
(Note that the IPsec security associations themselves are expected (Note that the IPsec security associations themselves are expected
to survive movements.) If manual IPsec configuration is used, the to survive movements.) If manual IPsec configuration is used, the
bit MUST be set to 1. bit MUST be cleared.
This bit is valid only in Binding Updates sent to the home agent, This bit is valid only in Binding Updates sent to the home agent,
and MUST be cleared in other Binding Updates. Correspondent nodes and MUST be cleared in other Binding Updates. Correspondent nodes
MUST ignore this bit. MUST ignore this bit.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
skipping to change at page 61, line 47 skipping to change at page 61, line 47
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
[12, 13]. [12, 13].
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 <xref options MUST use the option format defined in RFC 2461 [12]. This
target='RFC2461'>RFC 2461</xref>. This document defines one option document defines one option which may be carried in a Mobile Prefix
which may be carried in a Mobile Prefix Advertisement message, but Advertisement message, but future documents may define new options.
future documents may define new options. Home agents MUST silently Home agents MUST silently ignore any options they do not recognize
ignore any options they do not recognize and continue processing the and continue processing the message.
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 RFC
2461 [12], with modifications defined in Section 7.2 of this 2461 [12], with modifications defined in Section 7.2 of this
skipping to change at page 70, line 5 skipping to change at page 69, line 38
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.4. returning home, as discussed in Section 11.5.4.
Note that according to RFC 2461 [12], AdvDefaultLifetime is by
default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime
is used in the Router Lifetime field of Router Advertisements. Given
that this field is expressed in seconds, a small MaxRtrAdvInterval
value can result in a zero value for this field. To prevent this,
routers SHOULD keep 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:
o All IPv6 nodes. o All IPv6 nodes.
skipping to change at page 80, line 15 skipping to change at page 80, line 15
is a mobile node that is currently away from home, the packet will be is a mobile node that is currently away from home, the packet will be
intercepted by the mobile node's home agent and tunneled to the intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address. mobile node's current primary care-of address.
9.3.3 Sending Binding Error Messages 9.3.3 Sending Binding Error Messages
Section 9.2 and Section 9.3.1 describe error conditions that lead to Section 9.2 and Section 9.3.1 describe error conditions that lead to
a need to send a Binding Error message. a need to send a Binding Error message.
A Binding Error message is sent directly to the address that appeared A Binding Error message is sent directly to the address that appeared
in the IPv6 Source Address field of the offending packet (before any in the IPv6 Source Address field of the offending packet. If the
modifications possibly performed as specified in Section 9.3.1). If Source Address field does not contain a unicast address, the Binding
the Source Address field does not contain a unicast address, the Error message MUST NOT be sent.
Binding Error message MUST NOT be sent.
The Home Address field in the Binding Error message MUST be copied The Home Address field in the Binding Error message MUST be copied
from the Home Address field in the Home Address destination option of from the Home Address field in the Home Address destination option of
the offending packet, or set to the unspecified address if no such the offending packet, or set to the unspecified address if no such
option appeared in the packet. option appeared in the packet.
Note that the IPv6 Source Address and Home Address field values
discussed above are the values from the wire, i.e., before any
modifications possibly performed as specified in Section 9.3.1.
Binding Error messages SHOULD be subject to rate limiting in the same Binding Error messages SHOULD be subject to rate limiting in the same
manner as is done for ICMPv6 messages [14]. manner as is done for ICMPv6 messages [14].
9.3.4 Receiving ICMP Error Messages 9.3.4 Receiving ICMP Error Messages
When the correspondent node has a Binding Cache entry for a mobile When the correspondent node has a Binding Cache entry for a mobile
node, all traffic destined to the mobile node goes directly to the node, all traffic destined to the mobile node goes directly to the
current care-of address of the mobile node using a routing header. current care-of address of the mobile node using a routing header.
Any ICMP error message caused by packets on their way to the care-of Any ICMP error message caused by packets on their way to the care-of
address will be returned in the normal manner to the correspondent address will be returned in the normal manner to the correspondent
skipping to change at page 149, line 9 skipping to change at page 149, line 9
IPsec can provide anti-replay protection only if dynamic keying is IPsec can provide anti-replay protection only if dynamic keying is
used (which may not always be the case). IPsec also does not used (which may not always be the case). IPsec also does not
guarantee correct ordering of packets, only that they have not been guarantee correct ordering of packets, only that they have not been
replayed. Because of this, sequence numbers within the Mobile IPv6 replayed. Because of this, sequence numbers within the Mobile IPv6
messages are used to ensure correct ordering (see Section 5.1). messages are used to ensure correct ordering (see Section 5.1).
However, if the 16 bit Mobile IPv6 sequence number space is cycled However, if the 16 bit Mobile IPv6 sequence number space is cycled
through, or the home agent reboots and loses its state regarding the through, or the home agent reboots and loses its state regarding the
sequence numbers, replay and reordering attacks become possible. The sequence numbers, replay and reordering attacks become possible. The
use of dynamic keying, IPsec anti-replay protection, and the Mobile use of dynamic keying, IPsec anti-replay protection, and the Mobile
IPv6 sequence numbers can together prevent such attacks. IPv6 sequence numbers can together prevent such attacks. It is also
recommended that use of non-volatile storage is considered for home
agents, to avoid losing their state.
A sliding window scheme is used for the sequence numbers. The A sliding window scheme is used for the sequence numbers. The
protection against replays and reordering attacks without a key protection against replays and reordering attacks without a key
management mechanism works when the attacker remembers up to a management mechanism works when the attacker remembers up to a
maximum of 2**15 Binding Updates. maximum of 2**15 Binding Updates.
The above mechanisms do not show that the care-of address given in The above mechanisms do not show that the care-of address given in
the Binding Update is correct. This opens the possibility for the Binding Update is correct. This opens the possibility for
Denial-of-Service attacks against third parties. However, since the Denial-of-Service attacks against third parties. However, since the
mobile node and home agent have a security association, the home mobile node and home agent have a security association, the home
skipping to change at page 150, line 5 skipping to change at page 150, line 7
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 today are unlikely to cycled through. Typical movement patterns rarely reach this high
reach this high frequency. However, if it is expected that this frequency today.
may happen in a particular deployment scenario, the use of
automated key management is RECOMMENDED.
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 [28], this were not the case, manual keying would not be possible [28],
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
skipping to change at page 150, line 39 skipping to change at page 150, line 39
for each home address served by the home agent. for each home address served by the home agent.
It may be possible to include home addresses in the Subject It may be possible to include home addresses in the Subject
AltName field of certificate to avoid this. However, AltName field of certificate to avoid this. However,
implementations are not guaranteed to support the use of a implementations are not guaranteed to support the use of a
particular IP address (care-of address) while another address particular IP address (care-of address) while another address
(home address) appears in the certificate. In any case, even this (home address) appears in the certificate. In any case, even this
approach would require user-specific tasks in the certificate approach would require user-specific tasks in the certificate
authority. authority.
o Nevertheless, even if per-mobile node configuration is required
even with IKE, an important benefit of IKE is that it automates
the negotiation of cryptographic parameters, including the SPIs,
cryptographic algorithms, and so on. Thus less configuration
information is needed.
o If preshared secret authentication is used, IKEv1 main mode cannot o If preshared secret authentication is used, IKEv1 main mode cannot
be used. Aggressive mode or group preshared secrets need to be be used. Aggressive mode or group preshared secrets need to be
used instead, with corresponding security implications. used instead, with corresponding security implications.
Note that like many other issues, this is a general IKEv1 issue Note that like many other issues, this is a general IKEv1 issue
related to the ability to use different IP addresses, and not related to the ability to use different IP addresses, and not
specifically related to Mobile IPv6. For further information, see specifically related to Mobile IPv6. For further information, see
Section 4.4 in [21]. Section 4.4 in [21].
o Due to the problems outlined in Section 11.3.2, IKE phase 1 o Due to the problems outlined in Section 11.3.2, IKE phase 1
skipping to change at page 151, line 18 skipping to change at page 151, line 9
the mobile node's current care-of address. This implies that when the mobile node's current care-of address. This implies that when
the mobile node moves to a new location, it may have to the mobile node moves to a new location, it may have to
re-establish phase 1. A Key Management Mobility Capability (K) re-establish phase 1. A Key Management Mobility Capability (K)
flag is provided for implementations that can update the IKE phase flag is provided for implementations that can update the IKE phase
1 endpoints without re-establishing phase 1, but the support for 1 endpoints without re-establishing phase 1, but the support for
this behavior is optional. this behavior is optional.
o When certificates are used, IKE fragmentation can occur as o When certificates are used, IKE fragmentation can occur as
discussed in Section 7 in [21]. discussed in Section 7 in [21].
o Nevertheless, even if per-mobile node configuration is required
even with IKE, an important benefit of IKE is that it automates
the negotiation of cryptographic parameters, including the SPIs,
cryptographic algorithms, and so on. Thus less configuration
information is needed.
o The frequency of movements in some link layers or deployment
scenarios may be high enough to make replay and reordering attacks
possible, if only manual keying is used. IKE SHOULD be used in
such cases. Potentially vulnerable scenarios involve continuous
movement through small cells, or uncontrolled alternation between
available network attachment points.
o Similarly, in some deployment scenarios the number of mobile nodes
may be very large. It these cases it can be necessary to use
automatic mechanisms to reduce the management effort in the
administration of cryptographic parameters, even if some
per-mobile node configuration is always needed. IKE SHOULD also
be 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
[30] as well, at least as it is currently specified. [30] 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
skipping to change at page 166, line 9 skipping to change at page 167, line 9
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Appendix A. Changes from Previous Version of the Draft Appendix A. Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this draft This appendix briefly lists some of the major changes in this draft
relative to the previous version of this same draft, relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-21.txt: draft-ietf-mobileip-ipv6-22.txt:
o The required policy checks for protecting return routability
packets have been clarified; the language now allows different
implementations as long as the end result is the same (tracked
issue 306).
o The specification no longer discusses the differences of using
randomly generated and EUI-64 based interface identifiers for
link-local addresses while away from home (tracked issue 302).
o The rules for treating IKE cookies when using the Key Management
Capability (K) flag have been specified in Section 10.3.1 (tracked
issue 298).
o Section 6.2.7 now makes it clear why the home address does not
need to be a part of the formula for calculating the MAC; the home
address is taken in account in the construction of the keygen
tokens (tracked issue 298).
o The security considerations discuss the need for payload packet
protection in more depth than previously. In particular, the use
of payload packet protection is now recommended when communicating
with hosts in a home network protected with some form of perimeter
defense (tracked issue 298).
o The rules for treating IKE cookies when using the Key Management
Capability (K) flag have been specified in Section 10.3.1 (tracked
issue 298).
o Section 11.5.1 has been rewritten as a collection of hints about
movement or the lack thereof. Appropriate actions are specified
for each of the received hints (tracked issue 297).
o Section 11.5.1 no longer claims that tracking of inbound traffic
from the router ensures symmetric reachability (tracked issue
297).
o The specific mechanisms for tracking inbound reachability when not
sending any traffic have been moved outside this document (tracked
issue 297).
o The return routability MAC calculation formula has been aligned
between Section 5.2.6 and Section 6.2.7 (tracked issue 293).
o It is now required that nodes may not implement the Home Address
option or type 2 Routing header without conforming to all requires
in Section 8.2 (tracked issue 290).
o Section 9.5.1 now clearly specifies in which order the various
checks on Binding Updates must be performed before the update of
the sequence number can take place (tracked issue 290).
o It is now required that when sending packets to a correspondent
node using route optimization, mobile nodes use the same care-of
address which has been registered by the correspondent node as the
current location of the mobile node (tracked issue 289).
o The administrative capability for disabling route optimization is
now a SHOULD, not a MUST (tracked issue 289).
o The aggregate list of prefixes on the home network has been
replaced with the home agent's own AdvPrefixList and a
recommendation that the home agents be configured with the same
prefixes (tracked issue 289).
o It is now required that the mobile node MUST NOT use the Home
Address destination option for IPv6 Neighbor Discovery packets
(tracked issue 289).
o Section 11.7.2 now excludes any return routability related message
from initiating the need to update a binding (tracked issue 289).
o Section 11.7.2 no longer discusses what to do when the
correspondent node has a stale Binding Cache entry, because in
most cases this cannot be detected (tracked issue 289).
o Section 11.7.3 has been clarified to explain that after receiving
a Status value 128 or larger, the mobile node node should take
steps to correct the problem, and only if this fails it should
avoid resending Binding Updates (tracked issue 289).
o The events causing a Mobile Prefix Advertisement to be sent have
been clarified to not include prefix lifetime changes due to
passing of real-time (tracked issue 289).
o Section 15.4 and Section 15.4.6 discuss separately on-path attacks
and blind guessing of keygen tokens (tracked issue 288).
o The document now has an extensive discussion of the implications
of either using or not using IKE (tracked issue 282).
o A timeout mechanism has been specified for peers marked as not
supporting the Mobility Header protocol (tracked issue 281).
o The document now explicitly mentions that multiple home addresses
are supported (tracked issue 281).
o Mobile nodes are now allowed to respond to all Neighbor
Solicitations on the home link while waiting for a Binding
Acknowledgement from their home agent, as the Solicitations from
home agent cannot be distinguished from other Solicitations
(tracked issue 279).
o Section 11.5.1 takes in account that the link-local addresses of
two routers on different links can be equal. To counteract the
effect of this for movement detection, home agents are required to
send consistent information about their global address through the
Router Address (R) flag in Router Advertisements, and mobile nodes
track these addresses as well as the source address of the
advertisement when doing movement detection (tracked issue 278).
o The treatment of the Home registration (H) flag and the existence
of mobility options related to return routability has been
clarified. The options for return routability are must be present
if and only if the flag is zero (tracked issue 277).
o The sequence number example in Section 9.5.1 has been corrected
(tracked issue 276).
o ICMPv6 Parameter Problem and Binding Error messages are now sent
without a Binding Cache lookup (tracked issue 273).
o A new Binding Acknowledgment Status value 139 (Registration type
change disallowed) has been added to report an error where the
mobile node tries to change a home registration to a correspondent
registration, or vice versa (tracked issue 273).
o The use of Home Address destination option, type 2 Routing header, o A new set of rules regarding the use of automatic or manual key
and Binding Cache lookups has been clarified for all Mobility management has been provided (tracked issue 313).
Header messages in Section 6.1 (tracked issue 269).
o Looping Binding Cache entries are now forbidden (tracked issue o Rules regarding the use of the Key Management Capability (K) bit
268). have been corrected for the manual keying case (tracked issue
310).
o A number of editorial modifications have been performed (tracked o The specification now requires that a small MaxRtrAdvertisement
issues 267, 280, 283, 289, 290, 301, and 304). value should not lead to a router lifetime value under one second
(tracked issue 308).
Appendix B. Future Extensions Appendix B. Future Extensions
B.1 Piggybacking B.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 currently discussed can be specified in a separate document when currently discussed
issues such as the interaction between piggybacking and IPsec are issues such as the interaction between piggybacking and IPsec are
fully resolved (see also Appendix B.3). The return routability fully resolved (see also Appendix B.3). The return routability
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/