draft-ietf-mobileip-ipv6-11.txt   draft-ietf-mobileip-ipv6-12.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Carnegie Mellon University INTERNET-DRAFT Carnegie Mellon University
Charles Perkins Charles Perkins
Nokia Nokia
10 March 2000 27 April 2000
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-11.txt> <draft-ietf-mobileip-ipv6-12.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 RFC 2026. all provisions of Section 10 of RFC 2026.
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 Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 67 skipping to change at page 1, line 67
2. Comparison with Mobile IP for IPv4 3 2. Comparison with Mobile IP for IPv4 3
3. Terminology 6 3. Terminology 6
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7
3.3. Specification Language . . . . . . . . . . . . . . . . . 8 3.3. Specification Language . . . . . . . . . . . . . . . . . 8
4. Overview of Mobile IPv6 9 4. Overview of Mobile IPv6 9
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9
4.2. New IPv6 Destination Options and ICMP Messages . . . . . 11 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11
4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 14 4.3. Alignment Requirements for New Destination Options . . . 13
4.4. Binding Management . . . . . . . . . . . . . . . . . . . 18 4.4. IPsec Requirements for New Destination Options . . . . . 13
4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14
4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 14
4.7. Binding Management . . . . . . . . . . . . . . . . . . . 19
5. New IPv6 Destination Options and Message Types 20 5. New IPv6 Destination Options and Message Types 21
5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 20 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 21
5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25
5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29
5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 33 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 34
5.6. ICMP Home Agent Address Discovery Request Message . . . . 36 5.6. ICMP Home Agent Address Discovery Request Message . . . . 37
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 38 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 39
6. Modifications to IPv6 Neighbor Discovery 40 6. Modifications to IPv6 Neighbor Discovery 41
6.1. Modified Router Advertisement Message Format . . . . . . 40 6.1. Modified Router Advertisement Message Format . . . . . . 41
6.2. Modified Prefix Information Option Format . . . . . . . . 41 6.2. Modified Prefix Information Option Format . . . . . . . . 42
6.3. New Advertisement Interval Option Format . . . . . . . . 43 6.3. New Advertisement Interval Option Format . . . . . . . . 44
6.4. New Home Agent Information Option Format . . . . . . . . 44 6.4. New Home Agent Information Option Format . . . . . . . . 45
6.5. Changes to Sending Router Advertisements . . . . . . . . 46 6.5. Changes to Sending Router Advertisements . . . . . . . . 47
6.6. Changes to Sending Router Solicitations . . . . . . . . . 47 6.6. Changes to Sending Router Solicitations . . . . . . . . . 48
7. Requirements for IPv6 Nodes 49 7. Requirements for IPv6 Nodes 50
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 49 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 50
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 49 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 50
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 49 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 50
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 50 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 51
8. Correspondent Node Operation 52 8. Correspondent Node Operation 53
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 52 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 53
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 52 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 53
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 53 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 54
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 54 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 55
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 54 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 55
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 54 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 55
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 55 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 56
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 56 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 57
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 57 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 58
9. Home Agent Operation 59 9. Home Agent Operation 60
9.1. Receiving Router Advertisement Messages . . . . . . . . . 59 9.1. Receiving Router Advertisement Messages . . . . . . . . . 60
9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 60 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 61
9.3. Primary Care-of Address Registration . . . . . . . . . . 62 9.3. Primary Care-of Address Registration . . . . . . . . . . 63
9.4. Primary Care-of Address De-registration . . . . . . . . . 64 9.4. Primary Care-of Address De-registration . . . . . . . . . 65
9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 65 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 66
9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 67 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 68
9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 68 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 69
10. Mobile Node Operation 71 10. Mobile Node Operation 73
10.1. Sending Packets While Away from Home . . . . . . . . . . 71 10.1. Sending Packets While Away from Home . . . . . . . . . . 73
10.2. Interaction with Outbound IPsec Processing . . . . . . . 72 10.2. Interaction with Outbound IPsec Processing . . . . . . . 74
10.3. Receiving Packets While Away from Home . . . . . . . . . 74 10.3. Receiving Packets While Away from Home . . . . . . . . . 76
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 75 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 77
10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 78 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 80
10.6. Sending Binding Updates to the Home Agent . . . . . . . . 79 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 82
10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 80 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 83
10.8. Sending Binding Updates to Correspondent Nodes . . . . . 81 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 84
10.9. Establishing Forwarding from a Previous Care-of Address . 84 10.9. Establishing Forwarding from a Previous Care-of Address . 87
10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 85 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 88
10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 85 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 88
10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 86 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 89
10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 86 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 90
10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 87 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 90
10.15. Receiving Local Router Advertisement Messages . . . . . . 87 10.15. Receiving Local Router Advertisement Messages . . . . . . 91
10.16. Receiving Tunneled Router Advertisements . . . . . . . . 89 10.16. Receiving Tunneled Router Advertisements . . . . . . . . 92
10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 90 10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 93
10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 91 10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 94
10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 91 10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 95
11. Protocol Constants 94 11. Protocol Constants 97
12. IANA Considerations 95 12. IANA Considerations 98
13. Security Considerations 96 13. Security Considerations 99
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 96 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 99
13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 96 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 99
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 97 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 100
Changes from Previous Version of the Draft 99 Changes from Previous Version of the Draft 102
Acknowledgements 100 Acknowledgements 105
References 101 References 106
Chair's Address 103 Chair's Address 108
Authors' Addresses 104 Authors' Addresses 109
1. Introduction 1. Introduction
This document specifies the operation of mobile computers using This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support Internet Protocol Version 6 (IPv6) [6]. Without specific support
for mobility in IPv6, packets destined to a mobile node (host or for mobility in IPv6, packets destined to a mobile node (host or
router) would not be able to reach it while the mobile node is away router) would not be able to reach it while the mobile node is away
from its home link (the link on which its home IPv6 subnet prefix is from its home link (the link on which its home IPv6 subnet prefix is
in use), since routing is based on the subnet prefix in a packet's in use), since routing is based on the subnet prefix in a packet's
destination IP address. In order to continue communication in spite destination IP address. In order to continue communication in spite
skipping to change at page 11, line 41 skipping to change at page 11, line 41
non-mobile nodes. By also including the Home Address option in each non-mobile nodes. By also including the Home Address option in each
packet, the sending mobile node can communicate its home address to packet, the sending mobile node can communicate its home address to
the correspondent node receiving this packet, allowing the use of the correspondent node receiving this packet, allowing the use of
the care-of address to be transparent above the Mobile IPv6 support the care-of address to be transparent above the Mobile IPv6 support
level (e.g., at the transport layer). The inclusion of a Home level (e.g., at the transport layer). The inclusion of a Home
Address option in a packet affects only the correspondent node's Address option in a packet affects only the correspondent node's
receipt of this single packet; no state is created or modified in the receipt of this single packet; no state is created or modified in the
correspondent node as a result of receiving a Home Address option in correspondent node as a result of receiving a Home Address option in
a packet. a packet.
4.2. New IPv6 Destination Options and ICMP Messages 4.2. New IPv6 Destination Options
As discussed in general in Section 4.1, the following four new IPv6 As discussed in general in Section 4.1, the following four new IPv6
destination options are defined for Mobile IPv6: destination options are defined for Mobile IPv6:
Binding Update Binding Update
A Binding Update option is used by a mobile node to notify A Binding Update option is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked home agent to register its primary care-of address is marked
as a "home registration". Any packet that includes a Binding as a "home registration". Any packet that includes a Binding
Update option MUST be protected by IPsec [13] to guard against Update option MUST be protected by IPsec [13], as defined in
malicious Binding Updates. The Binding Update option and Section 4.4, to guard against malicious Binding Updates. The
its specific IPsec requirements are described in detail in Binding Update option and its specific IPsec requirements are
Section 5.1. described in detail in Section 5.1.
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement option is used to acknowledge receipt A Binding Acknowledgement option is used to acknowledge receipt
of a Binding Update, if an acknowledgement was requested of a Binding Update, if an acknowledgement was requested
in the Binding Update. Any packet that includes a Binding in the Binding Update. Any packet that includes a Binding
Acknowledgement option MUST be protected by IPsec [13] to Acknowledgement option MUST be protected by IPsec [13], as
guard against malicious Binding Acknowledgements. The Binding defined in Section 4.4, to guard against malicious Binding
Acknowledgement option and its specific IPsec requirements are Acknowledgements. The Binding Acknowledgement option and
described in detail in Section 5.2. its specific IPsec requirements are described in detail in
Section 5.2.
Binding Request Binding Request
A Binding Request option is used to request a mobile node to A Binding Request option is used to request a mobile node to
send to the requesting node a Binding Update containing the send to the requesting node a Binding Update containing the
mobile node's current binding. This option is typically used mobile node's current binding. This option is typically used
by a correspondent node to refresh a cached binding for a by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication binding's lifetime is close to expiration. No authentication
is required for the Binding Request option. The Binding is required for the Binding Request option. The Binding
skipping to change at page 12, line 47 skipping to change at page 12, line 48
correspondent node receiving the packet is able to substitute correspondent node receiving the packet is able to substitute
the mobile node's home address for this care-of address when the mobile node's home address for this care-of address when
processing the packet, thus making the use of the care-of processing the packet, thus making the use of the care-of
address transparent to the correspondent node. If the IP address transparent to the correspondent node. If the IP
header of a packet carrying a Home Address option is covered header of a packet carrying a Home Address option is covered
by authentication, then the Home Address option MUST also be by authentication, then the Home Address option MUST also be
covered by this authentication, but no other authentication is covered by this authentication, but no other authentication is
required for the Home Address option. The Home Address option required for the Home Address option. The Home Address option
is described in detail in Section 5.4. is described in detail in Section 5.4.
Sub-options within the format of these options MAY be included after Mobile IPv6 also defines a number of "sub-options" for use within
the fixed portion of the option data specified in this document. The these destination options; if included, any sub-options MUST
presence of such sub-options will be indicated by the Option Length appear after the fixed portion of the option data specified in this
field within the option. When the Option Length is greater than the document. The presence of such sub-options will be indicated by the
length required for the option specified here, the remaining octets Option Length field within the option. When the Option Length is
are interpreted as sub-options. The encoding and format of defined greater than the length required for the option specified here, the
sub-options are described in Section 5.5. remaining octets are interpreted as sub-options. The encoding and
format of defined sub-options are described in Section 5.5.
4.3. Alignment Requirements for New Destination Options
IPv6 requires that options appearing in a Hop-by-Hop Options IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple of n octets from the start of the header, at an integer multiple of n octets from the start of the header,
for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within the alignment requirements, so that multi-octet values within the
Sub-Option Data field of each sub-option fall on natural boundaries. Sub-Option Data field of each sub-option fall on natural boundaries.
The alignment requirement of an option or sub-option is specified in The alignment requirement of an option or sub-option is specified in
skipping to change at page 13, line 25 skipping to change at page 13, line 29
alignment requirements [6]. Specifically, the notation xn+y means alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets. multiple of x octets from the start of the header, plus y octets.
For example: For example:
2n means any 2-octet offset from the start of the header. 2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header, 8n+2 means any 8-octet offset from the start of the header,
plus 2 octets. plus 2 octets.
4.4. IPsec Requirements for New Destination Options
Any packet that includes a Binding Update or Binding Acknowledgement
option MUST be protected by IPsec [13] to guard against malicious
Binding Updates or Acknowledgements. Specifically, any packet that
includes a Binding Update or Binding Acknowledgement option MUST
utilize IPsec sender authentication, data integrity protection, and
replay protection.
Currently, Mobile IPv6 requires that this protection covering a
Binding Update or Binding Acknowledgement MUST be provided by use
of AH [11]. If another Security Association applied to the packet
for other reasons requires use of ESP [12], for example to encrypt
the transport layer data carried in the packet, this use of ESP
is not sufficient to satisfy the authentication requirements of
Mobile IPv6; instead, the packet MUST use both AH and ESP. Use of
ESP for protecting the Binding Update or Binding Acknowledgement is
not currently defined in this document, since ESP does not protect
the portion of the packet above the ESP header itself [12].
4.5. New IPv6 ICMP Messages
Mobile IPv6 also introduces two new ICMP message types, for use in Mobile IPv6 also introduces two new ICMP message types, for use in
the dynamic home agent address discovery mechanism. As discussed in the dynamic home agent address discovery mechanism. As discussed in
general in Section 4.1, the following two new ICMP message types are general in Section 4.1, the following two new ICMP message types are
used: used:
Home Agent Address Discovery Request Home Agent Address Discovery Request
The ICMP Home Agent Address Discovery Request message is used The ICMP Home Agent Address Discovery Request message is used
by a mobile node to initiate the dynamic home agent address by a mobile node to initiate the dynamic home agent address
discovery mechanism. When attempting a home registration, the discovery mechanism. When attempting a home registration, the
skipping to change at page 14, line 5 skipping to change at page 14, line 34
The ICMP Home Agent Address Discovery Reply message is used by The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.7. described in detail in Section 5.7.
4.3. Conceptual Data Structures 4.6. Conceptual Data Structures
This document describes the Mobile IPv6 protocol in terms of the This document describes the Mobile IPv6 protocol in terms of the
following three conceptual data structures: following three conceptual data structures:
Binding Cache Binding Cache
A cache, maintained by each IPv6 node, of bindings for other A cache, maintained by each IPv6 node, of bindings for other
nodes. The Binding Cache MAY be implemented in any manner nodes. The Binding Cache MAY be implemented in any manner
consistent with the external behavior described in this consistent with the external behavior described in this
document, for example by being combined with the node's document, for example by being combined with the node's
skipping to change at page 15, line 14 skipping to change at page 15, line 45
Cache entry indicates that this is a "home registration" Cache entry indicates that this is a "home registration"
entry. entry.
- The value of the Prefix Length field received in the - The value of the Prefix Length field received in the
Binding Update that created or last modified this Binding Binding Update that created or last modified this Binding
Cache entry. This field is only valid if the "home Cache entry. This field is only valid if the "home
registration" flag is set on this Binding Cache entry. registration" flag is set on this Binding Cache entry.
- The maximum value of the Sequence Number field received - The maximum value of the Sequence Number field received
in previous Binding Updates for this mobile node home in previous Binding Updates for this mobile node home
address. The Sequence Number field is 16 bits long, and address. The Sequence Number field is 16 bits long,
all comparisons between Sequence Number values MUST be and all comparisons between Sequence Number values
performed modulo 2**16. MUST be performed modulo 2**16. For example, using an
implementation in the C programming language, a Sequence
Number value A is greater than another Sequence Number
value B if ((short)((a) - (b)) > 0), if a "short" data type
is a 16-bit signed integer.
- Recent usage information for this Binding Cache entry, as - Recent usage information for this Binding Cache entry, as
needed to implement the cache replacement policy in use in needed to implement the cache replacement policy in use in
the Binding Cache and to assist in determining whether a the Binding Cache and to assist in determining whether a
Binding Request should be sent when the lifetime on this Binding Request should be sent when the lifetime on this
entry nears expiration. entry nears expiration.
- The time at which a Binding Request was last sent for this - The time at which a Binding Request was last sent for this
entry, as needed to implement the rate limiting restriction entry, as needed to implement the rate limiting restriction
for sending Binding Requests. for sending Binding Requests.
skipping to change at page 15, line 47 skipping to change at page 16, line 31
Address option in a received packet. Address option in a received packet.
Binding Update List Binding Update List
A list, maintained by each mobile node, recording information A list, maintained by each mobile node, recording information
for each Binding Update sent by this mobile node, for which the for each Binding Update sent by this mobile node, for which the
Lifetime sent in that Binding Update has not yet expired. The Lifetime sent in that Binding Update has not yet expired. The
Binding Update List includes all bindings sent by the mobile Binding Update List includes all bindings sent by the mobile
node: those to correspondent nodes, those to the mobile node's node: those to correspondent nodes, those to the mobile node's
home agent, and those to a home agent on the link on which the home agent, and those to a home agent on the link on which the
mobile node's previous care-of address is located. The Binding mobile node's previous care-of address is located. However,
Update List MAY be implemented in any manner consistent with for multiple Binding Updates sent to the same destination
the external behavior described in this document. Each Binding address, the Binding Update List contains only the most recent
Update List entry conceptually contains the following fields: Binding Update (i.e., with the greatest Sequence Number value)
sent to that destination. The Binding Update List MAY be
implemented in any manner consistent with the external behavior
described in this document. Each Binding Update List entry
conceptually contains the following fields:
- The IP address of the node to which a Binding Update was - The IP address of the node to which a Binding Update was
sent. This node might still have a Binding Cache entry sent. This node might still have a Binding Cache entry
created or updated from this Binding Update, if the Binding created or updated from this Binding Update, if the Binding
Update was successfully received by that node (e.g., not Update was successfully received by that node (e.g., not
lost by the network) and if that node has not deleted the lost by the network) and if that node has not deleted the
entry before its expiration (e.g., to reclaim space in its entry before its expiration (e.g., to reclaim space in its
Binding Cache for other entries). Binding Cache for other entries).
- The home address for which that Binding Update was sent. - The home address for which that Binding Update was sent.
skipping to change at page 16, line 22 skipping to change at page 17, line 10
most Binding Updates (Sections 10.6 and 10.8), but will most Binding Updates (Sections 10.6 and 10.8), but will
be the mobile node's previous care-of address for Binding be the mobile node's previous care-of address for Binding
Updates sent to to establish forwarding from by a home Updates sent to to establish forwarding from by a home
agent from this previous care-of address (Section 10.9). agent from this previous care-of address (Section 10.9).
- The care-of address sent in that Binding Update. This - The care-of address sent in that Binding Update. This
value is necessary for the mobile node to determine if it value is necessary for the mobile node to determine if it
has sent a Binding Update giving its new care-of address to has sent a Binding Update giving its new care-of address to
this destination after changing its care-of address. this destination after changing its care-of address.
- The initial value of the Lifetime field sent in that
Binding Update.
- The remaining lifetime of that binding. This lifetime is - The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding initialized from the Lifetime value sent in the Binding
Update and is decremented until it reaches zero, at which Update and is decremented until it reaches zero, at which
time this entry MUST be deleted from the Binding Update time this entry MUST be deleted from the Binding Update
List. List.
- The maximum value of the Sequence Number field sent in - The maximum value of the Sequence Number field sent in
previous Binding Updates to this destination. The Sequence previous Binding Updates to this destination. The Sequence
Number field is 16 bits long, and all comparisons between Number field is 16 bits long, and all comparisons between
Sequence Number values MUST be performed modulo 2**16. Sequence Number values MUST be performed modulo 2**16.
For example, using an implementation in the C programming
language, a Sequence Number value A is greater than another
Sequence Number value B if ((short)((a) - (b)) > 0), if a
"short" data type is a 16-bit signed integer.
- The time at which a Binding Update was last sent to this - The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting destination, as needed to implement the rate limiting
restriction for sending Binding Updates. restriction for sending Binding Updates.
- The state of any retransmissions needed for this Binding - The state of any retransmissions needed for this Binding
Update, if the Acknowledge (A) bit was set in this Binding Update, if the Acknowledge (A) bit was set in this Binding
Update. This state includes the time remaining until the Update. This state includes the time remaining until the
next retransmission attempt for the Binding Update, and the next retransmission attempt for the Binding Update, and the
current state of the exponential back-off mechanism for current state of the exponential back-off mechanism for
skipping to change at page 18, line 21 skipping to change at page 19, line 11
Advertisement, if the Router Advertisement contains a Home Advertisement, if the Router Advertisement contains a Home
Agent Information Option, and is otherwise set to the Agent Information Option, and is otherwise set to the
default value of 0. A home agent uses this preference in default value of 0. A home agent uses this preference in
ordering the Home Agents List returned in an ICMP Home ordering the Home Agents List returned in an ICMP Home
Agent Address Discovery message in response to a mobile Agent Address Discovery message in response to a mobile
node's initiation of dynamic home agent address discovery. node's initiation of dynamic home agent address discovery.
A mobile node uses this preference in determining which A mobile node uses this preference in determining which
of the home agents on its previous link to notify when it of the home agents on its previous link to notify when it
moves to a new link. moves to a new link.
4.4. Binding Management 4.7. Binding Management
When a mobile node configures a new care-of address and decides to When a mobile node configures a new care-of address and decides to
use this new address as its primary care-of address, the mobile use this new address as its primary care-of address, the mobile
node registers this new binding with its home agent by sending node registers this new binding with its home agent by sending
the home agent a Binding Update. The mobile node indicates the home agent a Binding Update. The mobile node indicates
that an acknowledgement is needed for this Binding Update and that an acknowledgement is needed for this Binding Update and
continues to periodically retransmit it until acknowledged. The continues to periodically retransmit it until acknowledged. The
home agent acknowledges the Binding Update by returning a Binding home agent acknowledges the Binding Update by returning a Binding
Acknowledgement to the mobile node. Acknowledgement to the mobile node.
skipping to change at page 21, line 29 skipping to change at page 22, line 29
The Duplicate Address Detection (D) bit is set by the sending The Duplicate Address Detection (D) bit is set by the sending
mobile node to request the receiving node (the mobile node's mobile node to request the receiving node (the mobile node's
home agent) to perform Duplicate Address Detection [27] on home agent) to perform Duplicate Address Detection [27] on
the mobile node's home link for the home address in this the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H) binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. If the Duplicate Address Detection performed by otherwise. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection Acknowledgement will be set to 138 (Duplicate Address Detection
failed). failed). The mobile node SHOULD set the Duplicate Address
Detection (D) bit based on any requirements for Duplicate
Address Detection that would apply to the mobile node if it
were at home [17, 27].
Reservd Reservd
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.
Prefix Length Prefix Length
The Prefix Length field is valid only for a "home registration" The Prefix Length field is valid only for a "home registration"
Binding Update; this field MUST be zero if the Home Binding Update; this field MUST be zero if the Home
skipping to change at page 22, line 7 skipping to change at page 23, line 10
the mobile node on the home link. The home agent becomes the the mobile node on the home link. The home agent becomes the
home agent not only for the individual home address given in home agent not only for the individual home address given in
this binding, but also for all other home addresses for this this binding, but also for all other home addresses for this
mobile node formed from this interface identifier. That is, mobile node formed from this interface identifier. That is,
for each on-link prefix on the home link, the home agent uses for each on-link prefix on the home link, the home agent uses
the interface identifier to form other valid addresses for the interface identifier to form other valid addresses for
the mobile node on the home link, and acts as a home agent the mobile node on the home link, and acts as a home agent
also for those addresses. In addition, the home agent forms also for those addresses. In addition, the home agent forms
the link-local address and site-local address corresponding the link-local address and site-local address corresponding
to this interface identifier, and defends each for purposes to this interface identifier, and defends each for purposes
of Duplicate Address Detection; the home agent also performs of Duplicate Address Detection. The home agent also performs
Duplicate Address Detection on each such address as part of Duplicate Address Detection on each such address as part of
the home registration processing, if the Duplicate Address the home registration processing (before returning the Binding
Detection (D) bit is set in the Binding Update. Details of Acknowledgement), if the Duplicate Address Detection (D) bit
this operation are described in Section 9.3. is set in the Binding Update. Details of this operation are
described in Section 9.3.
Sequence Number Sequence Number
Used by the receiving node to sequence Binding Updates and by Used by the receiving node to sequence Binding Updates and by
the sending node to match a returned Binding Acknowledgement the sending node to match a returned Binding Acknowledgement
with this Binding Update. Each Binding Update sent by a mobile with this Binding Update. Each Binding Update sent by a mobile
node MUST use a Sequence Number greater than the Sequence node MUST use a Sequence Number greater than the Sequence
Number value sent in the previous Binding Update (if any) to Number value sent in the previous Binding Update (if any) to
the same destination address (modulo 2**16). There is no the same destination address (modulo 2**16, as defined in
requirement, however, that the Sequence Number value strictly Section overview:data). There is no requirement, however, that
increase by 1 with each new Binding Update sent or received. the Sequence Number value strictly increase by 1 with each new
Binding Update sent or received.
Lifetime Lifetime
32-bit unsigned integer. The number of seconds remaining 32-bit unsigned integer. The number of seconds remaining
before the binding must be considered expired. A value of all before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node indicates that the Binding Cache entry for the mobile node MUST
should be deleted. be deleted.
Sub-Options Sub-Options
Additional information, associated with this Binding Update Additional information, associated with this Binding Update
option, that need not be present in all Binding Updates sent. option, that need not be present in all Binding Updates sent.
This use of sub-options also allows for future extensions to This use of sub-options also allows for future extensions to
the format of the Binding Update option to be defined. The the format of the Binding Update option to be defined. The
encoding and format of defined sub-options are described in encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding Section 5.5. The following sub-options are valid in a Binding
Update option: Update option:
skipping to change at page 23, line 13 skipping to change at page 24, line 18
Address field in the Home Address option in the packet. Address field in the Home Address option in the packet.
The care-of address for the binding given in the Binding Update The care-of address for the binding given in the Binding Update
option is normally specified by the Source Address field in the IPv6 option is normally specified by the Source Address field in the IPv6
header of the packet carrying the Binding Update option. However, a header of the packet carrying the Binding Update option. However, a
care-of address different from the Source Address MAY be specified care-of address different from the Source Address MAY be specified
by including an Alternate Care-of Address sub-option in the Binding by including an Alternate Care-of Address sub-option in the Binding
Update option. Update option.
Any packet that includes a Binding Update option MUST be protected by Any packet that includes a Binding Update option MUST be protected by
IPsec [13] to guard against malicious Binding Updates. Specifically, IPsec [13] to guard against malicious Binding Updates. The specific
any packet that includes a Binding Update option MUST utilize requirements for this protection are defined in Section 4.4.
IPsec sender authentication, data integrity protection, and replay
protection. Currently, Mobile IPv6 requires that this protection
covering a Binding Update MUST be provided by use of AH [11]; if
another Security Association applied to the packet for other reasons
requires use of ESP [12], the packet MUST use both AH and ESP. Use
of ESP for protecting the Binding Update is not currently defined in
this document, since ESP does not protect the portion of the packet
above the ESP header itself.
If the care-of address for the binding (specified either in an If the care-of address for the binding (specified either in an
Alternate Care-of Address sub-option in the Binding Update option, if Alternate Care-of Address sub-option in the Binding Update option, if
present, or in the Source Address field in the packet's IPv6 header) present, or in the Source Address field in the packet's IPv6 header)
is equal to the home address of the mobile node, the Binding Update is equal to the home address of the mobile node, the Binding Update
option indicates that any existing binding for the mobile node MUST option indicates that any existing binding for the mobile node MUST
be deleted. Likewise, if the Lifetime field in the Binding Update be deleted. Likewise, if the Lifetime field in the Binding Update
option is equal to 0, the Binding Update option indicates that any option is equal to 0, the Binding Update option indicates that any
existing binding for the mobile node MUST be deleted. In each of existing binding for the mobile node MUST be deleted. In each of
these cases, a Binding Cache entry for the mobile node MUST NOT be these cases, a Binding Cache entry for the mobile node MUST NOT be
skipping to change at page 27, line 35 skipping to change at page 27, line 35
option to be defined. The encoding and format of defined option to be defined. The encoding and format of defined
sub-options are described in Section 5.5. Currently, no valid sub-options are described in Section 5.5. Currently, no valid
sub-options are defined for in a Binding Acknowledgement sub-options are defined for in a Binding Acknowledgement
option. option.
The alignment requirement [6] for the Binding Acknowledgement option The alignment requirement [6] for the Binding Acknowledgement option
is 4n+3. is 4n+3.
Any packet that includes a Binding Acknowledgement option MUST Any packet that includes a Binding Acknowledgement option MUST
be protected by IPsec [13] to guard against malicious Binding be protected by IPsec [13] to guard against malicious Binding
Acknowledgements. Specifically, any packet that includes a Binding Acknowledgements. The specific requirements for this protection are
Acknowledgement option MUST utilize IPsec sender authentication, data defined in Section 4.4.
integrity protection, and replay protection. Currently, Mobile IPv6
requires that this protection covering a Binding Acknowledgement
MUST be provided by use of AH [11]; if another Security Association
applied to the packet for other reasons requires use of ESP [12],
the packet MUST use both AH and ESP. Use of ESP for protecting the
Binding Acknowledgement is not currently defined in this document,
since ESP does not protect the portion of the packet above the ESP
header itself.
If the node returning the Binding Acknowledgement accepted the If the node returning the Binding Acknowledgement accepted the
Binding Update for which the Acknowledgement is being returned (the Binding Update for which the Acknowledgement is being returned (the
value of the Status field in the Acknowledgement is less than 128), value of the Status field in the Acknowledgement is less than 128),
this node will have an entry for the mobile node in its Binding Cache this node will have an entry for the mobile node in its Binding Cache
and MUST use this entry (which includes the care-of address received and MUST use this entry (which includes the care-of address received
in the Binding Update) in sending the packet containing the Binding in the Binding Update) in sending the packet containing the Binding
Acknowledgement to the mobile node. The details of sending this Acknowledgement to the mobile node. The details of sending this
packet to the mobile node are the same as for sending any packet to a packet to the mobile node are the same as for sending any packet to a
mobile node using a binding, and are described in Section 8.9. The mobile node using a binding, and are described in Section 8.9. The
skipping to change at page 32, line 46 skipping to change at page 32, line 46
Upon receipt of a packet containing a Home Address option, the Upon receipt of a packet containing a Home Address option, the
receiving node replaces the Source Address in the IPv6 header with receiving node replaces the Source Address in the IPv6 header with
the Home Address in the Home Address option. By requiring that any the Home Address in the Home Address option. By requiring that any
authentication of the IPv6 header also cover the Home Address option, authentication of the IPv6 header also cover the Home Address option,
the security of the Source Address field in the IPv6 header is not the security of the Source Address field in the IPv6 header is not
compromised by the presence of a Home Address option. Security compromised by the presence of a Home Address option. Security
issues related to the Home Address option are discussed further in issues related to the Home Address option are discussed further in
Section 13. Section 13.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] MAY contain a separate Home Address
option associated with each encapsulating IP header.
The three highest-order bits of the Option Type are encoded to The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Home Address indicate specific processing of the option [6]. For the Home Address
option, these three bits are set to 110, indicating that any IPv6 option, these three bits are set to 110, indicating that any IPv6
node processing this option that does not recognize the Option Type node processing this option that does not recognize the Option Type
must discard the packet and, only if the packet's Destination Address must discard the packet and, only if the packet's Destination Address
was not a multicast address, return an ICMP Parameter Problem, was not a multicast address, return an ICMP Parameter Problem,
Code 2, message to the packet's Source Address; and that the data Code 2, message to the packet's Source Address; and that the data
within the option cannot change en-route to the packet's final within the option cannot change en-route to the packet's final
destination. destination.
skipping to change at page 50, line 27 skipping to change at page 51, line 27
packets in order to tunnel them to the primary care-of address packets in order to tunnel them to the primary care-of address
for the mobile node indicated in its binding in the home agent's for the mobile node indicated in its binding in the home agent's
Binding Cache. Binding Cache.
- Every home agent MUST be able to return a Binding Acknowledgement - Every home agent MUST be able to return a Binding Acknowledgement
option in response to a Binding Update option received with the option in response to a Binding Update option received with the
Acknowledge (A) bit set. Acknowledge (A) bit set.
- Every home agent MUST maintain a separate Home Agents List for - Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in each link on which it is serving as a home agent, as described in
Section 4.3. Section 4.6.
- Every home agent MUST be able to accept packets addressed to - Every home agent MUST be able to accept packets addressed to
the "Mobile IPv6 Home-Agents" anycast address for the subnet the "Mobile IPv6 Home-Agents" anycast address for the subnet
on which it is serving as a home agent [10], and MUST be on which it is serving as a home agent [10], and MUST be
able to participate in dynamic home agent address discovery able to participate in dynamic home agent address discovery
(Section 9.2). (Section 9.2).
- Every home agent SHOULD support a configuration mechanism to - Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to be sent allow a system administrator to manually set the value to be sent
by this home agent in the Home Agent Preference field of the Home by this home agent in the Home Agent Preference field of the Home
skipping to change at page 51, line 23 skipping to change at page 52, line 23
- Every IPv6 mobile node MUST support receiving a Binding Request - Every IPv6 mobile node MUST support receiving a Binding Request
option, by responding with a Binding Update option. option, by responding with a Binding Update option.
- Every IPv6 mobile node MUST support sending packets containing a - Every IPv6 mobile node MUST support sending packets containing a
Home Address option; this option MUST be included in all packets Home Address option; this option MUST be included in all packets
sent while away from home, if the packet would otherwise have sent while away from home, if the packet would otherwise have
been sent with the mobile node's home address as the IP Source been sent with the mobile node's home address as the IP Source
Address. Address.
- Every IPv6 mobile node MUST maintain a Home Agents List, as - Every IPv6 mobile node MUST maintain a Home Agents List, as
described in Section 4.3. described in Section 4.6.
8. Correspondent Node Operation 8. Correspondent Node Operation
A correspondent node is any node communicating with a mobile node. A correspondent node is any node communicating with a mobile node.
The correspondent node, itself, may be stationary or mobile, and may The correspondent node, itself, may be stationary or mobile, and may
possibly also be functioning as a home agent for Mobile IPv6. The possibly also be functioning as a home agent for Mobile IPv6. The
procedures in this section thus apply to all IPv6 nodes. procedures in this section thus apply to all IPv6 nodes.
8.1. Receiving Packets from a Mobile Node 8.1. Receiving Packets from a Mobile Node
skipping to change at page 52, line 40 skipping to change at page 53, line 40
the mobile node and the correspondent node above the level of the the mobile node and the correspondent node above the level of the
Home Address option generation and processing. Home Address option generation and processing.
8.2. Receiving Binding Updates 8.2. Receiving Binding Updates
Upon receiving a Binding Update option in some packet, the receiving Upon receiving a Binding Update option in some packet, the receiving
node MUST validate the Binding Update according to the following node MUST validate the Binding Update according to the following
tests: tests:
- The packet meets the specific IPsec requirements for Binding - The packet meets the specific IPsec requirements for Binding
Updates, defined in Section 5.1. Updates, defined in Section 4.4.
- The packet MUST contain a valid Home Address option. The home - The packet MUST contain a valid Home Address option. The home
address for the binding is specified by the Home Address field of address for the binding is specified by the Home Address field of
the Home Address option. the Home Address option.
- The Option Length field in the Binding Update option is greater - The Option Length field in the Binding Update option is greater
than or equal to the length specified in Section 5.1. than or equal to the length specified in Section 5.1.
- The Sequence Number field in the Binding Update option is greater - The Sequence Number field in the Binding Update option is greater
than the Sequence Number received in the previous Binding Update than the Sequence Number received in the previous Binding Update
for this home address, if any. The Sequence Number comparison is for this home address, if any. As noted in Section 4.6, this
performed modulo 2**16. Sequence Number comparison MUST be performed modulo 2**16.
Any Binding Update not satisfying all of these tests MUST be Any Binding Update not satisfying all of these tests MUST be
silently ignored, and the packet carrying the Binding Update MUST be silently ignored, and the packet carrying the Binding Update MUST be
discarded. 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:
- If the Lifetime specified in the Binding Update is nonzero and - If the Lifetime specified in the Binding Update is nonzero and
the specified Care-of Address is not equal to the home address the specified Care-of Address is not equal to the home address
skipping to change at page 53, line 46 skipping to change at page 54, line 46
Update. Update.
In this case, the receiving node SHOULD create a new entry in its In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this mobile node (or update its existing Binding Binding Cache for this mobile node (or update its existing Binding
Cache entry for this mobile node, if such an entry already exists). Cache entry for this mobile node, if such an entry already exists).
The home address of the mobile node is taken from the Home Address The home address of the mobile node is taken from the Home Address
field in the packet's Home Address option. The new Binding Cache field in the packet's Home Address option. The new Binding Cache
entry records the association between this home address and the entry records the association between this home address and the
care-of address for the binding, as specified in either the Care-of care-of address for the binding, as specified in either the Care-of
Address field of the Binding Update or in the Source Address field Address field of the Binding Update or in the Source Address field
in the packet's IPv6 header. Any Binding Cache entry created or in the packet's IPv6 header. The lifetime for the Binding Cache
updated in response to processing this Binding Update MUST be deleted entry is initialized from the Lifetime field specified in the Binding
after the expiration of the Lifetime period specified in the Binding Update, although this lifetime MAY be reduced by the node caching the
Update. binding; the lifetime for the Binding Cache entry MUST NOT be greater
than the Lifetime value specified in the Binding Update. Any Binding
Cache entry MUST be deleted after the expiration of this lifetime on
the Binding Cache entry.
8.4. Requests to Delete a Binding 8.4. Requests to Delete a Binding
When a node receives a Binding Update, it MUST validate it and When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described determine the type of Binding Update according to the steps described
in Section 8.2. This section describes the processing of a valid in Section 8.2. This section describes the processing of a valid
Binding Update that requests a node to delete a mobile node's binding Binding Update that requests a node to delete a mobile node's binding
from its Binding Cache, for which the Home Registration (H) bit is from its Binding Cache, for which the Home Registration (H) bit is
not set in the Binding Update. not set in the Binding Update.
skipping to change at page 54, line 35 skipping to change at page 55, line 35
entry in its Binding Cache for this binding, the Status field in entry in its Binding Cache for this binding, the Status field in
the Binding Acknowledgement MUST be set to a value less than 128; the Binding Acknowledgement MUST be set to a value less than 128;
if the node rejects the Binding Update and does not create or if the node rejects the Binding Update and does not create or
update an entry for this binding, the Status field in the Binding update an entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value greater than or equal to 128. Acknowledgement MUST be set to a value greater than or equal to 128.
Specific values for the Status field are described in Section 5.2 and Specific values for the Status field are described in Section 5.2 and
in the most recent "Assigned Numbers" [26]. in the most recent "Assigned Numbers" [26].
The packet in which the Binding Acknowledgement is returned MUST meet The packet in which the Binding Acknowledgement is returned MUST meet
the specific IPsec requirements for Binding Acknowledgements, defined the specific IPsec requirements for Binding Acknowledgements, defined
in Section 5.2; and the packet MUST be sent using a Routing header in Section 4.4; and the packet MUST be sent using a Routing header
in the same way as any other packet sent to a mobile node using a in the same way as any other packet sent to a mobile node using a
care-of address (even if the binding was rejected), as described care-of address (even if the binding was rejected), as described
in Section 8.9. The packet is routed first to the care-of address in Section 8.9. The packet is routed first to the care-of address
contained in the Binding Update being acknowledged, and then to the contained in the Binding Update being acknowledged, and then to the
mobile node's home address. This use of the Routing header ensures mobile node's home address. This use of the Routing header ensures
that the Binding Acknowledgement will be routed to the current that the Binding Acknowledgement will be routed to the current
location of the node sending the Binding Update, whether the Binding location of the node sending the Binding Update, whether the Binding
Update was accepted or rejected. Update was accepted or rejected.
8.6. Sending Binding Requests 8.6. Sending Binding Requests
skipping to change at page 60, line 51 skipping to change at page 61, line 51
subnet (the home agent is configured with this anycast address on one subnet (the home agent is configured with this anycast address on one
of its network interfaces) SHOULD return an ICMP Home Agent Address of its network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node (at its care-of address Discovery Reply message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), with the that was used as the Source Address of the Request message), with the
Source Address of the Reply packet set to one of the global unicast Source Address of the Reply packet set to one of the global unicast
addresses of the home agent. The Home Agent Addresses field in the addresses of the home agent. The Home Agent Addresses field in the
Reply message is constructed as follows: Reply message is constructed as follows:
- The Home Agent Addresses field SHOULD contain one global IP - The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home address for each home agent currently listed in this home
agent's own Home Agents List (Section 4.3). However, if this agent's own Home Agents List (Section 4.6). However, if this
home agent's own global IP address would be placed in the list home agent's own global IP address would be placed in the list
(as described below) as the first entry in the list, then this (as described below) as the first entry in the list, then this
home agent SHOULD NOT include its own address in the Home Agent home agent SHOULD NOT include its own address in the Home Agent
Addresses field in the Reply message. Not placing this home Addresses field in the Reply message. Not placing this home
agent's own IP address in the list will cause the receiving agent's own IP address in the list will cause the receiving
mobile node to consider this home agent as the most preferred mobile node to consider this home agent as the most preferred
home agent; otherwise, this home agent will be considered to be home agent; otherwise, this home agent will be considered to be
preferred in its order given by its place in the list returned. preferred in its order given by its place in the list returned.
- The IP addresses in the Home Agent Addresses field should be - The IP addresses in the Home Agent Addresses field SHOULD be
listed in order of decreasing preference value, based either listed in order of decreasing preference value, based either
on the respective advertised preference from a Home Agent on the respective advertised preference from a Home Agent
Information option or on the default preference of 0 if no Information option or on the default preference of 0 if no
preference is advertised (or on the configured home agent preference is advertised (or on the configured home agent
preference for this home agent itself). The home agent with preference for this home agent itself). The home agent with
the highest preference SHOULD be listed first in the Home Agent the highest preference SHOULD be listed first in the Home Agent
Addresses field, and the home agent with the lowest preference Addresses field, and the home agent with the lowest preference
SHOULD be listed last. SHOULD be listed last.
- Among home agents with equal preference, their IP addresses - Among home agents with equal preference, their IP addresses
in the Home Agent Addresses field SHOULD be listed in an in the Home Agent Addresses field SHOULD be listed in an
order randomized with respect to other home agents with equal order randomized with respect to other home agents with equal
preference, each time a Home Agent Address Discovery Reply preference, each time a Home Agent Address Discovery Reply
message is returned by this home agent. message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more - For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry, than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected to then one of these global IP addresses SHOULD be selected to
include in the Home Agent Addresses field in the Reply message. include in the Home Agent Addresses field in the Reply message.
As described in Section 4.3, one Home Agents List entry, As described in Section 4.6, one Home Agents List entry,
identified by the home agent's link-local address, exists for identified by the home agent's link-local address, exists for
each home agent on the link; associated with that list entry is each home agent on the link; associated with that list entry is
one or more global IP addresses for this home agent, learned one or more global IP addresses for this home agent, learned
through Prefix Information options with the Router Address (R) through Prefix Information options with the Router Address (R)
bit is set, received in Router Advertisements from this bit is set, received in Router Advertisements from this
link-local address. The selected global IP address for each home link-local address. The selected global IP address for each home
agent to include in forming the Home Agent Addresses field in the agent to include in forming the Home Agent Addresses field in the
Reply message MUST be the global IP address of the respective Reply message MUST be the global IP address of the respective
home agent sharing a prefix with the mobile node's home address home agent sharing a prefix with the mobile node's home address
as indicated in the Home Address option in the Request message; as indicated in the Home Address option in the Request message;
skipping to change at page 62, line 45 skipping to change at page 63, line 45
return a Binding Acknowledgement to the mobile node, in which the return a Binding Acknowledgement to the mobile node, in which the
Status field is set to 136 (incorrect subnet prefix length). Status field is set to 136 (incorrect subnet prefix length).
- Else, if the home agent chooses to reject the Binding Update for - Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for field is set to an appropriate value to indicate the reason for
the rejection. the rejection.
- Finally, if the Duplicate Address Detection (D) bit is set in the - Finally, if the Duplicate Address Detection (D) bit is set in
Binding Update, this home agent MUST perform Duplicate Address the Binding Update, this home agent MUST perform Duplicate
Detection [27] on the mobile node's home link for the home Address Detection [27] on the mobile node's home link for the
address in this binding. If this Duplicate Address Detection home address in this binding (before returning the Binding
fails, then the home agent MUST reject the Binding Update and Acknowledgement). Normal processing for Duplicate Address
SHOULD return a Binding Acknowledgement to the mobile node, in Detection specifies that, in certain cases, the node SHOULD
which the Status field is set to 138 (Duplicate Address Detection delay sending the initial Neighbor Solication message of
failed). Duplicate Address Detection by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the
home agent SHOULD NOT perform such a delay. If this Duplicate
Address Detection fails, then the home agent MUST reject the
Binding Update and SHOULD return a Binding Acknowledgement to the
mobile node, in which the Status field is set to 138 (Duplicate
Address Detection failed).
If the home agent does not reject the Binding Update as described If the home agent does not reject the Binding Update as described
above, then it becomes the home agent for the mobile node. The new above, then it becomes the home agent for the mobile node. The new
home agent (the receiving node) MUST then create a new entry in its home agent (the receiving node) MUST then create a new entry in its
Binding Cache for this mobile node (or update its existing Binding Binding Cache for this mobile node (or update its existing Binding
Cache entry for this mobile node, if such an entry already exists) Cache entry for this mobile node, if such an entry already exists)
The home address of the mobile node is taken from the Home Address The home address of the mobile node is taken from the Home Address
field in the packet's Home Address option. The care-of address for field in the packet's Home Address option. The care-of address for
this Binding Cache entry is taken from the Alternate Care-of Address this Binding Cache entry is taken from the Alternate Care-of Address
sub-option in the Binding Update option, if present, or from the sub-option in the Binding Update option, if present, or from the
skipping to change at page 63, line 30 skipping to change at page 64, line 36
policy used for the Binding Cache (Section 8.7) and MUST NOT be policy used for the Binding Cache (Section 8.7) and MUST NOT be
removed from the Binding Cache until the expiration of the Lifetime removed from the Binding Cache until the expiration of the Lifetime
period. period.
In addition, the home agent MUST copy the Router (R) bit from the In addition, the home agent MUST copy the Router (R) bit from the
Binding Update into the corresponding bit in this Binding Cache entry Binding Update into the corresponding bit in this Binding Cache entry
for this mobile node. for this mobile node.
The lifetime for the Binding Cache entry MUST NOT be greater than The lifetime for the Binding Cache entry MUST NOT be greater than
the remaining valid lifetime for the subnet prefix in the mobile the remaining valid lifetime for the subnet prefix in the mobile
node's home address specified with the Binding Update. The remaining node's home address specified with the Binding Update, and MUST NOT
valid lifetime for this prefix is determined by the home agent based be greater than the Lifetime value specified in the Binding Update.
on its own Prefix List entry for this prefix [17]. Furthermore, The remaining valid lifetime for this prefix is determined by the
if the Prefix Length field in the Binding Update is nonzero, then home agent based on its own Prefix List entry for this prefix [17].
the lifetime for the Binding Cache entry MUST NOT be greater than Furthermore, if the Prefix Length field in the Binding Update is
the minimum remaining valid lifetime for all subnet prefixes on nonzero, then the lifetime for the Binding Cache entry MUST NOT be
the mobile node's home link. If the value of the Lifetime field greater than the minimum remaining valid lifetime for all subnet
specified by the mobile node in its Binding Update is greater than prefixes on the mobile node's home link. If the value of the
this prefix lifetime, the home agent MUST decrease the binding Lifetime field specified by the mobile node in its Binding Update is
lifetime to less than or equal to the prefix valid lifetime. The greater than this prefix lifetime, the home agent MUST decrease the
home agent MAY further decrease the specified lifetime for the binding lifetime to less than or equal to the prefix valid lifetime.
The home agent MAY further decrease the specified lifetime for the
binding, for example based on a local policy implemented by the home binding, for example based on a local policy implemented by the home
agent. The resulting lifetime is stored by the home agent in the agent. The resulting lifetime is stored by the home agent in the
Binding Cache entry, and this Binding Cache entry MUST be deleted by Binding Cache entry, and this Binding Cache entry MUST be deleted by
the home agent after the expiration of this lifetime. the home agent after the expiration of this lifetime.
The Prefix Length in the Binding Update MUST also be saved in the The Prefix Length in the Binding Update MUST also be saved in the
Binding Cache entry. Binding Cache entry.
If the Acknowledge (A) bit is set in the Binding Update (it SHOULD If the Acknowledge (A) bit is set in the Binding Update (it SHOULD
be), then the home agent MUST return a Binding Acknowledgement to the be), then the home agent MUST return a Binding Acknowledgement to the
skipping to change at page 66, line 12 skipping to change at page 67, line 18
(the remaining low-order bits in the address after the indicated (the remaining low-order bits in the address after the indicated
subnet prefix), together with each one of the subnet prefixes subnet prefix), together with each one of the subnet prefixes
currently considered by the home agent to be on-link (including currently considered by the home agent to be on-link (including
both the link-local and site-local prefix). both the link-local and site-local prefix).
- For each specific IP address for the mobile node determined - For each specific IP address for the mobile node determined
in the first step above, the home agent multicasts onto the in the first step above, the home agent multicasts onto the
home link (to the all-nodes multicast address) a Neighbor home link (to the all-nodes multicast address) a Neighbor
Advertisement message [17] on behalf of the mobile node, to Advertisement message [17] on behalf of the mobile node, to
advertise the home agent's own link-layer address for this IP advertise the home agent's own link-layer address for this IP
address. The Target Address in the Neighbor Advertisement address.
message MUST be set to this IP address for the mobile node, and
the Advertisement MUST include a Target Link-layer Address option All fields in each such Neighbor Advertisement message SHOULD
specifying the home agent's link-layer address. In addition, be set in the same way they would be set by the mobile node
the Router (R) bit in the Advertisement MUST be copied from the itself if sending this Neighbor Advertisement while at home [17],
corresponding bit in the home agent's Binding Cache entry for with the following exceptions. The Target Address in the
the mobile node. The Solicited Flag (S) in the Advertisement Neighbor Advertisement message MUST be set to this IP address
MUST NOT be set, since it was not solicited by any Neighbor for the mobile node, and the Advertisement MUST include a Target
Solicitation message. The Override Flag (O) in the Advertisement Link-layer Address option specifying the home agent's link-layer
MUST be set, indicating that the Advertisement SHOULD override address. In addition, the Router (R) bit in the Advertisement
any existing Neighbor Cache entry at any node receiving it. MUST be copied from the corresponding bit in the home agent's
Binding Cache entry for the mobile node. The Solicited Flag (S)
in the Advertisement MUST NOT be set, since it was not solicited
by any Neighbor Solicitation message. The Override Flag (O) in
the Advertisement MUST be set, indicating that the Advertisement
SHOULD override any existing Neighbor Cache entry at any node
receiving it.
Any node on the home link receiving one of the Neighbor Advertisement Any node on the home link receiving one of the Neighbor Advertisement
messages described above will thus update its Neighbor Cache to messages described above will thus update its Neighbor Cache to
associate the mobile node's address with the home agent's link associate the mobile node's address with the home agent's link
layer address, causing it to transmit any future packets for the layer address, causing it to transmit any future packets for the
mobile node normally destined to this address instead to the mobile mobile node normally destined to this address instead to the mobile
node's home agent. Since multicasts on the local link (such as node's home agent. Since multicasts on the local link (such as
Ethernet) are typically not guaranteed to be reliable, the home Ethernet) are typically not guaranteed to be reliable, the home
agent MAY retransmit this Neighbor Advertisement message up to agent MAY retransmit this Neighbor Advertisement message up to
MAX_ADVERT_REXMIT times to increase its reliability. It is still MAX_ADVERT_REXMIT times to increase its reliability. It is still
skipping to change at page 73, line 17 skipping to change at page 75, line 17
were not being used. Mobile IP is transparent to such higher were not being used. Mobile IP is transparent to such higher
layers. layers.
- As part of outbound packet processing in IP, the packet is - As part of outbound packet processing in IP, the packet is
compared against the IPsec Security Policy Database (SPD) to compared against the IPsec Security Policy Database (SPD) to
determine what processing is required for the packet [13]. determine what processing is required for the packet [13].
- As a special case for Mobile IP, if a Binding Update or - As a special case for Mobile IP, if a Binding Update or
Binding Acknowledgement is being included in the packet, IPsec Binding Acknowledgement is being included in the packet, IPsec
authentication, integrity protection, and replay protection MUST authentication, integrity protection, and replay protection MUST
be applied to the packet [13, 11, 12], as defined in Sections 5.1 be applied to the packet [13, 11, 12], as defined in Section 4.4.
and 5.2. If the SPD check above has already indicated that If the SPD check above has already indicated that authentication
authentication and replay protection are required, this and replay protection are required, this processing is sufficient
processing is sufficient for the Mobile IP requirement that all for the Mobile IP requirement that all packets containing Binding
packets containing Binding Updates or Binding Acknowledgements be Updates or Binding Acknowledgements be authenticated and covered
authenticated and covered by replay protection. Otherwise, an by replay protection. Otherwise, an implementation can force
implementation can force the required IPsec processing on this the required IPsec processing on this individual packet by, for
individual packet by, for example, creating a temporary SPD entry example, creating a temporary SPD entry for the handling of this
for the handling of this packet. packet.
- If IPsec processing is required, the packet is either mapped to - If IPsec processing is required, the packet is either mapped to
an existing Security Association (or SA bundle), or a new SA (or an existing Security Association (or SA bundle), or a new SA (or
SA bundle) is created for the packet, according to the procedures SA bundle) is created for the packet, according to the procedures
defined for IPsec. defined for IPsec.
- Since the mobile node is away from home, the mobile node inserts - Since the mobile node is away from home, the mobile node inserts
a Home Address option into the packet, replacing the Source a Home Address option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in for the link on which the packet is being sent, as described in
skipping to change at page 75, line 48 skipping to change at page 77, line 48
for the response packet. If the received Routing header contained for the response packet. If the received Routing header contained
no additional hops (other than the mobile node's home address and no additional hops (other than the mobile node's home address and
care-of address), then any upper-layer protocol response packet care-of address), then any upper-layer protocol response packet
SHOULD NOT include a Routing header. SHOULD NOT include a Routing header.
10.4. Movement Detection 10.4. Movement Detection
A mobile node MAY use any combination of mechanisms available to it A mobile node MAY use any combination of mechanisms available to it
to detect when it has moved from one link to another. The primary to detect when it has moved from one link to another. The primary
movement detection mechanism for Mobile IPv6 defined here uses the movement detection mechanism for Mobile IPv6 defined here uses the
facilities of IPv6 Neighbor Discovery, including Router Discovery and facilities of IPv6 Neighbor Discovery, including Router Discovery
Neighbor Unreachability Detection. The description here is based on and Neighbor Unreachability Detection, although the mobile node MAY
the conceptual model of the organization and data structures defined supplement this mechanism with other information available to the
by Neighbor Discovery [17]. mobile node (e.g., from lower protocol layers). The description
here is based on the conceptual model of the organization and data
structures defined by Neighbor Discovery [17].
Mobile nodes SHOULD use Router Discovery to discover new routers and Mobile nodes SHOULD use Router Discovery to discover new routers and
on-link subnet prefixes; a mobile node MAY send Router Solicitation on-link subnet prefixes; a mobile node MAY send Router Solicitation
messages, or MAY wait for unsolicited (periodic) multicast Router messages, or MAY wait for unsolicited (periodic) multicast Router
Advertisement messages, as specified for Router Discovery [17]. Advertisement messages, as specified for Router Discovery [17].
Based on received Router Advertisement messages, a mobile node (in Based on received Router Advertisement messages, a mobile node (in
the same way as any other node) maintains an entry in its Default the same way as any other node) maintains an entry in its Default
Router List for each router, and an entry in its Prefix List for each Router List for each router, and an entry in its Prefix List for each
subnet prefix, that it currently considers to be on-link. Each entry subnet prefix, that it currently considers to be on-link. Each entry
in these lists has an associated invalidation timer value (extracted in these lists has an associated invalidation timer value (extracted
from the Router Advertisement) used to expire the entry when it from the Router Advertisement and Prefix Information options) used to
becomes invalid. expire the entry when it becomes invalid.
While away from home, a mobile node SHOULD select one router from While away from home, a mobile node SHOULD select one router from
its Default Router List to use as its default router, and one subnet its Default Router List to use as its default router, and one subnet
prefix advertised by that router from its Prefix List to use as prefix advertised by that router from its Prefix List to use as
the subnet prefix in its primary care-of address. A mobile node the subnet prefix in its primary care-of address. A mobile node
MAY also have associated additional care-of addresses, using other MAY also have associated additional care-of addresses, using other
subnet prefixes from its Prefix List. The method by which a mobile subnet prefixes from its Prefix List. The method by which a mobile
node selects and forms a care-of address from the available subnet node selects and forms a care-of address from the available subnet
prefixes is described in Section 10.5. The mobile node registers prefixes is described in Section 10.5. The mobile node registers
its primary care-of address with its home agent, as described in its primary care-of address with its home agent, as described in
Section 10.6. Section 10.6.
While a mobile node is away from home and using some router as its While a mobile node is away from home and using some router as its
default router, it is important for the mobile node to be able to default router, it is important for the mobile node to be able to
quickly detect when that router becomes unreachable, so that it can quickly detect when that router becomes unreachable, so that it can
switch to a new default router and to a new primary care-of address. switch to a new default router and to a new primary care-of address.
Since some links (notably wireless) do not necessarily work equally Since some links (notably wireless) do not necessarily work equally
well in both directions, it is likewise important for the mobile well in both directions, it is likewise important for the mobile
node to detect when it becomes unreachable to packets sent from its node to detect when it becomes unreachable for packets sent from its
default router, so that the mobile node can take steps to ensure that default router, so that the mobile node can take steps to ensure that
any correspondent nodes attempting to communicate with it can still any correspondent nodes attempting to communicate with it can still
reach it through some other route. reach it through some other route.
To detect when its default router becomes unreachable, a mobile To detect when its default router becomes unreachable, a mobile
node SHOULD use Neighbor Unreachability Detection. As specified in node SHOULD use Neighbor Unreachability Detection. As specified in
Neighbor Discovery [17], while the mobile node is actively sending Neighbor Discovery [17], while the mobile node is actively sending
packets to (or through) its default router, the mobile node can packets to (or through) its default router, the mobile node can
detect that the router (as its neighbor) is still reachable either detect that the router (as its neighbor) is still reachable either
through indications from upper layer protocols on the mobile node through indications from upper layer protocols on the mobile node
skipping to change at page 77, line 24 skipping to change at page 79, line 27
(IPv6) packets from its link-layer address (e.g., those forwarded but (IPv6) packets from its link-layer address (e.g., those forwarded but
not originated by the router) SHOULD be considered. not originated by the router) SHOULD be considered.
Since the router SHOULD be sending periodic unsolicited multicast Since the router SHOULD be sending periodic unsolicited multicast
Router Advertisement messages, the mobile node will have frequent Router Advertisement messages, the mobile node will have frequent
opportunity to check if it is still reachable from its default opportunity to check if it is still reachable from its default
router, even in the absence of other packets to it from the router. router, even in the absence of other packets to it from the router.
If Router Advertisements that the mobile node receives include If Router Advertisements that the mobile node receives include
an Advertisement Interval option, the mobile node MAY use its an Advertisement Interval option, the mobile node MAY use its
Advertisement Interval field as an indication of the frequency with Advertisement Interval field as an indication of the frequency with
which it should expect to continue to receive future Advertisements which it SHOULD expect to continue to receive future Advertisements
from that router. This field specifies the minimum rate (the maximum from that router. This field specifies the minimum rate (the maximum
amount of time between successive Advertisements) that the mobile amount of time between successive Advertisements) that the mobile
node should expect. If this amount of time elapses without the node SHOULD expect. If this amount of time elapses without the
mobile node receiving any Advertisement from this router, the mobile mobile node receiving any Advertisement from this router, the mobile
node can be sure that at least one Advertisement sent by the router node can be sure that at least one Advertisement sent by the router
has been lost. It is thus possible for the mobile node to implement has been lost. It is thus possible for the mobile node to implement
its own policy for determining the number of Advertisements from its own policy for determining the number of Advertisements from
its current default router it is willing to tolerate losing before its current default router it is willing to tolerate losing before
deciding to switch to a different router from which it may currently deciding to switch to a different router from which it may currently
be correctly receiving Advertisements. be correctly receiving Advertisements.
On some types of network interfaces, the mobile node MAY also On some types of network interfaces, the mobile node MAY also
supplement this monitoring of Router Advertisements, by setting its supplement this monitoring of Router Advertisements, by setting its
skipping to change at page 79, line 32 skipping to change at page 81, line 37
In some cases, a mobile node may already know a (constant) IPv6 In some cases, a mobile node may already know a (constant) IPv6
address that has been assigned to it for its use only while address that has been assigned to it for its use only while
visiting a specific foreign link. For example, a mobile node may be visiting a specific foreign link. For example, a mobile node may be
statically configured with an IPv6 address assigned by the system statically configured with an IPv6 address assigned by the system
administrator of some foreign link, for its use while visiting that administrator of some foreign link, for its use while visiting that
link. If so, rather than using Address Autoconfiguration to form a link. If so, rather than using Address Autoconfiguration to form a
new care-of address using this subnet prefix, the mobile node MAY use new care-of address using this subnet prefix, the mobile node MAY use
its own pre-assigned address as its care-of address on this link. its own pre-assigned address as its care-of address on this link.
After forming a new care-of address, a mobile node MAY perform
Duplicate Address Detection [27] on that new address to confirm its
uniqueness. However, doing so represents a tradeoff between safety
(ensuring that the new address is not used if it is a duplicate
address) and overhead (performing Duplicate Address Detection
requires the sending of one or more additional packets over what
may be, for example, a slow wireless link through which the mobile
node is connected). Performing Duplicate Address Detection also
in general would cause a delay before the mobile node could use
the new care-of address, possibly causing the mobile node to be
unable to continue communication with correspondent nodes for some
period of time. For these reasons, a mobile node a mobile node,
after forming a new care-of address, MAY begin using the new care-of
address without performing Duplicate Address Detection. Furthermore,
the mobile node MAY continue using the address without performing
Duplicate Address Detection, although it SHOULD in most cases (e.g.,
unless network bandwidth or battery consumption for communication is
of primary concern) begin Duplicate Address Detection asynchronously
when it begins use of the address, allowing the Duplicate Address
Detection procedure to complete in parallel with normal communication
using the address.
In addition, normal processing for Duplicate Address Detection
specifies that, in certain cases, the node SHOULD delay sending the
initial Neighbor Solication message of Duplicate Address Detection
by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27];
however, in this case, the mobile node SHOULD NOT perform such a
delay in its use of Duplicate Address Detection, unless the mobile
node is intializing after rebooting.
10.6. Sending Binding Updates to the Home Agent 10.6. Sending Binding Updates to the Home Agent
After deciding to change its primary care-of address as described After deciding to change its primary care-of address as described
in Sections 10.4 and 10.5, a mobile node MUST register this care-of in Sections 10.4 and 10.5, a mobile node MUST register this care-of
address with its home agent in order to make this its primary care-of address with its home agent in order to make this its primary care-of
address. To do so, the mobile node sends a packet to its home agent address. To do so, the mobile node sends a packet to its home agent
containing a Binding Update option, with the packet constructed as containing a Binding Update option, with the packet constructed as
follows: follows:
- The Home Registration (H) bit MUST be set in the Binding Update. - The Home Registration (H) bit MUST be set in the Binding Update.
skipping to change at page 80, line 11 skipping to change at page 82, line 43
- The care-of address for the binding MUST be used as the Source - The care-of address for the binding MUST be used as the Source
Address in the packet's IPv6 header, unless an Alternate Care-of Address in the packet's IPv6 header, unless an Alternate Care-of
Address sub-option is included in the Binding Update option. Address sub-option is included in the Binding Update option.
- The Prefix Length field SHOULD be set to the length of the mobile - The Prefix Length field SHOULD be set to the length of the mobile
node's subnet prefix in its home address, to request the mobile node's subnet prefix in its home address, to request the mobile
node's home agent to serve as a home agent for all home addresses node's home agent to serve as a home agent for all home addresses
for the mobile node based on all on-link subnet prefixes on the for the mobile node based on all on-link subnet prefixes on the
home link. Otherwise, this field MUST be set to zero. home link. Otherwise, this field MUST be set to zero.
- The value specified in the Lifetime field SHOULD be less than
or equal to the remaining lifetime of the home address and the
care-of address specified for the binding.
The Acknowledge (A) bit in the Binding Update requests the home The Acknowledge (A) bit in the Binding Update requests the home
agent to return a Binding Acknowledgement in response to this agent to return a Binding Acknowledgement in response to this
Binding Update. As described in Section 5.2, the mobile node SHOULD Binding Update. As described in Section 5.2, the mobile node SHOULD
retransmit this Binding Update to its home agent until it receives retransmit this Binding Update to its home agent until it receives
a matching Binding Acknowledgement. Once reaching a retransmission a matching Binding Acknowledgement. Once reaching a retransmission
timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD
continue to periodically retransmit the Binding Update at this rate continue to periodically retransmit the Binding Update at this rate
until acknowledged (or until it begins attempting to register a until acknowledged (or until it begins attempting to register a
different primary care-of address). different primary care-of address).
skipping to change at page 80, line 32 skipping to change at page 83, line 19
to request its home agent to serve all home addresses for the mobile to request its home agent to serve all home addresses for the mobile
node, as indicated by the interface identifier in the mobile node's node, as indicated by the interface identifier in the mobile node's
home address (the remaining low-order bits after the indicated subnet home address (the remaining low-order bits after the indicated subnet
prefix), together with each on-link subnet prefix on the home link. prefix), together with each on-link subnet prefix on the home link.
Until the lifetime of this registration expires, the home agent Until the lifetime of this registration expires, the home agent
considers itself the home agent for each such home address of the considers itself the home agent for each such home address of the
mobile node. As the set of on-link subnet prefixes on the home link mobile node. As the set of on-link subnet prefixes on the home link
changes over time, the home agent changes the set of home addresses changes over time, the home agent changes the set of home addresses
for this mobile node for which it is serving as the home agent. for this mobile node for which it is serving as the home agent.
When sending a Binding Update to its home agent, the mobile node MUST
also create or update the corresponding Binding Update List entry, as
specified in Section 10.8.
If the mobile node has additional home addresses using a different If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the packet containing a Binding Update to its home agent to register the
care-of address for each such other home address (or set of home care-of address for each such other home address (or set of home
addresses sharing an interface identifier). These additional Binding addresses sharing an interface identifier). These additional Binding
Updates MUST each be sent as a separate packet, since each MUST be Updates MUST each be sent as a separate packet, since each MUST be
protected by IPsec [13, 11, 12] to authenticate the Binding Update as protected by IPsec [13, 11, 12] to authenticate the Binding Update as
coming from the home address being bound, as defined in Section 5.1. coming from the home address being bound, as defined in Section 4.4.
10.7. Dynamic Home Agent Address Discovery 10.7. Dynamic Home Agent Address Discovery
It is possible that when the mobile node needs to send a Binding It is possible that when the mobile node needs to send a Binding
Update to its home agent to register its new primary care-of address, Update to its home agent to register its new primary care-of address,
as described in Section 10.6, the mobile node may not know the as described in Section 10.6, the mobile node may not know the
address of any router on its home link that can serve as a home agent address of any router on its home link that can serve as a home agent
for it. For example, some nodes on its home link may have been for it. For example, some nodes on its home link may have been
reconfigured while the mobile node has been away from home, such that reconfigured while the mobile node has been away from home, such that
the router that was operating as the mobile node's home agent has the router that was operating as the mobile node's home agent has
skipping to change at page 82, line 12 skipping to change at page 84, line 52
care-of address (either the Source Address in the packet's IPv6 care-of address (either the Source Address in the packet's IPv6
header or the Care-of Address field in the Binding Update) MUST be header or the Care-of Address field in the Binding Update) MUST be
set to one of the care-of addresses currently in use by the mobile set to one of the care-of addresses currently in use by the mobile
node or to the mobile node's home address. node or to the mobile node's home address.
If set to one of the mobile node's current care-of addresses (the If set to one of the mobile node's current care-of addresses (the
care-of address given MAY differ from the mobile node's primary care-of address given MAY differ from the mobile node's primary
care-of address), the Binding Update requests the correspondent node care-of address), the Binding Update requests the correspondent node
to create or update an entry for the mobile node in the correspondent to create or update an entry for the mobile node in the correspondent
node's Binding Cache to record this care-of address for use in node's Binding Cache to record this care-of address for use in
sending future packets to the mobile node. In this case, the sending future packets to the mobile node. In this case, the value
Lifetime value sent in the Binding Update MUST be no greater than specified in the Lifetime field sent in the Binding Update SHOULD be
the remaining lifetime of the mobile node's home registration of its less than or equal to the remaining lifetime of the home address and
primary care-of address at its home agent. the care-of address specified for the binding.
If, instead, the care-of address is set to the mobile node's home If, instead, the care-of address is set to the mobile node's home
address, the Binding Update requests the correspondent node to delete address, the Binding Update requests the correspondent node to delete
any existing Binding Cache entry that it has for the mobile node. any existing Binding Cache entry that it has for the mobile node.
A mobile node MAY set the care-of address differently for sending A mobile node MAY set the care-of address differently for sending
Binding Updates to different correspondent nodes. Binding Updates to different correspondent nodes.
When sending any Binding Update, the mobile node MUST record in its When sending any Binding Update, the mobile node MUST record in its
Binding Update List the following fields from the Binding Update: Binding Update List the following fields from the Binding Update:
- The IP address of the node to which the Binding Update was sent. - The IP address of the node to which the Binding Update was sent.
- The home address for which the Binding Update was sent (the value - The home address for which the Binding Update was sent (the value
in the Home Address option in the packet carrying the Binding in the Home Address option in the packet carrying the Binding
Update). Update).
- The remaining lifetime of the binding, initialized from the - The initial lifetime of the binding, initialized from the
Lifetime field sent in the Binding Update. Lifetime field sent in the Binding Update.
- The remaining lifetime of the binding, also initialized from
the Lifetime field sent in the Binding Update. This remaining
lifetime value counts down and may also be reduced when the
matching Binding Acknowledgement is received, based on the
Lifetime value specified in that Binding Acknowledgement, as
described in Section 10.12. When the this remaining lifetime
reaches zero, the Binding Update List entry MUST be deleted.
The mobile node MUST retain in its Binding Update List information The mobile node MUST retain in its Binding Update List information
about all Binding Updates sent, for which the lifetime of the binding about all Binding Updates sent, for which the lifetime of the binding
has not yet expired. However, when sending a Binding Update, if an has not yet expired. However, when sending a Binding Update, if an
entry already exists in the mobile node's Binding Update List for entry already exists in the mobile node's Binding Update List for
an earlier Binding Update sent to that same destination node, the an earlier Binding Update sent to that same destination node, the
existing Binding Update List entry is updated to reflect the new existing Binding Update List entry is updated to reflect the new
Binding Update rather than creating a new Binding Update List entry. Binding Update rather than creating a new Binding Update List entry.
In general, when a mobile node sends a Binding Update to its home In general, when a mobile node sends a Binding Update to its home
agent to register a new primary care-of address (as described in agent to register a new primary care-of address (as described in
skipping to change at page 85, line 15 skipping to change at page 88, line 15
Note that this home agent does not necessarily know (and need not Note that this home agent does not necessarily know (and need not
know) the mobile node's (permanent) home address as part of this know) the mobile node's (permanent) home address as part of this
registration. registration.
The packet carrying the Binding Update MUST be addressed to The packet carrying the Binding Update MUST be addressed to
this home agent's global unicast address. Normally, this global this home agent's global unicast address. Normally, this global
unicast address is learned by the mobile node based on the Router unicast address is learned by the mobile node based on the Router
Advertisements received by the mobile node (Section 6.2) while Advertisements received by the mobile node (Section 6.2) while
attached to the link on which this previous care-of address and this attached to the link on which this previous care-of address and this
home agent are located; the mobile node obtains this home agent home agent are located; the mobile node obtains this home agent
address from its Home Agents List (Section 4.3). Alternatively, address from its Home Agents List (Section 4.6). Alternatively,
the mobile node MAY use dynamic home agent address discovery the mobile node MAY use dynamic home agent address discovery
(Section 10.7) to discover the global unicast address of a home agent (Section 10.7) to discover the global unicast address of a home agent
on this previous link, but it SHOULD use an address from its Home on this previous link, but it SHOULD use an address from its Home
Agents List if available for the prefix it used in this previous Agents List if available for the prefix it used in this previous
care-of address. care-of address.
As with any packet containing a Binding Update 5.1, the Binding As with any packet containing a Binding Update 5.1, the Binding
Update packet to this home agent MUST meet the IPsec requirements for Update packet to this home agent MUST meet the IPsec requirements for
Binding Updates, defined in Section 5.1. Binding Updates, defined in Section 4.4.
10.10. Retransmitting Binding Updates 10.10. Retransmitting Binding Updates
If, after sending a Binding Update in which the Acknowledge (A) If, after sending a Binding Update in which the Acknowledge (A)
bit is set, a mobile node fails to receive a valid, matching bit is set, a mobile node fails to receive a valid, matching
Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the
mobile node SHOULD retransmit the Binding Update, until a Binding mobile node SHOULD retransmit the Binding Update, until a Binding
Acknowledgement is received. Such a retransmitted Binding Update Acknowledgement is received. Such a retransmitted Binding Update
MUST use a Sequence Number value greater than that used for the MUST use a Sequence Number value greater than that used for the
previous transmission of this Binding Update. The retransmissions by previous transmission of this Binding Update. The retransmissions by
skipping to change at page 86, line 11 skipping to change at page 89, line 11
node will eventually be able to process a Binding Update and begin node will eventually be able to process a Binding Update and begin
to route its packets directly to the mobile node at its new care-of to route its packets directly to the mobile node at its new care-of
address. address.
10.12. Receiving Binding Acknowledgements 10.12. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests: node MUST validate the packet according to the following tests:
- The packet meets the specific IPsec requirements for Binding - The packet meets the specific IPsec requirements for Binding
Acknowledgements, defined in Section 5.2. Acknowledgements, defined in Section 4.4.
- The Option Length field in the option is greater than or equal to - The Option Length field in the option is greater than or equal to
11 octets. 11 octets.
- The Sequence Number field matches the Sequence Number sent by the - The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding mobile node to this destination address in an outstanding Binding
Update. Update.
Any Binding Acknowledgement not satisfying all of these tests MUST be Any Binding Acknowledgement not satisfying all of these tests MUST be
silently ignored, although the remainder of the packet (i.e., other silently ignored, although the remainder of the packet (i.e., other
options, extension headers, or payload) SHOULD be processed normally options, extension headers, or payload) SHOULD be processed normally
according to any procedure defined for that part of the packet. according to any procedure defined for that part of the packet.
When a mobile node receives a packet carrying a valid Binding When a mobile node receives a packet carrying a valid Binding
Acknowledgement, the mobile node MUST examine the Status field as Acknowledgement, the mobile node MUST examine the Status field as
follows: follows:
- If the Status field indicates that the Binding Update was - If the Status field indicates that the Binding Update was
accepted (the Status field is less than 128), then the mobile accepted (the Status field is less than 128), then the mobile
node MUST update the corresponding entry in its Binding Update node MUST update the corresponding entry in its Binding Update
List to indicate that the Binding Update has been acknowledged. List to indicate that the Binding Update has been acknowledged;
The mobile node MUST then stop retransmitting the Binding Update. the mobile node MUST then stop retransmitting the Binding Update.
In addition, if the value specified in the Lifetime field in the
Binding Acknowledgement is less than the Lifetime value sent
in the Binding Update being acknowledged, then the mobile node
MUST subtract the difference between these two Lifetime values
from the remaining lifetime for the binding as maintained in the
corresponding Binding Update List entry (with a minimum value
for the Binding Update List entry lifetime of 0). That is, if
the Lifetime value sent in the Binding Update was L_update, the
Lifetime value received in the Binding Acknowledgement was L_ack,
and the current remaining lifetime of the Binding Update List
entry is L_remain, then the new value for the remaing lifetime of
the Binding Update List entry should be
max((L_remain - (L_update - L_ack)), 0)
where max(X, Y) is the maximum of X and Y. The effect of this
step is to correctly manage the mobile node's view of the
binding's remaining lifetime (as maintained in the corresponding
Binding Update List entry) so that it correctly counts down from
the Lifetime value given in the Binding Acknowledgement, but with
the timer countdown beginning at the time that the Binding Update
was sent.
- If the Status field indicates that the Binding Update was - If the Status field indicates that the Binding Update was
rejected (the Status field is greater than or equal to 128), then rejected (the Status field is greater than or equal to 128), then
the mobile node MUST delete the corresponding Binding Update List the mobile node MUST delete the corresponding Binding Update List
entry (and MUST also stop retransmitting the Binding Update). entry (and MUST also stop retransmitting the Binding Update).
Optionally, the mobile node MAY then take steps to correct the Optionally, the mobile node MAY then take steps to correct the
cause of the error and retransmit the Binding Update (with a new cause of the error and retransmit the Binding Update (with a new
Sequence Number value), subject to the rate limiting restriction Sequence Number value), subject to the rate limiting restriction
specified in Section 10.11. specified in Section 10.11.
skipping to change at page 87, line 27 skipping to change at page 90, line 49
SUb-Option Data field of the Unique Identifier Sub-Option MUST be SUb-Option Data field of the Unique Identifier Sub-Option MUST be
copied from the unique identifier carried in the Binding Request. copied from the unique identifier carried in the Binding Request.
10.14. Receiving ICMP Error Messages 10.14. Receiving ICMP Error Messages
The Option Type value for a Binding Update option specifies that The Option Type value for a Binding Update option specifies that
any node receiving this option that does not recognize the Option any node receiving this option that does not recognize the Option
Type SHOULD return an ICMP Parameter Problem, Code 2, message to Type SHOULD return an ICMP Parameter Problem, Code 2, message to
the sender of the packet containing the Binding Update option. If the sender of the packet containing the Binding Update option. If
a node sending a Binding Update receives such an ICMP error message a node sending a Binding Update receives such an ICMP error message
in response, it should record in its Binding Update List that future in response, it SHOULD record in its Binding Update List that future
Binding Updates should not be sent to this destination. Binding Updates SHOULD NOT be sent to this destination.
Likewise, although ALL IPv6 nodes (whether host or router, whether Likewise, although ALL IPv6 nodes (whether host or router, whether
mobile or stationary) MUST implement the ability to correctly process mobile or stationary) MUST implement the ability to correctly process
received packets containing a Home Address option, all Option Type received packets containing a Home Address option, all Option Type
values in IPv6 include a specification of the behavior that a node values in IPv6 include a specification of the behavior that a node
receiving a packet containing this option performs if it does not receiving a packet containing this option performs if it does not
implement receipt of that type of option. For the Home Address implement receipt of that type of option. For the Home Address
option, the Option Type value specifies that any node receiving option, the Option Type value specifies that any node receiving
this option that does not recognize the Option Type SHOULD return this option that does not recognize the Option Type SHOULD return
an ICMP Parameter Problem, Code 2, message to the sender of the an ICMP Parameter Problem, Code 2, message to the sender of the
skipping to change at page 97, line 45 skipping to change at page 100, line 45
the ordinary computing environment. In many cases, mobile computers the ordinary computing environment. In many cases, mobile computers
will be connected to the network via wireless links. Such links will be connected to the network via wireless links. Such links
are particularly vulnerable to passive eavesdropping, active replay are particularly vulnerable to passive eavesdropping, active replay
attacks, and other active attacks. Furthermore, mobile computers attacks, and other active attacks. Furthermore, mobile computers
are more susceptible to loss or theft than stationary computers. are more susceptible to loss or theft than stationary computers.
Any secrets such as authentication or encryption keys stored on the Any secrets such as authentication or encryption keys stored on the
mobile computer are thus subject to compromise in ways generally not mobile computer are thus subject to compromise in ways generally not
common in the non-mobile environment. common in the non-mobile environment.
Users who have sensitive data that they do not wish others to have Users who have sensitive data that they do not wish others to have
access to should use additional mechanisms (such as encryption) to access to SHOULD use additional mechanisms (such as encryption) to
provide privacy protection, but such mechanisms are beyond the scope provide privacy protection, but such mechanisms are beyond the scope
of this document. Users concerned about traffic analysis should of this document. Users concerned about traffic analysis SHOULD
consider appropriate use of link encryption. If stronger location consider appropriate use of link encryption. If stronger location
privacy is desired, the mobile node can create a tunnel to its home privacy is desired, the mobile node can create a tunnel to its home
agent. Then, packets destined for correspondent nodes will appear agent. Then, packets destined for correspondent nodes will appear
to emanate from the home subnet, and it may be more difficult to to emanate from the home subnet, and it may be more difficult to
pinpoint the location of the mobile node. Such mechanisms are all pinpoint the location of the mobile node. Such mechanisms are all
beyond the scope of this document. beyond the scope of this document.
Changes from Previous Version of the Draft Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this This appendix briefly lists some of the major changes in this
draft relative to the previous version of this same draft, draft relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-10.txt: draft-ietf-mobileip-ipv6-11.txt:
- Added material in Section 10.19 dealing with the problem of - Moved the definition of IPsec requirements for Binding Updates
Duplicate Address Detection on the home link when the mobile node and Binding Acknowledgements to Section 4.4), giving this
returns home. important information its own specific section with a section
title (IPsec Requirements for Mobile IPv6 Destination Options)
that will be identifiable in the table of contents for this
document. This makes these requirements harder to miss than
where they were defined in Sections 5.1 and 5.2, mixed in with
the definition of the format of these destination options.
- Moved all specific requirements for use of IPsec with Binding - In Section 4.6, added a precise definition of Sequence Number
Updates and Binding Acknowledgements to Sections 5.1 and 5.2, value comparison modulo 2**16. Also added a reference to this
respectively. This avoids repeating the same requirements in definition in each other place where Sequence Number comparison
possibly different ways in many places throughout the document. is discussed.
Instead, all such places now refer to Sections 5.1 or 5.2.
- Defined in Sections 5.1 and 5.2 that all packets including a - Added a statement in Section 9.5 to clarify the sending of a
Binding Update or Binding Acknowledgement, respectively, MUST use Neighbor Advertisement message by the home agent on behalf of the
AH to provide the required sender authentication, data integrity mobile node in order to intercept packets addressed to the mobile
protection, and replay protection. Use of ESP for protecting the node. Except for the specific fields defined there, all fields
Binding Updates and Binding Acknowledgements is not currently in each such Neighbor Advertisement SHOULD be set in the same
defined in this document, since ESP does not protect the portion way they would be set by the mobile node itself if sending this
of the packet above the ESP header itself. Neighbor Advertisement while at home [17].
- Corrected yet a few more minor typographical errors in places. - In Section 10.6, specified that the Lifetime in the Binding
Update sent by a mobile node to its home agent SHOULD be less
than or equal to the remaining lifetime of the home address and
the care-of address specified for the binding.
- In Section 10.8, modified the specification that was there
about the correct setting of the Lifetime in the Binding
Update sent by a mobile node to a correspondent node. The
original specification stated that the Lifetime value MUST be no
greater than the remaining lifetime of the mobile node's home
registration of its primary care-of address at its home agent.
However, there should be no necessary relationship between the
remaining lifetime of a home registration and the lifetime of
a binding at a correspondent node. Instead, as with the home
registration Binding Update, the Lifetime in the Binding Update
sent by a mobile node to a correspondent node SHOULD be less than
or equal to the remaining lifetime of the home address and the
care-of address specified for the binding.
- In Section 5.4, added a statement that a packet MUST NOT contain
more than one Home Address option, except that an encapsulated
packet [4] MAY contain a separate Home Address option associated
with each encapsulating IP header.
- In Section 4.6, added a new field in the Binding Update List
entry format to record the initial value of the Lifetime field
sent in that Binding Update.
- In Section 10.12, defined a new step in processing a received
Binding Acknowledgement: if the value specified in the Lifetime
field in the Binding Acknowledgement is less than the Lifetime
value sent in the Binding Update being acknowledged, then the
mobile node MUST subtract the difference between these two
Lifetime values from the remaining lifetime for the binding
as maintained in the corresponding Binding Update List entry.
The effect of this step is to correctly manage the mobile
node's view of the binding's remaining lifetime (as maintained
in the corresponding Binding Update List entry) so that it
correctly counts down from the Lifetime value given in the
Binding Acknowledgement, but with the timer countdown beginning
at the time that the Binding Update was sent. This change also
affected Section 10.8 in sending Binding Updates, to record both
the original lifetime and the remaining lifetime in the Binding
Update List.
- In Sections 5.1 and 9.3, clarified that the Duplicate Address
Detection performed by the home agent if the Duplicate Address
Detection (D) bit is set in the Binding Update, is performed
before returning the Binding Acknowledgement for that Binding
Update.
- In Section 5.1, clarified that the mobile node SHOULD set the
Duplicate Address Detection (D) bit in its home registration
Binding Updates based on any requirements for Duplicate Address
Detection that would apply to the mobile node if it were at
home [17, 27].
- In Section 9.3, specified that a home agent, when performing
Duplicate Address Detection for a mobile node when the
Duplicate Address Detection (D) bit is set in a received
Binding Update, SHOULD NOT delay sending the initial Neighbor
Solicitation message of Duplicate Address Detection by the random
delay specified for normal processing of Duplicate Address
Detection [17, 27].
- In Section 10.5, defined special considerations for a mobile
node's use of Duplicate Address Detection upon forming a new
care-of address. In particular, the mobile node MAY begin
using the new care-of address without performing Duplicate
Address Detection, and MAY optionally bypass Duplicate Address
Detection or begin Duplicate Address Detection asynchronously
when it begins use of the address, allowing the Duplicate
Address Detection procedure to complete in parallel with
normal communication using the address. In addition, the
mobile node SHOULD NOT delay sending the initial Neighbor
Solicitation message of Duplicate Address Detection by the random
delay specified for normal processing of Duplicate Address
Detection [17, 27], unless the mobile node is initializing after
rebooting.
- In Section 4.6, added a clarification to the definition of the
Binding Update List, that for multiple Binding Updates sent to
the same destination address, the Binding Update List contains
only the most recent Binding Update (i.e., with the greatest
Sequence Number value) sent to that destination. This was
already noted in previous versions of the draft in the sending of
Binding Updates, as defined in Section update-corresp, but was
not previously stated explicitly in the definition of the Binding
Update List conceptual data structure.
- In Section 9.3, added a specification that the lifetime for the
Binding Cache entry (and thus the Lifetime value returned in the
Binding Acknowledgement) MUST NOT be greater than the Lifetime
value specified in the Binding Update. Also added a similar
specification (and clarification) in Section 8.3 for the Binding
Cache entry in a correspondent node.
- In Section 10.6, added a clarification that, when sending a
Binding Update to its home agent, the mobile node MUST also
create or update the corresponding Binding Update List entry, as
specified in Section 10.8.
Acknowledgements 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
Groups for their comments and suggestions on this work. We would Working Groups for their comments and suggestions on this work.
particularly like to thank (in alphabetical order) Fred Baker We would particularly like to thank (in alphabetical order)
(Cisco), Josh Broch (Carnegie Mellon University), Rich Draves Fred Baker (Cisco), Josh Broch (Carnegie Mellon University),
(Microsoft Research), Francis Dupont (INRIA), Jun-Ichiro Hagino (IIJ Rich Draves (Microsoft Research), Francis Dupont (INRIA), Thomas
Research Laboratory), Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Eklund (SwithCore), Jun-Ichiro Hagino (IIJ Research Laboratory),
Erik Nordmark (Sun Microsystems), Simon Nybroe (Ericsson Telebit), Aime Lerouzic (Bull S.A.), Thomas Narten (IBM), Erik Nordmark
David Oran (Cisco), Basavaraj Patil (Nokia), Phil Roberts (Motorola), (Sun Microsystems), Simon Nybroe (Ericsson Telebit), David Oran
Patrice Romand (Bull S.A.), Tom Soderlund (Nokia Research), Hesham (Cisco), Basavaraj Patil (Nokia), Ken Powell (Compaq), Phil Roberts
Soliman (Ericsson), Jim Solomon (RedBack Networks), Benny Van Houdt (Motorola), Patrice Romand (Bull S.A.), Tom Soderlund (Nokia
(University of Antwerp), and Xinhua Zhao (Stanford University) for Research), Hesham Soliman (Ericsson), Jim Solomon (RedBack Networks),
their detailed reviews of earlier versions of this document. Their Benny Van Houdt (University of Antwerp), Jon-Olov Vatn (KTH), and
suggestions have helped to improve both the design and presentation Xinhua Zhao (Stanford University) for their detailed reviews of
of the protocol. earlier versions of this document. Their suggestions have helped to
improve both the design and presentation of the protocol.
We would also like to thank the participants in the Mobile IPv6 We would also like to thank the participants in the Mobile IPv6
testing event held at Nancy, France, September 15-17, 1999, for testing event held at Nancy, France, September 15-17, 1999, for
their valuable feedback as a result of interoperability testing their valuable feedback as a result of interoperability testing
of four Mobile IPv6 implementations coming from four different of four Mobile IPv6 implementations coming from four different
organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC organizations: Bull (AIX), Ericsson Telebit (FreeBSD), NEC
(FreeBSD), and INRIA (FreeBSD). Finally, we would like to thank the (FreeBSD), and INRIA (FreeBSD). Finally, we would like to thank the
feedback from the implementors who participated in the Mobile IPv6 feedback from the implementors who participated in the Mobile IPv6
interoperability testing at Connectathon 2000 in San Jose, interoperability testing at Connectathon 2000 in San Jose,
California, March 6-9, 2000. California, March 6-9, 2000.
 End of changes. 

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