draft-ietf-mobileip-ipv6-06.txt   draft-ietf-mobileip-ipv6-07.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
Sun Microsystems Sun Microsystems
4 August 1998 18 November 1998
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-06.txt> <draft-ietf-mobileip-ipv6-07.txt>
Status of This Memo Status of This Memo
This document is a submission by the Mobile IP Working Group of the This document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the Working Group mailing list at "mobile-ip@SmallWorks.COM". to the Working Group mailing list at "mobile-ip@SmallWorks.COM".
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at page 1, line 48 skipping to change at page 1, line 48
This document specifies the operation of mobile computers using IPv6. This document specifies the operation of mobile computers using IPv6.
Each mobile node is always identified by its home address, regardless Each mobile node is always identified by its home address, regardless
of its current point of attachment to the Internet. While situated of its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a care-of away from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current address, which provides information about the mobile node's current
location. IPv6 packets addressed to a mobile node's home address are location. IPv6 packets addressed to a mobile node's home address are
transparently routed to its care-of address. The protocol enables transparently routed to its care-of address. The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address, and to then send any packets destined for the its care-of address, and to then send any packets destined for the
mobile node directly to it at this care-of address. mobile node directly to it at this care-of address. To support this
operation, Mobile IPv6 defines four new IPv6 destination options,
including one that MUST be supported in packets received by any node,
whether mobile or stationary.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Comparison with Mobile IP for IPv4 3 2. Comparison with Mobile IP for IPv4 3
skipping to change at page 1, line 75 skipping to change at page 1, line 78
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 . . . . . . . . . . . . . . 11 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11
4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 13 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 13
4.4. Binding Management . . . . . . . . . . . . . . . . . . . 16 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 16
5. New IPv6 Destination Options 19 5. New IPv6 Destination Options 19
5.1. Binding Update Option Format . . . . . . . . . . . . . . 19 5.1. Binding Update Option Format . . . . . . . . . . . . . . 19
5.2. Binding Acknowledgement Option Format . . . . . . . . . . 23 5.2. Binding Acknowledgement Option Format . . . . . . . . . . 23
5.3. Binding Request Option Format . . . . . . . . . . . . . . 27 5.3. Binding Request Option Format . . . . . . . . . . . . . . 27
5.4. Home Address Option Format . . . . . . . . . . . . . . . 28 5.4. Home Address Option Format . . . . . . . . . . . . . . . 29
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 31
6. Modifications to IPv6 Neighbor Discovery 30 6. Modifications to IPv6 Neighbor Discovery 33
6.1. Modified Router Advertisement Message Format . . . . . . 30 6.1. Modified Router Advertisement Message Format . . . . . . 33
6.2. Modified Prefix Information Option Format . . . . . . . . 31 6.2. Modified Prefix Information Option Format . . . . . . . . 34
6.3. New Advertisement Interval Option Format . . . . . . . . 33 6.3. New Advertisement Interval Option Format . . . . . . . . 36
6.4. New Home Agent Information Option Format . . . . . . . . 34 6.4. New Home Agent Information Option Format . . . . . . . . 37
6.5. Changes to Sending Router Advertisements . . . . . . . . 36 6.5. Changes to Sending Router Advertisements . . . . . . . . 39
6.6. Changes to Sending Router Solicitations . . . . . . . . . 37 6.6. Changes to Sending Router Solicitations . . . . . . . . . 40
7. Requirements for IPv6 Nodes 39 7. Requirements for IPv6 Nodes 42
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 39 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 42
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 39 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 42
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 39 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 42
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 40 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 43
8. Correspondent Node Operation 42 8. Correspondent Node Operation 45
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 42 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 45
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 42 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 45
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 43 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 46
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 44 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 47
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 44 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 47
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 45 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 48
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 45 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 48
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 46 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 49
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 47 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 50
9. Home Agent Operation 49 9. Home Agent Operation 52
9.1. Receiving Router Advertisement Messages . . . . . . . . . 49 9.1. Receiving Router Advertisement Messages . . . . . . . . . 52
9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 50 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 53
9.3. Primary Care-of Address Registration . . . . . . . . . . 51 9.3. Primary Care-of Address Registration . . . . . . . . . . 55
9.4. Primary Care-of Address De-registration . . . . . . . . . 54 9.4. Primary Care-of Address De-registration . . . . . . . . . 57
9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 54 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 58
9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 56 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 60
9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 57 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 61
10. Mobile Node Operation 60 10. Mobile Node Operation 64
10.1. Sending Packets While Away from Home . . . . . . . . . . 60 10.1. Sending Packets While Away from Home . . . . . . . . . . 64
10.2. Receiving Packets While Away from Home . . . . . . . . . 62 10.2. Receiving Packets While Away from Home . . . . . . . . . 66
10.3. Movement Detection . . . . . . . . . . . . . . . . . . . 63 10.3. Movement Detection . . . . . . . . . . . . . . . . . . . 67
10.4. Forming New Care-of Addresses . . . . . . . . . . . . . . 66 10.4. Forming New Care-of Addresses . . . . . . . . . . . . . . 70
10.5. Sending Binding Updates to the Home Agent . . . . . . . . 67 10.5. Sending Binding Updates to the Home Agent . . . . . . . . 71
10.6. Dynamic Home Agent Address Discovery . . . . . . . . . . 68 10.6. Dynamic Home Agent Address Discovery . . . . . . . . . . 72
10.7. Sending Binding Updates to Correspondent Nodes . . . . . 69 10.7. Sending Binding Updates to Correspondent Nodes . . . . . 73
10.8. Sending Binding Updates to the Previous Default Router . 71 10.8. Sending Binding Updates to the Previous Default Router . 75
10.9. Retransmitting Binding Updates . . . . . . . . . . . . . 72 10.9. Retransmitting Binding Updates . . . . . . . . . . . . . 76
10.10. Rate Limiting for Sending Binding Updates . . . . . . . . 72 10.10. Rate Limiting for Sending Binding Updates . . . . . . . . 76
10.11. Receiving Binding Acknowledgements . . . . . . . . . . . 72 10.11. Receiving Binding Acknowledgements . . . . . . . . . . . 76
10.12. Receiving Binding Requests . . . . . . . . . . . . . . . 73 10.12. Receiving Binding Requests . . . . . . . . . . . . . . . 77
10.13. Receiving ICMP Error Messages . . . . . . . . . . . . . . 74 10.13. Receiving ICMP Error Messages . . . . . . . . . . . . . . 78
10.14. Receiving Tunneled Router Advertisements . . . . . . . . 74 10.14. Receiving Tunneled Router Advertisements . . . . . . . . 78
10.15. Using Multiple Care-of Addresses . . . . . . . . . . . . 75 10.15. Using Multiple Care-of Addresses . . . . . . . . . . . . 79
10.16. Routing Multicast Packets . . . . . . . . . . . . . . . . 76 10.16. Routing Multicast Packets . . . . . . . . . . . . . . . . 80
10.17. Returning Home . . . . . . . . . . . . . . . . . . . . . 76 10.17. Returning Home . . . . . . . . . . . . . . . . . . . . . 80
11. Constants 78 11. Constants 82
12. IANA Considerations 79 12. IANA Considerations 83
13. Security Considerations 80 13. Security Considerations 84
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 80 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 84
13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 80 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 84
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 81 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 85
Changes from Previous Draft 83 Changes from Previous Draft 87
Acknowledgements 85 Acknowledgements 89
References 86 References 90
Chair's Address 88 Chair's Address 92
Authors' Addresses 89 Authors' Addresses 93
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) [5]. Without specific support Internet Protocol Version 6 (IPv6) [5]. 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 12, line 47 skipping to change at page 12, line 47
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.
Extensions to the format of these options MAY be included after the Sub-options within the format of these options MAY be included after
fixed portion of the option data specified in this document. The the fixed portion of the option data specified in this document. The
presence of such extensions will be indicated by the Option Length presence of such sub-options will be indicated by the Option Length
field within the option. When the Option Length is greater than the field within the option. When the Option Length is greater than the
length required for the option specified here, the remaining octets length required for the option specified here, the remaining octets
are interpreted as extensions. Currently, no extensions have been are interpreted as sub-options. The encoding and format of defined
defined. sub-options are described in Section 5.5.
4.3. Conceptual Data Structures 4.3. 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
skipping to change at page 16, line 10 skipping to change at page 16, line 10
discovery mechanism. The information for the list is learned discovery mechanism. The information for the list is learned
through receipt of the periodic unsolicited multicast Router through receipt of the periodic unsolicited multicast Router
Advertisements from each other home agent on the link, in which Advertisements from each other home agent on the link, in which
the Home Agent (H) bit is set, in a manner similar to the the Home Agent (H) bit is set, in a manner similar to the
Default Router List conceptual data structure maintained by Default Router List conceptual data structure maintained by
each host for Neighbor Discovery [13]. The Home Agents List each host for Neighbor Discovery [13]. The Home Agents List
MAY be implemented in any manner consistent with the external MAY be implemented in any manner consistent with the external
behavior described in this document. Each Home Agents List behavior described in this document. Each Home Agents List
entry conceptually contains the following fields: entry conceptually contains the following fields:
- The IP address of another router on the home link that this - The link-local IP address of another router on the home
node currently believes is operating as a home agent for link that this node currently believes is operating as
this link. A new entry is created or an existing entry is a home agent for this link. A new entry is created or
updated in the Home Agents List in response to receipt of a an existing entry is updated in the Home Agents List in
valid Router Advertisement in which the Home Agent (H) bit response to receipt of a valid Router Advertisement in
is set. which the Home Agent (H) bit is set. The link-local
address of the home agent is learned through the Source
Address of the Router Advertisements received from it [13].
- One or more global IP addresses for this home agent,
learned through Prefix Information options with the
Router Address (R) bit is set, received in Router
Advertisements from this link-local address. Global
addresses for the router in a Home Agents List entry MUST
be deleted once the prefix associated with that address is
no longer valid [13].
- The remaining lifetime of this Home Agents List entry. If - The remaining lifetime of this Home Agents List entry. If
a Home Agent Information Option is present in a Router a Home Agent Information Option is present in a Router
Advertisement received from a home agent, the lifetime of Advertisement received from a home agent, the lifetime of
the Home Agents List entry representing this home agent the Home Agents List entry representing this home agent
is initialized from the Home Agent Lifetime field in the is initialized from the Home Agent Lifetime field in the
option; otherwise, the lifetime is initialized from the option; otherwise, the lifetime is initialized from the
Router Lifetime field in the received Router Advertisement. Router Lifetime field in the received Router Advertisement.
The Home Agents List entry lifetime is decremented until it The Home Agents List entry lifetime is decremented until it
reaches zero, at which time this entry MUST be deleted from reaches zero, at which time this entry MUST be deleted from
skipping to change at page 19, line 36 skipping to change at page 19, line 36
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Care-of Address + + Care-of Address +
| (only present if C bit set) | | (only present if C bit set) |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
195 ??? 195 ???
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. For the excluding the Option Type and Option Length fields. This field
current definition of the Binding Update option, the minimum MUST be set to 8 (or to 24 if the Care-of Address Present (C)
value for this field is 8; the length is 24 if the Care-of bit is set), plus the total length of all sub-options present,
Address Present (C) bit is set. including their Sub-Option Type and Sub-Option Len fields.
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobile node to The Acknowledge (A) bit is set by the sending mobile node to
request a Binding Acknowledgement (Section 5.2) be returned request a Binding Acknowledgement (Section 5.2) be returned
upon receipt of the Binding Update. upon receipt of the Binding Update.
Home Registration (H) Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node The Home Registration (H) bit is set by the sending mobile node
skipping to change at page 21, line 27 skipping to change at page 21, line 34
Care-of Address Care-of Address
This field in the Binding Update is optional and is only This field in the Binding Update is optional and is only
present when the Care-of Address Present (C) bit is set. If present when the Care-of Address Present (C) bit is set. If
present, it gives the care-of address of the mobile node for present, it gives the care-of address of the mobile node for
this binding. For most Binding Updates sent, it is expected this binding. For most Binding Updates sent, it is expected
that this field will not be present, and instead that the that this field will not be present, and instead that the
care-of address for the binding will be given by the Source care-of address for the binding will be given by the Source
Address field in the packet's IPv6 header. Address field in the packet's IPv6 header.
Sub-Options
Additional information, associated with this Binding Update
option, that need not be present in all Binding Updates sent.
This use of sub-options also allows for future extensions to
the format of the Binding Update option to be defined. The
encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding
Update option:
- Unique Identifier Sub-Option
Any packet that includes a Binding Update option MUST also include Any packet that includes a Binding Update option MUST also include
a Home Address option. The home address of the mobile node in the a Home Address option. The home address of the mobile node in the
binding given in the Binding Update option is indicated by the Home binding given in the Binding Update option is indicated by the Home
Address field in the Home Address option in the packet. Address field in the Home Address option in the packet.
Any packet that includes a Binding Update option MUST also include Any packet that includes a Binding Update option MUST also include
either an AH [8] or ESP [9] header providing sender authentication, either an AH [8] or ESP [9] header providing sender authentication,
data integrity protection, and replay protection. data integrity protection, and replay protection.
If the care-of address in the binding (either the Care-of Address If the care-of address in the binding (either the Care-of Address
skipping to change at page 22, line 19 skipping to change at page 23, line 5
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 [5]. For the Binding indicate specific processing of the option [5]. For the Binding
Update option, these three bits are set to 110, indicating that any Update option, these three bits are set to 110, indicating that any
IPv6 node processing this option that does not recognize the Option IPv6 node processing this option that does not recognize the Option
Type must discard the packet and, only if the packet's Destination Type must discard the packet and, only if the packet's Destination
Address was not a multicast address, return an ICMP Parameter Address was not a multicast address, return an ICMP Parameter
Problem, Code 2, message to the packet's Source Address; and that the Problem, 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 data within the option cannot change en-route to the packet's final
destination. destination.
Extensions to the Binding Update option format may be included after
the fixed portion of the Binding Update option specified above.
The presence of such extensions will be indicated by the Option
Length field. When the Option Length is greater than the length
defined above, the remaining octets are interpreted as extensions.
Currently, no extensions have been defined.
5.2. Binding Acknowledgement Option Format 5.2. Binding Acknowledgement Option Format
The Binding Acknowledgement destination option is used to acknowledge The Binding Acknowledgement destination option is used to acknowledge
receipt of a Binding Update option (Section 5.1). When a node receipt of a Binding Update option (Section 5.1). When a node
receives a packet containing a Binding Update option, with this receives a packet containing a Binding Update option, with this
node being the destination of the packet (only the destination node node being the destination of the packet (only the destination
processes the option since it is a destination option), this node node processes the option since it is a destination option),
MUST return a Binding Acknowledgement to the source of the packet, this node MUST return a Binding Acknowledgement to the source
if the Acknowledge (A) bit is set in the Binding Update. As a of the packet, if the Acknowledge (A) bit is set in the Binding
destination option, this node MAY included it in any existing packet Update. As a destination option, this node MAY included the Binding
being sent to the mobile node or MAY send it in a packet by itself; a Acknowledgement in any existing packet being sent to the mobile node
packet containing a Binding Acknowledgement is sent in the same way or MAY send it in a packet by itself. A packet containing a Binding
as any packet to a mobile node (Section 8.9). Acknowledgement is sent in the same way as any packet to a mobile
node, using a Routing header to route the packet to the mobile node
by way of the care-of address in the binding (Section 8.9).
The Binding Acknowledgement option is encoded in type-length-value The Binding Acknowledgement option is encoded in type-length-value
(TLV) format as follows: (TLV) format as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Option Type | | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Sequence Number | | Option Length | Status | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh | | Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Sub-Options...
+ + +-+-+-+-+-+-+-+-+-+-+-+-
. .
. Home Agents List .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type Option Type
2 ??? 2 ???
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field excluding the Option Type and Option Length fields. This field
MUST be set to 11, except when the Status field is equal to 135 MUST be set to 11 plus the total length of all sub-options
(dynamic home agent address discovery response), in which case present, including their Sub-Option Type and Sub-Option Len
this field MUST be set to 11 + 16 * N, where N is the number of fields.
IP addresses included in the Home Agents List field; the Home
Agents List field MUST NOT be included in the option if the
Status field is not set to 135.
Status Status
8-bit unsigned integer indicating the disposition of the 8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128 Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
0 Binding Update accepted 0 Binding Update accepted
skipping to change at page 25, line 29 skipping to change at page 25, line 21
Acknowledgement is not serving as the mobile node's home agent, Acknowledgement is not serving as the mobile node's home agent,
the Refresh period SHOULD be set equal to the Lifetime period the Refresh period SHOULD be set equal to the Lifetime period
in the Binding Acknowledgement; even if this node loses this in the Binding Acknowledgement; even if this node loses this
cache entry due to a failure of the node, packets from it can cache entry due to a failure of the node, packets from it can
still reach the mobile node through the mobile node's home still reach the mobile node through the mobile node's home
agent, causing a new Binding Update to this node to allow it agent, causing a new Binding Update to this node to allow it
to recreate this cache entry. The value of this field is to recreate this cache entry. The value of this field is
undefined if the Status field indicates that the Binding Update undefined if the Status field indicates that the Binding Update
was rejected. was rejected.
Home Agents List Sub-Options
A list of home agents on the home link for the mobile node to Additional information, associated with this Binding
which this Binding Acknowledgement is sent. This field MUST Acknowledgement option, that need not be present in all Binding
NOT be present (zero addresses listed) unless the Binding Acknowledgements sent. This use of sub-options also allows for
Acknowledgement is sent in response to an anycast Binding future extensions to the format of the Binding Acknowledgement
Update sent by this mobile node attempting dynamic home agent option to be defined. The encoding and format of defined
address discovery. In this case, the Status field MUST be sub-options are described in Section 5.5. The following
set to 135 (dynamic home agent address discovery response). sub-options are valid in a Binding Acknowledgement option:
The construction of the Home Agents List field in a Binding
Acknowledgement is defined in Section 9.2. - Home Agents List Sub-Option
Any packet that includes a Binding Acknowledgement option MUST Any packet that includes a Binding Acknowledgement option MUST
also include either an AH [8] or ESP [9] header providing sender also include either an AH [8] or ESP [9] header providing sender
authentication, data integrity protection, and replay protection. authentication, data integrity protection, and replay protection.
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
skipping to change at page 27, line 21 skipping to change at page 27, line 21
Binding Request option is sent in the same way as any packet to a Binding Request option is sent in the same way as any packet to a
mobile node (Section 8.9). When a mobile node receives a packet mobile node (Section 8.9). When a mobile node receives a packet
containing a Binding Request option, it SHOULD return a Binding containing a Binding Request option, it SHOULD return a Binding
Update (Section 5.1) to the source of the Binding Request. Update (Section 5.1) to the source of the Binding Request.
The Binding Request option is encoded in type-length-value (TLV) The Binding Request option is encoded in type-length-value (TLV)
format as follows: format as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Option Type | Option Length | | Option Type | Option Length | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
3 ??? 3 ???
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. For the excluding the Option Type and Option Length fields. This field
current definition of the Binding Request option, this field MUST be set to 0 plus the total length of all sub-options
MUST be set to 0. present, including their Sub-Option Type and Sub-Option Len
fields.
Sub-Options
Additional information, associated with this Binding Request
option, that need not be present in all Binding Requests sent.
This use of sub-options also allows for future extensions to
the format of the Binding Request option to be defined. The
encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding
Request option:
- Unique Identifier Sub-Option
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 [5]. For the Binding indicate specific processing of the option [5]. For the Binding
Request option, these three bits are set to 000, indicating that any Request option, these three bits are set to 000, indicating that any
IPv6 node processing this option that does not recognize the Option IPv6 node processing this option that does not recognize the Option
Type must skip over this option and continue processing the header, Type must skip over this option and continue processing the header,
and that the data within the option cannot change en-route to the and that the data within the option cannot change en-route to the
packet's final destination. packet's final destination.
Extensions to the Binding Request option format may be included after
the fixed portion of the Binding Request option specified above.
The presence of such extensions will be indicated by the Option
Length field. When the Option Length is greater than 0 octets,
the remaining octets are interpreted as extensions. Currently, no
extensions have been defined.
5.4. Home Address Option Format 5.4. Home Address Option Format
The Home Address destination option is used in a packet sent by a The Home Address destination option is used in a packet sent by a
mobile node while away from home, to inform the recipient of that mobile node while away from home, to inform the recipient of that
packet of the mobile node's home address. For packets sent by a packet of the mobile node's home address. For packets sent by a
mobile node while away from home, the mobile node generally uses mobile node while away from home, the mobile node generally uses
one of its care-of addresses as the Source Address in the packet's one of its care-of addresses as the Source Address in the packet's
IPv6 header. By including a Home Address option in the packet, the IPv6 header. By including a Home Address option in the packet, the
correspondent node receiving the packet is able to substitute the correspondent node receiving the packet is able to substitute the
mobile node's home address for this care-of address when processing mobile node's home address for this care-of address when processing
skipping to change at page 28, line 34 skipping to change at page 29, line 34
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
196 ??? 196 ???
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. For the excluding the Option Type and Option Length fields. This field
current definition of the Home Address option, this field MUST MUST be set to 16 plus the total length of all sub-options
be set to 16. present, including their Sub-Option Type and Sub-Option Len
fields.
Home Address Home Address
The home address of the mobile node sending the packet. The home address of the mobile node sending the packet.
Sub-Options
Additional information, associated with this Home Address
option, that need not be present in all Home Address options
sent. This use of sub-options also allows for future
extensions to the format of the Home Address option to be
defined. The encoding and format of defined sub-options are
described in Section 5.5. Currently, no valid sub-options are
defined for use in a Home Address option.
The inclusion of a Home Address option in a packet affects the The inclusion of a Home Address option in a packet affects the
receiving node's processing of only this single packet; no state is receiving node's processing of only this single packet; no state is
created or modified in the receiving node as a result of receiving a created or modified in the receiving node as a result of receiving a
Home Address option in a packet. In particular, the presence of a Home Address option in a packet. In particular, the presence of a
Home Address option in a received packet MUST NOT alter the contents Home Address option in a received packet MUST NOT alter the contents
of the receiver's Binding Cache and MUST NOT cause any changes in the of the receiver's Binding Cache and MUST NOT cause any changes in the
routing of subsequent packets sent by this receiving node. routing of subsequent packets sent by this receiving node.
No authentication of the Home Address option is required, except that No authentication of the Home Address option is required, except that
if the IPv6 header of a packet is covered by authentication, then if the IPv6 header of a packet is covered by authentication, then
skipping to change at page 29, line 38 skipping to change at page 31, line 5
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 [5]. For the Home Address indicate specific processing of the option [5]. 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.
Extensions to the Home Address option format may be included after 5.5. Mobile IPv6 Destination Option Sub-Options
the fixed portion of the Home Address option specified above.
The presence of such extensions will be indicated by the Option In order to allow optional fields that may not be needed in most uses
Length field. When the Option Length is greater than 8 octets, of any given Mobile IPv6 destination option, and to allow future
the remaining octets are interpreted as extensions. Currently, no extensions to the format of these destination options to be defined,
extensions have been defined. any of the Mobile IPv6 destination options defined in this document
MAY include one or more sub-options.
Such sub-options are included in the data portion of the destination
option itself, after the fixed portion of the option data specified
for that particular destination option (Sections 5.1 through 5.4).
The presence of such sub-options will be indicated by the Option
Length field. When the Option Length is greater than the standard
length defined for that destination option, the remaining octets are
interpreted as sub-options.
These sub-options are encoded within the remaining space of the
option data for that option, using a type-length-value (TLV) format
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type
8-bit identifier of the type of sub-option. In processing a
Mobile IPv6 destination option containing a sub-option for
which the Sub-Option Type value is not recognized by the
receiver, the receiver SHOULD quietly ignore and skip over the
sub-option, correctly handling any remaining sub-options in the
option.
Sub-Option Length
8-bit unsigned integer. Length of the Sub-Option Data field
of this sub-option, in octets. The Sub-Option Len does not
include the length of the Sub-Option Type and Sub-Option Len
fields.
Sub-Option Data
Variable-length field. Sub-Option-Type-specific data.
Each section above defining the Mobile IPv6 destination options
specifies which of the defined sub-options is valid for that
destination option.
Currently, the following two sub-option types are defined for use in
Mobile IPv6 destination options:
Unique Identifier Sub-Option
This sub-option is valid only in Binding Request and Binding
Update destination options. The Sub-Option Data contains a
single 16-bit value that serves to uniquely identify a Binding
Request among those sent by this Source Address, and to allow
the Binding Update to identify the specific Binding Request to
which it responds. This matching of Binding Updates to Binding
Requests is required in the procedure for renumbering the home
subnet while a mobile node is away from home (Section 9.7).
The Sub-Option Type and Sub-Option Len fields for this
sub-option MUST be set as follows:
- Sub-Option Type: 1
- Sub-Option Len: 2
Home Agents List Sub-Option
This sub-option is valid only in a Binding Acknowledgement
destination option. The Sub-Option Data contains a list of
home agents on the home link for the mobile node to which
this Binding Acknowledgement is sent. This sub-option MUST
NOT be present unless the Binding Acknowledgement is sent in
response to an anycast Binding Update sent by a mobile node
attempting dynamic home agent address discovery. In this case,
the Status field in the Binding Acknowledgement MUST be set
to 135 (dynamic home agent address discovery response). The
specific construction of the Sub-Option Data field for this
sub-option is defined in Section 9.2. The Sub-Option Type
and Sub-Option Len fields for this sub-option MUST be set as
follows:
- Sub-Option Type: 2
- Sub-Option Len: 16 * N, where N is the number of home
agent addresses included in the Sub-Option Data.
6. Modifications to IPv6 Neighbor Discovery 6. Modifications to IPv6 Neighbor Discovery
6.1. Modified Router Advertisement Message Format 6.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement Mobile IPv6 modifies the format of the Router Advertisement
message [13] by the addition of a single flag bit for use in the message [13] by the addition of a single flag bit for use in the
dynamic home agent address discovery mechanism (Sections 9.2 dynamic home agent address discovery mechanism (Sections 9.2
and 10.6). The format of the Router Advertisement message is and 10.6). The format of the Router Advertisement message is
as follows: as follows:
skipping to change at page 31, line 11 skipping to change at page 34, line 11
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Home Agent (H) bit. addition of the Home Agent (H) bit.
6.2. Modified Prefix Information Option Format 6.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address for two Mobile IPv6 requires knowledge of a router's global address for two
reasons: reasons:
- To allow a home agent (a router) to learn the address of all - To allow a home agent (a router) to learn the address of all
other home agents on the link for which it is proving home agent other home agents on the link for which it is providing home
service, for use in building its Home Agents List as part of the agent service, for use in building its Home Agents List as
dynamic home agent address discovery mechanism (Sections 9.2 part of the dynamic home agent address discovery mechanism
and 10.6). (Sections 9.2 and 10.6).
- To allow a mobile node to send a Binding Update to its previous - To allow a mobile node to send a Binding Update to its previous
default router, after moving to a new subnet and acquiring a new default router, after moving to a new subnet and acquiring a new
care-of address (Section 10.8). care-of address (Section 10.8).
However, Neighbor Discovery [13] only advertises a router's However, Neighbor Discovery [13] only advertises a router's
link-local address, by requiring this address to be used as the IP link-local address, by requiring this address to be used as the IP
Source Address of each Router Advertisement. Source Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to easily Mobile IPv6 extends Neighbor Discovery to allow a router to easily
skipping to change at page 32, line 30 skipping to change at page 35, line 30
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Router Address (R) bit. addition of the Router Address (R) bit.
In a solicited Router Advertisement, a router MUST include at least In a solicited Router Advertisement, a router MUST include at least
one Prefix Information option with the Router Address (R) bit set. one Prefix Information option with the Router Address (R) bit set.
Neighbor Discovery specifies that, if including all options in a Neighbor Discovery specifies that, if including all options in a
Router Advertisement causes the size of the Advertisement to exceed Router Advertisement causes the size of the Advertisement to exceed
the link MTU, multiple Advertisements can be sent, each containing the link MTU, multiple Advertisements can be sent, each containing
a subset of the options [13]. In this case, at least one of these a subset of the options [13]. In this case, at least one of these
multiple Advertisements begin sent instead of a single larger multiple Advertisements being sent instead of a single larger
solicited Advertisement, MUST include a Prefix Information option solicited Advertisement, MUST include a Prefix Information option
with the Router Address (R) bit set. with the Router Address (R) bit set.
All routers SHOULD include at least one Prefix Information option All routers SHOULD include at least on Prefix Information option with
with the Router Address (R) bit set, in each unsolicited multicast the Router Address (R) bit set, in each unsolicited multicast Router
Router Advertisement that they send. If multiple Advertisements Advertisement that they send. If multiple Advertisements are being
are being sent instead of a single larger unsolicited multicast sent instead of a single larger unsolicited multicast Advertisement,
Advertisement, at least one of these multiple Advertisements SHOULD at least one of these multiple Advertisements SHOULD include a Prefix
include a Prefix Information option with the Router Address (R) bit Information option with the Router Address (R) bit set.
set.
6.3. New Advertisement Interval Option Format 6.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the interval at which the Router Advertisement messages to advertise the interval at which the
sending router sends unsolicited multicast Router Advertisements. sending router sends unsolicited multicast Router Advertisements.
The format of the Advertisement Interval option is as follows: The format of the Advertisement Interval option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 34, line 37 skipping to change at page 37, line 37
the type and length fields) in units of 8 octets. The value of the type and length fields) in units of 8 octets. The value of
this field MUST be 1. this field MUST be 1.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Home Agent Preference Home Agent Preference
16-bit signed, twos-complement integer. The preference 16-bit signed, twos-complement integer. The preference for
for the home agent sending this Router Advertisement, for the home agent sending this Router Advertisement, for use
use in ordering the Home Agents List returned in a Binding in ordering the addresses contained in the Home Agents List
Acknowledgement; higher values mean more preferable. If this Sub-Option returned in a Binding Acknowledgement; higher values
option is not included in a Router Advertisement in which the mean more preferable. If this option is not included in a
Home Agent (H) bit is set, the preference value for this home Router Advertisement in which the Home Agent (H) bit is set,
agent SHOULD be considered to be 0. Values greater than 0 the preference value for this home agent SHOULD be considered
indicate a home agent more preferable than this default value, to be 0. Values greater than 0 indicate a home agent more
and values less than 0 indicate a less preferable home agent. preferable than this default value, and values less than 0
indicate a less preferable home agent.
Home Agent Lifetime Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the home 16-bit unsigned integer. The lifetime associated with the home
agent in units of seconds. The maximum value corresponds to agent in units of seconds. The maximum value corresponds to
18.2 hours. A value of 0 MUST NOT be used. The Home Agent 18.2 hours. A value of 0 MUST NOT be used. The Home Agent
Lifetime applies only to this router's usefulness as a home Lifetime applies only to this router's usefulness as a home
agent; it does not apply to information contained in other agent; it does not apply to information contained in other
message fields or options. If this option is not included in message fields or options. If this option is not included in
a Router Advertisement in which the Home Agent (H) bit is set, a Router Advertisement in which the Home Agent (H) bit is set,
skipping to change at page 42, line 19 skipping to change at page 45, line 19
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
Packets sent by a mobile node while away from home generally include Packets sent by a mobile node while away from home generally include
a Home Address option. When any node receives a packet containing a Home Address option. When any node receives a packet containing
a Home Address option, it MUST process the option in a manner a Home Address option, it MUST process the option in a manner
consistent with copying the Home Address field from the Home Address consistent with copying the Home Address field from the Home Address
option into the IPv6 header, replacing the original value of the option into the IPv6 header, replacing the original value of the
Source Address field there. Source Address field there. However, any actual modifications to
the Source Address field in the packet's IPv6 header MUST not be
performed until after all processing of other options contained in
this same Destination Options extension header is completed.
Further processing of such a packet (e.g., at the transport layer) Further processing of such a packet after option processing (e.g.,
thus need not know that the original Source Address was a care-of at the transport layer) thus need not know that the original Source
address, or that the Home Address option was used in the packet. Address was a care-of address, or that the Home Address option was
Since the sending mobile node uses its home address at the transport used in the packet. Since the sending mobile node uses its home
layer when sending such a packet, the use of the care-of address address at the transport layer when sending such a packet, the use of
and Home Address option is transparent to both the mobile node and the care-of address and Home Address option is transparent to both
the correspondent node above the level of the Home Address option the mobile node and the correspondent node above the level of the
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 contains a valid AH [8] or ESP [9] header that - The packet contains a valid AH [8] or ESP [9] header that
provides sender authentication, integrity protection, and replay provides sender authentication, integrity protection, and replay
protection. protection.
skipping to change at page 43, line 13 skipping to change at page 46, line 15
performed modulo 2**16. 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 Destination Address in the packet's IPv6 header is the - If the Destination Address in the packet's IPv6 header is the
Home-Agents anycast address for a local prefix and this address Home-Agents anycast address for an on-local prefix and this
is assigned to one of this node's network interfaces, then the address is assigned to one of this node's network interfaces,
mobile node sending this Binding Update is attempting dynamic then the mobile node sending this Binding Update is attempting
home agent address discovery. Processing for this type of dynamic home agent address discovery. Processing for this type
received Binding Update is described in Section 9.2. (If the of received Binding Update is described in Section 9.2. (If the
Destination Address is not assigned to one of this node's network Destination Address is not assigned to one of this node's network
interfaces, then the packet would have been forwarded as a normal interfaces, then the packet would have been forwarded as a normal
packet and the Binding Update, as a destination option, would not packet and the Binding Update, as a destination option, would not
be processed in any way by this node.) be processed in any way by this node.)
- 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
for the binding (as given in the Home Address option in the for the binding (as given in the Home Address option in the
packet), then this is a request to cache a binding for the packet), then this is a request to cache a binding for the
mobile node. If the Home Registration (H) bit is set in the mobile node. If the Home Registration (H) bit is set in the
skipping to change at page 49, line 30 skipping to change at page 52, line 30
processing algorithm specified for Neighbor Discovery [13], the home processing algorithm specified for Neighbor Discovery [13], the home
agent performs the following steps, in addition to any steps already agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery: required of it by Neighbor Discovery:
- If the Home Agent (H) bit in the Router Advertisement is not set, - If the Home Agent (H) bit in the Router Advertisement is not set,
skip all of the following steps. There are no special processing skip all of the following steps. There are no special processing
steps required by Mobile IP for this Router Advertisement, since steps required by Mobile IP for this Router Advertisement, since
the Advertisement was not sent by a home agent. the Advertisement was not sent by a home agent.
- Otherwise, extract the Source Address from the IP header of the - Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on Router Advertisement. This is the link-local IP address on this
this link of the home agent sending this Advertisement [13]. link of the home agent sending this Advertisement [13].
Determine the global address of the router based on the
Prefix Information option received from it in which the Router
Address (R) bit is set (Section 6.2).
- Determine from the Router Advertisement the preference for this - Determine from the Router Advertisement the preference for this
home agent. If the Router Advertisement contains a Home Agent home agent. If the Router Advertisement contains a Home Agent
Information Option, then the preference is taken from the Home Information Option, then the preference is taken from the Home
Agent Preference field in the option; otherwise, the default Agent Preference field in the option; otherwise, the default
preference of 0 SHOULD be used. preference of 0 SHOULD be used.
- Determine from the Router Advertisement the lifetime for - Determine from the Router Advertisement the lifetime for
this home agent. If the Router Advertisement contains a Home this home agent. If the Router Advertisement contains a Home
Agent Information Option, then the lifetime is taken from Agent Information Option, then the lifetime is taken from
the Home Agent Lifetime field in the option; otherwise, the the Home Agent Lifetime field in the option; otherwise, the
lifetime specified by the Router Lifetime field in the Router lifetime specified by the Router Lifetime field in the Router
Advertisement SHOULD be used. Advertisement SHOULD be used.
- If the global address of the home agent sending this - If the link-local address of the home agent sending this
Advertisement, as determined above, is not already present in the Advertisement is already present in this home agent's Home
Home Agents List maintained by the receiving home agent, and the Agents List and the received home agent lifetime value is zero,
lifetime for the sending home agent, also as determined above, immediately delete this entry in the Home Agents List.
- Otherwise, if the link-local address of the home agent sending
this Advertisement is already present in the receiving home
agent's Home Agents List, reset its lifetime and preference to
the values determined above.
- If the link-local address of the home agent sending this
Advertisement, as determined above, is not already present in
the Home Agents List maintained by the receiving home agent, and
the lifetime for the sending home agent, as determined above,
is non-zero, create a new entry in the list, and initialize its is non-zero, create a new entry in the list, and initialize its
lifetime and preference to the values determined above. lifetime and preference to the values determined above.
- If the global address of the home agent sending this - If the Home Agents List entry for the link-local address of
Advertisement is already present in the receiving home agent's the home agent sending this Advertisement was not deleted as
Home Agents List, reset its lifetime and preference to the values described above, determine any global address(es) of the home
determined above. agent based on each Prefix Information option received in
this Advertisement in which the Router Address (R) bit is set
- If the address is already present in this home agent's Home (Section 6.2). For each such global address determined from this
Agents List and the received home agent lifetime value is zero, Advertisement, add this global address to the list of global
immediately delete this entry in the Home Agents List. addresses for this home agent in this Home Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for A home agent SHOULD maintain an entry in its Home Agents List for
each such valid home agent address until that entry's lifetime each such valid home agent address until that entry's lifetime
expires, after which time the entry MUST be deleted. expires, after which time the entry MUST be deleted.
9.2. Dynamic Home Agent Address Discovery 9.2. Dynamic Home Agent Address Discovery
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
skipping to change at page 50, line 40 skipping to change at page 53, line 47
agent receiving such a Binding Update that is serving this subnet agent receiving such a Binding Update that is serving this subnet
(the home agent is configured with this anycast address on one of its (the home agent is configured with this anycast address on one of its
network interfaces) MUST reject the Binding Update and SHOULD return network interfaces) MUST reject the Binding Update and SHOULD return
a Binding Acknowledgement indicating this rejection, with the Source a Binding Acknowledgement indicating this rejection, with the Source
Address of the packet carrying the Binding Acknowledgement set to one Address of the packet carrying the Binding Acknowledgement set to one
of the global unicast addresses of the home agent. The Status field of the global unicast addresses of the home agent. The Status field
in the Binding Acknowledgement MUST be set to 135 (dynamic home agent in the Binding Acknowledgement MUST be set to 135 (dynamic home agent
address discovery response). address discovery response).
In this Binding Acknowledgement rejecting the dynamic home agent In this Binding Acknowledgement rejecting the dynamic home agent
address discovery Binding Update, this home agent SHOULD set the Home address discovery Binding Update, this home agent SHOULD include a
Agents List as follows: Home Agents List Sub-Option as follows:
- The Home Agents List in this Binding Acknowledgement SHOULD - The Home Agents List Sub-Option in this Binding Acknowledgement
contain the IP address of all home agents currently listed in SHOULD contain one global IP address for each home agent
this home agent's own Home Agents List (Section 4.3). However, currently listed in this home agent's own Home Agents List
if this home agent's own IP address would be placed in the list (Section 4.3). However, if this home agent's own global IP
(as described below) as the first entry in the list, then this address would be placed in the list (as described below) as the
home agent SHOULD NOT include its own address in the list in first entry in the list, then this home agent SHOULD NOT include
the Binding Acknowledgement. Not placing this home agent's own its own address in the list in the sub-option in the Binding
IP address in the list will cause the receiving mobile node Acknowledgement. Not placing this home agent's own IP address in
to consider this home agent as the most preferred home agent; the list will cause the receiving mobile node to consider this
otherwise, this home agent will be considered to be preferred in home agent as the most preferred home agent; otherwise, this home
its order given by its place in the list returned. agent will be considered to be preferred in its order given by
its place in the list returned.
- The IP addresses in the Home Agents List should be placed in - The IP addresses in the Home Agents List should be placed in
the Home Agents List in the Binding Acknowledgement in order the Home Agents List Sub-Option in the Binding Acknowledgement
of decreasing preference value, based either on the respective in order of decreasing preference value, based either on the
advertised preference from a Home Agent Information option or on respective advertised preference from a Home Agent Information
the default preference of 0 if no preference is advertised (or on option or on the default preference of 0 if no preference is
the configured home agent preference for this home agent itself). advertised (or on the configured home agent preference for this
The home agent with the highest preference SHOULD be listed home agent itself). The home agent with the highest preference
first, and the home agent with the lowest preference SHOULD be SHOULD be listed first, and the home agent with the lowest
listed last. preference SHOULD be listed last.
- Among home agents with equal preference, their IP addresses in - Among home agents with equal preference, their IP addresses in
the Home Agents List SHOULD be listed in an order randomized with the Home Agents List SHOULD be listed in an order randomized with
respect to other home agents with equal preference, each time respect to other home agents with equal preference, each time a
a Binding Acknowledgement with a non-empty Home Agents List is Binding Acknowledgement with a Home Agents List Sub-Option is
returned by this home agent. returned by this home agent.
- The Option Length field in this Binding Acknowledgement - For each entry in this home agent's Home Agents List, if more
MUST be set to 11 + 16 * N, where N is the number of IP than one global IP address is associated with this list entry,
addresses included in the Home Agents List field in the Binding then one of these global IP addresses SHOULD be selected to
Acknowledgement. include in the Home Agents List Sub-Option to be returned in the
Binding Acknowledgement. As described in Section 4.3, one Home
Agents List entry, identified by the home agent's link-local
address, exists for each home agent on the link; associated with
that list entry is one or more global IP addresses for this
home agent, learned through Prefix Information options with the
Router Address (R) bit is set, received in Router Advertisements
from this link-local address. The selected global IP address
for each home agent to include in forming the Home Agents List
Sub-Option to be returned in the Binding Acknowledgement MUST
be the global IP address of the respective home agent sharing a
prefix with the mobile node's home address for which the Binding
Acknowledgement is being returned; if no such global IP address
is known for some home agent, an entry for that home agent MUST
NOT be included in the Home Agents List Sub-Option returned in
the Binding Acknowledgement.
- In order to avoid the possibility of the packet carrying the
Binding Acknowledgement being fragmented, if the resulting
total packet size containing the complete Home Agents List
Sub-Option would exceed the minimum IPv6 MTU [5], the home agent
SHOULD reduce the number of home agent IP addresses returned
in the packet to the number of addresses that will fit without
exceeding this limit. The home agent addresses returned in the
packet SHOULD be those from the complete list with the highest
preference.
The mobile node, upon receiving this Binding Acknowledgement, MAY The mobile node, upon receiving this Binding Acknowledgement, MAY
then resend its Binding Update to the home agent address given as the then resend its Binding Update to the home agent address given as the
IP Source Address of the packet carrying the Binding Acknowledgement IP Source Address of the packet carrying the Binding Acknowledgement
or to any of the unicast IP addresses listed in the Home Agents List or to any of the unicast IP addresses listed in the Home Agents List
field in the Acknowledgement. For example, the mobile node may Sub-Option in the Acknowledgement. For example, the mobile node may
re-attempt its home registration with each of these home agents in re-attempt its home registration with each of these home agents in
turn, by sending each a Binding Update and waiting for the matching turn, by sending each a Binding Update and waiting for the matching
Binding Acknowledgement, until its registration is accepted by one Binding Acknowledgement, until its registration is accepted by one
of these home agents. In trying each of the returned home agent of these home agents. In trying each of the returned home agent
addresses, the mobile node SHOULD try each in the order listed in the addresses, the mobile node SHOULD try each in the order listed in the
Home Agents List in the Binding Acknowledgement. If the home agent Home Agents List Sub-Option in the Binding Acknowledgement. If the
identified by the Source Address field in the IP header of the packet home agent identified by the Source Address field in the IP header
carrying the Binding Acknowledgement is not listed in the Home Agents of the packet carrying the Binding Acknowledgement is not listed in
List, it SHOULD be tried before the first address given in the list; the Home Agents List Sub-Option, it SHOULD be tried before the first
otherwise, it SHOULD be tried in the in its listed order. address given in the list; otherwise, it SHOULD be tried in the in
its listed order.
9.3. Primary Care-of Address Registration 9.3. Primary Care-of Address Registration
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 the receiving node to serve as its home Binding Update that requests the receiving node to serve as its home
agent, registering its primary care-of address. agent, registering its primary care-of address.
To begin processing the Binding Update, the home agent MUST perform To begin processing the Binding Update, the home agent MUST perform
skipping to change at page 52, line 52 skipping to change at page 56, line 35
IPv6 header (otherwise). IPv6 header (otherwise).
The home agent MUST mark this Binding Cache entry as a "home The home agent MUST mark this Binding Cache entry as a "home
registration" to indicate that the node is serving as a home registration" to indicate that the node is serving as a home
agent for this binding. Binding Cache entries marked as a "home agent for this binding. Binding Cache entries marked as a "home
registration" MUST be excluded from the normal cache replacement registration" MUST be excluded from the normal cache replacement
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.
The lifetime for the Binding Cache entry MUST NOT be greater than the The lifetime for the Binding Cache entry MUST NOT be greater than
remaining valid lifetime for the subnet prefix in the mobile node's the remaining valid lifetime for the subnet prefix in the mobile
home address specified with the Binding Update. The remaining valid node's home address specified with the Binding Update. The remaining
lifetime for this prefix is determined by the home agent based on valid lifetime for this prefix is determined by the home agent based
its own Prefix List entry for this prefix [13]. If the value of the on its own Prefix List entry for this prefix [13]. Furthermore,
Lifetime field specified by the mobile node in its Binding Update is if the Prefix Length field in the Binding Update is nonzero, then
greater than this prefix lifetime, the home agent MUST decrease the the lifetime for the Binding Cache entry MUST NOT be greater than
binding lifetime to less than or equal to the prefix valid lifetime. the minimum remaining valid lifetime for all subnet prefixes on
The home agent MAY further decrease the specified lifetime for the the mobile node's home link. If the value of the Lifetime field
specified by the mobile node in its Binding Update is greater than
this prefix lifetime, the home agent MUST decrease 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 59, line 5 skipping to change at page 62, line 43
- The Source Address in the packet's IPv6 header MUST be set to the - The Source Address in the packet's IPv6 header MUST be set to the
home agent's IP address to which the mobile node addressed its home agent's IP address to which the mobile node addressed its
current home registration. current home registration.
- The packet MUST include either an AH [8] or ESP [9] header - The packet MUST include either an AH [8] or ESP [9] header
providing sender authentication, data integrity protection, and providing sender authentication, data integrity protection, and
replay protection. replay protection.
- The packet MUST include a Binding Request destination option. - The packet MUST include a Binding Request destination option.
- The Binding Request destination option MUST include a Unique
Identifier Sub-Option (Section 5.5), with the unique identifier
in the sub-option data set to a value different than that in
any other Binding Request sent recently by this node. The word
"recently" here means within the maximum likely lifetime of a
packet, including transit time from source to destination and
time spent awaiting reassembly with other fragments of the same
packet, if fragmented. However, it is not required that a source
node know the maximum packet lifetime. Rather, it is assumed
that the requirement can be met by maintaining a simple 16-bit
"wrap-around" counter to generate unique identifiers for Binding
Requests that contain a Unique Identifier Sub-Option, incremented
each time a Binding Request containing a Unique Identifier
Sub-Option is sent.
- The packet MUST be tunneled to the mobile node's primary care-of - The packet MUST be tunneled to the mobile node's primary care-of
address using a Routing header, in the same way as any packet address using a Routing header, in the same way as any packet
sent to the mobile node originated by the home agent (rather than sent to the mobile node originated by the home agent (rather than
using IPv6 encapsulation, as would be used by the home agent for using IPv6 encapsulation, as would be used by the home agent for
intercepted packets). intercepted packets).
The home agent SHOULD periodically continue to retransmit this The home agent SHOULD periodically continue to retransmit this
tunneled packet to the mobile node, until it is acknowledged by the tunneled packet to the mobile node, until it is acknowledged by
receipt from the mobile node of a Binding Update matching the Binding the receipt from the mobile node of a Binding Update matching
Request in the packet (i.e., with matching Sequence Number). If the Binding Request in the packet (i.e., with matching Sequence
while the mobile node is still retransmitting a Router Advertisement Number). A Binding Update matches a Binding Request if it specifies
to the mobile node, another condition as described above occurs on a binding for the mobile node to which the Binding Request was sent
the home link causing another Router Advertisement to be tunneled to and contains a Unique Identifier Sub-Option matching the unique
the mobile node, the home agent SHOULD combine any Prefix Information identifier sent in the Unique Identifier Sub-Option in the Binding
options in the unacknowledged Router Advertisement into the new Request.
Router Advertisement and then begin retransmitting the new Router
Advertisement rather than the old one. If while the home agent is still retransmitting a Router
Advertisement to the mobile node, another condition as described
above occurs on the home link causing another Router Advertisement
to be tunneled to the mobile node, the home agent SHOULD combine any
Prefix Information options in the unacknowledged Router Advertisement
into the new Router Advertisement and then begin retransmitting the
new Router Advertisement rather than the old one. When tunneling
a new Router Advertisement, even if it contains Prefix Information
options sent previously in an unacknowledged tunneled Router
Advertisement, the home agent MUST generate a new unique identifer
for use in the Unique Identifier Sub-Option in the Binding Request
tunneled with the new Router Advertisement.
In addition, as described in Section 9.3, the lifetime returned by a In addition, as described in Section 9.3, the lifetime returned by a
mobile node's home agent in its Binding Acknowledgement in response mobile node's home agent in its Binding Acknowledgement in response
to registration of a new primary care-of address by the mobile node to registration of a new primary care-of address by the mobile node
MUST be no greater than the remaining valid lifetime for the subnet MUST be no greater than the remaining valid lifetime for the subnet
prefix in the mobile node's home address. Furthermore, as described prefix in the mobile node's home address. Furthermore, as described
in Section 10.7, Binding Updates sent by the mobile node to other in Section 10.7, Binding Updates sent by the mobile node to other
nodes MUST use a lifetime no greater than the remaining lifetime of nodes MUST use a lifetime no greater than the remaining lifetime of
its home registration of its primary care-of address. These limits its home registration of its primary care-of address. These limits
on a binding lifetimes ensure that no node uses a mobile node's home on a binding lifetimes ensure that no node uses a mobile node's home
skipping to change at page 69, line 36 skipping to change at page 73, line 36
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 home address for which the Binding Update was sent (the value
in the Home Address option in the packet carrying the Binding
Update).
- The remaining lifetime of the binding, initialized from the - The remaining lifetime of the binding, initialized from the
Lifetime field sent in the Binding Update. Lifetime field sent in the Binding Update.
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
skipping to change at page 71, line 31 skipping to change at page 75, line 31
10.8. Sending Binding Updates to the Previous Default Router 10.8. Sending Binding Updates to the Previous Default Router
After switching to a new default router (and thus also changing its After switching to a new default router (and thus also changing its
primary care-of address), a mobile node MAY send a Binding Update to primary care-of address), a mobile node MAY send a Binding Update to
its previous default router, giving its new care-of address. The its previous default router, giving its new care-of address. The
packet carrying the Binding Update MUST be addressed to the mobile packet carrying the Binding Update MUST be addressed to the mobile
node's previous default router's global unicast address, learned node's previous default router's global unicast address, learned
by the mobile node based on Prefix Information options received in by the mobile node based on Prefix Information options received in
Router Advertisements from it in which the Router Address (R) bit is Router Advertisements from it in which the Router Address (R) bit is
set. set (Sections 4.3 and 6.2).
If the mobile node sends such a Binding Update, the home address If the mobile node sends such a Binding Update, the home address
for the binding, specified in the Home Address option included in for the binding, specified in the Home Address option included in
the packet carrying this Binding Update, MUST be set the mobile the packet carrying this Binding Update, MUST be set the mobile
node's old primary care-of address (that it used while using this node's old primary care-of address (that it used while using this
default router), and the care-of address for the binding (either the default router), and the care-of address for the binding (either the
Source Address in the packet's IPv6 header or the Care-of Address Source Address in the packet's IPv6 header or the Care-of Address
field in the Binding Update) MUST be set to the mobile node's new field in the Binding Update) MUST be set to the mobile node's new
primary care-of address. In addition, the Home Registration (H) primary care-of address. In addition, the Home Registration (H)
bit MUST also be set in this Binding Update, to request the mobile bit MUST also be set in this Binding Update, to request the mobile
skipping to change at page 73, line 27 skipping to change at page 77, line 27
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.10. In particular, if the Status field specified in Section 10.10. In particular, if the Status field
is equal to 135 (dynamic home agent address discovery response), is equal to 135 (dynamic home agent address discovery response),
then the mobile node MAY reattempt its home registration with then the mobile node MAY reattempt its home registration with
the home agent address given in the Source Address field of the the home agent address given in the Source Address field of the
packet carrying the Binding Acknowledgement or with any of the packet carrying the Binding Acknowledgement or with any of the
home agent IP addresses listed in the Home Agents List field in home agent IP addresses listed in the Home Agents List Sub-Option
the Binding Acknowledgement. If any of these addresses is not a in the Binding Acknowledgement. If any of these addresses is not
global unicast address or does not have a subnet prefix equal to a global unicast address or does not have a subnet prefix equal
the mobile node's own subnet prefix, then that particular address to the mobile node's own subnet prefix, then that particular
MUST be ignored and the mobile node MUST NOT reattempt its home address MUST be ignored and the mobile node MUST NOT reattempt
registration with that home agent. its home registration with that home agent.
10.12. Receiving Binding Requests 10.12. Receiving Binding Requests
When a mobile node receives a packet containing a Binding Request, When a mobile node receives a packet containing a Binding Request,
it SHOULD return to the sender a packet containing a Binding Update. it SHOULD return to the sender a packet containing a Binding Update.
The Lifetime field in this Binding Update SHOULD be set to a new The Lifetime field in this Binding Update SHOULD be set to a new
lifetime, extending any current lifetime remaining from a previous lifetime, extending any current lifetime remaining from a previous
Binding Update sent to this node (as indicated in any existing Binding Update sent to this node (as indicated in any existing
Binding Update List entry for this node), except that this lifetime Binding Update List entry for this node), except that this lifetime
MUST NOT exceed the remaining lifetime for the mobile node's primary MUST NOT exceed the remaining lifetime for the mobile node's primary
skipping to change at page 74, line 5 skipping to change at page 78, line 5
Binding Update, the mobile node MUST update its Binding Update List Binding Update, the mobile node MUST update its Binding Update List
in the same way as for any other Binding Update sent by the mobile in the same way as for any other Binding Update sent by the mobile
node. node.
Note, however, that the mobile node MAY choose to keep its current Note, however, that the mobile node MAY choose to keep its current
binding private from the sender of the Binding Request. In this binding private from the sender of the Binding Request. In this
case, the mobile node instead SHOULD returns a Binding Update to the case, the mobile node instead SHOULD returns a Binding Update to the
sender, in which the Lifetime field is set to zero and the care-of sender, in which the Lifetime field is set to zero and the care-of
address is set to the mobile node's home address. address is set to the mobile node's home address.
If the Binding Request for which the Binding Update is being returned
contains a Unique Identifer Sub-Option, the Binding Update MUST also
include a Unique Identifier Sub-Option. The unique identifier in the
SUb-Option Data field of the Unique Identifier Sub-Option MUST be
copied from the unique identifier carried in the Binding Request.
10.13. Receiving ICMP Error Messages 10.13. 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.
skipping to change at page 75, line 5 skipping to change at page 79, line 13
Advertisement is the same as the home agent address to which the Advertisement is the same as the home agent address to which the
mobile node last sent an accepted "home registration" Binding mobile node last sent an accepted "home registration" Binding
Update to register its primary care-of address. Update to register its primary care-of address.
- The packet contains either an AH [8] or ESP [9] header providing - The packet contains either an AH [8] or ESP [9] header providing
sender authentication, data integrity protection, and replay sender authentication, data integrity protection, and replay
protection. protection.
- The packet contains a Binding Request destination option. - The packet contains a Binding Request destination option.
- The Binding Request option contains a Unique Identifier
Sub-Option.
Any received tunneled Router Advertisement not meeting all of these Any received tunneled Router Advertisement not meeting all of these
tests MUST be silently discarded. tests MUST be silently discarded.
If a received tunneled Router Advertisement is not discarded If a received tunneled Router Advertisement is not discarded
according to the tests listed above, the mobile node MUST process the according to the tests listed above, the mobile node MUST process the
Router Advertisement as if it were connected to its home link [13]. Router Advertisement as if it were connected to its home link [13].
Such processing MAY result in the mobile node configuring a new home Such processing MAY result in the mobile node configuring a new home
address, although due to separation between preferred lifetime and address, although due to separation between preferred lifetime and
valid lifetime, such changes should not affect most communication by valid lifetime, such changes should not affect most communication by
the mobile node, in the same way as for nodes that are at home. the mobile node, in the same way as for nodes that are at home.
skipping to change at page 79, line 14 skipping to change at page 83, line 14
12. IANA Considerations 12. IANA Considerations
This document defines four new types of IPv6 destination options, This document defines four new types of IPv6 destination options,
each of which must be assigned an Option Type value: each of which must be assigned an Option Type value:
- The Binding Update option, described in Section 5.1 - The Binding Update option, described in Section 5.1
- The Binding Acknowledgement option, described in Section 5.2 - The Binding Acknowledgement option, described in Section 5.2
- The binding Request option, described in Section 5.3 - The Binding Request option, described in Section 5.3
- The Home Address option, described in Section 5.4 - The Home Address option, described in Section 5.4
In addition, this document defines two new Neighbor Discovery [13] In addition, this document defines two new Neighbor Discovery [13]
options, which must be assigned Option Type values within the option options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery messages: numbering space for Neighbor Discovery messages:
- The Advertisement Interval option, described in Section 6.3. - The Advertisement Interval option, described in Section 6.3.
- The Home Agent Information option, described in Section 6.4. - The Home Agent Information option, described in Section 6.4.
skipping to change at page 83, line 9 skipping to change at page 87, line 9
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 Draft Changes from Previous 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-05.txt: draft-ietf-mobileip-ipv6-06.txt:
- Clarified that the Advertisement Interval option in Section 6.3
MAY be included in Router Advertisements by any router, not just
by home agents.
- Modified Section 6.5 to document a required change to the
MaxRtrAdvInterval limit, in addition to the change to the
MinRtrAdvInterval limit, and clarified that these new limits MAY
be used by any router, not just by home agents.
- Added Section 6.6 to document new limits on sending Router
Solicitations by a mobile node while away from home. These
changes are related to the MAX_RTR_SOLICITATIONS and
RTR_SOLICITATION_INTERVAL Neighbor Discovery constants.
- Added Section 6.2 documenting a modification to the format of
a Prefix Information option for use in Router Advertisement
messages. This modification allows a router to easily and
efficiently advertise its own global unicast address.
- Defined a new Home Agent Information Option for Router
Advertisements (Section 6.4). This option allows those routers
functioning as a home agent to optionally specify a preference
(relative to other home agents on this link) and a lifetime for
this advertisement for providing home agent service. Use of this
option by home agents is optional.
- Added Section 10.2, defining the general procedures to be used
by a mobile node in receiving packets while away from home. In
particular, for packets received with a Routing header, this
section defines an exception for any use of a Routing header
automatically derived by "reversing" the received Routing header,
for any response packets sent by upper-layer protocols.
- Changed the treatment of packets addressed to a mobile node's
site-local address while the mobile node is away from home. The
current consensus of the Mobile IP Working Group is that such
packets SHOULD be tunneled to the mobile node by default, but
this behavior MUST be configurable to disable it; currently,
the exact definition and semantics of a "site" and a site-local
address are undefined in IPv6, and this default behavior might
change at some point in the future.
- Added a definition of the treatment of multicast packets - Changed the way in which optional information is included in
addressed to a multicast group to which a mobile node is Mobile IPv6 destination options. In pervious versions of this
subscribed, for which the multicast scope is link-local, draft, optional data was in an unspecified format (except for
site-local, organization-local, etc. As with packets sent to a the Home Agents List in a Binding Acknowledgement, which was
mobile node's link-local and site-local addresses, link-local a simple list of IP addresses). Instead, such optional data
multicast packets MUST NOT be tunneled to the mobile node, and is now specified as sub-options within the option data field,
multicast packets addressed to a multicast address with scope encoded in type-length-value (TLV) format. Added Section 5.5
larger than link-local but smaller than global (e.g., site-local to define the general format of sub-options and to specify the
and organization-local) SHOULD be tunneled to the mobile node by sub-option data format for each defined sub-option, and updated
default, but this behavior MUST be configurable to disable it. relevant references to such optional information throughout
the draft. This new TLV encoding of optional information
allows much more flexibility in future versions of the protocol
specification, and solves the problem that the previous encoding
of the Home Agents List in a Binding Acknowledgement prevented
other optional information from also being included in a Binding
Acknowledgement.
- Added Section 7.2, detailing Mobile IP requirements on all IPv6 - Specified in Section 9.2 that a home agent returning a Binding
routers. They SHOULD be able to send an Advertisement Interval Acknowledgement containing a Home Agents List Sub-Option SHOULD
option in their Router Advertisements, and SHOULD be able to limit the size of the list so as to avoid the possibility of the
support sending unsolicited multicast Router Advertisements at packet carrying the Binding Acknowledgement being fragmented.
the faster rate described in Section 6.5.
- Added Section 10.14 describing the mobile node side of - Specified in Section 4.3 that each Home Agents List entry
renumbering the home network, matching the home agent processing represents a single home agent by its link-local address
described in Section 9.7. (the Source Address used in its Router Advertisements),
and contains one or more global IP addresses for this home
agent, learned through Prefix Information options received
in Router Advertisements from this link-local address, in
which the Router Address (R) bit is set. Also specified in
Section ha-advert how to add global addresses to this list of
global addresses associated with a home agent in the Home Agents
List.
- Simplified the sequence of tests in Section 9.4 performed by a - Specified in Section 9.2 that in forming the Home Agents
home agent being requested to no longer serve as the sending List Sub-Option to return to a mobile node in a Binding
mobile node's home agent. Acknowledgement, only home agent global IP addresses sharing a
prefix with the mobile node's home address are returned in the
Binding Acknowledgement.
- Clarified in Section 10.5 that if a mobile node has multiple home - Specified in Section 8 that in processing a Home Address option
addresses using different interface identifiers, then it SHOULD in a received packet, any actual modifications to the Source
send a separate Binding Update to its home agent for each. Address field in the packet's IPv6 header MUST not be performed
until after all processing of other options contained in this
same Destination Options extension header is completed. This
restriction prevents confusion in the meaning of these other
destination options.
- Finally filled in Section 2, giving a comparison of Mobile IPv6 - General clarification and correction of minor typographical
with Mobile IP for IPv4. errors throughout.
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 Working
Groups for their comments and suggestions on this work. We would Groups for their comments and suggestions on this work. We would
particularly like to thank Josh Broch, Thomas Narten, Erik Nordmark, particularly like to thank (in alphabetical order) Josh Broch
and Jim Solomon for their detailed reviews of earlier versions of (Carnegie Mellon University), Thomas Narten (IBM), Erik Nordmark (Sun
this draft. Their suggestions have helped to improve both the design Microsystems), Simon Nybroe (Telebit Communications), Patrice Romand
and presentation of the protocol. (Bull S.A.), Tom Soderlund (Nokia Research), and Jim Solomon (RedBack
Networks) for their detailed reviews of earlier versions of this
draft. Their suggestions have helped to improve both the design and
presentation of the protocol.
References References
[1] S. M. Bellovin. Security problems in the TCP/IP protocol suite. [1] S. M. Bellovin. Security problems in the TCP/IP protocol suite.
ACM Computer Communications Review, 19(2), March 1989. ACM Computer Communications Review, 19(2), March 1989.
[2] Jim Bound and Charles Perkins. Dynamic Host Configuration [2] Jim Bound and Charles Perkins. Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). Internet-Draft, Protocol for IPv6 (DHCPv6). Internet-Draft,
draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress. draft-ietf-dhc-dhcpv6-10.txt, May 1997. Work in progress.
 End of changes. 

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