draft-ietf-mobileip-ipv6-09.txt   draft-ietf-mobileip-ipv6-10.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Carnegie Mellon University INTERNET-DRAFT Carnegie Mellon University
Charles Perkins Charles Perkins
Nokia Nokia
22 October 1999 10 February 2000
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-09.txt> <draft-ietf-mobileip-ipv6-10.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 66 skipping to change at page 1, line 67
2. Comparison with Mobile IP for IPv4 3 2. Comparison with Mobile IP for IPv4 3
3. Terminology 6 3. Terminology 6
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7
3.3. Specification Language . . . . . . . . . . . . . . . . . 8 3.3. Specification Language . . . . . . . . . . . . . . . . . 8
4. Overview of Mobile IPv6 9 4. Overview of Mobile IPv6 9
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9
4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 4.2. New IPv6 Destination Options and ICMP Messages . . . . . 11
4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 13 4.3. Conceptual Data Structures . . . . . . . . . . . . . . . 14
4.4. Binding Management . . . . . . . . . . . . . . . . . . . 17 4.4. Binding Management . . . . . . . . . . . . . . . . . . . 18
5. New IPv6 Destination Options 19
5.1. Binding Update Option Format . . . . . . . . . . . . . . 19
5.2. Binding Acknowledgement Option Format . . . . . . . . . . 23
5.3. Binding Request Option Format . . . . . . . . . . . . . . 27
5.4. Home Address Option Format . . . . . . . . . . . . . . . 29
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 31
6. Modifications to IPv6 Neighbor Discovery 34 5. New IPv6 Destination Options and Message Types 20
6.1. Modified Router Advertisement Message Format . . . . . . 34 5.1. Binding Update Option Format . . . . . . . . . . . . . . 20
6.2. Modified Prefix Information Option Format . . . . . . . . 36 5.2. Binding Acknowledgement Option Format . . . . . . . . . . 24
6.3. New Advertisement Interval Option Format . . . . . . . . 38 5.3. Binding Request Option Format . . . . . . . . . . . . . . 28
6.4. New Home Agent Information Option Format . . . . . . . . 39 5.4. Home Address Option Format . . . . . . . . . . . . . . . 30
6.5. Changes to Sending Router Advertisements . . . . . . . . 41 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 32
6.6. Changes to Sending Router Solicitations . . . . . . . . . 42 5.6. ICMP Home Agent Address Discovery Request Message . . . . 35
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 37
7. Requirements for IPv6 Nodes 44 6. Modifications to IPv6 Neighbor Discovery 39
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 44 6.1. Modified Router Advertisement Message Format . . . . . . 39
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 44 6.2. Modified Prefix Information Option Format . . . . . . . . 40
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 44 6.3. New Advertisement Interval Option Format . . . . . . . . 42
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 45 6.4. New Home Agent Information Option Format . . . . . . . . 43
6.5. Changes to Sending Router Advertisements . . . . . . . . 45
6.6. Changes to Sending Router Solicitations . . . . . . . . . 46
8. Correspondent Node Operation 47 7. Requirements for IPv6 Nodes 48
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 47 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 48
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 47 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 48
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 48 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 48
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 49 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 49
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 49 8. Correspondent Node Operation 51
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 50 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 51
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 50 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 51
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 51 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 52
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 52 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 53
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 53
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 53
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 54
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 55
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 56
9. Home Agent Operation 54 9. Home Agent Operation 58
9.1. Receiving Router Advertisement Messages . . . . . . . . . 54 9.1. Receiving Router Advertisement Messages . . . . . . . . . 58
9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 55 9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 59
9.3. Primary Care-of Address Registration . . . . . . . . . . 57 9.3. Primary Care-of Address Registration . . . . . . . . . . 61
9.4. Primary Care-of Address De-registration . . . . . . . . . 59 9.4. Primary Care-of Address De-registration . . . . . . . . . 63
9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 60 9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 64
9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 62 9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 66
9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 63 9.7. Renumbering the Home Subnet . . . . . . . . . . . . . . . 67
10. Mobile Node Operation 67 10. Mobile Node Operation 70
10.1. Sending Packets While Away from Home . . . . . . . . . . 67 10.1. Sending Packets While Away from Home . . . . . . . . . . 70
10.2. Interaction with Outbound IPsec Processing . . . . . . . 68 10.2. Interaction with Outbound IPsec Processing . . . . . . . 71
10.3. Receiving Packets While Away from Home . . . . . . . . . 69 10.3. Receiving Packets While Away from Home . . . . . . . . . 73
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 71 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 74
10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 74 10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 77
10.6. Sending Binding Updates to the Home Agent . . . . . . . . 75 10.6. Sending Binding Updates to the Home Agent . . . . . . . . 78
10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 76 10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 79
10.8. Sending Binding Updates to Correspondent Nodes . . . . . 76 10.8. Sending Binding Updates to Correspondent Nodes . . . . . 80
10.9. Establishing Forwarding from a Previous Care-of Address . 79 10.9. Establishing Forwarding from a Previous Care-of Address . 83
10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 80 10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 84
10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 80 10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 84
10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 81 10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 85
10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 82 10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 85
10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 82 10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 86
10.15. Receiving Tunneled Router Advertisements . . . . . . . . 83 10.15. Receiving Local Router Advertisement Messages . . . . . . 86
10.16. Using Multiple Care-of Addresses . . . . . . . . . . . . 84 10.16. Receiving Tunneled Router Advertisements . . . . . . . . 88
10.17. Routing Multicast Packets . . . . . . . . . . . . . . . . 84 10.17. Using Multiple Care-of Addresses . . . . . . . . . . . . 89
10.18. Returning Home . . . . . . . . . . . . . . . . . . . . . 85 10.18. Routing Multicast Packets . . . . . . . . . . . . . . . . 89
10.19. Returning Home . . . . . . . . . . . . . . . . . . . . . 90
11. Constants 86 11. Protocol Constants 92
12. IANA Considerations 87 12. IANA Considerations 93
13. Security Considerations 88 13. Security Considerations 94
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 88 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 94
13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 88 13.2. Home Address Option . . . . . . . . . . . . . . . . . . . 94
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 89 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 95
Changes from Previous Version of the Draft 91 Changes from Previous Version of the Draft 97
Acknowledgements 93 Acknowledgements 99
References 94 References 100
Chair's Address 96 Chair's Address 102
Authors' Addresses 97 Authors' Addresses 103
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) [6]. Without specific support
for mobility in IPv6, packets destined to a mobile node (host or for mobility in IPv6, packets destined to a mobile node (host or
router) would not be able to reach it while the mobile node is away router) would not be able to reach it while the mobile node is away
from its home link (the link on which its home IPv6 subnet prefix is from its home link (the link on which its home IPv6 subnet prefix is
in use), since routing is based on the subnet prefix in a packet's in use), since routing is based on the subnet prefix in a packet's
destination IP address. In order to continue communication in spite destination IP address. In order to continue communication in spite
of its movement, a mobile node could change its IP address each time of its movement, a mobile node could change its IP address each time
it moves to a new link, but the mobile node would then not be able it moves to a new link, but the mobile node would then not be able
to maintain transport and higher-layer connections when it changes to maintain transport and higher-layer connections when it changes
location. Mobility support in IPv6 is particularly important, as location. Mobility support in IPv6 is particularly important, as
mobile computers are likely to account for a majority or at least a mobile computers are likely to account for a majority or at least a
skipping to change at page 2, line 22 skipping to change at page 2, line 22
wireless networks. Some aspects of this problem are addressed wireless networks. Some aspects of this problem are addressed
by the movement detection procedure described in Section 10.4, by the movement detection procedure described in Section 10.4,
but no attempt has been made to fully solve this problem in its but no attempt has been made to fully solve this problem in its
general form. Most aspects of this problem can be solved by the general form. Most aspects of this problem can be solved by the
workaround of restricting such networks to only one router per workaround of restricting such networks to only one router per
link, although there are still possible hidden terminal problems link, although there are still possible hidden terminal problems
when two nodes on the same link (on opposite sides of the router) when two nodes on the same link (on opposite sides of the router)
attempt to communicate directly. attempt to communicate directly.
- Access control on a link being visited by a mobile node. This - Access control on a link being visited by a mobile node. This
is a general problem any time an untrusted node is allowed is a general problem any time an untrusted node is allowed to
to connect to any link layer. It is independent whether the connect to any link layer. It is independent of whether the
connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP
address on the link. address on the link.
2. Comparison with Mobile IP for IPv4 2. Comparison with Mobile IP for IPv4
The design of Mobile IP support in IPv6 (Mobile IPv6) represents a The design of Mobile IP support in IPv6 (Mobile IPv6) represents a
natural combination of the experiences gained from the development natural combination of the experiences gained from the development
of Mobile IP support in IPv4 (Mobile IPv4) [16, 15, 17], together of Mobile IP support in IPv4 (Mobile IPv4) [19, 18, 20], together
with the opportunities provided by the design and deployment of a new with the opportunities provided by the design and deployment of a new
version of IP itself (IPv6) and the new protocol features offered version of IP itself (IPv6) and the new protocol features offered
by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4,
but the protocol is now fully integrated into IP and provides many but the protocol is now fully integrated into IP and provides many
improvements over Mobile IPv4. This section summarizes the major improvements over Mobile IPv4. This section summarizes the major
differences between Mobile IPv4 and Mobile IPv6: differences between Mobile IPv4 and Mobile IPv6:
- Support for what is known in Mobile IPv4 as "Route - Support for what is known in Mobile IPv4 as "Route
Optimization" [18] is now built in as a fundamental part Optimization" [21] is now built in as a fundamental part
of the protocol, rather than being added on as a optional of the protocol, rather than being added on as an optional
set of extensions that may not be supported by all nodes set of extensions that may not be supported by all nodes
as in Mobile IPv4. This integration of Route Optimization as in Mobile IPv4. This integration of Route Optimization
functionality allows direct routing from any correspondent node functionality allows direct routing from any correspondent node
to any mobile node, without needing to pass through the mobile to any mobile node, without needing to pass through the mobile
node's home network and be forwarded by its home agent, and thus node's home network and be forwarded by its home agent, and thus
eliminates the problem of "triangle routing" present in the base eliminates the problem of "triangle routing" present in the base
Mobile IPv4 protocol [16]. This integration also allows the Mobile IPv4 protocol [19]. This integration also allows the
Mobile IPv4 "registration" functionality and the Mobile IPv4 Mobile IPv4 "registration" functionality and the Mobile IPv4
Route Optimization functionality to be performed by a single Route Optimization functionality to be performed by a single
protocol rather than two separate (and different) protocols. protocol rather than two separate (and different) protocols.
- Support is also integrated into Mobile IPv6 -- and into IPv6 - Support is also integrated into Mobile IPv6 -- and into IPv6
itself -- for allowing mobile nodes and Mobile IP to coexist itself -- for allowing mobile nodes and Mobile IP to coexist
efficiently with routers that perform "ingress filtering" [6]. A efficiently with routers that perform "ingress filtering" [7]. A
mobile node now uses its care-of address as the Source Address in mobile node now uses its care-of address as the Source Address in
the IP header of packets it sends, allowing the packets to pass the IP header of packets it sends, allowing the packets to pass
normally through ingress filtering routers. The home address normally through ingress filtering routers. The home address
of the mobile node is carried in the packet in a Home Address of the mobile node is carried in the packet in a Home Address
destination option, allowing the use of the care-of address in destination option, allowing the use of the care-of address in
the packet to be transparent above the IP layer. The ability the packet to be transparent above the IP layer. The ability
to correctly process a Home Address option in a received packet to correctly process a Home Address option in a received packet
is required in all IPv6 nodes, whether mobile nor stationary, is required in all IPv6 nodes, whether mobile nor stationary,
whether host or router. whether host or router.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
had to tunnel multicast packets to its home agent in order to had to tunnel multicast packets to its home agent in order to
transparently use its home address as the source of the multicast transparently use its home address as the source of the multicast
packets. With Mobile IPv6, the use of the Home Address option packets. With Mobile IPv6, the use of the Home Address option
allows the home address to be used but still be compatible with allows the home address to be used but still be compatible with
multicast routing that is based in part on the packet's Source multicast routing that is based in part on the packet's Source
Address. Address.
- There is no longer any need to deploy special routers as - There is no longer any need to deploy special routers as
"foreign agents" as are used in Mobile IPv4. In Mobile IPv6, "foreign agents" as are used in Mobile IPv4. In Mobile IPv6,
mobile nodes make use of the enhanced features of IPv6, such mobile nodes make use of the enhanced features of IPv6, such
as Neighbor Discovery [14] and Address Autoconfiguration [23], as Neighbor Discovery [17] and Address Autoconfiguration [27],
to operate in any location away from home without any special to operate in any location away from home without any special
support required from its local router. support required from its local router.
- Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security - Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security
(IPsec) [9, 10, 11] for all security requirements (sender (IPsec) [11, 12, 13] for all security requirements (sender
authentication, data integrity protection, and replay protection) authentication, data integrity protection, and replay protection)
for Binding Updates (which serve the role of both registration for Binding Updates (which serve the role of both registration
and Route Optimization in Mobile IPv4). Mobile IPv4 relies and Route Optimization in Mobile IPv4). Mobile IPv4 relies
on its own security mechanisms for these functions, based on on its own security mechanisms for these functions, based on
statically configured "mobility security associations". statically configured "mobility security associations".
- The movement detection mechanism in Mobile IPv6 provides - The movement detection mechanism in Mobile IPv6 provides
bidirectional confirmation of a mobile node's ability to bidirectional confirmation of a mobile node's ability to
communicate with its default router in its current location communicate with its default router in its current location
(packets that the router sends are reaching the mobile node, and (packets that the router sends are reaching the mobile node, and
skipping to change at page 4, line 37 skipping to change at page 4, line 37
link to the router does not work equally well in both directions, link to the router does not work equally well in both directions,
such as when the mobile node has moved out of good wireless such as when the mobile node has moved out of good wireless
transmission range from the router. The mobile node may then transmission range from the router. The mobile node may then
attempt to find a new router and begin using a new care-of attempt to find a new router and begin using a new care-of
address if its link to its current router is not working well. address if its link to its current router is not working well.
In contrast, in Mobile IPv4, only the forward direction (packets In contrast, in Mobile IPv4, only the forward direction (packets
from the router are reaching the mobile node) is confirmed, from the router are reaching the mobile node) is confirmed,
allowing the black hole condition to persist. allowing the black hole condition to persist.
- Most packets sent to a mobile node while away from home in - Most packets sent to a mobile node while away from home in
Mobile IPv6 are tunneled using an IPv6 Routing header rather than Mobile IPv6 are sent using an IPv6 Routing header rather than IP
IP encapsulation, whereas Mobile IPv4 must use encapsulation encapsulation, whereas Mobile IPv4 must use encapsulation for all
for all packets. The use of a Routing header requires less packets. The use of a Routing header requires less additional
additional header bytes to be added to the packet, reducing the header bytes to be added to the packet, reducing the overhead
overhead of Mobile IP packet delivery. To avoid modifying the of Mobile IP packet delivery. To avoid modifying the packet in
packet in flight, however, packets intercepted and tunneled flight, however, packets intercepted and tunneled by a mobile
by a mobile node's home agent in Mobile IPv6 must still use node's home agent in Mobile IPv6 must still use encapsulation for
encapsulation for tunneling. delivery to the mobile node.
- While a mobile node is away from home, its home agent intercepts - While a mobile node is away from home, its home agent intercepts
any packets for the mobile node that arrive at the home network, any packets for the mobile node that arrive at the home network,
using IPv6 Neighbor Discovery [14] rather than ARP [19] as is using IPv6 Neighbor Discovery [17] rather than ARP [23] as is
used in Mobile IPv4. The use of Neighbor Discovery improves used in Mobile IPv4. The use of Neighbor Discovery improves
the robustness of the protocol (e.g., due to the Neighbor the robustness of the protocol (e.g., due to the Neighbor
Advertisement "override" bit) and simplifies implementation Advertisement "override" bit) and simplifies implementation
of Mobile IP due to the ability to not be concerned with any of Mobile IP due to the ability to not be concerned with any
particular link layer as is required in ARP. particular link layer as is required in ARP.
- The use of IPv6 encapsulation (and the Routing header) removes - The use of IPv6 encapsulation (and the Routing header) removes
the need in Mobile IPv6 to manage "tunnel soft state", which was the need in Mobile IPv6 to manage "tunnel soft state", which was
required in Mobile IPv4 due to limitations in ICMP for IPv4. Due required in Mobile IPv4 due to limitations in ICMP for IPv4. Due
to the definition of ICMP for IPv6, the use of tunnel soft state to the definition of ICMP for IPv6, the use of tunnel soft state
is no longer required in IPv6 for correctly relaying ICMP error is no longer required in IPv6 for correctly relaying ICMP error
messages from within the tunnel back to the original sender of messages from within the tunnel back to the original sender of
the packet. the packet.
- The dynamic home agent address discovery mechanism in Mobile IPv6 - The dynamic home agent address discovery mechanism in Mobile IPv6
uses IPv6 anycast [8] and returns a single reply to the mobile uses IPv6 anycast [10] and returns a single reply to the mobile
node, rather than the corresponding Mobile IPv4 mechanism that node, rather than the corresponding Mobile IPv4 mechanism that
used IPv4 directed broadcast and returned a separate reply from used IPv4 directed broadcast and returned a separate reply from
each home agent on the mobile node's home link. The Mobile IPv6 each home agent on the mobile node's home link. The Mobile IPv6
mechanism is more efficient and more reliable, since only mechanism is more efficient and more reliable, since only
one packet need be sent back to the mobile node and since the one packet need be sent back to the mobile node and since the
mobile node is less likely to lose one of the replies because no mobile node is less likely to lose one of the replies because no
"implosion" of replies is required by the protocol. "implosion" of replies is required by the protocol.
- Mobile IPv6 defines an Advertisement Interval option on - Mobile IPv6 defines an Advertisement Interval option on
Router Advertisements (equivalent to Agent Advertisements in Router Advertisements (equivalent to Agent Advertisements in
skipping to change at page 9, line 32 skipping to change at page 9, line 32
with a mobile node while visiting a particular foreign link. The with a mobile node while visiting a particular foreign link. The
subnet prefix of a mobile node's care-of address is the subnet prefix subnet prefix of a mobile node's care-of address is the subnet prefix
(or one of the subnet prefixes) on the foreign link being visited by (or one of the subnet prefixes) on the foreign link being visited by
the mobile node; if the mobile node is connected to this foreign link the mobile node; if the mobile node is connected to this foreign link
while using that care-of address, packets addressed to this care-of while using that care-of address, packets addressed to this care-of
address will be routed to the mobile node in its location away from address will be routed to the mobile node in its location away from
home. home.
The association between a mobile node's home address and care-of The association between a mobile node's home address and care-of
address is known as a "binding" for the mobile node. A mobile node address is known as a "binding" for the mobile node. A mobile node
typically acquires its care-of address through stateless [23] or typically acquires its care-of address through stateless [27] or
stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [14]. Other methods to the methods of IPv6 Neighbor Discovery [17]. Other methods
of acquiring a care-of address are also possible, such as static of acquiring a care-of address are also possible, such as static
pre-assignment by the owner or manager of a particular foreign link, pre-assignment by the owner or manager of a particular foreign link,
but details of such other methods are beyond the scope of this but details of such other methods are beyond the scope of this
document. document.
While away from home, a mobile node registers one of its care-of While away from home, a mobile node registers one of its care-of
addresses with a router on its home link, requesting this router addresses with a router on its home link, requesting this router
to function as the "home agent" for the mobile node. This binding to function as the "home agent" for the mobile node. This binding
registration is done by the mobile node sending to the home agent registration is done by the mobile node sending to the home agent
a packet containing a "Binding Update" destination option; the a packet containing a "Binding Update" destination option; the
skipping to change at page 10, line 7 skipping to change at page 10, line 7
care-of address in this binding registered with its home agent is care-of address in this binding registered with its home agent is
known as the mobile node's "primary care-of address". The mobile known as the mobile node's "primary care-of address". The mobile
node's home agent thereafter uses proxy Neighbor Discovery to node's home agent thereafter uses proxy Neighbor Discovery to
intercept any IPv6 packets addressed to the mobile node's home intercept any IPv6 packets addressed to the mobile node's home
address (or home addresses) on the home link, and tunnels each address (or home addresses) on the home link, and tunnels each
intercepted packet to the mobile node's primary care-of address. intercepted packet to the mobile node's primary care-of address.
To tunnel each intercepted packet, the home agent encapsulates the To tunnel each intercepted packet, the home agent encapsulates the
packet using IPv6 encapsulation [4], with the outer IPv6 header packet using IPv6 encapsulation [4], with the outer IPv6 header
addressed to the mobile node's primary care-of address. addressed to the mobile node's primary care-of address.
Section 10.16 discusses the reasons why it may be desirable for Section 10.17 discusses the reasons why it may be desirable for
a mobile node to use more than one care-of address at the same a mobile node to use more than one care-of address at the same
time. However, a mobile node's primary care-of address is distinct time. However, a mobile node's primary care-of address is distinct
among these in that the home agent maintains only a single care-of among these in that the home agent maintains only a single care-of
address registered for each mobile node, and always tunnels a mobile address registered for each mobile node, and always tunnels a mobile
node's packets intercepted from its home link to this mobile node's node's packets intercepted from its home link to this mobile node's
registered primary care-of address. The home agent thus need not registered primary care-of address. The home agent thus need not
implement any policy to determine which of possibly many care-of implement any policy to determine which of possibly many care-of
addresses to which to tunnel each intercepted packet, leaving the addresses to which to tunnel each intercepted packet, leaving the
mobile node entirely in control of this policy by which of its mobile node entirely in control of this policy by which of its
care-of addresses it registers with its home agent. care-of addresses it registers with its home agent.
It is possible that while a mobile node is away from home, some nodes It is possible that while a mobile node is away from home, some nodes
on its home link may be reconfigured, such that the router that was on its home link may be reconfigured, such that the router that was
operating as the mobile node's home agent is replaced by a different operating as the mobile node's home agent is replaced by a different
router serving this role. In this case, the mobile node may not router serving this role. In this case, the mobile node may not
know the IP address of its own home agent. Mobile IPv6 provides a know the IP address of its own home agent. Mobile IPv6 provides a
mechanism, known as "dynamic home agent address discovery", that mechanism, known as "dynamic home agent address discovery", that
allows a mobile node to dynamically discover the IP address of a home allows a mobile node to dynamically discover the IP address of a home
agent on its home link with which it may register its care-of address agent on its home link with which it may register its care-of address
while away from home. The mobile node sends a Binding Update to the while away from home. The mobile node sends an ICMP "Home Agent
"Mobile IPv6 Home-Agents" anycast address for its own home subnet Address Discovery Request" message to the "Mobile IPv6 Home-Agents"
prefix [8] and thus reaches one of the (possibly many) routers on anycast address for its own home subnet prefix [10] and thus reaches
its home link currently operating as a home agent. This home agent one of the (possibly many) routers on its home link currently
rejects the mobile node's Binding Update, but returns in the Binding operating as a home agent. This home agent then returns an ICMP
Acknowledgement in response a list of all home agents on the home "Home Agent Address Discovery Reply" message to the mobile node,
link. This list of home agents is maintained by each home agent on including a list of home agents on the home link. This list of home
the home link through use of the Home Agent (H) bit in each home agents is maintained by each home agent on the home link through use
agent's periodic unsolicited multicast Router Advertisements. of the Home Agent (H) bit in each home agent's periodic unsolicited
multicast Router Advertisements.
The Binding Update and Binding Acknowledgement destination options, The Binding Update and Binding Acknowledgement destination options,
together with a "Binding Request" destination option, are also used together with a "Binding Request" destination option, are also used
to allow IPv6 nodes communicating with a mobile node, to dynamically to allow IPv6 nodes communicating with a mobile node, to dynamically
learn and cache the mobile node's binding. When sending a packet learn and cache the mobile node's binding. When sending a packet
to any IPv6 destination, a node checks its cached bindings for an to any IPv6 destination, a node checks its cached bindings for an
entry for the packet's destination address. If a cached binding for entry for the packet's destination address. If a cached binding for
this destination address is found, the node uses an IPv6 Routing this destination address is found, the node uses an IPv6 Routing
header [5] (instead of IPv6 encapsulation) to route the packet to header [6] (instead of IPv6 encapsulation) to route the packet to
the mobile node by way of the care-of address indicated in this the mobile node by way of the care-of address indicated in this
binding. If, instead, the sending node has no cached binding for binding. If, instead, the sending node has no cached binding for
this destination address, the node sends the packet normally (with this destination address, the node sends the packet normally (with
no Routing header), and the packet is subsequently intercepted and no Routing header), and the packet is subsequently intercepted and
tunneled by the mobile node's home agent as described above. Any tunneled by the mobile node's home agent as described above. Any
node communicating with a mobile node is referred to in this document node communicating with a mobile node is referred to in this document
as a "correspondent node" of the mobile node, and may itself be as a "correspondent node" of the mobile node, and may itself be
either a stationary node or a mobile node. either a stationary node or a mobile node.
Since a Binding Update, Binding Acknowledgement, and Binding Request Since a Binding Update, Binding Acknowledgement, and Binding Request
are each represented in a packet as an IPv6 destination option [5], are each represented in a packet as an IPv6 destination option [6],
they may be included in any IPv6 packet. Any of these options can be they may be included in any IPv6 packet. Any of these options can be
sent in either of two ways: sent in either of two ways:
- A Binding Update, Binding Acknowledgement, or Binding Request can - A Binding Update, Binding Acknowledgement, or Binding Request can
be included within any IPv6 packet carrying any payload such as be included within any IPv6 packet carrying any payload such as
TCP [21] or UDP [20]. TCP [25] or UDP [24].
- A Binding Update, Binding Acknowledgement, or Binding Request can - A Binding Update, Binding Acknowledgement, or Binding Request can
be sent as a separate IPv6 packet containing no payload. In this be sent as a separate IPv6 packet containing no payload. In this
case, the Next Header field in the last extension header in the case, the Next Header field in the last extension header in the
packet is set to the value 59, to indicate "No Next Header" [5]. packet is set to the value 59, to indicate "No Next Header" [6].
Mobile IPv6 also defines one additional IPv6 destination option. Mobile IPv6 also defines one additional IPv6 destination option.
When a mobile node sends a packet while away from home, it will When a mobile node sends a packet while away from home, it will
generally set the Source Address in the packet's IPv6 header to one generally set the Source Address in the packet's IPv6 header to one
of its current care-of addresses, and will also include a "Home of its current care-of addresses, and will also include a "Home
Address" destination option in the packet, giving the mobile node's Address" destination option in the packet, giving the mobile node's
home address. Many routers implement security policies such as home address. Many routers implement security policies such as
"ingress filtering" [6] that do not allow forwarding of packets that "ingress filtering" [7] that do not allow forwarding of packets that
appear to have a Source Address that is not topologically correct. appear to have a Source Address that is not topologically correct.
By using the care-of address as the IPv6 header Source Address, By using the care-of address as the IPv6 header Source Address,
the packet will be able to pass normally through such routers, the packet will be able to pass normally through such routers,
yet ingress filtering rules will still be able to locate the true yet ingress filtering rules will still be able to locate the true
topological source of the packet in the same way as packets from topological source of the packet in the same way as packets from
non-mobile nodes. By also including the Home Address option in each non-mobile nodes. By also including the Home Address option in each
packet, the sending mobile node can communicate its home address to packet, the sending mobile node can communicate its home address to
the correspondent node receiving this packet, allowing the use of the correspondent node receiving this packet, allowing the use of
the care-of address to be transparent above the Mobile IPv6 support the care-of address to be transparent above the Mobile IPv6 support
level (e.g., at the transport layer). The inclusion of a Home level (e.g., at the transport layer). The inclusion of a Home
Address option in a packet affects only the correspondent node's Address option in a packet affects only the correspondent node's
receipt of this single packet; no state is created or modified in the receipt of this single packet; no state is created or modified in the
correspondent node as a result of receiving a Home Address option in correspondent node as a result of receiving a Home Address option in
a packet. a packet.
4.2. New IPv6 Destination Options 4.2. New IPv6 Destination Options and ICMP Messages
As discussed in general in Section 4.1, the following four new IPv6 As discussed in general in Section 4.1, the following four new IPv6
destination options are defined for Mobile IPv6: destination options are defined for Mobile IPv6:
Binding Update Binding Update
A Binding Update option is used by a mobile node to notify A Binding Update option is used by a mobile node to notify
a correspondent node or the mobile node's home agent of a correspondent node or the mobile node's home agent of
its current binding. The Binding Update sent to the mobile its current binding. The Binding Update sent to the mobile
node's home agent to register its primary care-of address is node's home agent to register its primary care-of address is
marked as a "home registration". Any packet that includes a marked as a "home registration". Any packet that includes a
Binding Update option MUST also include either an AH [9] or Binding Update option MUST also include either an AH [11] or
ESP [10] header providing sender authentication, data integrity ESP [12] header providing sender authentication, data integrity
protection, and replay protection. The Binding Update option protection, and replay protection. The Binding Update option
is described in detail in Section 5.1. is described in detail in Section 5.1.
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement option is used to acknowledge receipt A Binding Acknowledgement option is used to acknowledge receipt
of a Binding Update, if an acknowledgement was requested of a Binding Update, if an acknowledgement was requested
in the Binding Update. Any packet that includes a Binding in the Binding Update. Any packet that includes a Binding
Acknowledgement option MUST also include either an AH [9] or Acknowledgement option MUST also include either an AH [11] or
ESP [10] header providing sender authentication, data integrity ESP [12] header providing sender authentication, data integrity
protection, and replay protection. The Binding Acknowledgement protection, and replay protection. The Binding Acknowledgement
option is described in detail in Section 5.2. option is described in detail in Section 5.2.
Binding Request Binding Request
A Binding Request option is used to request a mobile node to A Binding Request option is used to request a mobile node to
send to the requesting node a Binding Update containing the send to the requesting node a Binding Update containing the
mobile node's current binding. This option is typically used mobile node's current binding. This option is typically used
by a correspondent node to refresh a cached binding for a by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the mobile node, when the cached binding is in active use but the
skipping to change at page 13, line 5 skipping to change at page 13, line 5
is described in detail in Section 5.4. is described in detail in Section 5.4.
Sub-options within the format of these options MAY be included after Sub-options within the format of these options MAY be included after
the 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 sub-options 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 sub-options. The encoding and format of defined are interpreted as sub-options. The encoding and format of defined
sub-options are described in Section 5.5. sub-options are described in Section 5.5.
IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple of n octets from the start of the header,
for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within the
Sub-Option Data field of each sub-option fall on natural boundaries.
The alignment requirement of an option or sub-option is specified in
this document using the standard notation used elsewhere for IPv6
alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets.
For example:
2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header,
plus 2 octets.
Mobile IPv6 also introduces two new ICMP message types, for use in
the dynamic home agent address discovery mechanism. As discussed in
general in Section 4.1, the following two new ICMP message types are
used:
Home Agent Address Discovery Request
The ICMP Home Agent Address Discovery Request message is used
by a mobile node to initiate the dynamic home agent address
discovery mechanism. When attempting a home registration, the
mobile node may use this mechanism to discover the address of
one or more routers currently operating as home agents on its
home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described
in detail in Section 5.6.
Home Agent Address Discovery Reply
The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.7.
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
consistent with the external behavior described in this consistent with the external behavior described in this
document, for example by being combined with the node's document, for example by being combined with the node's
Destination Cache as maintained by Neighbor Discovery [14]. Destination Cache as maintained by Neighbor Discovery [17].
When sending a packet, the Binding Cache is searched before the When sending a packet, the Binding Cache is searched before the
Neighbor Discovery conceptual Destination Cache [14] (i.e., any Neighbor Discovery conceptual Destination Cache [17] (i.e., any
Binding Cache entry for this destination SHOULD take precedence Binding Cache entry for this destination SHOULD take precedence
over any Destination Cache entry for the same destination). over any Destination Cache entry for the same destination).
Each Binding Cache entry conceptually contains the following Each Binding Cache entry conceptually contains the following
fields: fields:
- The home address of the mobile node for which this is the - The home address of the mobile node for which this is the
Binding Cache entry. This field is used as the key for Binding Cache entry. This field is used as the key for
searching the Binding Cache for the destination address of searching the Binding Cache for the destination address of
a packet being sent. If the destination address of the a packet being sent. If the destination address of the
packet matches the home address in the Binding Cache entry, packet matches the home address in the Binding Cache entry,
skipping to change at page 16, line 7 skipping to change at page 17, line 7
- A flag that, when set, indicates that future Binding - A flag that, when set, indicates that future Binding
Updates should not be sent to this destination. The Updates should not be sent to this destination. The
mobile node sets this flag in the Binding Update List mobile node sets this flag in the Binding Update List
entry when it receives an ICMP Parameter Problem, Code 2, entry when it receives an ICMP Parameter Problem, Code 2,
error message in response to a Binding Update sent to that error message in response to a Binding Update sent to that
destination, as described in Section 10.14. destination, as described in Section 10.14.
Home Agents List Home Agents List
A list, maintained by each home agent, recording information A list, maintained by each home agent and each mobile node,
about each other home agent on a link on which this node recording information about each home agent from which this
is serving as a home agent; each home agent maintains a node has received a Router Advertisement in which the Home
separate Home Agents List for each such link on which it is Agent (H) bit is set, for which the remaining lifetime for
serving. This list is used in the dynamic home agent address this list entry (defined below) has not yet expired. The
discovery mechanism. The information for the list is learned home agents list is thus similar to the Default Router
through receipt of the periodic unsolicited multicast Router List conceptual data structure maintained by each host for
Advertisements from each other home agent on the link, in which Neighbor Discovery [17], although the Home Agents List MAY be
the Home Agent (H) bit is set, in a manner similar to the implemented in any manner consistent with the external behavior
Default Router List conceptual data structure maintained by described in this document.
each host for Neighbor Discovery [14]. The Home Agents List
MAY be implemented in any manner consistent with the external Each home agent maintains a separate Home Agents List for
behavior described in this document. Each Home Agents List each link on which it is serving as a home agent; this list
is used by a home agent in the dynamic home agent address
discovery mechanism. Each mobile node, while away from home,
also maintains a Home Agents List, to enable it to notify a
home agent on its previous link when it moves to a new link; a
mobile node MAY maintain a separate Home Agents List for each
link to which it is (or has recently) connected, or it MAY
maintain a single list for all links. Each Home Agents List
entry conceptually contains the following fields: entry conceptually contains the following fields:
- The link-local IP address of another router on the home - The link-local IP address of a router on the link, that
link that this node currently believes is operating as this node currently believes is operating as a home agent
a home agent for this link. A new entry is created or for that link. A new entry is created or an existing
an existing entry is updated in the Home Agents List in entry is updated in the Home Agents List in response to
response to receipt of a valid Router Advertisement in receipt of a valid Router Advertisement in which the Home
which the Home Agent (H) bit is set. The link-local Agent (H) bit is set. The link-local address of the home
address of the home agent is learned through the Source agent is learned through the Source Address of the Router
Address of the Router Advertisements received from it [14]. Advertisements received from it [17].
- One or more global IP addresses for this home agent, - One or more global IP addresses for this home agent,
learned through Prefix Information options with the learned through Prefix Information options with the
Router Address (R) bit is set, received in Router Router Address (R) bit is set, received in Router
Advertisements from this link-local address. Global Advertisements from this link-local address. Global
addresses for the router in a Home Agents List entry MUST addresses for the router in a Home Agents List entry MUST
be deleted once the prefix associated with that address is be deleted once the prefix associated with that address is
no longer valid [14]. no longer valid [17].
- 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 that 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
the Home Agents List. the Home Agents List.
- The preference for this home agent, for use in ordering the - The preference for this home agent; higher values
Home Agents List returned in a Binding Acknowledgement; indicate a more preferable home agent. The preference
higher values indicate a more preferable home agent. The value is taken from the Home Agent Preference field (a
preference value is taken from the Home Agent Preference signed, twos-complement integer) in the received Router
field (a signed, twos-complement integer) in the received Advertisement, if the Router Advertisement contains a Home
Router Advertisement, if the Router Advertisement contains Agent Information Option, and is otherwise set to the
a Home Agent Information Option, and is otherwise set to default value of 0. A home agent uses this preference in
the default value of 0. ordering the Home Agents List returned in an ICMP Home
Agent Address Discovery message in response to a mobile
node's initiation of dynamic home agent address discovery.
A mobile node uses this preference in determining which
of the home agents on its previous link to notify when it
moves to a new link.
4.4. Binding Management 4.4. Binding Management
When a mobile node configures a new care-of address and decides to When a mobile node configures a new care-of address and decides to
use this new address as its primary care-of address, the mobile use this new address as its primary care-of address, the mobile
node registers this new binding with its home agent by sending node registers this new binding with its home agent by sending
the home agent a Binding Update. The mobile node indicates the home agent a Binding Update. The mobile node indicates
that an acknowledgement is needed for this Binding Update and that an acknowledgement is needed for this Binding Update and
continues to periodically retransmit it until acknowledged. The continues to periodically retransmit it until acknowledged. The
home agent acknowledges the Binding Update by returning a Binding home agent acknowledges the Binding Update by returning a Binding
skipping to change at page 19, line 5 skipping to change at page 20, line 5
scalability and reliability, and for minimizing overall network load. scalability and reliability, and for minimizing overall network load.
By caching the care-of address of a mobile node, optimal routing of By caching the care-of address of a mobile node, optimal routing of
packets can be achieved from the correspondent node to the mobile packets can be achieved from the correspondent node to the mobile
node. Routing packets directly to the mobile node's care-of address node. Routing packets directly to the mobile node's care-of address
also eliminates congestion at the mobile node's home agent and home also eliminates congestion at the mobile node's home agent and home
link. In addition, the impact of any possible failure of the home link. In addition, the impact of any possible failure of the home
agent, the home link, or intervening networks leading to or from the agent, the home link, or intervening networks leading to or from the
home link is reduced, since these nodes and links are not involved in home link is reduced, since these nodes and links are not involved in
the delivery of most packets to the mobile node. the delivery of most packets to the mobile node.
5. New IPv6 Destination Options 5. New IPv6 Destination Options and Message Types
5.1. Binding Update Option Format 5.1. Binding Update Option Format
The Binding Update destination option is used by a mobile node The Binding Update destination option is used by a mobile node
to notify other nodes of a new care-of address for itself. As a to notify other nodes of a new care-of address for itself. As a
destination option, it MAY be included in any existing packet being destination option, it MAY be included in any existing packet being
sent to this same destination or MAY be sent in a packet by itself; sent to this same destination or MAY be sent in a packet by itself;
a packet containing a Binding Update is sent in the same way as any a packet containing a Binding Update is sent in the same way as any
packet sent by a mobile node (Section 10.1). packet sent by a mobile node (Section 10.1).
The Binding Update option is encoded in type-length-value (TLV) The Binding Update option is encoded in type-length-value (TLV)
format as follows: 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 Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R| Reserved| Prefix Length | Sequence Number | |A|H|R|D|Reservd| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
198 = 0xC6 198 = 0xC6
skipping to change at page 20, line 18 skipping to change at page 21, line 18
The Router (R) bit, when set, indicates that the sending The Router (R) bit, when set, indicates that the sending
mobile node is a router. This bit is only valid when the mobile node is a router. This bit is only valid when the
Home Registration (H) bit is also set, and MUST NOT be set Home Registration (H) bit is also set, and MUST NOT be set
otherwise. This bit is saved in the home agent's "home otherwise. This bit is saved in the home agent's "home
registration" Binding Cache entry for the mobile node, and registration" Binding Cache entry for the mobile node, and
is copied into the corresponding bit in all proxy Neighbor is copied into the corresponding bit in all proxy Neighbor
Advertisement messages sent on behalf of this mobile node by Advertisement messages sent on behalf of this mobile node by
the home agent using this Binding Cache entry. the home agent using this Binding Cache entry.
Reserved Duplicate Address Detection (D)
Reserved. Sent as 0; ignored on reception. The Duplicate Address Detection (D) bit is set by the sending
mobile node to request the receiving node (the mobile node's
home agent) to perform Duplicate Address Detection [27] on
the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection
failed).
Reservd
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Prefix Length Prefix Length
The Prefix Length field is valid only for a "home registration" The Prefix Length field is valid only for a "home registration"
Binding Update. This field MUST be zero if the Home Binding Update; this field MUST be zero if the Home
Registration (H) bit is not set in the Binding Update. The Registration (H) bit is not set in the Binding Update. The
Prefix Length field is set by the sending mobile node to the Prefix Length field is set by the sending mobile node to the
(nonzero) length of its subnet prefix in its home address (nonzero) length of its subnet prefix in its home address
(given in the Home Address option in the packet) to request (given in the Home Address option in the packet) to request
its home agent to use the interface identifier in the mobile its home agent to use the interface identifier in the mobile
node's home address (the remaining low-order bits after the node's home address (the remaining low-order bits after the
indicated subnet prefix) to form all other home addresses for indicated subnet prefix) to form all other home addresses for
the mobile node on the home link. The home agent becomes the the mobile node on the home link. The home agent becomes the
home agent not only for the individual home address given in home agent not only for the individual home address given in
this binding, but also for all other home addresses for this this binding, but also for all other home addresses for this
mobile node formed from this interface identifier. That is, mobile node formed from this interface identifier. That is,
for each on-link prefix on the home link, the home agent uses for each on-link prefix on the home link, the home agent uses
the interface identifier to form other valid addresses for the the interface identifier to form other valid addresses for
mobile node on the home link, and acts as a home agent also the mobile node on the home link, and acts as a home agent
for those addresses. In addition, the home agent forms the also for those addresses. In addition, the home agent forms
link-local address and site-local address corresponding to the link-local address and site-local address corresponding
this interface identifier, and defends each for purposes of to this interface identifier, and defends each for purposes
Duplicate Address Detection. Details of this operation are of Duplicate Address Detection; the home agent also performs
described in Section 9.3. Duplicate Address Detection on each such address as part of
the home registration processing, if the Duplicate Address
Detection (D) bit is set in the Binding Update. Details of
this operation are described in Section 9.3.
Sequence Number Sequence Number
Used by the receiving node to sequence Binding Updates and by Used by the receiving node to sequence Binding Updates and by
the sending node to match a returned Binding Acknowledgement the sending node to match a returned Binding Acknowledgement
with this Binding Update. Each Binding Update sent by a mobile with this Binding Update. Each Binding Update sent by a mobile
node MUST use a Sequence Number greater than the Sequence node MUST use a Sequence Number greater than the Sequence
Number value sent in the previous Binding Update (if any) to Number value sent in the previous Binding Update (if any) to
the same destination address (modulo 2**16). There is no the same destination address (modulo 2**16). There is no
requirement, however, that the Sequence Number value strictly requirement, however, that the Sequence Number value strictly
skipping to change at page 21, line 29 skipping to change at page 22, line 46
This use of sub-options also allows for future extensions to This use of sub-options also allows for future extensions to
the format of the Binding Update option to be defined. The the format of the Binding Update option to be defined. The
encoding and format of defined sub-options are described in encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding Section 5.5. The following sub-options are valid in a Binding
Update option: Update option:
- Unique Identifier Sub-Option - Unique Identifier Sub-Option
- Alternate Care-of Address Sub-Option - Alternate Care-of Address Sub-Option
The alignment requirement [5] for the Binding Update option is 4n+2. The alignment requirement [6] for the Binding Update option is 4n+2.
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.
The care-of address for the binding given in the Binding Update The care-of address for the binding given in the Binding Update
option is normally specified by the Source Address field in the IPv6 option is normally specified by the Source Address field in the IPv6
header of the packet carrying the Binding Update option. However, a header of the packet carrying the Binding Update option. However, a
care-of address different from the Source Address MAY be specified care-of address different from the Source Address MAY be specified
by including an Alternate Care-of Address sub-option in the Binding by including an Alternate Care-of Address sub-option in the Binding
Update option. Update option.
Any packet that includes a Binding Update option MUST also include Any packet that includes a Binding Update option MUST also include
either an AH [9] or ESP [10] header providing sender authentication, either an AH [11] or ESP [12] header providing sender authentication,
data integrity protection, and replay protection. data integrity protection, and replay protection.
If the care-of address for the binding (specified either in an If the care-of address for the binding (specified either in an
Alternate Care-of Address sub-option in the Binding Update option, if Alternate Care-of Address sub-option in the Binding Update option, if
present, or in the Source Address field in the packet's IPv6 header) present, or in the Source Address field in the packet's IPv6 header)
is equal to the home address of the mobile node, the Binding Update is equal to the home address of the mobile node, the Binding Update
option indicates that any existing binding for the mobile node MUST option indicates that any existing binding for the mobile node MUST
be deleted. Likewise, if the Lifetime field in the Binding Update be deleted. Likewise, if the Lifetime field in the Binding Update
option is equal to 0, the Binding Update option indicates that any option is equal to 0, the Binding Update option indicates that any
existing binding for the mobile node MUST be deleted. In each of existing binding for the mobile node MUST be deleted. In each of
skipping to change at page 22, line 21 skipping to change at page 23, line 40
a mobile node in a Binding Update is stored by a correspondent node a mobile node in a Binding Update is stored by a correspondent node
in its Binding Cache entry for that mobile node. Thus, the mobile in its Binding Cache entry for that mobile node. Thus, the mobile
node's and the correspondent node's knowledge of the last sequence node's and the correspondent node's knowledge of the last sequence
number expire at the same time. If the sending mobile node has no number expire at the same time. If the sending mobile node has no
Binding Update List entry, the Sequence Number may start at any Binding Update List entry, the Sequence Number may start at any
value; if the receiving correspondent node has no Binding Cache entry value; if the receiving correspondent node has no Binding Cache entry
for the sending mobile node, it MUST accept any Sequence Number value for the sending mobile node, it MUST accept any Sequence Number value
in a received Binding Update from this mobile node. in a received Binding Update from this mobile node.
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 [6]. 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.
5.2. Binding Acknowledgement Option Format 5.2. Binding Acknowledgement Option Format
skipping to change at page 24, line 18 skipping to change at page 25, line 18
Values of the Status field greater than or equal to 128 Values of the Status field greater than or equal to 128
indicate that the Binding Update was rejected by the receiving indicate that the Binding Update was rejected by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
128 Reason unspecified 128 Reason unspecified
130 Administratively prohibited 130 Administratively prohibited
131 Insufficient resources 131 Insufficient resources
132 Home registration not supported 132 Home registration not supported
133 Not home subnet 133 Not home subnet
135 Dynamic home agent address discovery response
136 Incorrect interface identifier length 136 Incorrect interface identifier length
137 Not home agent for this mobile node 137 Not home agent for this mobile node
138 Duplicate Address Detection failed
Up-to-date values of the Status field are to be specified in Up-to-date values of the Status field are to be specified in
the most recent "Assigned Numbers" [22]. the most recent "Assigned Numbers" [26].
Sequence Number Sequence Number
The Sequence Number in the Binding Acknowledgement is copied The Sequence Number in the Binding Acknowledgement is copied
from the Sequence Number field in the Binding Update being from the Sequence Number field in the Binding Update being
acknowledged, for use by the mobile node in matching this acknowledged, for use by the mobile node in matching this
Acknowledgement with an outstanding Binding Update. Acknowledgement with an outstanding Binding Update.
Lifetime Lifetime
skipping to change at page 25, line 26 skipping to change at page 26, line 26
The value of this field is undefined if the Status field The value of this field is undefined if the Status field
indicates that the Binding Update was rejected. indicates that the Binding Update was rejected.
Sub-Options Sub-Options
Additional information, associated with this Binding Additional information, associated with this Binding
Acknowledgement option, that need not be present in all Binding Acknowledgement option, that need not be present in all Binding
Acknowledgements sent. This use of sub-options also allows for Acknowledgements sent. This use of sub-options also allows for
future extensions to the format of the Binding Acknowledgement future extensions to the format of the Binding Acknowledgement
option to be defined. The encoding and format of defined option to be defined. The encoding and format of defined
sub-options are described in Section 5.5. The following sub-options are described in Section 5.5. Currently, no valid
sub-options are valid in a Binding Acknowledgement option: sub-options are defined for in a Binding Acknowledgement
option.
- Home Agents List Sub-Option
The alignment requirement [5] for the Binding Acknowledgement option The alignment requirement [6] for the Binding Acknowledgement option
is 4n+3. is 4n+3.
Any packet that includes a Binding Acknowledgement option MUST Any packet that includes a Binding Acknowledgement option MUST
also include either an AH [9] or ESP [10] header providing sender also include either an AH [11] or ESP [12] 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
in the Binding Update) in sending the packet containing the Binding in the Binding Update) in sending the packet containing the Binding
Acknowledgement to the mobile node. The details of sending this Acknowledgement to the mobile node. The details of sending this
packet to the mobile node are the same as for sending any packet to a packet to the mobile node are the same as for sending any packet to a
skipping to change at page 26, line 19 skipping to change at page 27, line 18
copied from the care-of address received in the rejected Binding copied from the care-of address received in the rejected Binding
Update; this node MUST NOT modify its Binding Cache in response Update; this node MUST NOT modify its Binding Cache in response
to receiving this rejected Binding Update and MUST ignore its to receiving this rejected Binding Update and MUST ignore its
Binding Cache in sending the packet in which it returns this Binding Binding Cache in sending the packet in which it returns this Binding
Acknowledgement. The packet is sent using a Routing header, routing Acknowledgement. The packet is sent using a Routing header, routing
the packet to the home address of the rejected Binding Update by the packet to the home address of the rejected Binding Update by
way of the care-of address indicated in the packet containing the way of the care-of address indicated in the packet containing the
Binding Update. When sending a Binding Acknowledgement to reject a Binding Update. When sending a Binding Acknowledgement to reject a
Binding Update, the Binding Acknowledgement MUST be sent in an IPv6 Binding Update, the Binding Acknowledgement MUST be sent in an IPv6
packet containing no payload (with the Next Header field in the last packet containing no payload (with the Next Header field in the last
extension header in the packet set to indicate "No Next Header" [5]). extension header in the packet set to indicate "No Next Header" [6]).
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 [6]. For the Binding
Acknowledgement option, these three bits are set to 000, indicating Acknowledgement option, these three bits are set to 000, indicating
that any IPv6 node processing this option that does not recognize the that any IPv6 node processing this option that does not recognize the
Option Type must skip over this option and continue processing the Option Type must skip over this option and continue processing the
header, and that the data within the option cannot change en-route to header, and that the data within the option cannot change en-route to
the packet's final destination. the packet's final destination.
5.3. Binding Request Option Format 5.3. Binding Request Option Format
The Binding Request destination option is used to request a mobile The Binding Request destination option is used to request a mobile
node's binding from the mobile node. As a destination option, it node's binding from the mobile node. As a destination option, it
skipping to change at page 27, line 49 skipping to change at page 28, line 49
Additional information, associated with this Binding Request Additional information, associated with this Binding Request
option, that need not be present in all Binding Requests sent. option, that need not be present in all Binding Requests sent.
This use of sub-options also allows for future extensions to This use of sub-options also allows for future extensions to
the format of the Binding Request option to be defined. The the format of the Binding Request option to be defined. The
encoding and format of defined sub-options are described in encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding Section 5.5. The following sub-options are valid in a Binding
Request option: Request option:
- Unique Identifier Sub-Option - Unique Identifier Sub-Option
There is no requirement for alignment [5] of the Binding Request There is no requirement for alignment [6] of the Binding Request
option. 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 [6]. 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.
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
skipping to change at page 30, line 15 skipping to change at page 31, line 15
Sub-Options Sub-Options
Additional information, associated with this Home Address Additional information, associated with this Home Address
option, that need not be present in all Home Address options option, that need not be present in all Home Address options
sent. This use of sub-options also allows for future sent. This use of sub-options also allows for future
extensions to the format of the Home Address option to be extensions to the format of the Home Address option to be
defined. The encoding and format of defined sub-options are defined. The encoding and format of defined sub-options are
described in Section 5.5. Currently, no valid sub-options are described in Section 5.5. Currently, no valid sub-options are
defined for use in a Home Address option. defined for use in a Home Address option.
The alignment requirement [5] for the Home Address option is 8n+6. The alignment requirement [6] for the Home Address option is 8n+6.
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
skipping to change at page 30, line 47 skipping to change at page 31, line 47
Upon receipt of a packet containing a Home Address option, the Upon receipt of a packet containing a Home Address option, the
receiving node replaces the Source Address in the IPv6 header with receiving node replaces the Source Address in the IPv6 header with
the Home Address in the Home Address option. By requiring that any the Home Address in the Home Address option. By requiring that any
authentication of the IPv6 header also cover the Home Address option, authentication of the IPv6 header also cover the Home Address option,
the security of the Source Address field in the IPv6 header is not the security of the Source Address field in the IPv6 header is not
compromised by the presence of a Home Address option. Security compromised by the presence of a Home Address option. Security
issues related to the Home Address option are discussed further in issues related to the Home Address option are discussed further in
Section 13. Section 13.
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 [6]. For the Home Address
option, these three bits are set to 110, indicating that any IPv6 option, these three bits are set to 110, indicating that any IPv6
node processing this option that does not recognize the Option Type node processing this option that does not recognize the Option Type
must discard the packet and, only if the packet's Destination Address must discard the packet and, only if the packet's Destination Address
was not a multicast address, return an ICMP Parameter Problem, was not a multicast address, return an ICMP Parameter Problem,
Code 2, message to the packet's Source Address; and that the data Code 2, message to the packet's Source Address; and that the data
within the option cannot change en-route to the packet's final within the option cannot change en-route to the packet's final
destination. destination.
5.5. Mobile IPv6 Destination Option Sub-Options 5.5. Mobile IPv6 Destination Option Sub-Options
skipping to change at page 31, line 52 skipping to change at page 32, line 52
8-bit unsigned integer. Length of the Sub-Option Data field 8-bit unsigned integer. Length of the Sub-Option Data field
of this sub-option, in octets. The Sub-Option Len does not of this sub-option, in octets. The Sub-Option Len does not
include the length of the Sub-Option Type and Sub-Option Len include the length of the Sub-Option Type and Sub-Option Len
fields. fields.
Sub-Option Data Sub-Option Data
Variable-length field. Sub-Option-Type-specific data. Variable-length field. Sub-Option-Type-specific data.
As with IPv6 options appearing in a Hop-by-Hop Options header As with IPv6 options appearing in a Hop-by-Hop Options header
or Destination Options header [5], individual sub-options within or Destination Options header [6], individual sub-options within
a Mobile IPv6 destination option may have specific alignment a Mobile IPv6 destination option may have specific alignment
requirements, to ensure that multi-octet values within Sub-Option requirements, to ensure that multi-octet values within Sub-Option
Data fields fall on natural boundaries. The alignment requirement Data fields fall on natural boundaries. The alignment requirement
of a sub-option is specified using the same notation as is used to of each sub-option is specified as part of the definition of each
specify alignment requirements for IPv6 options [5]. sub-option below.
Each section above defining the Mobile IPv6 destination options Each section above defining the Mobile IPv6 destination options
specifies which of the defined sub-options is valid for that specifies which of the defined sub-options is valid for that
destination option. In addition, there are two padding sub-options, destination option. In addition, there are two padding sub-options,
Pad1 and PadN (defined below), which are used when necessary to align Pad1 and PadN (defined below), which are used when necessary to align
subsequent sub-options. The Pad1 and PadN sub-options are valid for subsequent sub-options. The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike the padding options all Mobile IPv6 destination options. Unlike the padding options
used in Hop-by-Hop Options header or Destination Options header [5], used in Hop-by-Hop Options header or Destination Options header [6],
there is no requirement for padding the total size of any Mobile IPv6 there is no requirement for padding the total size of any Mobile IPv6
destination option to a multiple of 8 octets in length, and the destination option to a multiple of 8 octets in length, and the
Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All
Mobile IPv6 sub-options defined in this document MUST be recognized Mobile IPv6 sub-options defined in this document MUST be recognized
by all Mobile IPv6 implementations. by all Mobile IPv6 implementations.
Currently, the following sub-option types are defined for use in Currently, the following sub-option types are defined for use in
Mobile IPv6 destination options: Mobile IPv6 destination options:
Pad1 Sub-Option (alignment requirement: none) Pad1 Sub-Option (alignment requirement: none)
skipping to change at page 33, line 25 skipping to change at page 34, line 25
The Unique Identifier sub-option is valid only in Binding The Unique Identifier sub-option is valid only in Binding
Request and Binding Update destination options. The Unique Request and Binding Update destination options. The Unique
Identifier field contains a 16-bit value that serves to Identifier field contains a 16-bit value that serves to
uniquely identify a Binding Request among those sent by this uniquely identify a Binding Request among those sent by this
Source Address, and to allow the Binding Update to identify Source Address, and to allow the Binding Update to identify
the specific Binding Request to which it responds. This the specific Binding Request to which it responds. This
matching of Binding Updates to Binding Requests is required matching of Binding Updates to Binding Requests is required
in the procedure for renumbering the home subnet while a in the procedure for renumbering the home subnet while a
mobile node is away from home (Section 9.7). mobile node is away from home (Section 9.7).
Home Agents List Sub-Option (alignment requirement: 8n+6) Alternate Care-of Address Sub-Option (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 16 * N | | 4 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. Home Agent Addresses . | |
. (N = number of addresses present) . + Alternate Care-of Addresses +
. . | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Home Agents List sub-option is valid only in a Binding The Alternate Care-of Address sub-option is valid only in
Acknowledgement destination option. The Home Agents Binding Update destination options. The Alternate Care-of
Addresses field contains a list of N addresses of home Address field contains an address to use as the care-of
agents on the home link for the mobile node to which this address for the binding, rather than using the Source
Binding Acknowledgement is sent. This sub-option MUST NOT Address of the packet as the care-of address.
be present unless the Binding Acknowledgement is sent in
response to a "Mobile IPv6 Home-Agents" anycast Binding
Update sent by a mobile node attempting dynamic home agent
address discovery [8]. 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 Home Agent Addresses field for this
sub-option is defined in Section 9.2.
Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) 5.6. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Sections 9.2 and 10.7. The mobile
node sends a Home Agent Address Discovery Request message to the
"Mobile IPv6 Home-Agents" anycast address for its own home subnet
prefix [10], and one of the home agents there responds to the mobile
node with a Home Agent Address Discovery Reply message giving a list
of the routers on the mobile node's home link serving as home agents.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| Alternate Care-of Addresses | + Reserved +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address sub-option is valid only in Type
Binding Update destination options. The Alternate Care-of
Address field contains an address to use as the care-of <To Be Assigned by IANA>
address for the binding, rather than using the Source
Address of the packet as the care-of address. Code
0
Checksum
The ICMP checksum [5].
Identifier
An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request
message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Address
The home address of the mobile node sending the Home Agent
Address Discovery Request message.
The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of
addresses, and the mobile node MUST NOT include a Home Address
option in this packet; the home agent then MUST return the Home
Agent Address Discovery Reply message directly to this care-of
address. These restrictions are necessary, since at the time of
performing this dynamic home agent address discovery, the mobile node
is generally not registered with its home agent; using the mobile
node's care-of address simplifies the return of the Reply message to
the mobile node.
5.7. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a
home agent to respond to a mobile node using the dynamic home agent
address discovery mechanism, as described in Sections 9.2 and 10.7.
The mobile node sends a Home Agent Address Discovery Request message
to the "Mobile IPv6 Home-Agents" anycast address for its own home
subnet prefix [10], and one of the home agents there responds to the
mobile node with a Home Agent Address Discovery Reply message giving
a list of the routers on the mobile node's home link serving as home
agents.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Identifier
The identifier from the invoking Home Agent Address Discovery
Request message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Addresses
A list of addresses of home agents on the home link for the
mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message.
The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of
addresses, and the mobile node MUST NOT include a Home Address
option in this packet; the home agent then MUST return the Home
Agent Address Discovery Reply message directly to this care-of
address. These restrictions are necessary, since at the time of
performing this dynamic home agent address discovery, the mobile node
is generally not registered with its home agent; using the mobile
node's care-of address simplifies the return of the Reply message to
the mobile node.
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 [14] by the addition of a single flag bit for use in the message [17] by the addition of a single flag bit to indicate that
dynamic home agent address discovery mechanism (Sections 9.2 the router sending the Advertisement message is serving as a home
and 10.7). The format of the Router Advertisement message is agent on this link. The format of the Router Advertisement message
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime | | Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [14]: specified for Neighbor Discovery [17]:
Home Agent (H) Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is indicate that the router sending this Router Advertisement is
also functioning as a Mobile IP home agent. also functioning as a Mobile IP home agent on this link.
Reserved Reserved
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:
skipping to change at page 36, line 20 skipping to change at page 40, line 20
- 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 providing home other home agents on the link for which it is providing home
agent service, for use in building its Home Agents List as agent service, for use in building its Home Agents List as
part of the dynamic home agent address discovery mechanism part of the dynamic home agent address discovery mechanism
(Sections 9.2 and 10.7). (Sections 9.2 and 10.7).
- 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.9). care-of address (Section 10.9).
However, Neighbor Discovery [14] only advertises a router's However, Neighbor Discovery [17] 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
and efficiently advertise its global address, by the addition of a and efficiently advertise its global address, by the addition of a
single flag bit in the format of a Prefix Information option for single flag bit in the format of a Prefix Information option for
use in Router Advertisement messages. The format of the Prefix use in Router Advertisement messages. The format of the Prefix
Information option is as follows: Information option is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 36, line 51 skipping to change at page 40, line 51
| | | |
+ + + +
| | | |
+ Prefix + + Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [14]: specified for Neighbor Discovery [17]:
Router Address (R) Router Address (R)
1-bit router address flag. When set, indicates that the 1-bit router address flag. When set, indicates that the
Prefix field, in addition to advertising the indicated prefix, Prefix field, in addition to advertising the indicated prefix,
contains a complete IP address assigned to the sending router. contains a complete IP address assigned to the sending router.
This router IP address has the same scope and conforms to the This router IP address has the same scope and conforms to the
same lifetime values as the advertised prefix. This use of same lifetime values as the advertised prefix. This use of
the Prefix field is compatible with its use in advertising the Prefix field is compatible with its use in advertising
the prefix itself, since prefix advertisement uses only the the prefix itself, since prefix advertisement uses only the
skipping to change at page 37, line 29 skipping to change at page 41, line 29
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the 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 [14]. In this case, at least one of these a subset of the options [17]. In this case, at least one of these
multiple Advertisements being 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 one Prefix Information option
with the Router Address (R) bit set, in each unsolicited multicast with the Router Address (R) bit set, in each unsolicited multicast
Router Advertisement that they send. If multiple Advertisements Router Advertisement that they send. If multiple Advertisements
are being sent instead of a single larger unsolicited multicast are being sent instead of a single larger unsolicited multicast
Advertisement, at least one of these multiple Advertisements SHOULD Advertisement, at least one of these multiple Advertisements SHOULD
include a Prefix Information option with the Router Address (R) bit include a Prefix Information option with the Router Address (R) bit
skipping to change at page 38, line 41 skipping to change at page 42, line 41
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.
Advertisement Interval Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds, 32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited router Router Advertisement between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using messages sent by this router on this network interface. Using
the conceptual router configuration variables defined by the conceptual router configuration variables defined by
Neighbor Discovery [14], this field MUST be equal to the value Neighbor Discovery [17], this field MUST be equal to the value
MaxRtrAdvInterval, expressed in milliseconds. MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option in their Router Advertisements. A Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 10.4. in its movement detection algorithm, as described in Section 10.4.
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
skipping to change at page 39, line 38 skipping to change at page 43, line 38
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 for 16-bit signed, twos-complement integer. The preference for
the home agent sending this Router Advertisement, for use the home agent sending this Router Advertisement, for use in
in ordering the addresses contained in the Home Agents List ordering the addresses returned to a mobile node in the Home
Sub-Option returned in a Binding Acknowledgement; higher values Agent Addresses field of a Home Agent Address Discovery Reply
mean more preferable. If this option is not included in a message. higher values mean more preferable. If this option
Router Advertisement in which the Home Agent (H) bit is set, is not included in a Router Advertisement in which the Home
the preference value for this home agent SHOULD be considered Agent (H) bit is set, the preference value for this home agent
to be 0. Values greater than 0 indicate a home agent more SHOULD be considered to be 0. Values greater than 0 indicate a
preferable than this default value, and values less than 0 home agent more preferable than this default value, and values
indicate a less preferable home agent. In addition to the less than 0 indicate a less preferable home agent.
manual configuration of the Home Agent Preference value as
described in Section 7.3, the Home Agent Preference sent by In addition to the manual configuration of the Home Agent
a home agent could, for example, be set dynamically by the Preference value as described in Section 7.3, the Home Agent
sending home agent based on the number of mobile nodes it is Preference sent by a home agent could be set dynamically by the
currently serving or on its remaining resources for serving sending home agent, for example based on the number of mobile
additional mobile nodes, but such dynamic settings are beyond nodes it is currently serving or on its remaining resources for
the scope of this document. serving additional mobile nodes, but such dynamic settings are
beyond the scope of this document. Any such dynamic setting
of the Home Agent Preference, however, MUST be careful to set
the preference appropriately, relative to the default Home
Agent Preference value of 0 that may be in use by some home
agents on this link (i.e., a home agent not including a Home
Agent Information option in its Router Advertisements will be
considered to have a Home Agent Preference value of 0).
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 41, line 7 skipping to change at page 45, line 7
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
If both the Home Agent Preference and Home Agent Lifetime are set If both the Home Agent Preference and Home Agent Lifetime are set
to their default values specified above, this option SHOULD NOT be to their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home included in the Router Advertisement messages sent by this home
agent. agent.
6.5. Changes to Sending Router Advertisements 6.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [14] limits routers to The Neighbor Discovery protocol specification [17] limits routers to
a minimum interval of 3 seconds between sending unsolicited multicast a minimum interval of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface Router Advertisement messages from any given network interface
(limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough "Routers generate Router Advertisements frequently enough
that hosts will learn of their presence within a few that hosts will learn of their presence within a few
minutes, but not frequently enough to rely on an absence minutes, but not frequently enough to rely on an absence
of advertisements to detect router failure; a separate of advertisements to detect router failure; a separate
Neighbor Unreachability Detection algorithm provides failure Neighbor Unreachability Detection algorithm provides failure
detection." detection."
skipping to change at page 45, line 25 skipping to change at page 49, line 25
- Every home agent MUST be able to encapsulate such intercepted - Every home agent MUST be able to encapsulate such intercepted
packets in order to tunnel them to the primary care-of address packets in order to tunnel them to the primary care-of address
for the mobile node indicated in its binding in the home agent's for the mobile node indicated in its binding in the home agent's
Binding Cache. Binding Cache.
- Every home agent MUST be able to return a Binding Acknowledgement - Every home agent MUST be able to return a Binding Acknowledgement
option in response to a Binding Update option received with the option in response to a Binding Update option received with the
Acknowledge (A) bit set. Acknowledge (A) bit set.
- Every home agent MUST be able to accept packets addressed - Every home agent MUST maintain a separate Home Agents List for
to the "Mobile IPv6 Home-Agents" anycast address for the each link on which it is serving as a home agent, as described in
subnet on which it is serving as a home agent [8], and MUST be Section 4.3.
- Every home agent MUST be able to accept packets addressed to
the "Mobile IPv6 Home-Agents" anycast address for the subnet
on which it is serving as a home agent [10], and MUST be
able to participate in dynamic home agent address discovery able to participate in dynamic home agent address discovery
(Section 9.2). (Section 9.2).
- Every home agent SHOULD support a configuration mechanism to - Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to be sent allow a system administrator to manually set the value to be sent
by this home agent in the Home Agent Preference field of the Home by this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends. Agent Information Option in Router Advertisements that it sends.
7.4. Requirements for IPv6 Mobile Nodes 7.4. Requirements for IPv6 Mobile Nodes
skipping to change at page 47, line 5 skipping to change at page 50, line 22
- Every IPv6 mobile node MUST support receiving a Binding Request - Every IPv6 mobile node MUST support receiving a Binding Request
option, by responding with a Binding Update option. option, by responding with a Binding Update option.
- Every IPv6 mobile node MUST support sending packets containing a - Every IPv6 mobile node MUST support sending packets containing a
Home Address option; this option MUST be included in all packets Home Address option; this option MUST be included in all packets
sent while away from home, if the packet would otherwise have sent while away from home, if the packet would otherwise have
been sent with the mobile node's home address as the IP Source been sent with the mobile node's home address as the IP Source
Address. Address.
- Every IPv6 mobile node MUST maintain a Home Agents List, as
described in Section 4.3.
8. Correspondent Node Operation 8. Correspondent Node Operation
A correspondent node is any node communicating with a mobile node. A correspondent node is any node communicating with a mobile node.
The correspondent node, itself, may be stationary or mobile, and may The correspondent node, itself, may be stationary or mobile, and may
possibly also be functioning as a home agent for Mobile IPv6. The possibly also be functioning as a home agent for Mobile IPv6. The
procedures in this section thus apply to all IPv6 nodes. procedures in this section thus apply to all IPv6 nodes.
8.1. Receiving Packets from a Mobile Node 8.1. Receiving Packets from a Mobile Node
Packets sent by a mobile node while away from home generally include Packets sent by a mobile node while away from home generally include
skipping to change at page 47, line 39 skipping to change at page 51, line 39
the care-of address and Home Address option is transparent to both the care-of address and Home Address option is transparent to both
the mobile node and the correspondent node above the level of the the mobile node and the correspondent node above the level of the
Home Address option generation and processing. Home Address option generation and processing.
8.2. Receiving Binding Updates 8.2. Receiving Binding Updates
Upon receiving a Binding Update option in some packet, the receiving Upon receiving a Binding Update option in some packet, the receiving
node MUST validate the Binding Update according to the following node MUST validate the Binding Update according to the following
tests: tests:
- The packet contains a valid AH [9] or ESP [10] header that - The packet contains a valid AH [11] or ESP [12] header that
provides sender authentication, integrity protection, and replay provides sender authentication, integrity protection, and replay
protection. protection.
- The packet MUST contain a valid Home Address option. The home - The packet MUST contain a valid Home Address option. The home
address for the binding is specified by the Home Address field of address for the binding is specified by the Home Address field of
the Home Address option. the Home Address option.
- The Option Length field in the Binding Update option is greater - The Option Length field in the Binding Update option is greater
than or equal to the length specified in Section 5.1. than or equal to the length specified in Section 5.1.
skipping to change at page 48, line 14 skipping to change at page 52, line 14
for this home address, if any. The Sequence Number comparison is for this home address, if any. The Sequence Number comparison is
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
"Mobile IPv6 Home-Agents" anycast address [8] for an on-link
prefix and this address is assigned to one of this node's network
interfaces, then the mobile node sending this Binding Update is
attempting dynamic home agent address discovery. Processing for
this type of received Binding Update is described in Section 9.2.
(If the Destination Address is not assigned to one of this node's
network interfaces, then the packet would have been forwarded as
a normal packet and the Binding Update, as a destination option,
would not 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
Binding Update, the Binding Update is processed according to the Binding Update, the Binding Update is processed according to the
procedure specified in Section 9.3; otherwise, it is processed procedure specified in Section 9.3; otherwise, it is processed
according to the procedure specified in Section 8.3. according to the procedure specified in Section 8.3.
- If the Lifetime specified in the Binding Update is zero or the - If the Lifetime specified in the Binding Update is zero or the
skipping to change at page 49, line 41 skipping to change at page 53, line 31
When any node receives a packet containing a Binding Update option When any node receives a packet containing a Binding Update option
in which the Acknowledge (A) bit is set, it SHOULD return a Binding in which the Acknowledge (A) bit is set, it SHOULD return a Binding
Acknowledgement option acknowledging receipt of the Binding Update. Acknowledgement option acknowledging receipt of the Binding Update.
If the node accepts the Binding Update and creates or updates an If the node accepts the Binding Update and creates or updates an
entry in its Binding Cache for this binding, the Status field in entry in its Binding Cache for this binding, the Status field in
the Binding Acknowledgement MUST be set to a value less than 128; the Binding Acknowledgement MUST be set to a value less than 128;
if the node rejects the Binding Update and does not create or if the node rejects the Binding Update and does not create or
update an entry for this binding, the Status field in the Binding update an entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value greater than or equal to 128. Acknowledgement MUST be set to a value greater than or equal to 128.
Specific values for the Status field are described in Section 5.2 and Specific values for the Status field are described in Section 5.2 and
in the most recent "Assigned Numbers" [22]. in the most recent "Assigned Numbers" [26].
As described in Section 5.2, the packet in which the Binding As described in Section 5.2, the packet in which the Binding
Acknowledgement is returned MUST include either an AH [9] or ESP [10] Acknowledgement is returned MUST include either an AH [11] or
header providing sender authentication, data integrity protection, ESP [12] header providing sender authentication, data integrity
and replay protection; and the packet MUST be sent using a Routing protection, and replay protection; and the packet MUST be sent using
header in the same way as any other packet sent to a mobile node a Routing header in the same way as any other packet sent to a mobile
using a care-of address (even if the binding was rejected), as node using a care-of address (even if the binding was rejected), as
described in Section 8.9. The packet is routed first to the care-of described in Section 8.9. The packet is routed first to the care-of
address contained in the Binding Update being acknowledged, and address contained in the Binding Update being acknowledged, and
then to the mobile node's home address. This use of the Routing then to the mobile node's home address. This use of the Routing
header ensures that the Binding Acknowledgement will be routed to the header ensures that the Binding Acknowledgement will be routed to the
current location of the node sending the Binding Update, whether the current location of the node sending the Binding Update, whether the
Binding Update was accepted or rejected. Binding Update was accepted or rejected.
8.6. Sending Binding Requests 8.6. Sending Binding Requests
Entries in a node's Binding Cache MUST be deleted when their lifetime Entries in a node's Binding Cache MUST be deleted when their lifetime
skipping to change at page 52, line 31 skipping to change at page 56, line 19
Cache entry for the mobile node. Cache entry for the mobile node.
8.9. Sending Packets to a Mobile Node 8.9. Sending Packets to a Mobile Node
Before sending any packet, the sending node SHOULD examine its Before sending any packet, the sending node SHOULD examine its
Binding Cache for an entry for the destination address to which the Binding Cache for an entry for the destination address to which the
packet is being sent. If the sending node has a Binding Cache entry packet is being sent. If the sending node has a Binding Cache entry
for this address, the sending node SHOULD use a Routing header to for this address, the sending node SHOULD use a Routing header to
route the packet to this mobile node (the destination node) by way route the packet to this mobile node (the destination node) by way
of the care-of address in the binding recorded in that Binding Cache of the care-of address in the binding recorded in that Binding Cache
entry. For example, assuming use of a Type 0 Routing header [5], if entry. For example, assuming use of a Type 0 Routing header [6], if
no other use of a Routing header is involved in the routing of this no other use of a Routing header is involved in the routing of this
packet, the mobile node sets the fields in the packet's IPv6 header packet, the mobile node sets the fields in the packet's IPv6 header
and Routing header as follows: and Routing header as follows:
- The Destination Address in the packet's IPv6 header is set to - The Destination Address in the packet's IPv6 header is set to
the mobile node's care-of address copied from the Binding Cache the mobile node's care-of address copied from the Binding Cache
entry. entry.
- The Routing header is initialized to contain a single route - The Routing header is initialized to contain a single route
segment, with an Address of the mobile node's home address (the segment, with an Address of the mobile node's home address (the
original destination address to which the packet was being sent). original destination address to which the packet was being sent).
Following the definition of a Type 0 Routing header [5], this packet Following the definition of a Type 0 Routing header [6], this packet
will be routed to the mobile node's care-of address, where it will will be routed to the mobile node's care-of address, where it will
be delivered to the mobile node (the mobile node has associated the be delivered to the mobile node (the mobile node has associated the
care-of address with its network interface). Normal processing of care-of address with its network interface). Normal processing of
the Routing header by the mobile node will then proceed as follows: the Routing header by the mobile node will then proceed as follows:
- The mobile node swaps the Destination Address in the packet's - The mobile node swaps the Destination Address in the packet's
IPv6 header and the Address specified in the Routing header. IPv6 header and the Address specified in the Routing header.
This results in the packet's IP Destination Address being set to This results in the packet's IP Destination Address being set to
the mobile node's home address. the mobile node's home address.
- The mobile node then resubmits the packet to its IPv6 module for - The mobile node then resubmits the packet to its IPv6 module for
further processing, "looping back" the packet inside the mobile further processing, "looping back" the packet inside the mobile
node. Since the mobile node recognizes its own home address as node. Since the mobile node recognizes its own home address as
one of its current IP addresses, the packet is processed further one of its current IP addresses, the packet is processed further
within the mobile node, in the same way then as if the mobile within the mobile node, in the same way then as if the mobile
node was at home. node was at home.
skipping to change at page 54, line 17 skipping to change at page 58, line 17
9.1. Receiving Router Advertisement Messages 9.1. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent, the For each link on which a router provides service as a home agent, the
router maintains a Home Agents List recording information about all router maintains a Home Agents List recording information about all
other home agents on that link. This list is used in the dynamic other home agents on that link. This list is used in the dynamic
home agent address discovery mechanism, described in Section 9.2. home agent address discovery mechanism, described in Section 9.2.
The information for the list is learned through receipt of the The information for the list is learned through receipt of the
periodic unsolicited multicast Router Advertisements from each other periodic unsolicited multicast Router Advertisements from each other
home agent on the link, in which the Home Agent (H) bit is set, in a home agent on the link, in which the Home Agent (H) bit is set, in a
manner similar to the Default Router List conceptual data structure manner similar to the Default Router List conceptual data structure
maintained by each host for Neighbor Discovery [14]. maintained by each host for Neighbor Discovery [17].
On receipt of a valid Router Advertisement, as defined in the On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [14], the home processing algorithm specified for Neighbor Discovery [17], 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 this Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [14]. link of the home agent sending this Advertisement [17].
- 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
skipping to change at page 55, line 27 skipping to change at page 59, line 27
(Section 6.2). For each such global address determined from this (Section 6.2). For each such global address determined from this
Advertisement, add this global address to the list of global Advertisement, add this global address to the list of global
addresses for this home agent in this Home Agents List entry. 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 A mobile node, while away from home, MAY use the dynamic home agent
determine the type of Binding Update according to the steps described address discovery mechanism to attempt to discover the address of
in Section 8.2. This section describes the processing of a valid one or more routers serving as home agents on its home link. This
Binding Update that indicates that the mobile node sending it is discovery may be necessary, for example, if some nodes on its home
attempting dynamic home agent address discovery. link have been reconfigured while the mobile node has been away from
home, such that the router that was operating as the mobile node's
home agent has been replaced by a different router serving this role.
As described in Section 10.7, a mobile node attempts dynamic home As described in Section 10.7, a mobile node attempts dynamic home
agent address discovery by sending its "home registration" Binding agent address discovery by sending an ICMP Home Agent Address
Update to the "Mobile IPv6 Home-Agents" anycast address [8] for its Discovery message to the "Mobile IPv6 Home-Agents" anycast
home IP subnet prefix (the packet MUST also include a Home Address address [10] for its home IP subnet prefix; the packet MUST also
option). A home agent receiving such a Binding Update that is include a Home Address option. A home agent receiving such a Home
serving this subnet (the home agent is configured with this anycast Agent Address Discovery Request message that is serving this subnet
address on one of its network interfaces) MUST reject the Binding (the home agent is configured with this anycast address on one of
Update and SHOULD return a Binding Acknowledgement indicating this its network interfaces) SHOULD return an ICMP Home Agent Address
rejection, with the Source Address of the packet carrying the Binding Discovery Reply message to the mobile node, with the Source Address
Acknowledgement set to one of the global unicast addresses of the of the packet set to one of the global unicast addresses of the
home agent. The Status field in the Binding Acknowledgement MUST be home agent. The Home Agent Addresses field in the Reply message is
set to 135 (dynamic home agent address discovery response). constructed as follows:
In this Binding Acknowledgement rejecting the dynamic home agent
address discovery Binding Update, this home agent SHOULD include a
Home Agents List Sub-Option as follows:
- The Home Agents List Sub-Option in this Binding Acknowledgement - The Home Agent Addresses field SHOULD contain one global IP
SHOULD contain one global IP address for each home agent address for each home agent currently listed in this home
currently listed in this home agent's own Home Agents List agent's own Home Agents List (Section 4.3). However, if this
(Section 4.3). However, if this home agent's own global IP home agent's own global IP address would be placed in the list
address would be placed in the list (as described below) as the (as described below) as the first entry in the list, then this
first entry in the list, then this home agent SHOULD NOT include home agent SHOULD NOT include its own address in the Home Agent
its own address in the list in the sub-option in the Binding Addresses field in the Reply message. Not placing this home
Acknowledgement. Not placing this home agent's own IP address in agent's own IP address in the list will cause the receiving
the list will cause the receiving mobile node to consider this mobile node to consider this home agent as the most preferred
home agent as the most preferred home agent; otherwise, this home home agent; otherwise, this home agent will be considered to be
agent will be considered to be preferred in its order given by preferred in its order given by its place in the list returned.
its place in the list returned.
- The IP addresses in the Home Agents List should be placed in - The IP addresses in the Home Agent Addresses field should be
the Home Agents List Sub-Option in the Binding Acknowledgement listed in order of decreasing preference value, based either
in order of decreasing preference value, based either on the on the respective advertised preference from a Home Agent
respective advertised preference from a Home Agent Information Information option or on the default preference of 0 if no
option or on the default preference of 0 if no preference is preference is advertised (or on the configured home agent
advertised (or on the configured home agent preference for this preference for this home agent itself). The home agent with
home agent itself). The home agent with the highest preference the highest preference SHOULD be listed first in the Home Agent
SHOULD be listed first, and the home agent with the lowest Addresses field, and the home agent with the lowest preference
preference SHOULD be listed last. SHOULD be listed last.
- Among home agents with equal preference, their IP addresses in - Among home agents with equal preference, their IP addresses
the Home Agents List SHOULD be listed in an order randomized with in the Home Agent Addresses field SHOULD be listed in an
respect to other home agents with equal preference, each time a order randomized with respect to other home agents with equal
Binding Acknowledgement with a Home Agents List Sub-Option is preference, each time a Home Agent Address Discovery Reply
returned by this home agent. message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more - For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry, than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected to then one of these global IP addresses SHOULD be selected to
include in the Home Agents List Sub-Option to be returned in the include in the Home Agent Addresses field in the Reply message.
Binding Acknowledgement. As described in Section 4.3, one Home As described in Section 4.3, one Home Agents List entry,
Agents List entry, identified by the home agent's link-local identified by the home agent's link-local address, exists for
address, exists for each home agent on the link; associated with each home agent on the link; associated with that list entry is
that list entry is one or more global IP addresses for this one or more global IP addresses for this home agent, learned
home agent, learned through Prefix Information options with the through Prefix Information options with the Router Address (R)
Router Address (R) bit is set, received in Router Advertisements bit is set, received in Router Advertisements from this
from this link-local address. The selected global IP address link-local address. The selected global IP address for each home
for each home agent to include in forming the Home Agents List agent to include in forming the Home Agent Addresses field in the
Sub-Option to be returned in the Binding Acknowledgement MUST Reply message MUST be the global IP address of the respective
be the global IP address of the respective home agent sharing a home agent sharing a prefix with the mobile node's home address
prefix with the mobile node's home address for which the Binding as indicated in the Home Address option in the Request message;
Acknowledgement is being returned; if no such global IP address if no such global IP address is known for some home agent, an
is known for some home agent, an entry for that home agent MUST entry for that home agent MUST NOT be included in the Home Agent
NOT be included in the Home Agents List Sub-Option returned in Addresses field in the Reply message.
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 - In order to avoid the possibility of the Reply message packet
then resend its Binding Update to the home agent address given as the being fragmented (or rejected by an intermediate router with an
IP Source Address of the packet carrying the Binding Acknowledgement ICMP Packet Too Big message [5]), if the resulting total packet
or to any of the unicast IP addresses listed in the Home Agents List size containing the complete list of home agents in the Home
Sub-Option in the Acknowledgement. For example, the mobile node may Agent Addresses field would exceed the minimum IPv6 MTU [6], the
re-attempt its home registration with each of these home agents in home agent SHOULD reduce the number of home agent IP addresses
turn, by sending each a Binding Update and waiting for the matching returned in the packet to the number of addresses that will fit
Binding Acknowledgement, until its registration is accepted by one without exceeding this limit. The home agent addresses returned
of these home agents. In trying each of the returned home agent in the packet SHOULD be those from the complete list with the
addresses, the mobile node SHOULD try each in the order listed in the highest preference.
Home Agents List Sub-Option in the Binding Acknowledgement. If the
home agent identified by the Source Address field in the IP header
of the packet carrying the Binding Acknowledgement is not listed in
the Home Agents List Sub-Option, it SHOULD be tried before the first
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 58, line 15 skipping to change at page 61, line 45
return a Binding Acknowledgement to the mobile node, in which the return a Binding Acknowledgement to the mobile node, in which the
Status field is set to 136 (incorrect subnet prefix length). Status field is set to 136 (incorrect subnet prefix length).
- Else, if the home agent chooses to reject the Binding Update for - Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for field is set to an appropriate value to indicate the reason for
the rejection. the rejection.
- Finally, if the Duplicate Address Detection (D) bit is set in the
Binding Update, this home agent MUST perform Duplicate Address
Detection [27] on the mobile node's home link for the home
address in this binding. If this Duplicate Address Detection
fails, then the home agent MUST reject the Binding Update and
SHOULD return a Binding Acknowledgement to the mobile node, in
which the Status field is set to 138 (Duplicate Address Detection
failed).
If the home agent does not reject the Binding Update as described If the home agent does not reject the Binding Update as described
above, then it becomes the home agent for the mobile node. The new above, then it becomes the home agent for the mobile node. The new
home agent (the receiving node) MUST then create a new entry in its home agent (the receiving node) MUST then create a new entry in its
Binding Cache for this mobile node (or update its existing Binding Binding Cache for this mobile node (or update its existing Binding
Cache entry for this mobile node, if such an entry already exists) Cache entry for this mobile node, if such an entry already exists)
The home address of the mobile node is taken from the Home Address The home address of the mobile node is taken from the Home Address
field in the packet's Home Address option. The care-of address for field in the packet's Home Address option. The care-of address for
this Binding Cache entry is taken from the Alternate Care-of Address this Binding Cache entry is taken from the Alternate Care-of Address
sub-option in the Binding Update option, if present, or from the sub-option in the Binding Update option, if present, or from the
Source Address field in the packet's IPv6 header, otherwise. Source Address field in the packet's IPv6 header, otherwise.
skipping to change at page 58, line 42 skipping to change at page 62, line 32
period. period.
In addition, the home agent MUST copy the Router (R) bit from the In addition, the home agent MUST copy the Router (R) bit from the
Binding Update into the corresponding bit in this Binding Cache entry Binding Update into the corresponding bit in this Binding Cache entry
for this mobile node. for this mobile node.
The lifetime for the Binding Cache entry MUST NOT be greater than The lifetime for the Binding Cache entry MUST NOT be greater than
the remaining valid lifetime for the subnet prefix in the mobile the remaining valid lifetime for the subnet prefix in the mobile
node's home address specified with the Binding Update. The remaining node's home address specified with the Binding Update. The remaining
valid lifetime for this prefix is determined by the home agent based valid lifetime for this prefix is determined by the home agent based
on its own Prefix List entry for this prefix [14]. Furthermore, on its own Prefix List entry for this prefix [17]. Furthermore,
if the Prefix Length field in the Binding Update is nonzero, then if the Prefix Length field in the Binding Update is nonzero, then
the lifetime for the Binding Cache entry MUST NOT be greater than the lifetime for the Binding Cache entry MUST NOT be greater than
the minimum remaining valid lifetime for all subnet prefixes on the minimum remaining valid lifetime for all subnet prefixes on
the mobile node's home link. If the value of the Lifetime field 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 specified by the mobile node in its Binding Update is greater than
this prefix lifetime, the home agent MUST decrease the binding this prefix lifetime, the home agent MUST decrease the binding
lifetime to less than or equal to the prefix valid lifetime. The lifetime to less than or equal to the prefix valid lifetime. The
home agent MAY further decrease the specified lifetime for 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
skipping to change at page 60, line 50 skipping to change at page 64, line 41
node has an entry in its Binding Cache for this mobile node that is node has an entry in its Binding Cache for this mobile node that is
marked as a "home registration"), this node MUST attempt to intercept marked as a "home registration"), this node MUST attempt to intercept
packets on the mobile node's home link addressed to the mobile node, packets on the mobile node's home link addressed to the mobile node,
and MUST tunnel each intercepted packet to the mobile node using and MUST tunnel each intercepted packet to the mobile node using
using IPv6 encapsulation [4]. using IPv6 encapsulation [4].
In order to intercept such packets on the home link, when a node In order to intercept such packets on the home link, when a node
becomes the home agent for some mobile node (it did not already becomes the home agent for some mobile node (it did not already
have a Binding Cache entry for this mobile node marked as a "home have a Binding Cache entry for this mobile node marked as a "home
registration"), then the home agent MUST multicast onto the home link registration"), then the home agent MUST multicast onto the home link
a "gratuitous" Neighbor Advertisement message [14] on behalf of the a "gratuitous" Neighbor Advertisement message [17] on behalf of the
mobile node. Specifically, the home agent performs the following mobile node. Specifically, the home agent performs the following
steps: steps:
- The home agent examines the value of the Prefix Length field - The home agent examines the value of the Prefix Length field
in the new "home registration" Binding Cache entry. If this in the new "home registration" Binding Cache entry. If this
value is zero, the following step is carried out only for the value is zero, the following step is carried out only for the
individual home address specified for this binding. If, instead, individual home address specified for this binding. If, instead,
this field is nonzero, then the following step is carried out this field is nonzero, then the following step is carried out
for each address for the mobile node formed from the interface for each address for the mobile node formed from the interface
identifier in the mobile node's home address in this binding identifier in the mobile node's home address in this binding
(the remaining low-order bits in the address after the indicated (the remaining low-order bits in the address after the indicated
subnet prefix), together with each one of the subnet prefixes subnet prefix), together with each one of the subnet prefixes
currently considered by the home agent to be on-link (including currently considered by the home agent to be on-link (including
both the link-local and site-local prefix). both the link-local and site-local prefix).
- For each specific IP address for the mobile node determined - For each specific IP address for the mobile node determined
in the first step above, the home agent multicasts onto the in the first step above, the home agent multicasts onto the
home link (to the all-nodes multicast address) a Neighbor home link (to the all-nodes multicast address) a Neighbor
Advertisement message [14] on behalf of the mobile node, to Advertisement message [17] on behalf of the mobile node, to
advertise the home agent's own link-layer address for this IP advertise the home agent's own link-layer address for this IP
address. The Target Address in the Neighbor Advertisement address. The Target Address in the Neighbor Advertisement
message MUST be set to this IP address for the mobile node, and message MUST be set to this IP address for the mobile node, and
the Advertisement MUST include a Target Link-layer Address option the Advertisement MUST include a Target Link-layer Address option
specifying the home agent's link-layer address. In addition, specifying the home agent's link-layer address. In addition,
the Router (R) bit in the Advertisement MUST be copied from the the Router (R) bit in the Advertisement MUST be copied from the
corresponding bit in the home agent's Binding Cache entry for corresponding bit in the home agent's Binding Cache entry for
the mobile node. The Solicited Flag (S) in the Advertisement the mobile node. The Solicited Flag (S) in the Advertisement
MUST NOT be set, since it was not solicited by any Neighbor MUST NOT be set, since it was not solicited by any Neighbor
Solicitation message. The Override Flag (O) in the Advertisement Solicitation message. The Override Flag (O) in the Advertisement
skipping to change at page 61, line 46 skipping to change at page 65, line 36
associate the mobile node's address with the home agent's link associate the mobile node's address with the home agent's link
layer address, causing it to transmit any future packets for the layer address, causing it to transmit any future packets for the
mobile node normally destined to this address instead to the mobile mobile node normally destined to this address instead to the mobile
node's home agent. Since multicasts on the local link (such as node's home agent. Since multicasts on the local link (such as
Ethernet) are typically not guaranteed to be reliable, the home Ethernet) are typically not guaranteed to be reliable, the home
agent MAY retransmit this Neighbor Advertisement message up to agent MAY retransmit this Neighbor Advertisement message up to
MAX_ADVERT_REXMIT times to increase its reliability. It is still MAX_ADVERT_REXMIT times to increase its reliability. It is still
possible that some nodes on the home link will not receive any of possible that some nodes on the home link will not receive any of
these Neighbor Advertisements, but these nodes will eventually be these Neighbor Advertisements, but these nodes will eventually be
able to detect the link-layer address change for the mobile node's able to detect the link-layer address change for the mobile node's
home address, through use of Neighbor Unreachability Detection [14]. home address, through use of Neighbor Unreachability Detection [17].
While a node is serving as a home agent for some mobile node (it While a node is serving as a home agent for some mobile node (it
still has a "home registration" entry for this mobile node in its still has a "home registration" entry for this mobile node in its
Binding Cache), the home agent uses IPv6 Neighbor Discovery [14] Binding Cache), the home agent uses IPv6 Neighbor Discovery [17]
to intercept unicast packets on the home link addressed the mobile to intercept unicast packets on the home link addressed the mobile
node's home address. In order to intercept packets in this way, node's home address. In order to intercept packets in this way,
the home agent MUST act as a proxy for this mobile node to reply to the home agent MUST act as a proxy for this mobile node to reply to
any received Neighbor Solicitation messages for it. When a home any received Neighbor Solicitation messages for it. When a home
agent receives a Neighbor Solicitation message, it MUST check if the agent receives a Neighbor Solicitation message, it MUST check if the
Target Address specified in the message matches the home address Target Address specified in the message matches the home address
of any mobile node for which it has a Binding Cache entry marked of any mobile node for which it has a Binding Cache entry marked
as a "home registration". This check MUST include all possible as a "home registration". This check MUST include all possible
home addresses for the mobile node, based on the subnet prefixes home addresses for the mobile node, based on the subnet prefixes
currently considered to be on-link by the home agent (including the currently considered to be on-link by the home agent (including the
skipping to change at page 62, line 23 skipping to change at page 66, line 14
If such an entry exists in the home agent's Binding Cache, the home If such an entry exists in the home agent's Binding Cache, the home
agent MUST reply to the Neighbor Solicitation message with a Neighbor agent MUST reply to the Neighbor Solicitation message with a Neighbor
Advertisement message, giving the home agent's own link-layer address Advertisement message, giving the home agent's own link-layer address
as the link-layer address for the specified Target Address. In as the link-layer address for the specified Target Address. In
addition, the Router (R) bit in the Advertisement MUST be copied from addition, the Router (R) bit in the Advertisement MUST be copied from
the corresponding bit in the home agent's Binding Cache entry for the the corresponding bit in the home agent's Binding Cache entry for the
mobile node. Acting as a proxy in this way allows other nodes on mobile node. Acting as a proxy in this way allows other nodes on
the mobile node's home link to resolve the mobile node's IPv6 home the mobile node's home link to resolve the mobile node's IPv6 home
address, and allows the home agent to to defend these addresses on address, and allows the home agent to to defend these addresses on
the home link for Duplicate Address Detection [14]. the home link for Duplicate Address Detection [17].
9.6. Tunneling Intercepted Packets to a Mobile Node 9.6. Tunneling Intercepted Packets to a Mobile Node
For any packet sent to a mobile node from the mobile node's home For any packet sent to a mobile node from the mobile node's home
agent (for which the home agent is the original sender of the agent (for which the home agent is the original sender of the
packet), the home agent is operating as a correspondent node of packet), the home agent is operating as a correspondent node of
the mobile node for this packet and the procedures described in the mobile node for this packet and the procedures described in
Section 8.9 apply. The home agent (as a correspondent node) uses a Section 8.9 apply. The home agent (as a correspondent node) uses a
Routing header to route the packet to the mobile node by way of the Routing header to route the packet to the mobile node by way of the
care-of address in the home agent's Binding Cache (the mobile node's care-of address in the home agent's Binding Cache (the mobile node's
primary care-of address, in this case). primary care-of address, in this case).
While the mobile node is away from home and this node is acting While the mobile node is away from home and this node is acting
as the mobile node's home agent, the home agent intercepts any as the mobile node's home agent, the home agent intercepts any
packets on the home link addressed to the mobile node's home address packets on the home link addressed to the mobile node's home address
(including addresses formed from other on-link prefixes, if the (including addresses formed from other on-link prefixes, if the
Prefix Length field was nonzero in the Binding Update), as described Prefix Length field was nonzero in the Binding Update), as described
in Section 9.5. The home agent cannot use a Routing header to in Section 9.5. The home agent cannot use a Routing header to
forward these intercepted packets to the mobile node, since it cannot forward these intercepted packets to the mobile node, since it cannot
modify the packet in flight without invalidating any existing IPv6 modify the packet in flight without invalidating any existing IPv6
AH [9] or ESP [10] header present in the packet. AH [11] or ESP [12] header present in the packet.
For forwarding each intercepted packet to the mobile node, the For forwarding each intercepted packet to the mobile node, the
home agent MUST tunnel the packet to the mobile node using IPv6 home agent MUST tunnel the packet to the mobile node using IPv6
encapsulation [4]; the tunnel entry point node is the home agent, encapsulation [4]; the tunnel entry point node is the home agent,
and the tunnel exit point node is the primary care-of address as and the tunnel exit point node is the primary care-of address as
registered with the home agent (which is an address of the mobile registered with the home agent (which is an address of the mobile
node itself). When a home agent encapsulates an intercepted packet node itself). When a home agent encapsulates an intercepted packet
for forwarding to the mobile node, the home agent sets the Source for forwarding to the mobile node, the home agent sets the Source
Address in the prepended tunnel IP header to the home agent's own IP Address in the prepended tunnel IP header to the home agent's own IP
address, and sets the Destination Address in the tunnel IP header address, and sets the Destination Address in the tunnel IP header
skipping to change at page 63, line 25 skipping to change at page 67, line 15
this Source Address is a multicast address). Packets addressed to this Source Address is a multicast address). Packets addressed to
the mobile node's site-local address SHOULD be tunneled to the mobile the mobile node's site-local address SHOULD be tunneled to the mobile
node by default, but this behavior MUST be configurable to disable node by default, but this behavior MUST be configurable to disable
it; currently, the exact definition and semantics of a "site" and a it; currently, the exact definition and semantics of a "site" and a
site-local address are undefined in IPv6, and this default behavior site-local address are undefined in IPv6, and this default behavior
might change at some point in the future. might change at some point in the future.
Tunneling of multicast packets to a mobile node follows similar Tunneling of multicast packets to a mobile node follows similar
limitations to those defined above for unicast packets addressed to limitations to those defined above for unicast packets addressed to
the mobile node's link-local and site-local addresses. Multicast the mobile node's link-local and site-local addresses. Multicast
packets addressed to a multicast address with link-local scope [7], packets addressed to a multicast address with link-local scope [9],
to which the mobile node is subscribed, MUST NOT be tunneled to which the mobile node is subscribed, MUST NOT be tunneled
to the mobile node; such packets SHOULD be silently discarded to the mobile node; such packets SHOULD be silently discarded
(after delivering to other local multicast recipients). Multicast (after delivering to other local multicast recipients). Multicast
packets addressed to a multicast address with scope larger packets addressed to a multicast address with scope larger
than link-local but smaller than global (e.g., site-local and than link-local but smaller than global (e.g., site-local and
organization-local) [7], to which the mobile node is subscribed, organization-local) [9], to which the mobile node is subscribed,
SHOULD be tunneled to the mobile node by default, but this behavior SHOULD be tunneled to the mobile node by default, but this behavior
MUST be configurable to disable it; this default behavior might MUST be configurable to disable it; this default behavior might
change at some point in the future as the definition of these scopes change at some point in the future as the definition of these scopes
become better defined in IPv6. become better defined in IPv6.
9.7. Renumbering the Home Subnet 9.7. Renumbering the Home Subnet
IPv6 provides mechanisms through Neighbor Discovery [14] and Address IPv6 provides mechanisms through Neighbor Discovery [17] and Address
Autoconfiguration [23] to aid in renumbering a subnet, such as when a Autoconfiguration [27] to aid in renumbering a subnet, such as when a
site switches to a new network service provider. In renumbering, new site switches to a new network service provider. In renumbering, new
prefixes and addresses can be introduced for the subnet and old ones prefixes and addresses can be introduced for the subnet and old ones
can be deprecated and removed. These mechanisms are defined to work can be deprecated and removed. These mechanisms are defined to work
while all nodes using the old prefixes are at home, connected to the while all nodes using the old prefixes are at home, connected to the
link using these prefixes. Mobile IPv6 extends these mechanisms for link using these prefixes. Mobile IPv6 extends these mechanisms for
the case in which one or more mobile nodes using the old prefixes are the case in which one or more mobile nodes using the old prefixes are
away from home while the renumbering takes place. away from home while the renumbering takes place.
The IPv6 renumbering mechanisms are based on nodes on the link The IPv6 renumbering mechanisms are based on nodes on the link
receiving Prefix Information options in Router Advertisement messages receiving Prefix Information options in Router Advertisement messages
giving the valid lifetime and preferred lifetime for different giving the valid lifetime and preferred lifetime for different
prefixes on the link [14]. Mobile IPv6 arranges to tunnel certain prefixes on the link [17]. Mobile IPv6 arranges to tunnel certain
Router Advertisements giving "important" Prefix Information options Router Advertisements giving "important" Prefix Information options
to mobile nodes while away from home. To avoid the need to tunnel to mobile nodes while away from home. To avoid the need to tunnel
all Router Advertisements from the home link to a mobile node away all Router Advertisements from the home link to a mobile node away
from home, those Router Advertisements that are tunneled to the from home, those Router Advertisements that are tunneled to the
mobile node are retransmitted until acknowledged. To avoid possible mobile node are retransmitted until acknowledged. To avoid possible
security attacks from forged Router Advertisements tunneled to security attacks from forged Router Advertisements tunneled to
the mobile node, all such tunneled Router Advertisements must be the mobile node, all such tunneled Router Advertisements must be
authenticated to the mobile node by its home agent using AH [9] or authenticated to the mobile node by its home agent using AH [11] or
ESP [10]. ESP [12].
Specifically, a home agent serving some mobile node SHOULD construct Specifically, a home agent serving some mobile node SHOULD construct
and tunnel to the mobile node a new Router Advertisement when any of and tunnel to the mobile node a new Router Advertisement when any of
the following conditions occur: the following conditions occur:
- The preferred or valid lifetime for an existing prefix on the - The preferred or valid lifetime for an existing prefix on the
home link is reduced. home link is reduced.
- A new prefix is introduced on the home link. - A new prefix is introduced on the home link.
- The state of the home agent's AdvManagedFlag flag [14] changes - The state of the home agent's AdvManagedFlag flag [17] changes
from FALSE to TRUE or from TRUE to FALSE. from FALSE to TRUE or from TRUE to FALSE.
The home agent determines these conditions based on its own The home agent determines these conditions based on its own
configuration as a router and based on the Router Advertisements configuration as a router and based on the Router Advertisements
that it receives on the home link. The home agent constructs a new that it receives on the home link. The home agent constructs a new
Router Advertisement message containing no options other than the Router Advertisement message containing no options other than the
Prefix Information options describing the prefixes for which one of Prefix Information options describing the prefixes for which one of
the conditions above has occurred since the last Router Advertisement the conditions above has occurred since the last Router Advertisement
tunneled to and acknowledged by the mobile node. When multiple tunneled to and acknowledged by the mobile node. When multiple
conditions occur at or near the same time, the home agent SHOULD conditions occur at or near the same time, the home agent SHOULD
attempt to combine them into a single Router Advertisement message to attempt to combine them into a single Router Advertisement message to
the mobile node. the mobile node.
In tunneling each such Router Advertisement to the mobile node, the In tunneling each such Router Advertisement to the mobile node, the
home agent MUST construct the packet as follows: home agent MUST construct the packet as follows:
- 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 [9] or ESP [10] header - The packet MUST include either an AH [11] or ESP [12] 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 - The Binding Request destination option MUST include a Unique
Identifier Sub-Option (Section 5.5), with the unique identifier Identifier Sub-Option (Section 5.5), with the unique identifier
in the sub-option data set to a value different than that in in the sub-option data set to a value different than that in
any other Binding Request sent recently by this node. The word any other Binding Request sent recently by this node. The word
"recently" here means within the maximum likely lifetime of a "recently" here means within the maximum likely lifetime of a
skipping to change at page 67, line 15 skipping to change at page 70, line 15
10. Mobile Node Operation 10. Mobile Node Operation
10.1. Sending Packets While Away from Home 10.1. Sending Packets While Away from Home
While a mobile node is away from home, it continues to use its home While a mobile node is away from home, it continues to use its home
address as well as also using one or more care-of addresses. When address as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node MAY choose among sending a packet while away from home, a mobile node MAY choose among
these in selecting the address that it will use as the source of the these in selecting the address that it will use as the source of the
packet, as follows: packet, as follows:
- From the point of view of protocol layers and applications - From the point of view of protocol layers and applications above
above Mobile IP (e.g., transport protocols), the mobile node Mobile IP (e.g., transport protocols), the mobile node will
will generally use its home address as the source of the packet generally use its home address as the source of the packet for
for most packets, even while away from home, since Mobile IP most packets, even while away from home, since Mobile IP is
is designed to make mobility transparent to such software. designed to make mobility transparent to such software. Doing
Doing so also makes the node's mobility and the fact that it is so also makes the node's mobility---and the fact that it is
currently away from home transparent to the correspondent nodes currently away from home---transparent to the correspondent nodes
with which it communicates. For packets sent that are part of with which it communicates. For packets sent that are part of
transport-level connections established while the mobile node transport-level connections established while the mobile node
was at home, the mobile node MUST use its home address in this was at home, the mobile node MUST use its home address in this
way. Likewise, for packets sent that are part of transport-level way. Likewise, for packets sent that are part of transport-level
connections that the mobile node may still be using after moving connections that the mobile node may still be using after moving
to a new location, the mobile node SHOULD use its home address to a new location, the mobile node SHOULD use its home address
in this way. When sending such packets, Mobile IP will modify in this way. When sending such packets, Mobile IP will modify
the packet to move the home address into a Home Address option the packet to move the home address into a Home Address option
and will set the IPv6 header's Source Address field to one of and will set the IPv6 header's Source Address field to one of
the mobile node's care-of addresses; these modifications to the mobile node's care-of addresses; these modifications to
the packet are then reversed in the node receiving the packet, the packet are then reversed in the node receiving the packet,
restoring the mobile node's home address to be the packet's restoring the mobile node's home address to be the packet's
Source Address before processing by higher protocol layers and Source Address before processing by higher protocol layers and
applications. applications.
- For short-term communication, particularly for communication that - For short-term communication, particularly for communication that
may easily be retried if it fails, the mobile node MAY choose may easily be retried if it fails, the mobile node MAY choose
to directly use one of its care-of addresses as the source of to directly use one of its care-of addresses as the source of
the packet, thus not requiring the use of a Home Address option the packet, thus not requiring the use of a Home Address option
in the packet. An example of this type of communication might in the packet. An example of this type of communication might
be DNS queries sent by the mobile node [12, 13]. Using the be DNS queries sent by the mobile node [15, 16]. Using the
mobile node's care-of address as the source for such queries will mobile node's care-of address as the source for such queries will
generally have a lower overhead than using the mobile node's generally have a lower overhead than using the mobile node's
home address, since no extra options need be used in either the home address, since no extra options need be used in either the
query or its reply, and all packets can be routed normally, query or its reply, and all packets can be routed normally,
directly between their source and destination without relying directly between their source and destination without relying
on Mobile IP. If the mobile node has no particular knowledge on Mobile IP. If the mobile node has no particular knowledge
that the communication being sent fits within this general type that the communication being sent fits within this general type
of communication, however, the mobile node SHOULD NOT use its of communication, however, the mobile node SHOULD NOT use its
care-of address as the source of the packet in this way. care-of address as the source of the packet in this way.
skipping to change at page 68, line 17 skipping to change at page 71, line 17
no special Mobile IP processing is required for sending that packet. no special Mobile IP processing is required for sending that packet.
In each case, the packet is simply addressed and transmitted in the In each case, the packet is simply addressed and transmitted in the
same way as any normal IPv6 packet. same way as any normal IPv6 packet.
For each other packet sent by the mobile node (i.e., packets sent For each other packet sent by the mobile node (i.e., packets sent
while away from home, using the mobile node's home address as while away from home, using the mobile node's home address as
the source, from the point of view of higher protocol layers and the source, from the point of view of higher protocol layers and
applications), special Mobile IP processing of the packet is required applications), special Mobile IP processing of the packet is required
for the insertion of the Home Address option. Specifically: for the insertion of the Home Address option. Specifically:
- Since Mobile IP is transparent to higher protocol layers (e.g., - Construct the packet using the mobile node's home address as the
to TCP), the packet is initially constructed using the mobile packet's Source Address, in the same way as if the mobile node
node's home address as the packet's Source Address, in the same were at home. This preserves the transparency of Mobile IP to
way as if the mobile node were at home. higher protocol layers (e.g., to TCP).
- Insert a Home Address option into the packet, with the Home - Insert a Home Address option into the packet, with the Home
Address field copied from the original value of the Source Address field copied from the original value of the Source
Address field in the packet. Address field in the packet.
- Change the Source Address field in the packet's IPv6 header to - Change the Source Address field in the packet's IPv6 header to
one of the mobile node's care-of addresses. This will typically one of the mobile node's care-of addresses. This will typically
be the mobile node's current primary care-of address, but MUST be the mobile node's current primary care-of address, but MUST
be a care-of address with a subnet prefix that is on-link on the be a care-of address with a subnet prefix that is on-link on the
network interface on which the mobile node will transmit the network interface on which the mobile node will transmit the
packet. packet.
By using the care-of address as the Source Address in the IPv6 By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through any Address option, the packet will be able to safely pass through any
router implementing ingress filtering [6]. router implementing ingress filtering [7].
10.2. Interaction with Outbound IPsec Processing 10.2. Interaction with Outbound IPsec Processing
As a guidance to implementors, this section sketches the interaction As a guidance to implementors, this section sketches the interaction
between outbound Mobile IP processing and outbound IP Security between outbound Mobile IP processing and outbound IP Security
(IPsec) processing for packets sent by a mobile node while away (IPsec) processing for packets sent by a mobile node while away
from home. Any specific implementation MAY use algorithms and data from home. Any specific implementation MAY use algorithms and data
structures other than those suggested here, but its processing structures other than those suggested here, but its processing MUST
MUST be consistent with these steps and with the relevant IPsec be consistent with the effect of the operation described here and
specifications. In the steps described below, it is assumed that with the relevant IPsec specifications. In the steps described
IPsec is being used in transport mode [11] and that the mobile node below, it is assumed that IPsec is being used in transport mode [13]
is using its home address as the source for the packet (from the and that the mobile node is using its home address as the source
point of view of higher protocol layers or applications, as described for the packet (from the point of view of higher protocol layers or
in Section 10.1): applications, as described in Section 10.1):
- The packet is created by higher layer protocols and applications - The packet is created by higher layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IP (e.g., by TCP) as if the mobile node were at home and Mobile IP
were not being used. Mobile IP is transparent to such higher were not being used. Mobile IP is transparent to such higher
layers. layers.
- As part of outbound packet processing in IP, the packet is - As part of outbound packet processing in IP, the packet is
compared against the IPsec Security Policy Database (SPD) to compared against the IPsec Security Policy Database (SPD) to
determine what processing is required for the packet [11]. determine what processing is required for the packet [13].
- As a special case for Mobile IP, if a Binding Update or - As a special case for Mobile IP, if a Binding Update or
Binding Acknowledgement is being included in the packet, IPsec Binding Acknowledgement is being included in the packet, IPsec
authentication and replay protection using AH [9] or ESP [10] authentication and replay protection using AH [11] or ESP [12]
MUST be applied to the packet. If the SPD check above has MUST be applied to the packet. If the SPD check above has
already indicated that authentication and replay protection already indicated that authentication and replay protection
are required, this processing is sufficient for the Mobile IP are required, this processing is sufficient for the Mobile IP
requirement that all packets containing Binding Updates or requirement that all packets containing Binding Updates or
Binding Acknowledgements be authenticated and covered by replay Binding Acknowledgements be authenticated and covered by replay
protection. Otherwise, an implementation can force the required protection. Otherwise, an implementation can force the required
IPsec processing on this individual packet by, for example, IPsec processing on this individual packet by, for example,
creating a temporary SPD entry for handling of this packet. creating a temporary SPD entry for the handling of this packet.
- If IPsec processing is required, the packet is either mapped to - If IPsec processing is required, the packet is either mapped to
an existing Security Association (or SA bundle), or a new SA (or an existing Security Association (or SA bundle), or a new SA (or
SA bundle) is created for the packet, according to the procedures SA bundle) is created for the packet, according to the procedures
defined for IPsec. defined for IPsec.
- Since the mobile node is away from home, the mobile node inserts - Since the mobile node is away from home, the mobile node inserts
a Home Address option into the packet, replacing the Source a Home Address option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in for the link on which the packet is being sent, as described in
Section 10.1. The Home Address option MUST be inserted in a Section 10.1. The Destination Options header in which the Home
Destination Options header that appears in the packet after the Address option is inserted MUST appear in the packet before the
AH or ESP header. AH or ESP header, so that the Home Address option is processed by
the destination node before the AH or ESP header is processed.
- If a Binding Update is being included in the packet, it is also - If a Binding Update is being included in the packet, it is
added to the Destination Options header in the packet. also added to a Destination Options header in the packet. The
Destination Options header in which the Binding Update option is
inserted MAY appear either before or after the AH or ESP header.
If it is inserted before the AH or ESP header, it SHOULD be
placed in the same Destination Options header in which the Home
Address option was inserted.
- Finally, once the packet is fully assembled, the necessary IPsec - Finally, once the packet is fully assembled, the necessary IPsec
authentication (and encryption, if required) processing is authentication (and encryption, if required) processing is
performed on the packet, initializing the Authentication Data in performed on the packet, initializing the Authentication Data in
the AH or ESP header. the AH or ESP header.
In addition, when using any automated key management protocol [13]
(such as IKE [8]) to create any new SA (or SA bundle) while away from
home (whether due to the inclusion of a Binding Update or Binding
Acknowledgement in an outgoing packet, or otherwise), a mobile node
MUST take special care in its processing of the key management
protocol. Otherwise, other nodes with which the mobile node
must communicate as part of the automated key management protocol
processing may be unable to correctly deliver packets to the mobile
node if they and/or the mobile node's home agent do not then have a
current Binding Cache entry for the mobile node. For the default
case of using IKE as the automated key management protocol [8, 13],
such problems can be avoided by the following requirements on the use
of IKE by a mobile node while away from home:
- The mobile node MUST use its care-of address as the Source
Address of all packets it sends as part of the key management
protocol (without use of Mobile IP for these packets, as
suggested in Section 10.1).
- In addition, the mobile node MUST include an ISAKMP
Identification Payload [14] in the IKE exchange, giving the
mobile node's home address as the initiator of the Security
Association [22].
10.3. Receiving Packets While Away from Home 10.3. Receiving Packets While Away from Home
While away from home, a mobile node will receive packets addressed to While away from home, a mobile node will receive packets addressed to
its home address, by one of three methods: its home address, by one of three methods:
- Packets sent by a correspondent node that does not have a - Packets sent by a correspondent node that does not have a
Binding Cache entry for the mobile node, will be sent by the Binding Cache entry for the mobile node, will be sent by the
correspondent node in the same way as any normal IP packet. Such correspondent node in the same way as any normal IP packet. Such
packets will then be intercepted by the mobile node's home agent, packets will then be intercepted by the mobile node's home agent,
encapsulated using IPv6 encapsulation [4], and tunneled to the encapsulated using IPv6 encapsulation [4], and tunneled to the
skipping to change at page 70, line 44 skipping to change at page 74, line 24
sender of the packet, as described in Section 10.8, subject to the sender of the packet, as described in Section 10.8, subject to the
rate limiting defined in Section 10.11. The mobile node SHOULD rate limiting defined in Section 10.11. The mobile node SHOULD
also process the received packet in the manner defined for IPv6 also process the received packet in the manner defined for IPv6
encapsulation [4], which will result in the encapsulated (inner) encapsulation [4], which will result in the encapsulated (inner)
packet being processed normally by upper-layer protocols within the packet being processed normally by upper-layer protocols within the
mobile node, as if it had been addressed (only) to the mobile node's mobile node, as if it had been addressed (only) to the mobile node's
home address. home address.
For packets received by the second method above (using a Routing For packets received by the second method above (using a Routing
header), the mobile node SHOULD process the received packet in the header), the mobile node SHOULD process the received packet in the
manner defined for the type of IPv6 Routing header used [5], which manner defined for the type of IPv6 Routing header used [6], which
will result in the packet being processed normally by upper-layer will result in the packet being processed normally by upper-layer
protocols within the mobile node, as if it had been addressed (only) protocols within the mobile node, as if it had been addressed (only)
to the mobile node's home address. to the mobile node's home address.
In addition, the general procedures defined by IPv6 for Routing In addition, the general procedures defined by IPv6 for Routing
headers suggest that a received Routing header MAY be automatically headers suggest that a received Routing header MAY be automatically
"reversed" to construct a Routing header for use in any response "reversed" to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the received packet is packets sent by upper-layer protocols, if the received packet is
authenticated [5]. If this is done for upper-layer protocol response authenticated [6]. If this is done for upper-layer protocol response
packets sent by a mobile node while away from home, the mobile packets sent by a mobile node while away from home, the mobile
node SHOULD NOT include its own care-of address, which appears in node SHOULD NOT include its own care-of address, which appears in
the Routing header of the received packet, in the reversed route the Routing header of the received packet, in the reversed route
for the response packet. If the received Routing header contained for the response packet. If the received Routing header contained
no additional hops (other than the mobile node's home address and no additional hops (other than the mobile node's home address and
care-of address), then any upper-layer protocol response packet care-of address), then any upper-layer protocol response packet
SHOULD NOT include a Routing header. SHOULD NOT include a Routing header.
10.4. Movement Detection 10.4. Movement Detection
A mobile node MAY use any combination of mechanisms available to it A mobile node MAY use any combination of mechanisms available to it
to detect when it has moved from one link to another. The primary to detect when it has moved from one link to another. The primary
movement detection mechanism for Mobile IPv6 defined here uses the movement detection mechanism for Mobile IPv6 defined here uses the
facilities of IPv6 Neighbor Discovery, including Router Discovery and facilities of IPv6 Neighbor Discovery, including Router Discovery and
Neighbor Unreachability Detection. The description here is based on Neighbor Unreachability Detection. The description here is based on
the conceptual model of the organization and data structures defined the conceptual model of the organization and data structures defined
by Neighbor Discovery [14]. by Neighbor Discovery [17].
Mobile nodes SHOULD use Router Discovery to discover new routers and Mobile nodes SHOULD use Router Discovery to discover new routers and
on-link subnet prefixes; a mobile node MAY send Router Solicitation on-link subnet prefixes; a mobile node MAY send Router Solicitation
messages, or MAY wait for unsolicited (periodic) multicast Router messages, or MAY wait for unsolicited (periodic) multicast Router
Advertisement messages, as specified for Router Discovery [14]. Advertisement messages, as specified for Router Discovery [17].
Based on received Router Advertisement messages, a mobile node (in Based on received Router Advertisement messages, a mobile node (in
the same way as any other node) maintains an entry in its Default the same way as any other node) maintains an entry in its Default
Router List for each router, and an entry in its Prefix List for each Router List for each router, and an entry in its Prefix List for each
subnet prefix, that it currently considers to be on-link. Each entry subnet prefix, that it currently considers to be on-link. Each entry
in these lists has an associated invalidation timer value (extracted in these lists has an associated invalidation timer value (extracted
from the Router Advertisement) used to expire the entry when it from the Router Advertisement) used to expire the entry when it
becomes invalid. becomes invalid.
While away from home, a mobile node SHOULD select one router from While away from home, a mobile node SHOULD select one router from
its Default Router List to use as its default router, and one subnet its Default Router List to use as its default router, and one subnet
skipping to change at page 72, line 9 skipping to change at page 75, line 41
switch to a new default router and to a new primary care-of address. switch to a new default router and to a new primary care-of address.
Since some links (notably wireless) do not necessarily work equally Since some links (notably wireless) do not necessarily work equally
well in both directions, it is likewise important for the mobile well in both directions, it is likewise important for the mobile
node to detect when it becomes unreachable to packets sent from its node to detect when it becomes unreachable to packets sent from its
default router, so that the mobile node can take steps to ensure that default router, so that the mobile node can take steps to ensure that
any correspondent nodes attempting to communicate with it can still any correspondent nodes attempting to communicate with it can still
reach it through some other route. reach it through some other route.
To detect when its default router becomes unreachable, a mobile To detect when its default router becomes unreachable, a mobile
node SHOULD use Neighbor Unreachability Detection. As specified in node SHOULD use Neighbor Unreachability Detection. As specified in
Neighbor Discovery [14], while the mobile node is actively sending Neighbor Discovery [17], while the mobile node is actively sending
packets to (or through) its default router, the mobile node can packets to (or through) its default router, the mobile node can
detect that the router (as its neighbor) is still reachable either detect that the router (as its neighbor) is still reachable either
through indications from upper layer protocols on the mobile node through indications from upper layer protocols on the mobile node
that a connection is making "forward progress" (e.g., receipt of TCP that a connection is making "forward progress" (e.g., receipt of TCP
acknowledgements for new data transmitted), or through receipt of a acknowledgements for new data transmitted), or through receipt of a
Neighbor Advertisement message from its default router in response Neighbor Advertisement message from its default router in response
to an explicit Neighbor Solicitation messages to it. Note that to an explicit Neighbor Solicitation messages to it. Note that
although this mechanism detects that the mobile node's default router although this mechanism detects that the mobile node's default router
has become unreachable to the mobile node only while the mobile node has become unreachable to the mobile node only while the mobile node
is actively sending packets to it, this is the only time that this is actively sending packets to it, this is the only time that this
skipping to change at page 74, line 31 skipping to change at page 78, line 13
node MAY form a new (non-primary) care-of address using that subnet node MAY form a new (non-primary) care-of address using that subnet
prefix, even when it has not switched to a new default router. A prefix, even when it has not switched to a new default router. A
mobile node can have only one primary care-of address at a time mobile node can have only one primary care-of address at a time
(which is registered with its home agent), but it MAY have an (which is registered with its home agent), but it MAY have an
additional care-of address for any or all of the prefixes on its additional care-of address for any or all of the prefixes on its
current link. Furthermore, since a wireless network interface may current link. Furthermore, since a wireless network interface may
actually allow a mobile node to be reachable on more than one link at actually allow a mobile node to be reachable on more than one link at
a time (i.e., within wireless transmitter range of routers on more a time (i.e., within wireless transmitter range of routers on more
than one separate link), a mobile node MAY have care-of addresses than one separate link), a mobile node MAY have care-of addresses
on more than one link at a time. The use of more than one care-of on more than one link at a time. The use of more than one care-of
address at a time is described in Section 10.16. address at a time is described in Section 10.17.
As described in Section 4, in order to form a new care-of address, As described in Section 4, in order to form a new care-of address,
a mobile node MAY use either stateless [23] or stateful (e.g., a mobile node MAY use either stateless [27] or stateful (e.g.,
DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to DHCPv6 [2]) Address Autoconfiguration. If a mobile node needs to
send packets as part of the method of address autoconfiguration, send packets as part of the method of address autoconfiguration,
it MUST use an IPv6 link-local address rather than its own IPv6 it MUST use an IPv6 link-local address rather than its own IPv6
home address as the Source Address in the IPv6 header of each such home address as the Source Address in the IPv6 header of each such
autoconfiguration packet. autoconfiguration packet.
In some cases, a mobile node may already know a (constant) IPv6 In some cases, a mobile node may already know a (constant) IPv6
address that has been assigned to it for its use only while address that has been assigned to it for its use only while
visiting a specific foreign link. For example, a mobile node may be visiting a specific foreign link. For example, a mobile node may be
statically configured with an IPv6 address assigned by the system statically configured with an IPv6 address assigned by the system
skipping to change at page 75, line 54 skipping to change at page 79, line 34
home address (the remaining low-order bits after the indicated subnet home address (the remaining low-order bits after the indicated subnet
prefix), together with each on-link subnet prefix on the home link. prefix), together with each on-link subnet prefix on the home link.
Until the lifetime of this registration expires, the home agent Until the lifetime of this registration expires, the home agent
considers itself the home agent for each such home address of the considers itself the home agent for each such home address of the
mobile node. As the set of on-link subnet prefixes on the home link mobile node. As the set of on-link subnet prefixes on the home link
changes over time, the home agent changes the set of home addresses changes over time, the home agent changes the set of home addresses
for this mobile node for which it is serving as the home agent. for this mobile node for which it is serving as the home agent.
If the mobile node has additional home addresses using a different If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register packet containing a Binding Update to its home agent to register the
the care-of address for each such other home address (or set of care-of address for each such other home address (or set of home
home addresses sharing an interface identifier). These additional addresses sharing an interface identifier). These additional Binding
Binding Updates MUST each be sent as a separate packet, since each Updates MUST each be sent as a separate packet, since each MUST
MUST contain an AH [9] or ESP [10] header to authenticate the Binding contain an AH [11] or ESP [12] header to authenticate the Binding
Update as coming from the home address being bound. Update as coming from the home address being bound.
10.7. Dynamic Home Agent Address Discovery 10.7. Dynamic Home Agent Address Discovery
It is possible that when the mobile node needs to send a Binding It is possible that when the mobile node needs to send a Binding
Update to its home agent to register its new primary care-of address, Update to its home agent to register its new primary care-of address,
as described in Section 10.6, the mobile node may not know the as described in Section 10.6, the mobile node may not know the
address of any router on its home link that can serve as a home agent address of any router on its home link that can serve as a home agent
for it. For example, some nodes on its home link may have been for it. For example, some nodes on its home link may have been
reconfigured while the mobile node has been away from home, such that reconfigured while the mobile node has been away from home, such that
the router that was operating as the mobile node's home agent has the router that was operating as the mobile node's home agent has
been replaced by a different router serving this role. been replaced by a different router serving this role.
In this case, the mobile node SHOULD use the dynamic home agent In this case, the mobile node MAY use the dynamic home agent address
address discovery procedure to find the address of a suitable home discovery mechanism to find the address of a suitable home agent on
agent on its home link. To do so, the mobile node sends the packet, its home link. To do so, the mobile node sends an ICMP Home Agent
as described above, with the Destination Address in the packet's Address Discovery Request message to the "Mobile IPv6 Home-Agents"
IPv6 header set to the "Mobile IPv6 Home-Agents" anycast address [8] anycast address [10] for its home subnet prefix. This packet MUST
for its home subnet prefix. As described in Section 9.2, the also include a Home Address option giving the mobile node's home
home agent on its home link that receives this Binding Update will address. As described in Section 9.2, the home agent on its home
reject the Update, returning to the mobile node the home agent's own link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message, giving this home agent's own
global unicast IP address along with a list of the global unicast IP global unicast IP address along with a list of the global unicast IP
addresses of each other home agent operating on the home link. The address of each other home agent operating on the home link.
mobile node SHOULD then retransmit its Binding Update to one of these
homes agent using the provided global unicast address; the mobile The mobile node, upon receiving this Home Agent Address Discovery
node MAY re-attempt this home registration with each of these home Reply message, MAY then send its home registration Binding Update to
agents in turn, by sending each a Binding Update and waiting for the the home agent address given as the IP Source Address of the packet
matching Binding Acknowledgement, until its registration is accepted carrying the Reply message or to any of the unicast IP addresses
by one of these home agents. listed in the Home Agent Addresses field in the Reply. For example,
if necessary, the mobile node MAY attempt its home registration
with each of these home agents, in turn, by sending each a Binding
Update and waiting for the matching Binding Acknowledgement, until
its registration is accepted by one 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 Home Agent Addresses field in the
received Home Agent Address Discovery Reply message. If the home
agent identified by the Source Address field in the IP header of the
packet carrying the Home Agent Address Discovery Reply message is
not listed in the Home Agent Addresses field in the Reply, it SHOULD
be tried before the first address given in the list; otherwise, it
SHOULD be tried in its listed order.
If the mobile node has a current registration with some home agent If the mobile node has a current registration with some home agent
on its home link (the Lifetime for that registration has not yet on its home link (the Lifetime for that registration has not yet
expired), then the mobile node MUST attempt any new registration expired), then the mobile node MUST attempt any new registration
first with that home agent. If that registration attempt fails first with that home agent. If that registration attempt fails
(e.g., times out or is rejected), the mobile node SHOULD then (e.g., times out or is rejected), the mobile node SHOULD then
reattempt this registration with another home agent on its home link. reattempt this registration with another home agent on its home link.
If the mobile node knows of no other suitable home agent, then it MAY If the mobile node knows of no other suitable home agent, then it MAY
attempt the dynamic home agent address discovery procedure described attempt the dynamic home agent address discovery mechanism described
above. above.
10.8. Sending Binding Updates to Correspondent Nodes 10.8. Sending Binding Updates to Correspondent Nodes
A mobile node MAY send a Binding Update to any correspondent node at A mobile node MAY send a Binding Update to any correspondent node at
any time to allow the correspondent node to cache the mobile node's any time to allow the correspondent node to cache the mobile node's
current care-of address (subject to the rate limiting defined in current care-of address (subject to the rate limiting defined in
Section 10.11). In any Binding Update sent by a mobile node, the Section 10.11). In any Binding Update sent by a mobile node, the
care-of address (either the Source Address in the packet's IPv6 care-of address (either the Source Address in the packet's IPv6
header or the Care-of Address field in the Binding Update) MUST be header or the Care-of Address field in the Binding Update) MUST be
skipping to change at page 80, line 19 skipping to change at page 84, line 11
Note that this home agent does not necessarily know (and need not Note that this home agent does not necessarily know (and need not
know) the mobile node's (permanent) home address as part of this know) the mobile node's (permanent) home address as part of this
registration. registration.
The packet carrying the Binding Update MUST be addressed to The packet carrying the Binding Update MUST be addressed to
this home agent's global unicast address. Normally, this global this home agent's global unicast address. Normally, this global
unicast address is learned by the mobile node based on the Router unicast address is learned by the mobile node based on the Router
Advertisements received by the mobile node (Section 6.2) while Advertisements received by the mobile node (Section 6.2) while
attached to the link on which this previous care-of address and this attached to the link on which this previous care-of address and this
home agent are located; the mobile node obtains this home agent home agent are located; the mobile node obtains this home agent
address from its Home Agents List (Section 4.3) before clearing the address from its Home Agents List (Section 4.3). Alternatively,
list upon connecting to the new link. Alternatively, the mobile the mobile node MAY use dynamic home agent address discovery
node MAY use dynamic home agent address discovery (Section 10.7) to (Section 10.7) to discover the global unicast address of a home agent
discover the global unicast address of a home agent on this previous on this previous link, but it SHOULD use an address from its Home
link, but it SHOULD use the address from its Home Agents List if Agents List if available for the prefix it used in this previous
available. care-of address.
As with any packet containing a Binding Update 5.1, the Binding
Update packet to this home agent MUST include either an AH [11] or
ESP [12] header providing sender authentication, data integrity
protection, and replay protection.
10.10. Retransmitting Binding Updates 10.10. Retransmitting Binding Updates
If, after sending a Binding Update in which the Acknowledge (A) bit If, after sending a Binding Update in which the Acknowledge (A)
is set, a mobile node fails to receive a Binding Acknowledgement bit is set, a mobile node fails to receive a valid, matching
within INITIAL_BINDACK_TIMEOUT seconds, the mobile node SHOULD Binding Acknowledgement within INITIAL_BINDACK_TIMEOUT seconds, the
retransmit the Binding Update until a Binding Acknowledgement mobile node SHOULD retransmit the Binding Update, until a Binding
is received. Such a retransmitted Binding Update MUST use the Acknowledgement is received. Such a retransmitted Binding Update
same Sequence Number value as the original transmission. The MUST use a Sequence Number value greater than that used for the
retransmissions by the mobile node MUST use an exponential previous transmission of this Binding Update. The retransmissions by
back-off process, in which the timeout period is doubled the mobile node MUST use an exponential back-off process, in which
upon each retransmission until either the node receives a the timeout period is doubled upon each retransmission until either
Binding Acknowledgement or the timeout period reaches the value the node receives a Binding Acknowledgement or the timeout period
MAX_BINDACK_TIMEOUT. reaches the value MAX_BINDACK_TIMEOUT.
10.11. Rate Limiting for Sending Binding Updates 10.11. Rate Limiting for Sending Binding Updates
A mobile node MUST NOT send Binding Updates about the same binding A mobile node MUST NOT send Binding Updates about the same binding to
to any node more often than once per MAX_UPDATE_RATE seconds. After any individual node more often than once per MAX_UPDATE_RATE seconds.
sending MAX_FAST_UPDATES consecutive Binding Updates to a particular After sending MAX_FAST_UPDATES consecutive Binding Updates to a
node with the same care-of address, the mobile node SHOULD reduce particular node with the same care-of address, the mobile node SHOULD
its rate of sending Binding Updates to that node, to the rate of reduce its rate of sending Binding Updates to that node, to the rate
SLOW_UPDATE_RATE per second. The mobile node MAY continue to send of SLOW_UPDATE_RATE per second. The mobile node MAY continue to send
Binding Updates at this slower rate indefinitely, in hopes that the Binding Updates at this slower rate indefinitely, in hopes that the
node will eventually be able to process a Binding Update and begin node will eventually be able to process a Binding Update and begin
to route its packets directly to the mobile node at its new care-of to route its packets directly to the mobile node at its new care-of
address. address.
10.12. Receiving Binding Acknowledgements 10.12. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests: node MUST validate the packet according to the following tests:
- The packet contains a valid AH [9] or ESP [10] header providing - The packet contains a valid AH [11] or ESP [12] header providing
sender authentication, data integrity protection, and replay sender authentication, data integrity protection, and replay
protection. protection.
- The Option Length field in the option is greater than or equal to - The Option Length field in the option is greater than or equal to
11 octets. 11 octets.
- The Sequence Number field matches the Sequence Number sent by the - The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding mobile node to this destination address in an outstanding Binding
Update. Update.
skipping to change at page 81, line 43 skipping to change at page 85, line 43
List to indicate that the Binding Update has been acknowledged. List to indicate that the Binding Update has been acknowledged.
The mobile node MUST then stop retransmitting the Binding Update. The mobile node MUST then stop retransmitting the Binding Update.
- If the Status field indicates that the Binding Update was - If the Status field indicates that the Binding Update was
rejected (the Status field is greater than or equal to 128), then rejected (the Status field is greater than or equal to 128), then
the mobile node MUST delete the corresponding Binding Update List the mobile node MUST delete the corresponding Binding Update List
entry (and MUST also stop retransmitting the Binding Update). entry (and MUST also stop retransmitting the Binding Update).
Optionally, the mobile node MAY then take steps to correct the Optionally, the mobile node MAY then take steps to correct the
cause of the error and retransmit the Binding Update (with a new cause of the error and retransmit the Binding Update (with a new
Sequence Number value), subject to the rate limiting restriction Sequence Number value), subject to the rate limiting restriction
specified in Section 10.11. In particular, if the Status field specified in Section 10.11.
is equal to 135 (dynamic home agent address discovery response),
then the mobile node MAY reattempt its home registration with
the home agent address given in the Source Address field of the
packet carrying the Binding Acknowledgement or with any of the
home agent IP addresses listed in the Home Agents List Sub-Option
in the Binding Acknowledgement. If any of these addresses is not
a global unicast address or does not have a subnet prefix equal
to the mobile node's own subnet prefix, then that particular
address MUST be ignored and the mobile node MUST NOT reattempt
its home registration with that home agent.
10.13. Receiving Binding Requests 10.13. 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 83, line 8 skipping to change at page 86, line 48
this option that does not recognize the Option Type SHOULD return this option that does not recognize the Option Type SHOULD return
an ICMP Parameter Problem, Code 2, message to the sender of the an ICMP Parameter Problem, Code 2, message to the sender of the
packet containing the Home Address option. If a mobile node receives packet containing the Home Address option. If a mobile node receives
such an ICMP error message from some node indicating that it does such an ICMP error message from some node indicating that it does
not recognize the mobile node's Home Address option, the mobile not recognize the mobile node's Home Address option, the mobile
node SHOULD log the error and then discard the ICMP message; this node SHOULD log the error and then discard the ICMP message; this
error message indicates that the node to which the original packet error message indicates that the node to which the original packet
was addressed (the node returning the ICMP error message) does not was addressed (the node returning the ICMP error message) does not
correctly implement this required part of the IPv6 protocol. correctly implement this required part of the IPv6 protocol.
10.15. Receiving Tunneled Router Advertisements 10.15. Receiving Local Router Advertisement Messages
Each mobile node maintains a Home Agents List recording information
about all home agents from which it receives a Router Advertisement,
for which the home agent lifetime indicated in that Router
Advertisement has not yet expired. This list is used by the mobile
node to enable it to send a Binding Update to the global unicast
address of a home agent on its previous link when it moves to a new
link, as described in Section 10.9. On receipt of a valid Router
Advertisement, as defined in the processing algorithm specified for
Neighbor Discovery [17], the mobile node performs the following
steps, in addition to any steps already required of it by Neighbor
Discovery and by other procedures described in this document:
- If the Home Agent (H) bit in the Router Advertisement is not
set, skip all of the following steps. There are no special
processing steps required by this aspect of Mobile IP for this
Router Advertisement, since the Advertisement was not sent by a
home agent.
- Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [17].
- Determine from the Router Advertisement the preference for this
home agent. If the Router Advertisement contains a Home Agent
Information Option, then the preference is taken from the Home
Agent Preference field in the option; otherwise, the default
preference of 0 SHOULD be used.
- Determine from the Router Advertisement the lifetime for
this home agent. If the Router Advertisement contains a Home
Agent Information Option, then the lifetime is taken from
the Home Agent Lifetime field in the option; otherwise, the
lifetime specified by the Router Lifetime field in the Router
Advertisement SHOULD be used.
- If the link-local address of the home agent sending this
Advertisement is already present in this mobile node's Home
Agents List and the received home agent lifetime value is zero,
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 mobile
node'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 mobile node, and
the lifetime for the sending home agent, as determined above,
is non-zero, create a new entry in the list, and initialize its
lifetime and preference to the values determined above.
- If the Home Agents List entry for the link-local address of
the home agent sending this Advertisement was not deleted as
described above, determine any global address(es) of the home
agent based on each Prefix Information option received in
this Advertisement in which the Router Address (R) bit is set
(Section 6.2). For each such global address determined from this
Advertisement, add this global address to the list of global
addresses for this home agent in this Home Agents List entry.
A mobile node SHOULD maintain an entry in its Home Agents List for
each such valid home agent address until that entry's lifetime
expires, after which time the entry MUST be deleted.
10.16. Receiving Tunneled Router Advertisements
Section 9.7 describes the operation of a home agent to support Section 9.7 describes the operation of a home agent to support
renumbering a mobile node's home subnet while the mobile node is renumbering a mobile node's home subnet while the mobile node is
away from home. The home agent tunnels certain Router Advertisement away from home. The home agent tunnels certain Router Advertisement
messages to the mobile node while away from home, giving "important" messages to the mobile node while away from home, giving "important"
Prefix Information options that describe changes in the prefixes in Prefix Information options that describe changes in the prefixes in
use on the mobile node's home link. use on the mobile node's home link.
When a mobile node receives a tunneled Router Advertisement, it MUST When a mobile node receives a tunneled Router Advertisement, it MUST
validate it according to the following tests: validate it according to the following tests:
- The Source Address of the IP packet carrying the Router - The Source Address of the IP packet carrying the Router
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 [9] or ESP [10] header providing - The packet contains either an AH [11] or ESP [12] header
sender authentication, data integrity protection, and replay providing sender authentication, data integrity protection, and
protection. replay 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 - The Binding Request option contains a Unique Identifier
Sub-Option. 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 [14]. Router Advertisement as if it were connected to its home link [17].
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.
In addition, in processing the packet containing this Router In processing the packet containing this Router Advertisement, the
Advertisement, the mobile node SHOULD return to the home agent a mobile node SHOULD return to the home agent a Binding Update in
Binding Update in response to the Binding Request carried in the response to the Binding Request carried in the packet. The correct
packet. The correct formation of this Binding Update by the mobile formation of this Binding Update by the mobile node and processing
node and processing of it by the home agent will be viewed by the of it by the home agent will be viewed by the home agent as an
home agent as an acknowledgement of this Router Advertisement, acknowledgement of this Router Advertisement, confirming to it that
confirming to it that this Router Advertisement was received by the this Router Advertisement was received by the mobile node.
mobile node.
10.16. Using Multiple Care-of Addresses In addition, if processing of this Router Advertisement resulted in
the mobile node configuring a new home address, and if the method
used for this new home address configuration would require the mobile
node to perform Duplicate Address Detection [27] for the new address
if the mobile node were located at home, then the mobile node MUST
set the Duplicate Address Detection (D) bit in this Binding Update to
its home agent, to request the home agent to perform this Duplicate
Address Detection on behalf of the mobile node.
10.17. Using Multiple Care-of Addresses
As described in Section 10.5, a mobile node MAY use more than one As described in Section 10.5, a mobile node MAY use more than one
care-of address at a time. Particularly in the case of many wireless care-of address at a time. Particularly in the case of many wireless
networks, a mobile node effectively might be reachable through networks, a mobile node effectively might be reachable through
multiple links at the same time (e.g., with overlapping wireless multiple links at the same time (e.g., with overlapping wireless
cells), on which different on-link subnet prefixes may exist. A cells), on which different on-link subnet prefixes may exist. A
mobile node SHOULD select a primary care-of address from among those mobile node SHOULD select a primary care-of address from among those
care-of addresses it has formed using any of these subnet prefixes, care-of addresses it has formed using any of these subnet prefixes,
based on the movement detection mechanism in use, as described in based on the movement detection mechanism in use, as described in
Section 10.4. When the mobile node selects a new primary care-of Section 10.4. When the mobile node selects a new primary care-of
skipping to change at page 84, line 31 skipping to change at page 89, line 48
its previous primary care-of address as a (non-primary) care-of its previous primary care-of address as a (non-primary) care-of
address, and SHOULD still accept packets at this address, even after address, and SHOULD still accept packets at this address, even after
registering its new primary care-of address with its home agent. registering its new primary care-of address with its home agent.
This is reasonable, since the mobile node could only receive packets This is reasonable, since the mobile node could only receive packets
at its previous primary care-of address if it were indeed still at its previous primary care-of address if it were indeed still
connected to that link. If the previous primary care-of address was connected to that link. If the previous primary care-of address was
allocated using stateful Address Autoconfiguration [2], the mobile allocated using stateful Address Autoconfiguration [2], the mobile
node may not wish to release the address immediately upon switching node may not wish to release the address immediately upon switching
to a new primary care-of address. to a new primary care-of address.
10.17. Routing Multicast Packets 10.18. Routing Multicast Packets
A mobile node that is connected to its home link functions in the A mobile node that is connected to its home link functions in the
same way as any other (stationary) node. Thus, when it is at home, same way as any other (stationary) node. Thus, when it is at home,
a mobile node functions identically to other multicast senders and a mobile node functions identically to other multicast senders and
receivers. This section therefore describes the behavior of a mobile receivers. This section therefore describes the behavior of a mobile
node that is not on its home link. node that is not on its home link.
In order to receive packets sent to some multicast group, a mobile In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method by which a mobile node must join that multicast group. One method by which a mobile
node MAY join the group is via a (local) multicast router on the node MAY join the group is via a (local) multicast router on the
skipping to change at page 85, line 13 skipping to change at page 90, line 29
node. node.
A mobile node that wishes to send packets to a multicast group A mobile node that wishes to send packets to a multicast group
also has two options: (1) send directly on the foreign link being also has two options: (1) send directly on the foreign link being
visited; or (2) send via a tunnel to its home agent. Because visited; or (2) send via a tunnel to its home agent. Because
multicast routing in general depends upon the Source Address used in multicast routing in general depends upon the Source Address used in
the IPv6 header of the multicast packet, a mobile node that tunnels a the IPv6 header of the multicast packet, a mobile node that tunnels a
multicast packet to its home agent MUST use its home address as the multicast packet to its home agent MUST use its home address as the
IPv6 Source Address of the inner multicast packet. IPv6 Source Address of the inner multicast packet.
10.18. Returning Home 10.19. Returning Home
A mobile node detects that it has returned to its home link through A mobile node detects that it has returned to its home link through
the movement detection algorithm in use (Section 10.4), when the the movement detection algorithm in use (Section 10.4), when the
mobile node detects that its home subnet prefix is again on-link. mobile node detects that its home subnet prefix is again on-link.
The mobile node SHOULD then send a Binding Update to its home agent, The mobile node SHOULD then send a Binding Update to its home agent,
to instruct its home agent to no longer intercept or tunnel packets to instruct its home agent to no longer intercept or tunnel packets
for it. In this Binding Update, the mobile node MUST set the care-of for it. In this Binding Update, the mobile node MUST set the care-of
address for the binding (the Source Address field in the packet's address for the binding (the Source Address field in the packet's
IPv6 header) to the mobile node's own home address. As with other IPv6 header) to the mobile node's own home address. As with other
Binding Updates sent to register with its home agent, the mobile Binding Updates sent to register with its home agent, the mobile
node MUST set the Acknowledge (A) and Home Registration (H) bits, node MUST set the Acknowledge (A) and Home Registration (H) bits,
and SHOULD retransmit the Binding Update until a matching Binding and SHOULD retransmit the Binding Update until a matching Binding
Acknowledgement is received. Acknowledgement is received.
In addition, the mobile node MUST multicast onto the home link In addition, the mobile node MUST multicast onto the home link
(to the all-nodes multicast address) a Neighbor Advertisement (to the all-nodes multicast address) a Neighbor Advertisement
message [14], to advertise the mobile node's own link-layer address message [17], to advertise the mobile node's own link-layer address
for its own home address. The Target Address in this Neighbor for its own home address. The Target Address in this Neighbor
Advertisement message MUST be set to the mobile node's home address, Advertisement message MUST be set to the mobile node's home address,
and the Advertisement MUST include a Target Link-layer Address option and the Advertisement MUST include a Target Link-layer Address option
specifying the mobile node's link-layer address. The mobile node specifying the mobile node's link-layer address. The mobile node
MUST multicast such a Neighbor Advertisement message for each of its MUST multicast such a Neighbor Advertisement message for each of its
home addresses, as defined by the current on-link prefixes, including home addresses, as defined by the current on-link prefixes, including
its link-local address and site-local address. The Solicited its link-local address and site-local address. The Solicited
Flag (S) in these Advertisements MUST NOT be set, since they were Flag (S) in these Advertisements MUST NOT be set, since they were
not solicited by any Neighbor Solicitation message. The Override not solicited by any Neighbor Solicitation message. The Override
Flag (O) in these Advertisements MUST be set, indicating that the Flag (O) in these Advertisements MUST be set, indicating that the
Advertisements SHOULD override any existing Neighbor Cache entries at Advertisements SHOULD override any existing Neighbor Cache entries at
any node receiving them. any node receiving them.
Since multicasts on the local link (such as Ethernet) are typically Since multicasts on the local link (such as Ethernet) are typically
not guaranteed to be reliable, the mobile node MAY retransmit these not guaranteed to be reliable, the mobile node MAY retransmit these
Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to Neighbor Advertisement messages up to MAX_ADVERT_REXMIT times to
increase their reliability. It is still possible that some nodes on increase their reliability. It is still possible that some nodes on
the home link will not receive any of these Neighbor Advertisements, the home link will not receive any of these Neighbor Advertisements,
but these nodes will eventually be able to recover through use of but these nodes will eventually be able to recover through use of
Neighbor Unreachability Detection [14]. Neighbor Unreachability Detection [17].
11. Constants 11. Protocol Constants
INITIAL_BINDACK_TIMEOUT 1 second INITIAL_BINDACK_TIMEOUT 1 second
MAX_BINDACK_TIMEOUT 256 seconds MAX_BINDACK_TIMEOUT 256 seconds
MAX_UPDATE_RATE once per second MAX_UPDATE_RATE once per second
SLOW_UPDATE_RATE once per 10 seconds SLOW_UPDATE_RATE once per 10 seconds
MAX_FAST_UPDATES 5 transmissions MAX_FAST_UPDATES 5 transmissions
MAX_ADVERT_REXMIT 3 transmissions MAX_ADVERT_REXMIT 3 transmissions
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; and
- 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 [14] In addition, this document defines two ICMP message types, used as
options, which must be assigned Option Type values within the option part of the dynamic home agent address discovery mechanism:
numbering space for Neighbor Discovery messages:
- The Advertisement Interval option, described in Section 6.3. - The Home Agent Address Discovery Request message, described in
Section 5.6; and
- The Home Agent Address Discovery Reply message, described in
Section 5.7.
This document also defines two new Neighbor Discovery [17] options,
which must be assigned Option Type values within the option numbering
space for Neighbor Discovery messages:
- The Advertisement Interval option, described in Section 6.3; and
- The Home Agent Information option, described in Section 6.4. - The Home Agent Information option, described in Section 6.4.
Finally, this document defines a new type of anycast address, which Finally, this document defines a new type of anycast address, which
must be assigned a reserved value for use with any subnet prefix to must be assigned a reserved value for use with any subnet prefix to
define this anycast address on each subnet: define this anycast address on each subnet:
- The "Mobile IPv6 Home-Agents" anycast address [8], used in the - The "Mobile IPv6 Home-Agents" anycast address [10], used in the
dynamic home agent address discovery procedure described in dynamic home agent address discovery mechanism described in
Sections 9.2 and 10.7. Sections 9.2 and 10.7.
13. Security Considerations 13. Security Considerations
13.1. Binding Updates, Acknowledgements, and Requests 13.1. Binding Updates, Acknowledgements, and Requests
The Binding Update option described in this document will result The Binding Update option described in this document will result
in packets addressed to a mobile node being delivered instead to in packets addressed to a mobile node being delivered instead to
its care-of address. This ability to change the routing of these its care-of address. This ability to change the routing of these
packets could be a significant vulnerability if any packet containing packets could be a significant vulnerability if any packet containing
skipping to change at page 89, line 11 skipping to change at page 95, line 11
in the IPv6 header, the security of the Source Address field in the in the IPv6 header, the security of the Source Address field in the
IPv6 header is not compromised by the presence of a Home Address IPv6 header is not compromised by the presence of a Home Address
option. Without authentication of the packet, then any field in the option. Without authentication of the packet, then any field in the
IPv6 header, including the Source Address field, and any other parts IPv6 header, including the Source Address field, and any other parts
of the packet, including the Home Address option, can be forged or of the packet, including the Home Address option, can be forged or
modified in transit. In this case, the contents of the Home Address modified in transit. In this case, the contents of the Home Address
option is no more suspect than any other part of the packet. option is no more suspect than any other part of the packet.
The use of the Home Address option allows packets sent by a The use of the Home Address option allows packets sent by a
mobile node to pass normally through routers implementing ingress mobile node to pass normally through routers implementing ingress
filtering [6]. Since the care-of address used in the Source Address filtering [7]. Since the care-of address used in the Source Address
field of the packet's IPv6 header is topologically correct for the field of the packet's IPv6 header is topologically correct for the
sending location of the mobile node, ingress filtering can trace the sending location of the mobile node, ingress filtering can trace the
location of the mobile node in the same way as can be done with any location of the mobile node in the same way as can be done with any
sender when ingress filtering is in use. sender when ingress filtering is in use.
However, if a node receiving a packet that includes a Home Address However, if a node receiving a packet that includes a Home Address
option implements the processing of this option by physically option implements the processing of this option by physically
copying the Home Address field from the option into the IPv6 header, copying the Home Address field from the option into the IPv6 header,
replacing the Source Address field there, then the ability to replacing the Source Address field there, then the ability to
trace the true location of the sender is removed once this step trace the true location of the sender is removed once this step
skipping to change at page 91, line 9 skipping to change at page 97, 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 Version of the Draft Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this This appendix briefly lists some of the major changes in this
draft relative to the previous version of this same draft, draft relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-08.txt: draft-ietf-mobileip-ipv6-09.txt:
- Added a new section (Section 10.2), giving guidance to - Added additional material in Section 10.2, discussing use any
implementors on the interaction between outbound Mobile IP automated key management protocol [13] (such as IKE [8]) to
processing and outbound IPsec processing for packets sent by a create any new SA (or SA bundle) while away from home.
mobile node while away from home.
- Changed the optional Care-of Address field in the Binding Update - Also added additional material in Section 10.2 to define the
option format (Section 5.1) to instead be a sub-option. This order in which the Home Address option and Binding Update option
better matches the use of other sub-options to encode optional appear in the packet relative to the AH or ESP header that is
information in an option, and also makes the specification of the required when a Binding Update is inserted. In addition, this
alignment requirement for the Binding Update option easier. change corrects the placement of the Home Address option in the
packet to be before (not after) the AH or ESP header, so that the
Home Address option is processed by the destination node before
the AH or ESP header is processed.
- Also removed the Care-of Address Present (C) bit in the Binding - Changed the dynamic home agent address discovery mechanism
Update option format, as it is no longer needed with the use of a to use dedicated ICMP message types (defined in Sections 5.6
sub-option to specify the alternate care-of address. NOTE: This and 5.7) rather than (re)using the Binding Update and Binding
change also resulted in moving the Router (R) bit over by one bit Acknowledgement options. This change was primarily motivated
position in the Binding Update option format. by the fact that IP packets sent to an anycast address cannot
(currently) use AH or ESP authentication since the packet is not
directed to any single node with which a Security Association
could be established. In addition, this change simplifies the
processing of Binding Updates and Binding Acknowledgements, since
it removes the special cases there for dynamic home agent address
discovery.
- Added explicit specification of the alignment requirements [5] - Removed the Binding Acknowledgement option Status value of 135
for each of the Mobile IPv6 destination options and sub-options. (dynamic home agent address discovery response) since it is
no longer needed with the revised dynamic home agent address
discovery mechanism.
- Introduced Pad1 and PadN sub-options (Section 5.5) to allow - Removed the Home Agents List Sub-Option since it is no longer
the sub-options in Mobile IPv6 options to be aligned properly. needed with the revised dynamic home agent address discovery
To match the option numbering used for the Pad1 and PadN mechanism.
options defined for use in Hop-by-Hop Options and Destination
Options extension headers [5], these two sub-options have been
numbered 0 and 1, respectively. NOTE: This change also resulted
in changing the sub-option numbers of the other Mobile IPv6
sub-options.
- Added an explicit specification of the units in which - Added a Duplicate Address Detection (D) bit in the Binding
the Lifetime and Refresh fields are expressed in the Update option format, to request the mobile node's home agent to
Binding Acknowledgement option (Section 5.2). As with the perform Duplicate Address Detection on the mobile node's home
corresponding Lifetime field in the Binding Update option and the link for the home address in this binding. Also defined a new
Valid Lifetime and Preferred Lifetime in the Prefix Information Status value of 138 (Duplicate Address Detection failed) for
option used by Neighbor Discovery [14], these fields in the the Binding Acknowledgement, to indicate any failure of this
Binding Acknowledgement option are expressed in seconds. Duplicate Address Detection on the home link. The addition of
the Duplicate Address Detection (D) bit in the Binding Update
option also reduced the Reserved field from a 5-bit field to a
4-bit field (and caused it to be renamed Reservd so that the
label fits in the packet format drawing).
- Rewrote Section 10.9 to indicate that the Binding Update is sent - Added text in Section 9.3 and 10.16 to describe the use of the
to any home agent on the link on which the specified previous new Duplicate Address Detection (D) bit in the Binding Update
care-of address is located, rather than (necessarily) to the option format.
router that it used as its default router on that link. Also,
the mobile node can establish packet forwarding from any previous
care-of address, not just from its previous primary care-of
address.
- Removed the Status value of 129 (Poorly formed Binding Update) - Changed the description of the Home Agents List conceptual data
for the Binding Acknowledgement option, since this value is not structure to require maintenance of a Home Agents List by each
used. Instead, poorly formed Binding Updates have already been mobile node, as well as by each home agent. A mobile node uses
defined (Section 8.2) to be silently discarded. this list to enable notifying a home agent on its previous link,
when the mobile node moves to a new link.
- Removed the Status value of 134 (Sequence Number field value too - In Section 10.10, changed the procedure for retransmitting
small) for the Binding Acknowledgement option, since this value Binding Updates to require that the Sequence Number field in
is not used. Instead, received Binding Updates in which the each successive retransmission MUST be greater than that used
Sequence Number field is not greater than the Sequence Number in the previous transmission. The draft previously incorrectly
received in the previous Binding Update for this home address, specified here that the same sequence number must be used for
if any, have already been defined (Section 8.2) to be silently each retransmission. The change is needed since such reuse
discarded. of sequence numbers will fail if the original transmission
of the Binding Update was in fact received, but the Binding
Acknowledgement (instead of the Binding Update) was lost in
transmission on the network. Changing the Sequence Number on
each retransmission also avoids the any acknowledgement ambiguity
problem, making the start time for the binding lifetime more
clear.
- Corrected a few more minor typographical errors in places. - Corrected yet a few more minor typographical errors in places.
Acknowledgements Acknowledgements
We would like to thank the members of the Mobile IP and IPng We would like to thank the members of the Mobile IP and IPng Working
Working Groups for their comments and suggestions on this work. Groups for their comments and suggestions on this work. We would
We would particularly like to thank (in alphabetical order) particularly like to thank (in alphabetical order) Fred Baker
Josh Broch (Carnegie Mellon University), Rich Draves (Microsoft (Cisco), Josh Broch (Carnegie Mellon University), Rich Draves
Research), Jun-Ichiro Hagino (IIJ Research Laboratory), Thomas Narten (Microsoft Research), Francis Dupont (INRIA), Jun-Ichiro Hagino
(IIJ Research Laboratory), Aime Lerouzic (Bull S.A.), Thomas Narten
(IBM), Erik Nordmark (Sun Microsystems), Simon Nybroe (Telebit (IBM), Erik Nordmark (Sun Microsystems), Simon Nybroe (Telebit
Communications), Patrice Romand (Bull S.A.), Tom Soderlund (Nokia Communications), David Oran (Cisco), Basavaraj Patil (Nokia), Phil
Research), and Jim Solomon (RedBack Networks) for their detailed Roberts (Motorola), Patrice Romand (Bull S.A.), Tom Soderlund (Nokia
reviews of earlier versions of this draft. Their suggestions have Research), Hesham Soliman (Ericsson), Jim Solomon (RedBack Networks),
helped to improve both the design and presentation of the protocol. Benny Van Houdt (University of Antwerp), and Xinhua Zhao (Stanford
University) for their detailed reviews of earlier versions of this
document. Their suggestions have helped to improve both the design
and presentation of the protocol. We would also like to thank the
participants in the Mobile IPv6 testing event held at Nancy, France,
September 15-17, 1999, for their valuable feedback as a result of
interoperability testing of four Mobile IPv6 implementations coming
from four different organizations: Bull (AIX), Ericsson-Telebit
(FreeBSD), NEC (FreeBSD), and INRIA (FreeBSD).
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), February 1999. Work in progress. Protocol for IPv6 (DHCPv6), February 1999. Work in progress.
[3] Scott Bradner. Key words for use in RFCs to indicate [3] Scott Bradner. Key words for use in RFCs to indicate
requirement levels. RFC 2119, March 1997. requirement levels. RFC 2119, March 1997.
[4] Alex Conta and Stephen Deering. Generic packet tunneling in [4] Alex Conta and Stephen Deering. Generic packet tunneling in
IPv6 specification. RFC 2473, December 1998. IPv6 specification. RFC 2473, December 1998.
[5] Stephen E. Deering and Robert M. Hinden. Internet Protocol [5] Alex Conta and Stephen Deering. Internet Control Message
Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6)
specification. RFC 2463, December 1998.
[6] Stephen E. Deering and Robert M. Hinden. Internet Protocol
version 6 (IPv6) specification. RFC 2460, December 1998. version 6 (IPv6) specification. RFC 2460, December 1998.
[6] Paul Ferguson and Daniel Senie. Network ingress filtering: [7] Paul Ferguson and Daniel Senie. Network ingress filtering:
Defeating denial of service attacks which employ IP source Defeating denial of service attacks which employ IP source
address spoofing. RFC 2267, January 1998. address spoofing. RFC 2267, January 1998.
[7] Robert M. Hinden and Stephen E. Deering. IP Version 6 [8] Dan Harkins and Dave Carrel. The Internet Key Exchange (IKE).
RFC 2409, November 1998.
[9] Robert M. Hinden and Stephen E. Deering. IP Version 6
addressing architecture. RFC 2373, July 1998. addressing architecture. RFC 2373, July 1998.
[8] David B. Johnson and Stephen E. Deering. Reserved IPv6 subnet [10] David B. Johnson and Stephen E. Deering. Reserved IPv6 subnet
anycast addresses. RFC 2526, March 1999. anycast addresses. RFC 2526, March 1999.
[9] Stephen Kent and Randall Atkinson. IP Authentication header. [11] Stephen Kent and Randall Atkinson. IP Authentication header.
RFC 2402, November 1998. RFC 2402, November 1998.
[10] Stephen Kent and Randall Atkinson. IP Encapsulating Security [12] Stephen Kent and Randall Atkinson. IP Encapsulating Security
Payload (ESP). RFC 2406, November 1998. Payload (ESP). RFC 2406, November 1998.
[11] Stephen Kent and Randall Atkinson. Security architecture for [13] Stephen Kent and Randall Atkinson. Security architecture for
the Internet Protocol. RFC 2401, November 1998. the Internet Protocol. RFC 2401, November 1998.
[12] P. Mockapetris. Domain Names -- concepts and facilities. [14] Douglas Maughan, Mark Schneider, Mark Schertler, and Jeff
Turner. Internet Security Association and Key Management
Protocol (ISAKMP). RFC 2408, November 1998.
[15] P. Mockapetris. Domain Names -- concepts and facilities.
RFC 1034, November 1987. RFC 1034, November 1987.
[13] P. Mockapetris. Domain Names -- implementation and [16] P. Mockapetris. Domain Names -- implementation and
specification. RFC 1035, November 1987. specification. RFC 1035, November 1987.
[14] Thomas Narten, Erik Nordmark, and William Allen Simpson. [17] Thomas Narten, Erik Nordmark, and William Allen Simpson.
Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December Neighbor Discovery for IP version 6 (IPv6). RFC 2461, December
1998. 1998.
[15] Charles Perkins. IP encapsulation within IP. RFC 2003, October [18] Charles Perkins. IP encapsulation within IP. RFC 2003, October
1996. 1996.
[16] Charles Perkins, editor. IP mobility support. RFC 2002, [19] Charles Perkins, editor. IP mobility support. RFC 2002,
October 1996. October 1996.
[17] Charles Perkins. Minimal encapsulation within IP. RFC 2004, [20] Charles Perkins. Minimal encapsulation within IP. RFC 2004,
October 1996. October 1996.
[18] Charles Perkins and David B. Johnson. Route optimization in [21] Charles Perkins and David B. Johnson. Route optimization in
Mobile IP, February 1999. Work in progress. Mobile IP, February 1999. Work in progress.
[19] David C. Plummer. An Ethernet address resolution protocol: [22] Derrell Piper. The Internet IP security domain of
interpretation for ISAKMP. RFC 2407, November 1998.
[23] David C. Plummer. An Ethernet address resolution protocol:
Or converting network protocol addresses to 48.bit Ethernet Or converting network protocol addresses to 48.bit Ethernet
addresses for transmission on Ethernet hardware. RFC 826, addresses for transmission on Ethernet hardware. RFC 826,
November 1982. November 1982.
[20] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [24] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[21] J. B. Postel, editor. Transmission Control Protocol. RFC 793, [25] J. B. Postel, editor. Transmission Control Protocol. RFC 793,
September 1981. September 1981.
[22] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700, [26] Joyce K. Reynolds and Jon Postel. Assigned numbers. RFC 1700,
October 1994. See also http://www.iana.org/numbers.html. October 1994. See also http://www.iana.org/numbers.html.
[23] Susan Thomson and Thomas Narten. IPv6 stateless address [27] Susan Thomson and Thomas Narten. IPv6 stateless address
autoconfiguration. RFC 2462, December 1998. autoconfiguration. RFC 2462, December 1998.
Chair's Address Chair's Address
The Working Group can be contacted via its current chairs: The Working Group can be contacted via its current chairs:
Phil Roberts Phil Roberts
Motorola Motorola
1501 West Shure Drive 1501 West Shure Drive
Arlington Heights, IL 60004 Arlington Heights, IL 60004
Phone: +1 847 632-3148 Phone: +1 847 632-3148
E-mail: qa3445@email.mot.com E-mail: qa3445@email.mot.com
Basavaraj Patil Basavaraj Patil
Nortel Networks, Inc. Nokia
2201 Lakeside Blvd. 6000 Connection Drive
Richardson, TX 75082-4399 M/S M8-540
Irving, TX 75039
USA USA
Phone: +1 972 684-1489 Phone: +1 972 894-6709
Fax: +1 972 685-3207 Fax: +1 972 894-5349
E-mail: bpatil@nortelnetworks.com E-mail: raj.patil@nokia.com
Authors' Addresses Authors' Addresses
Questions about this document can also be directed to the authors: Questions about this document can also be directed to the authors:
David B. Johnson David B. Johnson
Carnegie Mellon University Carnegie Mellon University
Computer Science Department Computer Science Department
5000 Forbes Avenue 5000 Forbes Avenue
Pittsburgh, PA 15213-3891 Pittsburgh, PA 15213-3891
 End of changes. 

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