draft-ietf-mobileip-ipv6-13.txt   draft-ietf-mobileip-ipv6-14.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Rice University INTERNET-DRAFT Rice University
Charles Perkins Charles Perkins
Nokia Nokia Research Center
17 November 2000 2 July 2000
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-14.txt>
<draft-ietf-mobileip-ipv6-13.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 63 skipping to change at page 1, line 62
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Comparison with Mobile IP for IPv4 3 2. Comparison with Mobile IP for IPv4 3
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
4. Overview of Mobile IPv6 9 4. Overview of Mobile IPv6 8
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11
4.3. Alignment Requirements for New Destination Options . . . 13 4.3. Alignment Requirements for New Destination Options . . . 12
4.4. IPsec Requirements for New Destination Options . . . . . 13 4.4. Authentication Requirements for New Destination Options . 13
4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14
4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 14 4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 15
4.7. Binding Management . . . . . . . . . . . . . . . . . . . 19 4.7. Binding Management . . . . . . . . . . . . . . . . . . . 19
4.8. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 21
5. New IPv6 Destination Options and Message Types 21 5. New IPv6 Destination Options and Message Types 22
5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 21 5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 22
5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 25 5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 27
5.3. Binding Request Option . . . . . . . . . . . . . . . . . 29 5.3. Binding Request Option . . . . . . . . . . . . . . . . . 32
5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 31 5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 34
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 34 5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 37
5.6. ICMP Home Agent Address Discovery Request Message . . . . 37 5.6. ICMP Home Agent Address Discovery Request Message . . . . 41
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 39 5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 43
5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 45
5.9. ICMP Mobile Prefix Advertisement Message Format . . . . . 47
6. Modifications to IPv6 Neighbor Discovery 41 6. Modifications to IPv6 Neighbor Discovery 49
6.1. Modified Router Advertisement Message Format . . . . . . 41 6.1. Modified Router Advertisement Message Format . . . . . . 49
6.2. Modified Prefix Information Option Format . . . . . . . . 42 6.2. Modified Prefix Information Option Format . . . . . . . . 50
6.3. New Advertisement Interval Option Format . . . . . . . . 44 6.3. New Advertisement Interval Option Format . . . . . . . . 52
6.4. New Home Agent Information Option Format . . . . . . . . 45 6.4. New Home Agent Information Option Format . . . . . . . . 53
6.5. Changes to Sending Router Advertisements . . . . . . . . 47 6.5. Changes to Sending Router Advertisements . . . . . . . . 55
6.6. Changes to Sending Router Solicitations . . . . . . . . . 48 6.6. Changes to Sending Router Solicitations . . . . . . . . . 56
7. Requirements for Types of IPv6 Nodes 50 7. Requirements for Types of IPv6 Nodes 58
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 50 7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 58
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 50 7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 58
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 50 7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 58
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 51 7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 59
8. Correspondent Node Operation 53 8. Correspondent Node Operation 61
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 53 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 61
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 53 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 61
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 54 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 62
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 55 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 63
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 55 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 63
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 55 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 63
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 56 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 64
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 57 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 65
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 58 8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 66
9. Home Agent Operation 60 9. Home Agent Operation 68
9.1. Receiving Router Advertisement Messages . . . . . . . . . 60 9.1. Primary Care-of Address Registration . . . . . . . . . . 68
9.2. Dynamic Home Agent Address Discovery . . . . . . . . . . 61 9.2. Primary Care-of Address De-registration . . . . . . . . . 71
9.3. Primary Care-of Address Registration . . . . . . . . . . 63 9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 71
9.4. Primary Care-of Address De-registration . . . . . . . . . 65 9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 73
9.5. Intercepting Packets for a Mobile Node . . . . . . . . . 66 9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 75
9.6. Tunneling Intercepted Packets to a Mobile Node . . . . . 68 9.6. Home Prefix Propagation . . . . . . . . . . . . . . . . . 75
9.7. Handling Reverse Tunneled Packets from a Mobile Node . . 69 9.7. Receiving Router Advertisement Messages . . . . . . . . . 75
9.8. Renumbering the Home Subnet . . . . . . . . . . . . . . . 70 9.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 77
9.8.1. Building Aggregate List of Home Network Prefixes 70 9.8.1. Aggregate List of Home Network Prefixes . . . . . 78
9.8.2. Sending Changed Prefix Information to the Mobile 9.8.2. Scheduling Prefix Deliveries to the Mobile Node . 80
Node . . . . . . . . . . . . . . . . . . . 71 9.8.3. Sending Advertisements to the Mobile Node . . . . 81
9.8.3. Tunneling Router Advertisements to the Mobile Node 73 9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 83
9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 74
10. Mobile Node Operation 75 10. Mobile Node Operation 84
10.1. Sending Packets While Away from Home . . . . . . . . . . 75 10.1. Sending Packets While Away from Home . . . . . . . . . . 84
10.2. Interaction with Outbound IPsec Processing . . . . . . . 76 10.2. Interaction with Outbound IPsec Processing . . . . . . . 85
10.3. Receiving Packets While Away from Home . . . . . . . . . 78 10.3. Receiving Packets While Away from Home . . . . . . . . . 87
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 80 10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 88
10.5. Forming New Care-of Addresses . . . . . . . . . . . . . . 82 10.5. Receiving Local Router Advertisement Messages . . . . . . 91
10.6. Sending Binding Updates to the Home Agent . . . . . . . . 84 10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 92
10.7. Dynamic Home Agent Address Discovery . . . . . . . . . . 86 10.7. Sending Binding Updates to the Home Agent . . . . . . . . 94
10.8. Sending Binding Updates to Correspondent Nodes . . . . . 87 10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 96
10.9. Establishing Forwarding from a Previous Care-of Address . 89 10.9. Sending Binding Updates to Correspondent Nodes . . . . . 97
10.10. Retransmitting Binding Updates . . . . . . . . . . . . . 90 10.10. Establishing Forwarding from a Previous Care-of Address . 99
10.11. Rate Limiting for Sending Binding Updates . . . . . . . . 91 10.11. Retransmitting Binding Updates . . . . . . . . . . . . . 100
10.12. Receiving Binding Acknowledgements . . . . . . . . . . . 91 10.12. Rate Limiting for Sending Binding Updates . . . . . . . . 101
10.13. Receiving Binding Requests . . . . . . . . . . . . . . . 92 10.13. Receiving Binding Acknowledgements . . . . . . . . . . . 101
10.14. Receiving ICMP Error Messages . . . . . . . . . . . . . . 93 10.14. Receiving Binding Requests . . . . . . . . . . . . . . . 103
10.15. Receiving Local Router Advertisement Messages . . . . . . 94 10.15. Receiving ICMP Error Messages . . . . . . . . . . . . . . 103
10.16. Sending Tunneled Router Solicitations . . . . . . . . . . 95 10.16. Sending Mobile Prefix Solicitations . . . . . . . . . . . 104
10.17. Receiving Tunneled Router Advertisements . . . . . . . . 96 10.17. Receiving Mobile Prefix Advertisements . . . . . . . . . 104
10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 97 10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 105
10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 97 10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 106
10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 98 10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 106
11. Protocol Constants 100 11. Protocol Constants 108
12. IANA Considerations 101 12. IANA Considerations 110
13. Security Considerations 102 13. Security Considerations 112
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 102 13.1. Binding Updates, Acknowledgements, and Requests . . . . . 112
13.2. Security for the Home Address Option . . . . . . . . . . 102 13.2. Security for the Home Address Option . . . . . . . . . . 112
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 103 13.3. General Mobile Computing Issues . . . . . . . . . . . . . 113
Changes from Previous Version of the Draft 104 Acknowledgements 113
Acknowledgements 105 References 115
References 106 A. Changes from Previous Version of the Draft 116
A. Remote Home Address Configuration 108 B. Remote Home Address Configuration 117
Chair's Address 109 Chairs' Addresses 119
Authors' Addresses 110 Authors' Addresses 120
1. Introduction 1. Introduction
This document specifies the operation of mobile computers using This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support Internet Protocol Version 6 (IPv6) [6]. Without specific support
for mobility in IPv6, packets destined to a mobile node (host or for mobility in IPv6, packets destined to a mobile node (host or
router) would not be able to reach it while the mobile node is away router) would not be able to reach it while the mobile node is away
from its home link (the link on which its home IPv6 subnet prefix is from its home link (the link on which its home IPv6 subnet prefix is
in use), since routing is based on the subnet prefix in a packet's in use), since routing is based on the subnet prefix in a packet's
destination IP address. In order to continue communication in spite destination IP address. In order to continue communication in spite
skipping to change at page 1, line 203 skipping to change at page 1, line 203
The Mobile IPv6 protocol is just as suitable for mobility across The Mobile IPv6 protocol is just as suitable for mobility across
homogeneous media as for mobility across heterogeneous media. For homogeneous media as for mobility across heterogeneous media. For
example, Mobile IPv6 facilitates node movement from one Ethernet example, Mobile IPv6 facilitates node movement from one Ethernet
segment to another as well as it facilitates node movement from an segment to another as well as it facilitates node movement from an
Ethernet segment to a wireless LAN cell, with the mobile node's IP Ethernet segment to a wireless LAN cell, with the mobile node's IP
address remaining unchanged in spite of such movement. address remaining unchanged in spite of such movement.
One can think of the Mobile IPv6 protocol as solving the One can think of the Mobile IPv6 protocol as solving the
network-layer mobility management problem. Some mobility management network-layer mobility management problem. Some mobility management
applications -- for example, handoff among wireless transceivers, applications -- for example, handover among wireless transceivers,
each of which covers only a very small geographic area -- have been each of which covers only a very small geographic area -- have been
solved using link-layer techniques. For example, in many current solved using link-layer techniques. For example, in many current
wireless LAN products, link-layer mobility mechanisms allow a wireless LAN products, link-layer mobility mechanisms allow a
"handoff" of a mobile node from one cell to another, reestablishing "handover" of a mobile node from one cell to another, reestablishing
link-layer connectivity to the node in each new location. Within link-layer connectivity to the node in each new location. Within
the natural limitations imposed by link-management solutions, and as the natural limitations imposed by link-management solutions, and as
long as such handoff occurs only within cells of the mobile node's long as such handover occurs only within cells of the mobile node's
home link, such link-layer mobility mechanisms MAY offer faster home link, such link-layer mobility mechanisms MAY offer faster
convergence and lower overhead than Mobile IPv6. Extensions to the convergence and lower overhead than Mobile IPv6. Extensions to the
Mobile IPv6 protocol have been proposed to support a more local, Mobile IPv6 protocol have been proposed to support a more local,
hierarchical form of mobility management, but such extensions are hierarchical form of mobility management, but such extensions are
beyond the scope of this document. beyond the scope of this document.
The protocol specified in this document solves the problem of The protocol specified in this document solves the problem of
transparently routing packets to and from mobile nodes while away transparently routing packets to and from mobile nodes while away
from home. However, it does not attempt to solve all general from home. However, it does not attempt to solve all general
problems related to the use of mobile computers or wireless networks. problems related to the use of mobile computers or wireless networks.
In particular, this protocol does not attempt to solve: In particular, this protocol does not attempt to solve:
- Handling links with partial reachability, such as typical - Handling links with partial reachability, or unidirectional
wireless networks. Some aspects of this problem are addressed connectivity, such as are often found in wireless networks. Some
by the movement detection procedure described in Section 10.4, aspects of this problem are addressed by the movement detection
but no attempt has been made to fully solve this problem in its procedure described in Section 10.4, but no attempt has been made
general form. Most aspects of this problem can be solved by the to fully solve this problem in its general form. Most aspects of
workaround of restricting such networks to only one router per this problem can be solved by the workaround of restricting such
link, although there are still possible hidden terminal problems networks to only one router per link, although there are still
when two nodes on the same link (on opposite sides of the router) possible hidden terminal problems when two nodes on the same
attempt to communicate directly. link (on opposite sides of the router) 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 to is a general problem any time an unauthenticated node is allowed
connect to any link layer. It is independent of whether the to 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) [19, 18, 20], 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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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.
- The use of IPv6 destination options allows all Mobile IPv6
control traffic to be piggybacked on any existing IPv6 packets,
whereas in Mobile IPv4 and its Route Optimization extensions,
separate UDP packets were required for each control message.
- The use of the care-of address as the Source Address in each - The use of the care-of address as the Source Address in each
packet's IP header also simplifies routing of multicast packets packet's IP header also simplifies routing of multicast packets
sent by a mobile node. With Mobile IPv4, the mobile node sent by a mobile node. With Mobile IPv4, the mobile node
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 IPv6 features, such as Neighbor mobile nodes make use of IPv6 features, such as Neighbor
Discovery [17] and Address Autoconfiguration [27], to operate in Discovery [17] and Address Autoconfiguration [27], to operate in
any location away from home without any special support required any location away from home without any special support required
from its local router. from its local router.
- Unlike Mobile IPv4, Mobile IPv6 utilizes IP Security
(IPsec) [11, 12, 13] for all security requirements (sender
authentication, data integrity protection, and replay protection)
for Binding Updates (which serve the role of both registration
and Route Optimization in Mobile IPv4). Mobile IPv4 relies
on its own security mechanisms for these functions, based on
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
packets that the mobile node sends are reaching the router). packets that the mobile node sends are reaching the router).
This confirmation provides a detection of the "black hole" This confirmation provides a detection of the "black hole"
situation that may exist in some wireless environments where the situation that may exist in some wireless environments where the
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
skipping to change at page 5, line 25 skipping to change at page 6, line 5
packet need be sent back to the mobile node. The mobile node is packet need be sent back to the mobile node. The mobile node is
less likely to lose one of the replies because no "implosion" of less likely to lose one of the replies because no "implosion" of
replies is required by the protocol. 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
Mobile IPv4), allowing a mobile node to decide for itself how Mobile IPv4), allowing a mobile node to decide for itself how
many Router Advertisements (Agent Advertisements) it is willing many Router Advertisements (Agent Advertisements) it is willing
to miss before declaring its current router unreachable. to miss before declaring its current router unreachable.
- The use of IPv6 destination options allows all Mobile IPv6
control traffic to be piggybacked on any existing IPv6 packets,
whereas in Mobile IPv4 and its Route Optimization extensions,
separate UDP packets were required for each control message.
3. Terminology 3. Terminology
3.1. General Terms The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
IP document are to be interpreted as described in RFC 2119 [3].
Internet Protocol Version 6 (IPv6).
node
A device that implements IP.
router
A node that forwards IP packets not explicitly addressed to 3.1. General Terms
itself.
host IP Internet Protocol Version 6 (IPv6).
Any node that is not a router. node A device that implements IP.
link router A node that forwards IP packets not explicitly
addressed to itself.
A communication facility or medium over which nodes can host Any node that is not a router.
communicate at the link layer, such as an Ethernet (simple or
bridged). A link is the layer immediately below IP.
interface link A communication facility or medium over which nodes
can communicate at the link layer, such as an
Ethernet (simple or bridged). A link is the layer
immediately below IP.
A node's attachment to a link. interface A node's attachment to a link.
subnet prefix subnet prefix
A bit string that consists of some number of initial
A bit string that consists of some number of initial bits of an bits of an IP address.
IP address.
interface identifier interface identifier
A number used to identify a node's interface on a
A number used to identify a node's interface on a link. The link. The interface identifier is the remaining
interface identifier is the remaining low-order bits in the low-order bits in the node's IP address after the
node's IP address after the subnet prefix. subnet prefix.
link-layer address link-layer address
A link-layer identifier for an interface, such as
IEEE 802 addresses on Ethernet links.
A link-layer identifier for an interface, such as IEEE 802 packet An IP header plus payload.
addresses on Ethernet links.
packet Security Association
a security object shared between two nodes which
includes the data mutually agreed on for operation
of some cryptographic algorithm (typically including
a key, as defined above).
An IP header plus payload. Security Policy Database (SPD)
A database of security associations selectable by
rulesets (policies) that determine the packets for
which each security association is to be applied.
3.2. Mobile IPv6 Terms 3.2. Mobile IPv6 Terms
home address home address An IP address assigned to a mobile node within its
home link.
An IP address assigned to a mobile node within its home link.
home subnet prefix home subnet prefix
The IP subnet prefix corresponding to a mobile
node's home address.
The IP subnet prefix corresponding to a mobile node's home home link The link on which a mobile node's home subnet prefix
address. is defined. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home
home link address to its home link.
The link on which a mobile node's home subnet prefix is
defined. Standard IP routing mechanisms will deliver packets
destined for a mobile node's home address to its home link.
mobile node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
movement mobile node A node that can change its point of attachment from
one link to another, while still being reachable via
its home address.
A change in a mobile node's point of attachment to the Internet movement A change in a mobile node's point of attachment to
such that it is no longer connected to the same link as it was the Internet such that it is no longer connected to
previously. If a mobile node is not currently attached to its the same link as it was previously. If a mobile
home link, the mobile node is said to be "away from home". node is not currently attached to its home link, the
mobile node is said to be "away from home".
correspondent node correspondent node
A peer node with which a mobile node is
A peer node with which a mobile node is communicating. The communicating. The correspondent node may be either
correspondent node may be either mobile or stationary. mobile or stationary.
foreign subnet prefix foreign subnet prefix
Any IP subnet prefix other than the mobile node's
home subnet prefix.
Any IP subnet prefix other than the mobile node's home subnet foreign link Any link other than the mobile node's home link.
prefix.
foreign link
Any link other than the mobile node's home link.
home agent
A router on a mobile node's home link with which the mobile home agent A router on a mobile node's home link with which
node has registered its current care-of address. While the the mobile node has registered its current care-of
mobile node is away from home, the home agent intercepts address. While the mobile node is away from home,
packets on the home link destined to the mobile node's home the home agent intercepts packets on the home
address, encapsulates them, and tunnels them to the mobile link destined to the mobile node's home address,
encapsulates them, and tunnels them to the mobile
node's registered care-of address. node's registered care-of address.
care-of address care-of address
An IP address associated with a mobile node while
visiting a foreign link; the subnet prefix of this
IP address is a foreign subnet prefix. Among the
multiple care-of addresses that a mobile node
may have at a time (e.g., with different subnet
prefixes), the one registered with the mobile node's
home agent is called its "primary" care-of address.
An IP address associated with a mobile node while visiting a binding The association of the home address of a mobile node
foreign link; the subnet prefix of this IP address is a foreign with a care-of address for that mobile node, along
subnet prefix. Among the multiple care-of addresses that a with the remaining lifetime of that association.
mobile node may have at a time (e.g., with different subnet
prefixes), the one registered with the mobile node's home agent
is called its "primary" care-of address.
binding
The association of the home address of a mobile node with a
care-of address for that mobile node, along with the remaining
lifetime of that association.
3.3. Specification Language Binding Key
a key used for authenticating Binding Update
messages.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Binding Security Association (BSA)
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this a security association established specifically
document are to be interpreted as described in RFC 2119 [3]. for the purpose of producing and verifying
authentication data passed with a Binding Update
destination option.
4. Overview of Mobile IPv6 4. Overview of Mobile IPv6
4.1. Basic Operation 4.1. Basic Operation
A mobile node is always addressable by its home address, whether it A mobile node is always addressable by its home address, whether it
is currently attached to its home link or is away from home. While is currently attached to its home link or is away from home. While
a mobile node is at home, packets addressed to its home address are a mobile node is at home, packets addressed to its home address are
routed to it using conventional Internet routing mechanisms in the routed to it using conventional Internet routing mechanisms in the
same way as if the node were never mobile. Since the subnet prefix same way as if the node were never mobile. Since the subnet prefix
skipping to change at page 10, line 13 skipping to change at page 9, line 30
addressed to the mobile node's primary care-of address. addressed to the mobile node's primary care-of address.
When a mobile node moves from one care-of address to a new care-of When a mobile node moves from one care-of address to a new care-of
address on a new link, it is desirable for packets arriving at the address on a new link, it is desirable for packets arriving at the
previous care-of address to be tunneled to the mobile node's care-of previous care-of address to be tunneled to the mobile node's care-of
address. Since the purpose of a Binding Update is to establish address. Since the purpose of a Binding Update is to establish
exactly this kind of tunneling, it is specified to be used (at exactly this kind of tunneling, it is specified to be used (at
least temporarily) for tunnels originating at the mobile node's least temporarily) for tunnels originating at the mobile node's
previous care-of address, in exactly the same way that it is used previous care-of address, in exactly the same way that it is used
for establishing tunnels from the mobile node's home address to the for establishing tunnels from the mobile node's home address to the
mobile node's current care-of address. Section 10.9 describes the mobile node's current care-of address. Section 10.10 describes the
use of the Binding Update for this purpose. use of the Binding Update for this purpose.
Section 10.18 discusses the reasons why it may be desirable for Section 10.18 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 the particular care-of address to
addresses to which to tunnel each intercepted packet. The mobile which it will tunnel each intercepted packet. The mobile node alone
node alone controls the policy by which it selects the care-of controls the policy by which it selects the care-of addresses to
addresses to register with its home agent. register 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
agent on its home link with which it may register its care-of address home agent on its home link with which it may register its (primary)
while away from home. The mobile node sends an ICMP "Home Agent care-of address while away from home. The mobile node sends an ICMP
Address Discovery Request" message to the "Mobile IPv6 Home-Agents" "Home Agent Address Discovery Request" message to the "Mobile IPv6
anycast address for its own home subnet prefix [10] and thus reaches Home-Agents" anycast address for its own home subnet prefix [10] and
one of the (possibly many) routers on its home link currently thus reaches one of the (possibly many) routers on its home link
operating as a home agent. This home agent then returns an ICMP currently operating as a home agent. This home agent then returns an
"Home Agent Address Discovery Reply" message to the mobile node, ICMP "Home Agent Address Discovery Reply" message to the mobile node,
including a list of home agents on the home link. This list of home including a list of home agents on the home link. This list of home
agents is maintained by each home agent on the home link through use agents is maintained by each home agent on the home link through use
of the Home Agent (H) bit in each home agent's periodic unsolicited of the Home Agent (H) bit in each home agent's periodic unsolicited
multicast Router Advertisements. 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
skipping to change at page 12, line 12 skipping to change at page 11, line 25
As mentioned in Section 4.1, the following four new IPv6 destination As mentioned in Section 4.1, the following four new IPv6 destination
options are defined for Mobile IPv6: options are defined for Mobile IPv6:
Binding Update Binding Update
A Binding Update option is used by a mobile node to notify A Binding Update option is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked home agent to register its primary care-of address is marked
as a "home registration". Any packet that includes a Binding as a "home registration". Any packet that includes a Binding
Update option MUST be protected by IPsec [13], as defined in Update option MUST be protected by some authentication data
Section 4.4, to guard against malicious Binding Updates. The (see section 5.1), as defined in Section 4.4, to guard against
Binding Update option and its specific IPsec requirements are malicious Binding Updates. The Binding Update option and
described in detail in Section 5.1. its specific IPsec requirements are described in detail in
Section 5.1.
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement option is used to acknowledge receipt A Binding Acknowledgement option is used to acknowledge receipt
of a Binding Update, if an acknowledgement was requested of a Binding Update, if an acknowledgement was requested
in the Binding Update. Any packet that includes a Binding in the Binding Update. Any packet that includes a Binding
Acknowledgement option MUST be protected by IPsec [13], as Acknowledgement option MUST be protected by some authentication
defined in Section 4.4, to guard against malicious Binding data (see section 5.2), as defined in Section 4.4, to guard
Acknowledgements. The Binding Acknowledgement option and against malicious Binding Acknowledgements. The Binding
its specific IPsec requirements are described in detail in Acknowledgement option and its specific IPsec requirements are
Section 5.2. described in detail in Section 5.2.
Binding Request Binding Request
A Binding Request option is used to request a mobile node to A Binding Request option is used to request a mobile node to
send to the requesting node a Binding Update containing the send to the requesting node a Binding Update containing the
mobile node's current binding. This option is typically used mobile node's current binding. This option is typically used
by a correspondent node to refresh a cached binding for a by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication binding's lifetime is close to expiration. No authentication
is required for the Binding Request option. The Binding is required for the Binding Request option. The Binding
skipping to change at page 13, line 38 skipping to change at page 13, line 5
alignment requirements [6]. Specifically, the notation xn+y means alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets. multiple of x octets from the start of the header, plus y octets.
For example: For example:
2n means any 2-octet offset from the start of the header. 2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header, 8n+2 means any 8-octet offset from the start of the header,
plus 2 octets. plus 2 octets.
4.4. IPsec Requirements for New Destination Options 4.4. Authentication Requirements for New Destination Options
Any packet that includes a Binding Update or Binding Acknowledgement Any packet that includes a Binding Update or Binding Acknowledgement
option MUST be protected by IPsec [13] to guard against malicious option has to contain some Authentication Data to guard against
Binding Updates or Acknowledgements. Specifically, any packet that malicious Binding Updates or Acknowledgements. The way that the
includes a Binding Update or Binding Acknowledgement option MUST Authentication Data is computed has to provide sender authentication,
utilize IPsec sender authentication, data integrity protection, and data integrity protection, and replay protection.
replay protection.
Mobile IPv6 requires that this protection covering a Binding Update Mobile IPv6 requires that the Authentication Data covering a Binding
or Binding Acknowledgement MUST be provided by use of AH [11]. If Update or MUST be computed over a bitstring containing the following
another Security Association applied to the packet for other reasons fields of the IPv6 header and destination options, in order:
Destination IP Address of the IPv6 header
Care-of Address, in the Source IP Address of the IPv6 header
Home Address, from the Home Address destination option
Option Type of the Binding Update destination option
Option Length of the Binding Update destination option
All flags of the Binding Update destination option
Reserved Field of the Binding Update destination option
7-bit Prefix Length of the Binding Update destination option
Authentication Data Length of the Binding Update
Lifetime of the Binding Update destination option
Security Parameters Index (SPI) of the Binding Update
Sequence Number Field of the Binding Update
The entire data from all Binding Update Sub-Options, if any
Mobile IPv6 requires that the Authentication Data covering a Binding
Acknowledgement MUST be computed over a bitstring containing the
following data, in order:
Destination IP Address of the IPv6 header
Source IP Address of the IPv6 header
Option Type of the Binding Acknowledgement destination
option
Option Length of the Binding Acknowledgement
Status of the Binding Acknowledgement
Authentication Data Length of the Binding Acknowledgement
Lifetime of the Binding Acknowledgement destination option
Security Parameters Index (SPI) of the Binding
Acknowledgement
Sequence Number Field of the Binding Acknowledgement
The entire data from all Binding Acknowledgement
Sub-Options, if any
If a Security Association applied to the packet for other reasons
requires use of ESP [12], for example to encrypt the transport layer requires use of ESP [12], for example to encrypt the transport layer
data carried in the packet, this use of ESP is not sufficient to data carried in the packet, this use of ESP is not sufficient to
satisfy the authentication requirements of Mobile IPv6; instead, satisfy the authentication requirements of Mobile IPv6.
the packet MUST use both AH and ESP. Use of ESP for protecting the
Binding Update or Binding Acknowledgement is not currently defined in
this document, since ESP does not protect the portion of the packet
above the ESP header itself [12].
4.5. New IPv6 ICMP Messages 4.5. New IPv6 ICMP Messages
Mobile IPv6 also introduces two new ICMP message types, for use in Mobile IPv6 also introduces four new ICMP message types, two for use
the dynamic home agent address discovery mechanism. As discussed in in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in
general in Section 4.1, the following two new ICMP message types are general in Section 4.1, the following two new ICMP message types are
used: used for home agent address discovery:
Home Agent Address Discovery Request Home Agent Address Discovery Request
The ICMP Home Agent Address Discovery Request message is used The ICMP Home Agent Address Discovery Request message is used
by a mobile node to initiate the dynamic home agent address by a mobile node to initiate the dynamic home agent address
discovery mechanism. When attempting a home registration, the discovery mechanism. When attempting a home registration, the
mobile node may use this mechanism to discover the address of mobile node may use this mechanism to discover the address of
one or more routers currently operating as home agents on its one or more routers currently operating as home agents on its
home link, with which it may register while away from home. home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described The Home Agent Address Discovery Request message is described
skipping to change at page 14, line 38 skipping to change at page 14, line 35
The ICMP Home Agent Address Discovery Reply message is used by The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.7. described in detail in Section 5.7.
The next two message types are used for network renumbering
and address configuration on the mobile node, as described in
Section 9.6:
Mobile Prefix Solicitation
The ICMP Mobile Prefix Solicitation message is used by a mobile
node to request prefix information about the home subnet, in
order to retrieve prefixes that are served by home agents and
can be used to configure one or more home addresses, or to
refresh home addresses before the expiration of their validity.
This message is specified in Section 5.8.
Mobile Prefix Advertisement
The ICMP Mobile Prefix Advertisement is used by a home agent to
distribute information to a mobile node about prefixes on the
home link which are available for use by the mobile node while
away from home. This message may be sent as a response to a
Mobile Prefix Solicitation, or due to network renumbering or
other prefix changes as specified in Section 5.9
4.6. Conceptual Data Structures 4.6. Conceptual Data Structures
This document describes the Mobile IPv6 protocol in terms of the This document describes the Mobile IPv6 protocol in terms of the
following three conceptual data structures: following three conceptual data structures:
Binding Cache Binding Cache
A cache, maintained by each IPv6 node, of bindings for other A cache, maintained by each IPv6 node, of bindings for other
nodes. A separate Binding Cache SHOULD be maintained by each nodes. A separate Binding Cache SHOULD be maintained by each
IPv6 node for each of its IPv6 addresses. The Binding Cache IPv6 node for each of its IPv6 addresses. The Binding Cache
skipping to change at page 15, line 22 skipping to change at page 15, line 38
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,
this entry SHOULD be used in routing that packet. this entry SHOULD be used in routing that packet.
- The care-of address for the mobile node indicated by - The care-of address for the mobile node indicated by
the home address field in this Binding Cache entry. If the home address field in this Binding Cache entry. If
the destination address of a packet being routed by a the destination address of a packet being routed by a
node matches the home address in this entry, the packet node matches the home address in this entry, the packet
SHOULD be routed to this care-of address, as described in SHOULD be routed to this care-of address, as described in
Section 8.9, for packets originated by this node, or in Section 8.9, for packets originated by this node, or in
Section 9.6, if this node is the mobile node's home agent Section 9.4, if this node is the mobile node's home agent
and the packet was intercepted by it on the home link. and the packet was intercepted by it on the home link.
- A lifetime value, indicating the remaining lifetime - A lifetime value, indicating the remaining lifetime
for this Binding Cache entry. The lifetime value is for this Binding Cache entry. The lifetime value is
initialized from the Lifetime field in the Binding Update initialized from the Lifetime field in the Binding Update
that created or last modified this Binding Cache entry. that created or last modified this Binding Cache entry.
Once the lifetime on this entry expires, the entry MUST be Once the lifetime on this entry expires, the entry MUST be
deleted from the Binding Cache. deleted from the Binding Cache.
- A flag indicating whether or not this Binding Cache entry - A flag indicating whether or not this Binding Cache entry
skipping to change at page 15, line 49 skipping to change at page 16, line 14
Cache entry indicates that this is a "home registration" Cache entry indicates that this is a "home registration"
entry. entry.
- The value of the Prefix Length field received in the - The value of the Prefix Length field received in the
Binding Update that created or last modified this Binding Binding Update that created or last modified this Binding
Cache entry. This field is only valid if the "home Cache entry. This field is only valid if the "home
registration" flag is set on this Binding Cache entry. registration" flag is set on this Binding Cache entry.
- The maximum value of the Sequence Number field received - The maximum value of the Sequence Number field received
in previous Binding Updates for this mobile node home in previous Binding Updates for this mobile node home
address. The Sequence Number field is 16 bits long, address. The Sequence Number field is 8 bits long,
and all comparisons between Sequence Number values and all comparisons between Sequence Number values
MUST be performed modulo 2**16. For example, using an MUST be performed modulo 2**8. For example, using an
implementation in the C programming language, a Sequence implementation in the C programming language, a Sequence
Number value A is greater than another Sequence Number Number value A is greater than another Sequence Number
value B if ((short)((a) - (b)) > 0), if a "short" data type value B if ((int)((a) - (b)) > 0), if the "int" data type
is a 16-bit signed integer. is a 8-bit signed integer.
- Recent usage information for this Binding Cache entry, as - Recent usage information for this Binding Cache entry, as
needed to implement the cache replacement policy in use in needed to implement the cache replacement policy in use in
the Binding Cache and to assist in determining whether a the Binding Cache and to assist in determining whether a
Binding Request should be sent when the lifetime on this Binding Request should be sent when the lifetime on this
entry nears expiration. entry nears expiration.
- The time at which a Binding Request was last sent for this - The Binding Security Association (BSA) to be be used when
entry, as needed to implement the rate limiting restriction authenticating Binding Updates that are received for this
for sending Binding Requests. Binding Cache entry.
- The Binding Security Association (BSA) to be be used when
calculating authentication data for inclusion in Binding
Acknowledgements in response to Binding Updates that are
received for this Binding Cache entry.
An entry in a node's Binding Cache for which the node is An entry in a node's Binding Cache for which the node is
serving as a home agent is marked as a "home registration" serving as a home agent is marked as a "home registration"
entry and SHOULD NOT be deleted by the home agent until the entry and SHOULD NOT be deleted by the home agent until the
expiration of its binding lifetime. Other Binding Cache expiration of its binding lifetime. Other Binding Cache
entries MAY be replaced at any time by any reasonable local entries MAY be replaced at any time by any reasonable local
cache replacement policy but SHOULD NOT be unnecessarily cache replacement policy but SHOULD NOT be unnecessarily
deleted. The Binding Cache for any one of a node's IPv6 deleted. The Binding Cache for any one of a node's IPv6
addresses may contain at most one entry for each mobile node addresses may contain at most one entry for each mobile node
home address. The contents of a node's Binding Cache MUST NOT home address. The contents of a node's Binding Cache MUST NOT
skipping to change at page 16, line 49 skipping to change at page 17, line 18
mobile node's previous care-of address is located. However, mobile node's previous care-of address is located. However,
for multiple Binding Updates sent to the same destination for multiple Binding Updates sent to the same destination
address, the Binding Update List contains only the most recent address, the Binding Update List contains only the most recent
Binding Update (i.e., with the greatest Sequence Number value) Binding Update (i.e., with the greatest Sequence Number value)
sent to that destination. The Binding Update List MAY be sent to that destination. The Binding Update List MAY be
implemented in any manner consistent with the external behavior implemented in any manner consistent with the external behavior
described in this document. Each Binding Update List entry described in this document. Each Binding Update List entry
conceptually contains the following fields: conceptually contains the following fields:
- The IP address of the node to which a Binding Update was - The IP address of the node to which a Binding Update was
sent. This node might still have a Binding Cache entry sent. That node might still have a Binding Cache entry
created or updated from this Binding Update, if the Binding created or updated from this Binding Update, if the Binding
Update was successfully received by that node (e.g., not Update was successfully received by that node (e.g., not
lost by the network) and if that node has not deleted the lost by the network) and if that node has not deleted the
entry before its expiration (e.g., to reclaim space in its entry before its expiration (e.g., to reclaim space in its
Binding Cache for other entries). Binding Cache for other entries).
- The home address for which that Binding Update was sent. - The home address for which that Binding Update was sent.
This will be one of the following: This will be one of the following:
* the mobile node's home addresses for typical Binding * the mobile node's home addresses for typical Binding
Updates (Sections 10.6 and 10.8), or Updates (Sections 10.7 and 10.9), or
* the mobile node's previous care-of address for Binding * the mobile node's previous care-of address for Binding
Updates sent to establish forwarding from the mobile Updates sent to establish forwarding from the mobile
node's previous care-of address by a home agent from node's previous care-of address by a home agent from
this previous care-of address (Section 10.9). this previous care-of address (Section 10.10).
- The care-of address sent in that Binding Update. This - The care-of address sent in that Binding Update. This
value is necessary for the mobile node to determine if it value is necessary for the mobile node to determine if it
has sent a Binding Update giving its new care-of address to has sent a Binding Update giving its new care-of address to
this destination after changing its care-of address. this destination after changing its care-of address.
- The initial value of the Lifetime field sent in that - The initial value of the Lifetime field sent in that
Binding Update. Binding Update.
- The remaining lifetime of that binding. This lifetime is - The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding initialized from the Lifetime value sent in the Binding
Update and is decremented until it reaches zero, at which Update and is decremented until it reaches zero, at which
time this entry MUST be deleted from the Binding Update time this entry MUST be deleted from the Binding Update
List. List.
- The maximum value of the Sequence Number field sent in - The maximum value of the Sequence Number field sent in
previous Binding Updates to this destination. The Sequence previous Binding Updates to this destination. The Sequence
Number field is 16 bits long, and all comparisons between Number field is 8 bits long, and all comparisons between
Sequence Number values MUST be performed modulo 2**16. Sequence Number values MUST be performed modulo 2**8. For
For example, using an implementation in the C programming example, using an implementation in the C programming
language, a Sequence Number value A is greater than another language, a Sequence Number value A is greater than another
Sequence Number value B if ((short)((a) - (b)) > 0), if a Sequence Number value B if ((int)((a) - (b)) > 0), if the
"short" data type is a 16-bit signed integer. "int" data type is a 8-bit signed integer.
- The time at which a Binding Update was last sent to this - The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting destination, as needed to implement the rate limiting
restriction for sending Binding Updates. restriction for sending Binding Updates.
- The state of any retransmissions needed for this Binding - The state of any retransmissions needed for this Binding
Update, if the Acknowledge (A) bit was set in this Binding Update, if the Acknowledge (A) bit was set in this Binding
Update. This state includes the time remaining until the Update. This state includes the time remaining until the
next retransmission attempt for the Binding Update, and the next retransmission attempt for the Binding Update, and the
current state of the exponential back-off mechanism for current state of the exponential back-off mechanism for
retransmissions. retransmissions.
- 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.15.
Home Agents List Home Agents List
A list, maintained by each home agent and each mobile node, A list, maintained by each home agent and each mobile node,
recording information about each home agent from which this recording information about each home agent from which this
node has received a Router Advertisement in which the Home node has received a Router Advertisement in which the Home
Agent (H) bit is set, for which the remaining lifetime for Agent (H) bit is set, for which the remaining lifetime for
this list entry (defined below) has not yet expired. The this list entry (defined below) has not yet expired. The
home agents list is thus similar to the Default Router home agents list is thus similar to the Default Router
List conceptual data structure maintained by each host for List conceptual data structure maintained by each host for
skipping to change at page 18, line 46 skipping to change at page 19, line 16
Advertisements received from it [17]. 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 learned through Prefix Information options with
the Router Address (R) bit set, received in Router the Router Address (R) bit 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 [17]. no longer valid [17].
Are there interactions with the new Router
Advertisement stuff?
- 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 that 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.
skipping to change at page 19, line 19 skipping to change at page 19, line 44
Advertisement, if the Router Advertisement contains a Home Advertisement, if the Router Advertisement contains a Home
Agent Information Option, and is otherwise set to the Agent Information Option, and is otherwise set to the
default value of 0. A home agent uses this preference in default value of 0. A home agent uses this preference in
ordering the Home Agents List returned in an ICMP Home ordering the Home Agents List returned in an ICMP Home
Agent Address Discovery message in response to a mobile Agent Address Discovery message in response to a mobile
node's initiation of dynamic home agent address discovery. node's initiation of dynamic home agent address discovery.
A mobile node uses this preference in determining which A mobile node uses this preference in determining which
of the home agents on its previous link to notify when it of the home agents on its previous link to notify when it
moves to a new link. moves to a new link.
Can we delete the preference stuff? Is anyone using
it?
4.7. Binding Management 4.7. Binding Management
When a mobile node configures a new care-of address and decides to When a mobile node configures a new care-of address and decides to
use this new address as its primary care-of address, the mobile use this new address as its primary care-of address, the mobile
node registers this new binding with its home agent by sending node registers this new binding with its home agent by sending
the home agent a Binding Update. The mobile node indicates the home agent a Binding Update. The mobile node indicates
that an acknowledgement is needed for this Binding Update and that an acknowledgement is needed for this Binding Update and
continues to periodically retransmit it until acknowledged. The continues to periodically retransmit it until acknowledged. The
home agent acknowledges the Binding Update by returning a Binding home agent acknowledges the Binding Update by returning a Binding
Acknowledgement to the mobile node. Acknowledgement to the mobile node.
When a mobile node receives a packet tunneled to it from its When a mobile node receives a packet tunneled to it from its home
home agent, the mobile node assumes that the original sending agent, the mobile node uses that as an indication that the original
correspondent node has no Binding Cache entry for the mobile node, sending correspondent node has no Binding Cache entry for the mobile
since the correspondent node would otherwise have sent the packet node, since the correspondent node would otherwise have sent the
directly to the mobile node using a Routing header. The mobile node packet directly to the mobile node using a Routing header. If the
thus returns a Binding Update to the correspondent node, allowing mobile node has a Binding Security Association (BSA) with that
it to cache the mobile node's binding for routing future packets to correspondent node, the mobile node thus returns a Binding Update
it. Although the mobile node may request an acknowledgement for to the correspondent node, allowing it to cache the mobile node's
this Binding Update, it need not, since subsequent packets from the binding for routing future packets to it. Although the mobile node
correspondent node will continue to be intercepted and tunneled by may request an acknowledgement for this Binding Update, it need not,
the mobile node's home agent, effectively causing any needed Binding since subsequent packets from the correspondent node will continue
Update retransmission. to be intercepted and tunneled by the mobile node's home agent,
effectively causing any needed Binding Update retransmission.
If the mobile node receives such a tunneled packet but does not have
a BSA with the correspondent node, the mobile node SHOULD initiate
the process of establishing the necessary security association by
following the procedures outlined in [?].
A correspondent node with a Binding Cache entry for a mobile node A correspondent node with a Binding Cache entry for a mobile node
may refresh this binding, for example if the binding's lifetime may refresh this binding, for example if the binding's lifetime
is near expiration, by sending a Binding Request to the mobile is near expiration, by sending a Binding Request to the mobile
node. Normally, a correspondent node will only refresh a Binding node. Normally, a correspondent node will only refresh a Binding
Cache entry in this way if it is actively communicating with the Cache entry in this way if it is actively communicating with the
mobile node and has indications, such as an open TCP connection to mobile node and has indications, such as an open TCP connection to
the mobile node, that it will continue this communication in the the mobile node, that it will continue this communication in the
future. When a mobile node receives a Binding Request, it replies by future. When a mobile node receives a Binding Request, it replies by
returning a Binding Update to the node sending the Binding Request. returning a Binding Update to the node sending the Binding Request.
A mobile node may use more than one care-of address at the same A mobile node may use more than one care-of address at the same time,
time, although only one care-of address may be registered for it at although only one care-of address may be registered for it at its
its home agent as its primary care-of address. The mobile node's home agent as its primary care-of address. The mobile node's home
home agent will tunnel all intercepted packets for the mobile node agent will tunnel all intercepted packets for the mobile node to its
to its (single) registered primary care-of address, but the mobile (single) registered primary care-of address, but the mobile node
node will accept packets that it receives at any of its current will accept packets that it receives at any of its current care-of
care-of addresses. Use of more than one care-of address by a mobile addresses. Use of more than one care-of address by a mobile node
node may be useful, for example, to improve smooth handoff when the may be useful, for example, to improve smooth handover when the
mobile node moves from one wireless link to another. If each of mobile node moves from one wireless link to another. If each of
these wireless links is connected to the Internet through a separate these wireless links is connected to the Internet through a separate
base station, such that the wireless transmission range from the base station, such that the wireless transmission range from the
two base stations overlap, the mobile node may be able to remain two base stations overlap, the mobile node may be able to remain
connected to both links while in the area of overlap. In this case, connected to both links while in the area of overlap. In this case,
the mobile node could acquire a new care-of address on the new link the mobile node could acquire a new care-of address on the new link
before moving out of transmission range and disconnecting from the before moving out of transmission range and disconnecting from the
old link. The mobile node may thus still accept packets at its old link. The mobile node may thus still accept packets at its
old care-of address while it works to update its home agent and old care-of address while it works to update its home agent and
correspondent nodes, notifying them of its new care-of address on the correspondent nodes, notifying them of its new care-of address on the
skipping to change at page 21, line 5 skipping to change at page 21, line 21
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.
4.8. Mobile Routers
If a router is itself mobile, and it has acquired a new care-of
address, then that new care-of address should be used by the home
agent for the mobile router, and also to tunnel packets for any home
address that matches the routing prefixes advertised by the mobile
router. The simplest way to do this is for the mobile router to
tell the home agent about the prefix length of the network (and,
consequently, subnets with longer prefixes) being served by the
mobile router. For this purpose, the Mobile Router Prefix Length
Sub-option has been specified (see section 5.5).
This information may be supplied by the mobile router to any
correspondent node; there is no restriction that it be sent only
to Home Agents. However, unless the recipient is itself a router,
it may not have the necessary processing capabilities to make the
entries into its Binding Cache to cover all the matching necessary
for the implied range of Home Addresses. Thus, the sender MUST
be prepared to cease supplying the Mobile Router Prefix Length
Sub-Option to nodes that send back a negative status as part of a
Binding Acknowledgement.
5. New IPv6 Destination Options and Message Types 5. New IPv6 Destination Options and Message Types
5.1. Binding Update Option 5.1. Binding Update Option
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|D|Reservd| Prefix Length | Sequence Number | |A|H|R|D| Reservd |Prefix Length|AuthData Length| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =
= Authentication Data (variable length) =
= =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
198 = 0xC6 198 = 0xC6
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
skipping to change at page 22, line 38 skipping to change at page 23, line 45
Acknowledgement will be set to 138 (Duplicate Address Detection Acknowledgement will be set to 138 (Duplicate Address Detection
failed). failed).
Reservd Reservd
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Prefix Length Prefix Length
The Prefix Length field is valid only for a "home registration" The 7-bit Prefix Length field is valid only for a "home
Binding Update; this field MUST be zero if the Home registration" Binding Update; this field MUST be zero if the
Registration (H) bit is not set in the Binding Update. The Home Registration (H) bit is not set in the Binding Update.
Prefix Length field is set by the sending mobile node to the The Prefix Length field is set by the sending mobile node to
(nonzero) length of its subnet prefix in its home address the (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 interface identifier to form other valid addresses for
skipping to change at page 23, line 14 skipping to change at page 24, line 20
the link-local address and site-local address corresponding the link-local address and site-local address corresponding
to this interface identifier, and defends each for purposes to this interface identifier, and defends each for purposes
of Duplicate Address Detection. The home agent also performs of Duplicate Address Detection. The home agent also performs
Duplicate Address Detection on at least one such address as Duplicate Address Detection on at least one such address as
part of the home registration processing (before returning part of the home registration processing (before returning
the Binding Acknowledgement), if the Duplicate Address the Binding Acknowledgement), if the Duplicate Address
Detection (D) bit is set in the Binding Update; it is not Detection (D) bit is set in the Binding Update; it is not
necessary to perform Duplicate Address Detection individually necessary to perform Duplicate Address Detection individually
on each of these addresses, since address uniqueness here is on each of these addresses, since address uniqueness here is
determined solely by the interface identifier [27]. Details of determined solely by the interface identifier [27]. Details of
this operation are described in Section 9.3. this operation are described in Section 9.1.
Sequence Number AuthDataLength
Used by the receiving node to sequence Binding Updates and by The length of the Authentication Data field in octets.
the sending node to match a returned Binding Acknowledgement
with this Binding Update. Each Binding Update sent by a mobile Sequence #
node MUST use a Sequence Number greater than the Sequence
Number value sent in the previous Binding Update (if any) to An 8-bit number sed by the receiving node to sequence Binding
the same destination address (modulo 2**16, as defined in Updates and by the sending node to match a returned Binding
Section 4.6). There is no requirement, however, that the Acknowledgement with this Binding Update. Each Binding Update
Sequence Number value strictly increase by 1 with each new sent by a mobile node MUST use a Sequence Number greater than
Binding Update sent or received. the Sequence Number value sent in the previous Binding Update
(if any) to the same destination address (modulo 2**8, as
defined in Section 4.6). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each
new Binding Update sent or received.
Lifetime Lifetime
32-bit unsigned integer. The number of seconds remaining 32-bit unsigned integer. The number of seconds remaining
before the binding MUST be considered expired. A value of all before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value is zero one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST indicates that the Binding Cache entry for the mobile node MUST
be deleted. be deleted.
Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that, in combination with
the destination IP address, uniquely identifies the Binding
Security Association (BSA) for this datagram. The set of
SPI values in the range 1 through 255 are reserved by the
Internet Assigned Numbers Authority (IANA) for future use;
a reserved SPI value will not normally be assigned by IANA
unless the use of the assigned SPI value is specified in an
RFC. It is ordinarily selected by the destination system upon
establishment of an BSA.
The SPI value of zero (0) is reserved for local,
implementation-specific use and MUST NOT be sent on the
wire. For example, a key management implementation MAY use the
zero SPI value to mean "No Binding Security Association Exists"
during the period when the implementation has requested that
its key management entity establish a new SA, but the SA has
not yet been established.
Authentication Data
This is a variable-length field that contains the
Authentication Data necessary to secure this Binding Update.
The field must be an integral multiple of 32 bits in length.
The details of the authentication calculation are given
in Section 4.4. This field may include explicit padding,
depending upon the requirements of the algorithm selected by
the SPI.
Sub-Options Sub-Options
Additional information, associated with this Binding Update Additional information, associated with this Binding Update
option, that need not be present in all Binding Updates sent. option, that need not be present in all Binding Updates sent.
This use of sub-options also allows for future extensions to This use of sub-options also allows for future extensions to
the format of the Binding Update option to be defined. The the format of the Binding Update option to be defined. The
encoding and format of defined sub-options are described in encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding Section 5.5. The following sub-options are valid in a Binding
Update option: Update option:
- Unique Identifier Sub-Option - Unique Identifier Sub-Option
- Mobile Router Prefix Length Sub-Option
- Alternate Care-of Address Sub-Option - Alternate Care-of Address Sub-Option
The alignment requirement [6] 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 that which was received binding given in the Binding Update option is that which was received
as the value of the Home Address field in the Home Address option in as the value of the Home Address field in the Home Address option in
the packet. 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 that which was received as the value in the Source option is normally that which was received as the value in the Source
Address field in the IPv6 header of the packet carrying the Binding Address field in the IPv6 header of the packet carrying the Binding
Update option. However, a care-of address different from the Source Update option. However, a care-of address different from the Source
Address MAY be specified by including an Alternate Care-of Address Address MAY be specified by including an Alternate Care-of Address
sub-option in the Binding Update option. sub-option in the Binding Update option.
Any packet that includes a Binding Update option MUST be protected by
IPsec [13] to guard against malicious Binding Updates. The specific
requirements for this protection are defined in Section 4.4.
If the care-of address for the binding (specified either in an If the care-of address for the binding (specified either in an
Alternate Care-of Address sub-option in the Binding Update option, if Alternate Care-of Address sub-option in the Binding Update option, if
present, or in the Source Address field in the packet's IPv6 header) present, or in the Source Address field in the packet's IPv6 header)
is equal to the home address of the mobile node, the Binding Update is equal to the home address of the mobile node, the Binding Update
option indicates that any existing binding for the mobile node MUST option indicates that any existing binding for the mobile node MUST
be deleted. Likewise, if the Lifetime field in the Binding Update be deleted. Likewise, if the Lifetime field in the Binding Update
option is equal to 0, the Binding Update option indicates that any option is equal to 0, the Binding Update option indicates that any
existing binding for the mobile node MUST be deleted. In each of existing binding for the mobile node MUST be deleted. In each of
these cases, a Binding Cache entry for the mobile node MUST NOT be these cases, a Binding Cache entry for the mobile node MUST NOT be
created in response to receiving the Binding Update. created in response to receiving the Binding Update.
When the care-of address is NOT equal to the home address,
what if we just delete that particular care-of address?
The last Sequence Number value sent to a destination in a Binding The last Sequence Number value sent to a destination in a Binding
Update is stored by the mobile node in its Binding Update List entry Update is stored by the mobile node in its Binding Update List entry
for that destination; the last Sequence Number value received from for that destination; the last Sequence Number value received from
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
skipping to change at page 25, line 29 skipping to change at page 27, line 29
care-of address in the binding (Section 8.9). care-of address in the binding (Section 8.9).
The Binding Acknowledgement option is encoded in type-length-value The Binding Acknowledgement option is encoded in type-length-value
(TLV) format as follows: (TLV) format as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Option Type | | Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Sequence Number | | Option Length | Status |AuthData Length| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh | | Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Authentication Data (variable length) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
7 7
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
skipping to change at page 26, line 19 skipping to change at page 28, line 26
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
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 138 Duplicate Address Detection failed
139 No security association
140 Mobile Router Prefix Length Sub-Option Rejected
141 Sequence number too small
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" [26]. the most recent "Assigned Numbers" [26].
Sequence Number AuthDataLength
The length of the Authentication Data field in octets.
Sequence #
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
The granted lifetime, in seconds, for which this node will The granted lifetime, in seconds, for which this node will
attempt to retain the entry for this mobile node in its Binding attempt to retain the entry for this mobile node in its Binding
skipping to change at page 26, line 45 skipping to change at page 29, line 7
serving as the mobile node's home agent, the Lifetime period serving as the mobile node's home agent, the Lifetime period
also indicates the period for which this node will continue also indicates the period for which this node will continue
this service; if the mobile node requires home agent service this service; if the mobile node requires home agent service
from this node beyond this period, the mobile node MUST send a from this node beyond this period, the mobile node MUST send a
new Binding Update to it before the expiration of this period new Binding Update to it before the expiration of this period
(even if it is not changing its primary care-of address), in (even if it is not changing its primary care-of address), in
order to extend the lifetime. The value of this field is order to extend the lifetime. The value of this field is
undefined if the Status field indicates that the Binding Update undefined if the Status field indicates that the Binding Update
was rejected. was rejected.
Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that, in combination
with the destination IP address, uniquely identifies the
BSA for this datagram. The set of SPI values in the range
1 through 255 are reserved by the Internet Assigned Numbers
Authority (IANA) for future use; a reserved SPI value will not
normally be assigned by IANA unless the use of the assigned
SPI value is specified in an RFC. It is ordinarily selected by
the destination system upon establishment of an SA (see the
Security Architecture document for more details).
The SPI value of zero (0) is reserved for local,
implementation- specific use and MUST NOT be sent on
the wire.
Refresh Refresh
The recommended interval, in seconds, at which the mobile The recommended interval, in seconds, at which the mobile
node SHOULD send a new Binding Update to this node in order node SHOULD send a new Binding Update to this node in order
to "refresh" the mobile node's binding in this node's Binding to "refresh" the mobile node's binding in this node's Binding
Cache. This refreshing of the binding is useful in case the Cache. This refreshing of the binding is useful in case the
node fails and loses its cache state. The Refresh period is node fails and loses its cache state. The Refresh period is
determined by the node sending the Binding Acknowledgement determined by the node sending the Binding Acknowledgement
(the node caching the binding). If this node is serving as (the node caching the binding). If this node is serving as
the mobile node's home agent, the Refresh value may be set, the mobile node's home agent, the Refresh value may be set,
skipping to change at page 27, line 15 skipping to change at page 29, line 45
node sending the Binding Acknowledgement is not serving as the node sending the Binding Acknowledgement is not serving as the
mobile node's home agent, the Refresh period SHOULD be set mobile node's home agent, the Refresh period SHOULD be set
equal to the Lifetime period in the Binding Acknowledgement; equal to the Lifetime period in the Binding Acknowledgement;
even if this node loses this cache entry due to a failure of even if this node loses this cache entry due to a failure of
the node, packets from it can still reach the mobile node the node, packets from it can still reach the mobile node
through the mobile node's home agent, causing a new Binding through the mobile node's home agent, causing a new Binding
Update to this node to allow it to recreate this cache entry. Update to this node to allow it to recreate this cache entry.
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.
Authentication Data
This is a variable-length field that contains the
Authentication Data necessary to secure this Binding Update.
The field must be an integral multiple of 32 bits in length.
The details of the authentication data computation are
described in Section 4.4. This field may include explicit
padding, depending upon the requirements of the algorithm
selected by the SPI.
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. Currently, no valid sub-options are
sub-options are described in Section 5.5. Currently, no valid defined for a Binding Acknowledgement option.
sub-options are defined for a Binding Acknowledgement option.
The alignment requirement [6] for the Binding Acknowledgement option The alignment requirement [6] for the Binding Acknowledgement option
is 4n+3. is 4n+3.
Any packet that includes a Binding Acknowledgement option MUST Any packet that includes a Binding Acknowledgement option MUST
be protected by IPsec [13] to guard against malicious Binding contain authentication data to guard against malicious Binding
Acknowledgements. The specific requirements for this protection are Updates. The computation for this authentication data must follow
defined in Section 4.4. the rules in Section 4.4.
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
and MUST use this entry (which includes the care-of address received Cache and MUST use this entry (which includes the care-of address
in the Binding Update) in sending the packet containing the Binding received in the Binding Update) in sending the packet containing the
Acknowledgement to the mobile node. The details of sending this Binding Acknowledgement to the mobile node. The details of sending
packet to the mobile node are the same as for sending any packet to this packet (using a Routing header) to the mobile node are the same
a mobile node using a binding, as are described in Section 8.9. The as for sending any packet to a mobile node using a binding, as are
packet is sent using a Routing header, routing the packet to the described in Section 8.9.
mobile node by way of its care-of address recorded in the Binding
Cache entry.
If the node returning the Binding Acknowledgement instead If the node returning the Binding Acknowledgement instead
rejected the Binding Update (the value of the Status field in the rejected the Binding Update (the value of the Status field in the
Acknowledgement is greater than or equal to 128), this node MUST Acknowledgement is greater than or equal to 128), this node MUST
similarly use a Routing header in sending the packet containing the similarly use a Routing header in sending the packet containing the
Binding Acknowledgement, as described in Section 8.9, but MUST NOT Binding Acknowledgement, as described in Section 8.9, but MUST NOT
use its Binding Cache in forming the IP header or Routing header use its Binding Cache in forming the IP header or Routing header
in this packet. Rather, the care-of address used by this node in in this packet. Rather, the care-of address used by this node in
sending the packet containing the Binding Acknowledgement MUST be sending the packet containing the Binding Acknowledgement MUST be
copied from the care-of address received in the rejected Binding copied from the care-of address received in the rejected Binding
skipping to change at page 29, line 5 skipping to change at page 31, line 9
extension header in the packet set to indicate "No Next Header" [6]). 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 [6]. 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.
If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the
home agent MUST send back a Binding Acknowledgement with status code
141, and the last accepted sequence number in the Sequence Number
field of the Binding Acknowledgement.
5.3. Binding Request Option 5.3. Binding Request Option
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
MAY be included in any existing packet being sent to the mobile MAY be included in any existing packet being sent to the mobile
node or MAY be sent in a packet by itself; a packet containing a node or MAY be sent in a packet by itself; a packet containing a
Binding Request option is sent in the same way as any packet to a Binding Request option is sent in the same way as any packet to a
mobile node (Section 8.9). When a mobile node receives a packet mobile node (Section 8.9). When a mobile node receives a packet
containing a Binding Request option, it SHOULD return a Binding containing a Binding Request option, it SHOULD return a Binding
Update (Section 5.1) to the source of the Binding Request. Update (Section 5.1) to the source of the Binding Request.
skipping to change at page 32, line 11 skipping to change at page 35, line 11
Home Address Home Address
The home address of the mobile node sending the packet. The home address of the mobile node sending the packet.
Sub-Options 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. Currently, no valid sub-options are defined for use
described in Section 5.5. Currently, no valid sub-options are in a Home Address option.
defined for use in a Home Address option.
The alignment requirement [6] 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.
skipping to change at page 35, line 32 skipping to change at page 38, line 32
Pad1 Sub-Option (alignment requirement: none) Pad1 Sub-Option (alignment requirement: none)
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 | | 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 sub-option is a special NOTE! the format of the Pad1 sub-option is a special
case -- it does not have Sub-Option Len and Sub-Option Data case -- it has neither Sub-Option Len nor Sub-Option Data
fields. fields.
The Pad1 sub-option is used to insert one octet of padding The Pad1 sub-option is used to insert one octet of padding
into the Sub-Options area of a Mobile IPv6 option. If more into the Sub-Options area of a Mobile IPv6 option. If more
than one octet of padding is required, the PadN sub-option, than one octet of padding is required, the PadN sub-option,
described next, should be used, rather than multiple Pad1 described next, should be used, rather than multiple Pad1
sub-options. sub-options.
PadN Sub-Option (alignment requirement: none) PadN Sub-Option (alignment requirement: none)
skipping to change at page 36, line 21 skipping to change at page 39, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.8). mobile node is away from home (Section 9.6).
Alternate Care-of Address Sub-Option (alignment requirement: 8n+6) Mobile Router Prefix Length Sub-Option (alignment requirement:
2n+1)
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 |x|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile Router Prefix Length Sub-Option is valid only
in the Binding Update destination option. The Prefix
Length field contains a 7-bit value that serves to notify
the recipient that the care-of address may be used for
delivery of packets to any home address whose initial
Prefix-Length address bits match the corresponding bits of
the home address reported in the Home Address destination
option, which MUST also be present in the same message.
See section 4.8 for a discussion about the use of this
Sub-Option.
If a node receives the Mobile Router Prefix Length
Sub-Option, and it cannot carry out the necessary matching
operations with relevant Binding Cache entries, the node
MUST return a Binding Acknowledgement message including
status code 140.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 16 | | 4 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Alternate Care-of Address + + Alternate Care-of Address +
| | | |
skipping to change at page 37, line 9 skipping to change at page 41, line 9
The Alternate Care-of Address sub-option is valid only in The Alternate Care-of Address sub-option is valid only in
Binding Update destination options. The Alternate Care-of Binding Update destination options. The Alternate Care-of
Address field contains an address to use as the care-of Address field contains an address to use as the care-of
address for the binding, rather than using the Source address for the binding, rather than using the Source
Address of the packet as the care-of address. Address of the packet as the care-of address.
5.6. ICMP Home Agent Address Discovery Request Message 5.6. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Sections 9.2 and 10.7. The mobile mechanism, as described in Sections 9.8 and 10.8. The mobile
node sends a Home Agent Address Discovery Request message to the node sends a Home Agent Address Discovery Request message to the
"Mobile IPv6 Home-Agents" anycast address for its own home subnet "Mobile IPv6 Home-Agents" anycast address for its own home subnet
prefix [10], and one of the home agents there responds to the mobile 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 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. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
skipping to change at page 39, line 5 skipping to change at page 42, line 26
message packet MUST be one of the mobile node's current care-of message packet MUST be one of the mobile node's current care-of
addresses, and the mobile node MUST NOT include a Home Address addresses, and the mobile node MUST NOT include a Home Address
option in this packet; the home agent then MUST return the Home option in this packet; the home agent then MUST return the Home
Agent Address Discovery Reply message directly to this care-of Agent Address Discovery Reply message directly to this care-of
address. These restrictions are necessary, since at the time of address. These restrictions are necessary, since at the time of
performing this dynamic home agent address discovery, the mobile node performing this dynamic home agent address discovery, the mobile node
is generally not registered with its home agent; using the mobile is generally not registered with its home agent; using the mobile
node's care-of address simplifies the return of the Reply message to node's care-of address simplifies the return of the Reply message to
the mobile node. the mobile node.
If the mobile node does not have a home address, then the Home
Address field MUST be set to the unspecified address (0::0).
5.7. ICMP Home Agent Address Discovery Reply Message 5.7. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a 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 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. address discovery mechanism, as described in Sections 9.8 and 10.8.
The mobile node sends a Home Agent Address Discovery Request message The mobile node sends a Home Agent Address Discovery Request message
to the "Mobile IPv6 Home-Agents" anycast address for its own home 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 subnet prefix [10], and one of the home agents there responds to the
mobile node with a Home Agent Address Discovery Reply message giving 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 a list of the routers on the mobile node's home link serving as home
agents. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 5 skipping to change at page 45, line 5
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 Addresses Home Agent Addresses
A list of addresses of home agents on the home link for the A list of addresses of home agents on the home link for the
mobile node. The number of addresses present in the list is mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message. the Home Agent Address Discovery Reply message.
5.8. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node
to its home agent while it is away from home. The purpose of the
message is to solicit a Mobile Prefix Advertisement from the home
agent, which will allow the mobile node to gather prefix information
about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [27],
or update address(es) according to changes in prefix information
supplied by the home agent.
The Mobile Prefix Solicitation is similar to the Router Solicitation
used in Neighbor Discovery [17], except it is routed from the mobile
node on the visited network to the home agent on the home network by
usual unicast routing rules.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The mobile node's care-of address.
Destination Address
The address of the mobile node's home agent. This home agent
must be on the link which the mobile node wishes to learn
prefix information about.
Hop Limit
Set to an initial hop limit value, and this message is routed
according to the rules of a typical unicast packet. A hop
limit of 64 is currently suggested [26].
Authentication Header
If a Security Association for the IP Authentication Header
exists between the sender and the destination address, then the
sender SHOULD include this header. [subject to change]
ICMP Fields:
Type
<To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
5.9. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message to a
mobile node to distribute prefix information about the home link
while the mobile node is traveling away from the home network. This
will occur in response to a Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according to
the rules in Section 5.9.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The home agent's address as the mobile node would
expect to see it (i.e. same prefix)
Destination Address
If this message is a response to a Mobile Prefix
Solicitation, the Source Address field from that
packet. For unsolicited messages, the mobile node's
care-of address SHOULD be used, if it is currently
registered with the home agent. Otherwise, the
mobile node's home address SHOULD be used.
Authentication Header
This header MUST be sent, unless the mobile node
has not yet configured, and is using its care-of
address. [subject to change]
ICMP Fields:
Type
<To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Options:
Prefix Information
Each message contains one or more Prefix Information options,
which contain the prefix(es) the mobile node should configure
its home address(es) with. Section 9.6 describes which
prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2
of [17], with modifications defined in Section 6.2 of this
specification. The home agent MUST use this modified Prefix
Information option to send the aggregate list of home network
prefixes as defined in Section 9.8.1.
The Mobile Prefix Advertisement sent by the home agent MAY include
the Source Link-layer Address option defined in RFC 2461 [17], or the
Advertisement Interval option specified in Section 6.3.
Future versions of this protocol may define new option types. Home
Agents MUST silently ignore any options they do not recognize and
continue processing the message.
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 [17] by the addition of a single flag bit to indicate that message [17] by the addition of a single flag bit to indicate that
the router sending the Advertisement message is serving as a home the router sending the Advertisement message is serving as a home
agent on this link. The format of the Router Advertisement message agent on this link. The format of the Router Advertisement message
is as follows: is as follows:
skipping to change at page 42, line 14 skipping to change at page 50, line 14
6.2. Modified Prefix Information Option Format 6.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address for two Mobile IPv6 requires knowledge of a router's global address for two
reasons: reasons:
- To allow a home agent (a router) to learn the address of all - To allow a home agent (a router) to learn the address of all
other home agents on the link for which it is 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.8 and 10.8).
- To allow a mobile node to send a Binding Update to a router on - To allow a mobile node to send a Binding Update to a router on
the link on which its previous care-of address is located, for the link on which its previous care-of address is located, for
purposes of establishing forwarding from this previous care-of purposes of establishing forwarding from this previous care-of
address to its new care-of address (Section 10.9). address to its new care-of address (Section 10.10).
However, Neighbor Discovery [17] 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:
skipping to change at page 43, line 24 skipping to change at page 51, line 24
leading number Prefix bits specified by the Prefix Length leading number Prefix bits specified by the Prefix Length
field. Interpretation of this flag bit is thus independent field. Interpretation of this flag bit is thus independent
of the processing required for the On-Link (L) and Autonomous of the processing required for the On-Link (L) and Autonomous
Address-Configuration (A) flag bits. Address-Configuration (A) flag bits.
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the 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 home agent MUST, and all other
one Prefix Information option with the Router Address (R) bit set. routers SHOULD, include at least one Prefix Information option with
Neighbor Discovery specifies that, if including all options in a the Router Address (R) bit set. Neighbor Discovery specifies that,
Router Advertisement causes the size of the Advertisement to exceed if including all options in a Router Advertisement causes the size of
the link MTU, multiple Advertisements can be sent, each containing the Advertisement to exceed the link MTU, multiple Advertisements can
a subset of the options [17]. In this case, at least one of these be sent, each containing a subset of the options [17]. In this case,
multiple Advertisements being sent instead of a single larger at least one of these multiple Advertisements being sent instead
solicited Advertisement, MUST include a Prefix Information option of a single larger solicited Advertisement, MUST include a Prefix
with the Router Address (R) bit set. Information option 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
set. set.
6.3. New Advertisement Interval Option Format 6.3. New Advertisement Interval Option Format
skipping to change at page 47, line 41 skipping to change at page 55, line 41
this limit such that routers MAY send unsolicited multicast Router this limit such that routers MAY send unsolicited multicast Router
Advertisements more frequently. In particular, on network interfaces Advertisements more frequently. In particular, on network interfaces
where the router is expecting to provide service to visiting mobile where the router is expecting to provide service to visiting mobile
nodes (e.g., wireless network interfaces), or on which it is serving nodes (e.g., wireless network interfaces), or on which it is serving
as a home agent to one or more mobile nodes (who may return home and as a home agent to one or more mobile nodes (who may return home and
need to hear its Advertisements), the router SHOULD be configured need to hear its Advertisements), the router SHOULD be configured
with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value,
to allow sending of unsolicited multicast Router Advertisements more to allow sending of unsolicited multicast Router Advertisements more
often. Recommended values for these limits are: often. Recommended values for these limits are:
- MinRtrAdvInterval 0.5 seconds - MinRtrAdvInterval 0.05 seconds
- MaxRtrAdvInterval 1.5 seconds - MaxRtrAdvInterval 1.5 seconds
Use of these modified limits MUST be configurable, and specific Use of these modified limits MUST be configurable, and specific
knowledge of the type of network interface in use SHOULD be taken knowledge of the type of network interface in use SHOULD be taken
into account in configuring these limits for each network interface. into account in configuring these limits for each network interface.
When sending unsolicited multicast Router Advertisements more When sending unsolicited multicast Router Advertisements more
frequently than the standard limit on unsolicited multicast frequently than the standard limit on unsolicited multicast
Advertisement frequency, the sending router need not include all Advertisement frequency, the sending router need not include all
skipping to change at page 50, line 45 skipping to change at page 58, line 45
- Every IPv6 router SHOULD be able to send an Advertisement - Every IPv6 router SHOULD be able to send an Advertisement
Interval option in its Router Advertisements, to aid movement Interval option in its Router Advertisements, to aid movement
detection by mobile nodes. The use of this option in Router detection by mobile nodes. The use of this option in Router
Advertisements MUST be configurable. Advertisements MUST be configurable.
- Every IPv6 router SHOULD be able to support sending unsolicited - Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in multicast Router Advertisements at the faster rate described in
Section 6.5. The use of this faster rate MUST be configurable. Section 6.5. The use of this faster rate MUST be configurable.
- each router SHOULD include at least one prefix with the 'R' bit
set and with its full IP address in its router advertisements.
7.3. Requirements for IPv6 Home Agents 7.3. Requirements for IPv6 Home Agents
In order for a mobile node to operate correctly while away from home, In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function at least one IPv6 router on the mobile node's home link must function
as a home agent for the mobile node. The following additional as a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers capable of serving as a home requirements apply to all IPv6 routers capable of serving as a home
agent: agent:
- Every home agent MUST be able to maintain an entry in its Binding - Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as the home Cache for each mobile node for which it is serving as the home
skipping to change at page 51, line 33 skipping to change at page 59, line 35
Acknowledge (A) bit set. Acknowledge (A) bit set.
- Every home agent MUST maintain a separate Home Agents List for - Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in each link on which it is serving as a home agent, as described in
Section 4.6. Section 4.6.
- Every home agent MUST be able to accept packets addressed to - Every home agent MUST be able to accept packets addressed to
the "Mobile IPv6 Home-Agents" anycast address for the subnet the "Mobile IPv6 Home-Agents" anycast address for the subnet
on which it is serving as a home agent [10], and MUST be on which it is serving as a home agent [10], and MUST be
able to participate in dynamic home agent address discovery able to participate in dynamic home agent address discovery
(Section 9.2). (Section 9.8).
- 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.
- Every home agent SHOULD support sending ICMP Mobile
Prefix Advertisements, and SHOULD respond to Mobile Prefix
Solicitations.
7.4. Requirements for IPv6 Mobile Nodes 7.4. Requirements for IPv6 Mobile Nodes
Finally, the following requirements apply to all IPv6 nodes capable Finally, the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes: of functioning as mobile nodes:
- Every IPv6 mobile node MUST be able to perform IPv6 - Every IPv6 mobile node MUST be able to perform IPv6
decapsulation [4]. decapsulation [4].
- Every IPv6 mobile node MUST support sending Binding Update - Every IPv6 mobile node MUST support sending Binding Update
options, as specified in Sections 10.6, 10.8, and 10.9; and MUST options, as specified in Sections 10.7, 10.9, and 10.10; and MUST
be able to receive and process Binding Acknowledgement options, be able to receive and process Binding Acknowledgement options,
as specified in Section 10.12. as specified in Section 10.13.
- Every IPv6 mobile node MUST support use of the dynamic home agent - Every IPv6 mobile node MUST support use of the dynamic home agent
address discovery mechanism, as described in Section 10.7. address discovery mechanism, as described in Section 10.8.
- Every IPv6 mobile node MUST maintain a Binding Update List in - Every IPv6 mobile node MUST maintain a Binding Update List in
which it records the IP address of each other node to which it which it records the IP address of each other node to which it
has sent a Binding Update, for which the Lifetime sent in that has sent a Binding Update, for which the Lifetime sent in that
binding has not yet expired. binding has not yet expired.
- Every IPv6 mobile node MUST support receiving a Binding Request - Every IPv6 mobile node MUST support receiving a Binding Request
option, by responding with a Binding Update option. option, by responding with a Binding Update option.
- Every IPv6 mobile node MUST support sending packets containing a - Every IPv6 mobile node MUST support sending packets containing a
Home Address option; this option MUST be included in all packets Home Address option; this option MUST be included in all packets
sent while away from home, if the packet would otherwise have sent while away from home, if the packet would otherwise have
been sent with the mobile node's home address as the IP Source been sent with the mobile node's home address as the IP Source
Address. Address.
- Every IPv6 mobile node MUST maintain a Home Agents List, as - Every IPv6 mobile node MUST maintain a Home Agents List, as
described in Section 4.6. described in Section 4.6.
- Every mobile node MUST support receiving Mobile Prefix
Advertisements and reconfiguring its home address based on the
prefix information contained therein.
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 53, line 40 skipping to change at page 61, line 40
a packet, the use of the care-of address and Home Address option is a packet, the use of the care-of address and Home Address option is
transparent to both the mobile node and the correspondent node above transparent to both the mobile node and the correspondent node above
the level of the Home Address option generation and processing. the level of the Home Address option generation and processing.
8.2. Receiving Binding Updates 8.2. Receiving Binding Updates
Upon receiving a Binding Update option in some packet, the receiving Upon receiving a Binding Update option in some packet, the receiving
node MUST validate the Binding Update according to the following node MUST validate the Binding Update according to the following
tests: tests:
- The packet meets the specific IPsec requirements for Binding - The packet meets the specific authentication requirements for
Updates, defined in Section 4.4. Binding Updates, defined in Section 4.4.
- The packet MUST contain a Home Address option. - The packet MUST contain a Home Address option.
- The Option Length field in the Binding Update option is greater - The Option Length field in the Binding Update option is greater
than or equal to the length specified in Section 5.1. than or equal to the length specified in Section 5.1.
- The Sequence Number field in the Binding Update option is greater - The Sequence Number field in the Binding Update option is greater
than the Sequence Number received in the previous Binding Update than the Sequence Number received in the previous Binding Update
for this home address, if any. As noted in Section 4.6, this for this home address, if any. As noted in Section 4.6, this
Sequence Number comparison MUST be performed modulo 2**16. Sequence Number comparison MUST be performed modulo 2**8.
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.
In this section, the care-of address refers to the IPv6 address, In this section, the care-of address refers to the IPv6 address,
which was originally located in the IPv6 header when the packet was which was originally located in the IPv6 header when the packet was
transmitted by the mobile node. transmitted by the mobile node.
If the Binding Update is valid according to the tests above, then the If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows: Binding Update is processed further as follows:
- If the Lifetime specified in the Binding Update is nonzero and - If the Lifetime specified in the Binding Update is nonzero and
the specified Care-of Address is not equal to the home address the specified Care-of Address is not equal to the home address
for the binding, then this is a request to cache a binding for for the binding, then this is a request to cache a binding for
the mobile node. If the Home Registration (H) bit is set in the 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.1; 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
specified Care-of Address matches the home address for the specified Care-of Address matches the home address for the
binding, then this is a request to delete the mobile node's binding, then this is a request to delete the mobile node's
cached binding. If the Home Registration (H) bit is set in the cached binding. 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.4; otherwise, it is processed procedure specified in Section 9.2; otherwise, it is processed
according to the procedure specified in Section 8.4. according to the procedure specified in Section 8.4.
8.3. Requests to Cache a Binding 8.3. Requests to Cache a Binding
When a node receives a Binding Update, it MUST validate it and When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described determine the type of Binding Update according to the steps described
in Section 8.2. This section describes the processing of a valid in Section 8.2. This section describes the processing of a valid
Binding Update that requests a node to cache a mobile node's binding, Binding Update that requests a node to cache a mobile node's binding,
for which the Home Registration (H) bit is not set in the Binding for which the Home Registration (H) bit is not set in the Binding
Update. Update.
skipping to change at page 55, line 40 skipping to change at page 63, line 40
for the Status field are described in Section 5.2 and in the most for the Status field are described in Section 5.2 and in the most
recent "Assigned Numbers" [26]. recent "Assigned Numbers" [26].
The packet in which the Binding Acknowledgement is returned MUST meet The packet in which the Binding Acknowledgement is returned MUST meet
the specific IPsec requirements for Binding Acknowledgements, defined the specific IPsec requirements for Binding Acknowledgements, defined
in Section 4.4; and the packet MUST be sent using a Routing header in Section 4.4; and the packet MUST be sent using a Routing header
in the same way as any other packet sent to a mobile node using a in the same way as any other packet sent to a mobile node using a
care-of address (even if the binding was rejected), as described in care-of address (even if the binding was rejected), as described in
Section 8.9. Section 8.9.
In response to a Binding Update, a node MAY send a Binding
Acknowledgement even when the 'A' bit is not set in the Binding
Update. This would happen, for instance, if a mobile node attempted
to send a Binding Update with the 'H' bit set to a correspondent
node.
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
expires. If such an entry is still in active use in sending packets expires. If such an entry is still in active use in sending packets
to a mobile node, the next packet sent to the mobile node will be to a mobile node, the next packet sent to the mobile node will be
routed normally to the mobile node's home link, where it will be routed normally to the mobile node's home link, where it will be
intercepted and tunneled to the mobile node. The mobile node will intercepted and tunneled to the mobile node. The mobile node will
then return a Binding Update to the sender, allowing it to create then return a Binding Update to the sender, allowing it to create
a new Binding Cache entry for sending future packets to the mobile a new Binding Cache entry for sending future packets to the mobile
node. Communication with the mobile node continues uninterrupted, node. Communication with the mobile node continues uninterrupted,
but the forwarding of this packet through the mobile node's home but the forwarding of this packet through the mobile node's home
agent creates additional overhead and latency in delivering packets agent creates additional overhead and latency in delivering packets
to the mobile node. to the mobile node. Such routing paths could, for instance,
temporarily or permanently disrupt any negotiated Quality of Service
reservations which had been made by the mobile node on its home
network.
If the sender knows that the Binding Cache entry is still in active If the sender knows that the Binding Cache entry is still in active
use, it MAY send a Binding Request option to the mobile node in use, it MAY send a Binding Request option to the mobile node in
an attempt to avoid this overhead and latency due to deleting and an attempt to avoid this overhead and latency due to deleting and
recreating the Binding Cache entry. Since a Binding Request is a recreating the Binding Cache entry. Since a Binding Request is a
destination option, it may, for example, be included in any packet destination option, it may, for example, be included in any packet
already being sent to the mobile node, such as a packet that is part already being sent to the mobile node, such as a packet that is part
of ongoing TCP communication with the mobile node. When the mobile of ongoing TCP communication with the mobile node. When the mobile
node receives a packet from some sender containing a Binding Request node receives a packet from some sender containing a Binding Request
option, it returns a Binding Update option to that sender, giving its option, it returns a Binding Update option to that sender, giving its
skipping to change at page 56, line 30 skipping to change at page 64, line 38
which the entry was created or last updated. Conceptually, a node which the entry was created or last updated. Conceptually, a node
maintains a separate timer for each entry in its Binding Cache. When maintains a separate timer for each entry in its Binding Cache. When
creating or updating a Binding Cache entry in response to a received creating or updating a Binding Cache entry in response to a received
and accepted Binding Update, the node sets the timer for this entry and accepted Binding Update, the node sets the timer for this entry
to the specified Lifetime period. When a Binding Cache entry's timer to the specified Lifetime period. When a Binding Cache entry's timer
expires, the node deletes the entry. expires, the node deletes the entry.
Each node's Binding Cache will, by necessity, have a finite size. Each node's Binding Cache will, by necessity, have a finite size.
A node MAY use any reasonable local policy for managing the space A node MAY use any reasonable local policy for managing the space
within its Binding Cache, except that any entry marked as a "home within its Binding Cache, except that any entry marked as a "home
registration" (Section 9.3) MUST NOT be deleted from the cache until registration" (Section 9.1) MUST NOT be deleted from the cache until
the expiration of its lifetime period. When attempting to add a new the expiration of its lifetime period. When attempting to add a
"home registration" entry in response to a Binding Update with the new "home registration" entry in response to a Binding Update with
Home Registration (H) bit set, if insufficient space exists (and the Home Registration (H) bit set, if insufficient space exists
sufficient space cannot be reclaimed) in the node's Binding Cache, (and sufficient space cannot be reclaimed) in the node's Binding
the node MUST reject the Binding Update and SHOULD return a Binding Cache, the node MUST reject the Binding Update and SHOULD return a
Acknowledgement to the sending mobile node, in which the Status field Binding Acknowledgement to the sending mobile node, in which the
is set to 131 (insufficient resources). When otherwise attempting to Status field is set to 131 (insufficient resources). When otherwise
add a new entry to its Binding Cache, a node MAY, if needed, choose attempting to add a new entry to its Binding Cache, a node MAY, if
to drop any entry already in its Binding Cache, other than a "home needed, choose to drop any entry already in its Binding Cache, other
registration" entry, in order to make space for the new entry. For than a "home registration" entry, in order to make space for the new
example, a "least-recently used" (LRU) strategy for cache entry entry. For example, a "least-recently used" (LRU) strategy for cache
replacement among entries not marked as a "home registration" is entry replacement among entries not marked as a "home registration"
likely to work well. is likely to work well unless the size of the Binding Cache is
substantially insufficient.
Any binding dropped from a node's Binding Cache due to lack of cache Any binding dropped from a node's Binding Cache due to lack of cache
space will be rediscovered and a new cache entry created, if the space will be rediscovered and a new cache entry created, if the
binding is still in active use by the node for sending packets. If binding is still in active use by the node for sending packets. If
the node sends a packet to a destination for which it has dropped the the node sends a packet to a destination for which it has dropped the
entry from its Binding Cache, the packet will be routed normally, entry from its Binding Cache, the packet will be routed normally,
leading to the mobile node's home link. There, the packet will be leading to the mobile node's home link. There, the packet will be
intercepted by the mobile node's home agent and tunneled to the intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address. As when a Binding mobile node's current primary care-of address. As when a Binding
Cache entry is initially created, this indirect routing to the mobile Cache entry is initially created, this indirect routing to the mobile
skipping to change at page 57, line 24 skipping to change at page 65, line 35
address in the binding recorded in the Binding Cache entry. Any ICMP address in the binding recorded in the Binding Cache entry. Any ICMP
error message caused by the packet on its way to the mobile node will error message caused by the packet on its way to the mobile node will
be returned normally to the correspondent node. be returned normally to the correspondent node.
On the other hand, if the correspondent node has no Binding Cache On the other hand, if the correspondent node has no Binding Cache
entry for the mobile node, the packet will be routed to the mobile entry for the mobile node, the packet will be routed to the mobile
node's home link. There, it will be intercepted by the mobile node's node's home link. There, it will be intercepted by the mobile node's
home agent, encapsulated, and tunneled to the mobile node's primary home agent, encapsulated, and tunneled to the mobile node's primary
care-of address. Any ICMP error message caused by the packet on care-of address. Any ICMP error message caused by the packet on
its way to the mobile node while in the tunnel, will be transmitted its way to the mobile node while in the tunnel, will be transmitted
to the mobile node's home agent (the source of the tunnel). By the to the mobile node's home agent (the source of the tunnel). By
definition of IPv6 encapsulation [4], this encapsulating node MUST the definition of IPv6 encapsulation [4], the home agent (as the
relay certain ICMP error messages back to the original sender of the encapsulating node) MUST relay certain ICMP error messages back
packet, which in this case is the correspondent node. to the original sender of the packet, which in this case is the
correspondent node.
Likewise, if a packet for a mobile node arrives at the mobile node's Likewise, if a packet for a mobile node arrives at the mobile node's
previous link and is intercepted there by a home agent for the mobile previous link and is intercepted there by a home agent for the mobile
node's previous care-of address as described in Section 10.9 (e.g., node's previous care-of address as described in Section 10.10 (e.g.,
the mobile node moved after the packet was sent), that home agent the mobile node moved after the packet was sent), that home agent
will encapsulate and tunnel the packet to the mobile node's new will encapsulate and tunnel the packet to the mobile node's new
care-of address. As above, any ICMP error message caused by the care-of address. As above, any ICMP error message caused by the
packet while in this tunnel will be returned to that home agent (the packet while in this tunnel will be returned to that home agent (the
source of the tunnel), which MUST relay certain ICMP error messages source of the tunnel), which MUST relay certain ICMP error messages
back to the correspondent node [4]. back to the correspondent node [4]. The relayed packet MUST NOT
contain a routing header entry with the care-of address of the mobile
node.
Thus, in all cases, any meaningful ICMP error messages caused Thus, in all cases, any meaningful ICMP error messages caused
by packets from a correspondent node to a mobile node will be by packets from a correspondent node to a mobile node will be
returned to the correspondent node. If the correspondent node returned to the correspondent node. If the correspondent node
receives persistent ICMP Destination Unreachable messages after receives persistent ICMP Destination Unreachable messages after
sending packets to a mobile node based on an entry in its Binding sending packets to a mobile node based on an entry in its Binding
Cache, the correspondent node SHOULD delete this Binding Cache Cache, the correspondent node MUST delete this Binding Cache
entry. If the correspondent node subsequently transmits another entry. If the correspondent node subsequently transmits another
packet to the mobile node, the packet will be routed to the mobile packet to the mobile node, the packet will be routed to the mobile
node's home link, intercepted by the mobile node's home agent, and node's home link, intercepted by the mobile node's home agent, and
tunneled to the mobile node's primary care-of address using IPv6 tunneled to the mobile node's primary care-of address using IPv6
encapsulation. The mobile node will then return a Binding Update to encapsulation. The mobile node will then return a Binding Update to
the correspondent node, allowing it to recreate a (correct) Binding the correspondent node, allowing it to recreate a (correct) Binding
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
skipping to change at page 58, line 53 skipping to change at page 67, line 14
If, instead, the sending node has no Binding Cache entry for the If, instead, the sending node has no Binding Cache entry for the
destination address to which the packet is being sent, the sending destination address to which the packet is being sent, the sending
node simply sends the packet normally, with no Routing header. If node simply sends the packet normally, with no Routing header. If
the destination node is not a mobile node (or is a mobile node that the destination node is not a mobile node (or is a mobile node that
is currently at home), the packet will be delivered directly to this is currently at home), the packet will be delivered directly to this
node and processed normally by it. If, however, the destination node node and processed normally by it. If, however, the destination node
is a mobile node that is currently away from home, the packet will is a mobile node that is currently away from home, the packet will
be intercepted by the mobile node's home agent and tunneled (using be intercepted by the mobile node's home agent and tunneled (using
IPv6 encapsulation [4]) to the mobile node's current primary care-of IPv6 encapsulation [4]) to the mobile node's current primary care-of
address, as described in Section 9.6. The mobile node will then send address, as described in Section 9.4. The mobile node will then send
a Binding Update to the sending node, as described in Section 10.8, a Binding Update to the sending node, as described in Section 10.9,
allowing the sending node to create a Binding Cache entry for its use allowing the sending node to create a Binding Cache entry for its use
in sending subsequent packets to this mobile node. in sending subsequent packets to this mobile node.
9. Home Agent Operation 9. Home Agent Operation
9.1. Receiving Router Advertisement Messages 9.1. Primary Care-of Address Registration
For each link on which a router provides service as a home agent, the
router maintains a Home Agents List recording information about all
other home agents on that link. This list is used in the dynamic
home agent address discovery mechanism, described in Section 9.2.
The information for the list is learned through receipt of the
periodic unsolicited multicast Router Advertisements from each other
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
maintained by each host for Neighbor Discovery [17].
On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [17], the home
agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery:
- 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 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 MUST 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 home agent'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 home
agent's Home Agents List, reset its lifetime and preference to
the values determined above.
- If the link-local address of the home agent sending this
Advertisement, as determined above, is not already present in
the Home Agents List maintained by the receiving home agent, and
the lifetime for the sending home agent, as determined above,
is non-zero, create a new entry in the list, and initialize its
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 home agent 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.
9.2. Dynamic Home Agent Address Discovery
A mobile node, while away from home, MAY use the dynamic home agent
address discovery mechanism to attempt to discover the address of
one or more routers serving as home agents on its home link. This
discovery may be necessary, for example, if some nodes on its home
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
agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the "Mobile IPv6 Home-Agents" anycast
address [10] for its home IP subnet prefix, using its care-of address
as the Source Address of the packet. A home agent receiving such a
Home Agent Address Discovery Request message that is serving this
subnet (the home agent is configured with this anycast address on one
of its network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), with the
Source Address of the Reply packet set to one of the global unicast
addresses of the home agent. The Home Agent Addresses field in the
Reply message is constructed as follows:
- The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home
agent's own Home Agents List (Section 4.6). However, if this
home agent's own global IP address would be placed in the list
(as described below) as the first entry in the list, then this
home agent SHOULD NOT include its own address in the Home Agent
Addresses field in the Reply message. Not placing this home
agent's own IP address in the list will cause the receiving
mobile node to consider this home agent as the most preferred
home agent; otherwise, this home agent will be considered to be
preferred in its order given by its place in the list returned.
- The IP addresses in the Home Agent Addresses field SHOULD be
listed in order of decreasing preference value, based either
on the respective advertised preference from a Home Agent
Information option or on the default preference of 0 if no
preference is advertised (or on the configured home agent
preference for this home agent itself). The home agent with
the highest preference SHOULD be listed first in the Home Agent
Addresses field, and the home agent with the lowest preference
SHOULD be listed last.
- Among home agents with equal preference, their IP addresses
in the Home Agent Addresses field SHOULD be listed in an
order randomized with respect to other home agents with equal
preference, each time a Home Agent Address Discovery Reply
message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected to
include in the Home Agent Addresses field in the Reply message.
As described in Section 4.6, one Home Agents List entry,
identified by the home agent's link-local address, exists for
each home agent on the link; associated with that list entry is
one or more global IP addresses for this home agent, learned
through Prefix Information options with the Router Address (R)
bit is set, received in Router Advertisements from this
link-local address. The selected global IP address for each home
agent to include in forming the Home Agent Addresses field in the
Reply message MUST be the global IP address of the respective
home agent sharing a prefix with the mobile node's home address
as indicated in the Home Address option in the Request message;
if no such global IP address is known for some home agent, an
entry for that home agent MUST NOT be included in the Home Agent
Addresses field in the Reply message.
- In order to avoid the possibility of the Reply message packet
being fragmented (or rejected by an intermediate router with an
ICMP Packet Too Big message [5]), if the resulting total packet
size containing the complete list of home agents in the Home
Agent Addresses field would exceed the minimum IPv6 MTU [6], 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.
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
the following sequence of tests: the following sequence of tests:
skipping to change at page 63, line 47 skipping to change at page 68, line 49
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 - Finally, if the Duplicate Address Detection (D) bit is set in
the Binding Update, this home agent MUST perform Duplicate the Binding Update, this home agent MUST perform Duplicate
Address Detection [27] on the mobile node's home link for the Address Detection [27] on the mobile node's home link for the
home address in this binding (before returning the Binding home address in this binding (before returning the Binding
Acknowledgement); if the Prefix Length field is nonzero in the Acknowledgement); if the 7-bit Prefix Length field is nonzero
Binding Update, the home agent MAY choose to perform Duplicate in the Binding Update, the home agent SHOULD perform Duplicate
Address Detection for only one of the addresses formed from the Address Detection for only one of the addresses formed from the
interface identifier for this binding, and if so, the address interface identifier for this binding, and if so, the address
used for Duplicate Address Detection SHOULD be the mobile used for Duplicate Address Detection SHOULD be the mobile node's
node's link-local address. Normal processing for Duplicate link-local address. Normal processing for Duplicate Address
Address Detection specifies that, in certain cases, the node Detection specifies that, in certain cases, the node SHOULD
SHOULD delay sending the initial Neighbor Solication message delay sending the initial Neighbor Solicitation message of
of Duplicate Address Detection by a random delay between 0 and Duplicate Address Detection by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the MAX_RTR_SOLICITATION_DELAY [17, 27]; however, in this case, the
home agent SHOULD NOT perform such a delay. If this Duplicate home agent SHOULD NOT perform such a delay. If this Duplicate
Address Detection fails, then the home agent MUST reject the Address Detection fails, then the home agent MUST reject the
Binding Update and SHOULD return a Binding Acknowledgement to the Binding Update and SHOULD return a Binding Acknowledgement to the
mobile node, in which the Status field is set to 138 (Duplicate mobile node, in which the Status field is set to 138 (Duplicate
Address Detection failed). 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, then it becomes
above, then it becomes the home agent for the mobile node. The new or remains the home agent for the mobile node. The home agent MUST
home agent (the receiving node) MUST then create a new entry in its then create a new entry in its Binding Cache for this mobile node (or
Binding Cache for this mobile node (or update its existing Binding update its existing Binding Cache entry for this mobile node, if such
Cache entry for this mobile node, if such an entry already exists) an entry already exists). The home address of the mobile node is
The home address of the mobile node is taken to be the value which, taken to be the value which, when the packet was originally received,
when the packet was originally received, was located in the Home was located in the Home Address field in the packet's Home Address
Address field in the packet's Home Address option. The care-of option. The care-of address for this Binding Cache entry is taken
address for this Binding Cache entry is taken to be the value which, to be the value which, when the packet was originally received, was
when the packet was originally received, was located either in the located either in the Alternate Care-of Address sub-option in the
Alternate Care-of Address sub-option in the Binding Update option, Binding Update option, if present, or from the Source Address field
if present, or from the Source Address field in the packet's IPv6 in the packet's IPv6 header, otherwise.
header, otherwise.
The home agent MUST mark this Binding Cache entry as a "home The home agent MUST mark this Binding Cache entry as a "home
registration" to indicate that the node is serving as a home registration" to indicate that the node is serving as a home
agent for this binding. Binding Cache entries marked as a "home agent for this binding. Binding Cache entries marked as a "home
registration" MUST be excluded from the normal cache replacement registration" MUST be excluded from the normal cache replacement
policy used for the Binding Cache (Section 8.7) and MUST NOT be policy used for the Binding Cache (Section 8.7) and MUST NOT be
removed from the Binding Cache until the expiration of the Lifetime removed from the Binding Cache until the expiration of the Lifetime
period. period.
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
the remaining valid lifetime for the subnet prefix in the mobile remaining valid lifetime for the subnet prefix in the mobile node's
node's home address specified with the Binding Update, and MUST NOT home address specified with the Binding Update, and MUST NOT be
be greater than the Lifetime value specified in the Binding Update. greater than the Lifetime value specified in the Binding Update. The
The remaining valid lifetime for this prefix is determined by the remaining valid lifetime for this prefix is determined by the home
home agent based on its own Prefix List entry for this prefix [17]. agent based on its own Prefix List entry for this prefix [17].
Furthermore, if the Prefix Length field in the Binding Update is
nonzero, then the lifetime for the Binding Cache entry MUST NOT be If the 7-bit Prefix Length field in the Binding Update is nonzero,
greater than the minimum remaining valid lifetime for all subnet the Home Agent creates or updates Binding Cache entries for each of
prefixes on the mobile node's home link. If the value of the possible several home addresses. The set of such home addresses
Lifetime field specified by the mobile node in its Binding Update is is formed by replacing the routing prefix (as determined by the
greater than this prefix lifetime, the home agent MUST decrease the Prefix Length field value) with all other routing prefixes that are
binding lifetime to less than or equal to the prefix valid lifetime. supported by the home agent processing the Binding Update. The Home
The home agent MAY further decrease the specified lifetime for the Agent creates such a separate primary care-of address registration
binding, for example based on a local policy implemented by the home for each such home address. Furthermore, if the 7-bit Prefix
agent. The resulting lifetime is stored by the home agent in the Length field in the Binding Update is nonzero, then the lifetime for
Binding Cache entry, and this Binding Cache entry MUST be deleted by the each Binding Cache entry MUST NOT be greater than the minimum
the home agent after the expiration of this lifetime. remaining valid lifetime for all subnet prefixes on the mobile
node's home link. If the value of the Lifetime field specified by
the mobile node in its Binding Update is greater than this prefix
lifetime, the home agent MUST decrease the binding lifetime to less
than or equal to the prefix valid lifetime. The home agent MAY
further decrease the specified lifetime for the binding, for example
based on a local policy. The resulting lifetime is stored by the
home agent in the Binding Cache entry, and this Binding Cache entry
MUST be deleted by the home agent after the expiration of this
lifetime.
The Prefix Length in the Binding Update MUST also be saved in the The Prefix Length in the Binding Update MUST also be saved in the
Binding Cache entry. Binding Cache entry.
The home agent MUST return a Binding Acknowledgement to the mobile Regardless of the setting of the 'A' bit in the Binding Update, the
node, constructed as follows: home agent MUST return a Binding Acknowledgement to the mobile node,
constructed as follows:
- The Status field MUST be set to a value indicating success (the - The Status field MUST be set to a value indicating success; this
value MUST be less than 128). The only currently defined success value MUST be less than 128. The only currently defined success
Status value is 0, indicating simply that the Binding Update was Status value is 0, indicating simply that the Binding Update was
accepted. accepted.
- The Sequence Number field MUST be copied from the Sequence Number - The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update. given in the Binding Update.
- The Lifetime field MUST be set to the remaining lifetime for - The Lifetime field MUST be set to the remaining lifetime for
the binding as set by the home agent in its "home registration" the binding as set by the home agent in its "home registration"
Binding Cache entry for the mobile node. As described above, Binding Cache entry for the mobile node, as described above.
this lifetime MUST NOT be greater than the remaining valid
lifetime for the subnet prefix in the mobile node's home address.
- The Refresh field MUST be set to a value less than or equal to - The Refresh field MUST be set to a value less than or equal to
the Lifetime value being returned in the Binding Update. If the the Lifetime value being returned in the Binding Update. If the
home agent stores the Binding Cache entry in nonvolatile storage home agent stores the Binding Cache entry in nonvolatile storage
(that survives the crash or other failure of the home agent), (that survives the crash or other failure of the home agent),
then the Refresh field SHOULD be set to the same value as the then the Refresh field SHOULD be set to the same value as the
Lifetime field; otherwise, the home agent MAY set the Refresh Lifetime field; otherwise, the home agent MAY set the Refresh
field to a value less than the Lifetime field, to indicate that field to a value less than the Lifetime field, to indicate that
the mobile node SHOULD attempt to refresh its home registration the mobile node SHOULD attempt to refresh its home registration
at the indicated shorter interval (although the home agent will at the indicated shorter interval (although the home agent will
still retain the registration for the Lifetime period, even if still retain the registration for the Lifetime period, even if
the mobile node does not refresh its registration within the the mobile node does not refresh its registration within the
Refresh period). Refresh period).
In addition, the home agent MUST follow the procedure defined in In addition, the home agent MUST follow the procedure defined in
Section 9.5 to intercept packets on the mobile node's home link Section 9.3 to intercept packets on the mobile node's home link
addressed to the mobile node, while the home agent is serving as the addressed to the mobile node, while the home agent is serving as the
home agent for this mobile node. home agent for this mobile node.
9.4. Primary Care-of Address De-registration 9.2. Primary Care-of Address De-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 no longer serve as Binding Update that requests the receiving node to no longer serve as
its home agent, de-registering its primary care-of address. its home agent, de-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
the following test: the following test:
- If the receiving node has no entry in its Binding Cache for this - If the receiving node has no entry in its Binding Cache for this
mobile node that is marked as a "home registration", then this mobile node that is marked as a "home registration", then this
node MUST reject the Binding Update and SHOULD return a Binding node MUST reject the Binding Update and SHOULD return a Binding
Acknowledgement to the mobile node, in which the Status field is Acknowledgement to the mobile node, in which the Status field is
set to 137 (not home agent for this mobile node). set to 137 (not home agent for this mobile node).
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 MUST delete any existing entry in its Binding Cache above, then it MUST delete any existing entry in its Binding Cache
for this mobile node. for this mobile node, and proceed as follows.
If the Acknowledge (A) bit is set in the Binding Update (it SHOULD The home agent MUST return a Binding Acknowledgement to the mobile
be), then the home agent MUST return a Binding Acknowledgement to the node, constructed as follows:
mobile node, constructed as follows:
- The Status field MUST be set to a value indicating success (the - The Status field MUST be set to a value indicating success (the
value MUST be less than 128). The only currently defined success value MUST be less than 128). The only currently defined success
Status value is 0, indicating simply that the Binding Update was Status value is 0, indicating simply that the Binding Update was
accepted. accepted.
- The Sequence Number field MUST be copied from the Sequence Number - The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update. given in the Binding Update.
- The Lifetime field MUST be set to zero. - The Lifetime field MUST be set to zero.
- The Refresh field MUST be set to zero. - The Refresh field MUST be set to zero.
In addition, the home agent MUST stop intercepting packets on the In addition, the home agent MUST stop intercepting packets on the
mobile node's home link addressed to the mobile node (Section 9.5). mobile node's home link addressed to the mobile node (Section 9.3).
9.5. Intercepting Packets for a Mobile Node 9.3. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for mobile node (while the While a node is serving as the home agent for mobile node (while the
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 begins serving as the home agent for some mobile node (it did not
have a Binding Cache entry for this mobile node marked as a "home already have a Binding Cache entry for this mobile node marked as a
registration"), then the home agent MUST multicast onto the home link "home registration"), then the home agent MUST multicast onto the
a "gratuitous" Neighbor Advertisement message [17] on behalf of the home link a "gratuitous" Neighbor Advertisement message [17] on
mobile node. Specifically, the home agent performs the following behalf of the mobile node. Specifically, the home agent performs the
steps: following 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
skipping to change at page 68, line 7 skipping to change at page 73, line 17
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 [17]. 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 [17] Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] to
to intercept unicast packets on the home link addressed the mobile intercept unicast packets on the home link addressed to 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, and reply
any received Neighbor Solicitation messages for it. When a home to 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
corresponding link-local address and site-local address), if the corresponding link-local address and site-local address), if the
Prefix Length in the Binding Cache entry for this mobile node (from Prefix Length in the Binding Cache entry for this mobile node (from
the Binding Update that created this Cache entry) is nonzero. the Binding Update that created this Cache entry) is nonzero.
skipping to change at page 68, line 33 skipping to change at page 73, line 43
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 defend these addresses on the address, and allows the home agent to defend these addresses on the
home link for Duplicate Address Detection [17]. home link for Duplicate Address Detection [17].
9.6. Tunneling Intercepted Packets to a Mobile Node 9.4. 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.3. 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 [11] or ESP [12] 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 In order to forward 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. When a home agent encapsulates
node itself). When a home agent encapsulates an intercepted packet an intercepted packet for forwarding to the mobile node, the home
for forwarding to the mobile node, the home agent sets the Source agent sets the Source Address in the prepended tunnel IP header to
Address in the prepended tunnel IP header to the home agent's own IP the home agent's own IP address, and sets the Destination Address
address, and sets the Destination Address in the tunnel IP header in the tunnel IP header to the mobile node's primary care-of
to the mobile node's primary care-of address. When received by the address. When received by the mobile node (using its primary care-of
mobile node (using its primary care-of address), normal processing of address), normal processing of the tunnel header [4] will result in
the tunnel header [4] will result in decapsulation and processing of decapsulation and processing of the original packet by the mobile
the original packet by the mobile node. node.
However, packets addressed to the mobile node's link-local address However, packets addressed to the mobile node's link-local address
MUST NOT be tunneled to the mobile node. Instead, such a packet MUST MUST NOT be tunneled to the mobile node. Instead, such a packet MUST
be discarded, and the home agent SHOULD return an ICMP Destination be discarded, and the home agent SHOULD return an ICMP Destination
Unreachable, Code 3, message to the packet's Source Address (unless Unreachable, Code 3, message to the packet's Source Address (unless
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 incompletely defined in IPv6, and this default
might change at some point in the future. behavior 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 [9], 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) [9], 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 more completely defined in IPv6.
9.7. Handling Reverse Tunneled Packets from a Mobile Node 9.5. Handling Reverse Tunneled Packets from a Mobile Node
A home agent MUST support decapsulating reverse tunneled packets A home agent MUST support decapsulating reverse tunneled packets
sent to it from a mobile node. Such reverse tunneled packets MAY be sent to it from a mobile node's home address. Such reverse tunneled
discarded unless accompanied by a valid AH. This support for reverse packets MAY be discarded unless accompanied by a valid AH. This
tunneling allows mobile nodes to defeat certain kinds of traffic support for reverse tunneling allows mobile nodes to defeat certain
analysis. Requiring AH on reverse tunneled packets allows the home kinds of traffic analysis. Requiring AH on reverse tunneled packets
agent to protect the home network against unwarranted intrusions by allows the home agent to protect the home network against unwarranted
malicious nodes masquerading as a mobile node with a home address on intrusions by malicious nodes masquerading as a mobile node with a
the network served by the home agent. home address on the network served by the home agent.
9.8. Renumbering the Home Subnet 9.6. Home Prefix Propagation
IPv6 provides mechanisms through Neighbor Discovery [17] and Address IPv6 provides mechanisms as part of Neighbor Discovery [17] and
Autoconfiguration [27] to aid in renumbering a subnet, such as when a Address Autoconfiguration [27] to aid in mobile node configuration
site switches to a new network service provider. In renumbering, new when a mobile node turns on, and in renumbering a subnet, such as
prefixes and addresses can be introduced for the subnet and old ones when a site switches to a new network service provider.
can be deprecated and removed. These mechanisms are defined to work
while all nodes using the old prefixes are at home, connected to the
link using these prefixes. Mobile IPv6 extends these mechanisms for
the case in which one or more mobile nodes using the old prefixes are
away from home while the renumbering takes place.
The IPv6 renumbering mechanisms are based on nodes on the link In renumbering, new prefixes and addresses can be introduced for the
receiving Prefix Information options in Router Advertisement subnet and old ones can be deprecated and removed. These mechanisms
messages giving the valid lifetime and preferred lifetime for are defined to work while all nodes using the old prefixes are at
different prefixes on the link [17]. Mobile IPv6 arranges to home, connected to the link using these prefixes. Mobile IPv6
tunnel certain Router Advertisements giving "important" Prefix extends these mechanisms for the case in which one or more mobile
Information options to mobile nodes while away from home. To avoid nodes using the old prefixes are away from home and registered at the
the need to tunnel all Router Advertisements from the home link to home agent while the renumbering takes place.
a mobile node away from home, those Router Advertisements that are
tunneled to the mobile node are retransmitted until acknowledged. To
avoid possible security attacks from forged Router Advertisements
tunneled to the mobile node, all such tunneled Router Advertisements
must be authenticated to the mobile node by its home agent using
IPsec [13, 11, 12].
9.8.1. Building Aggregate List of Home Network Prefixes In the IPv6 renumbering mechanism, nodes on the visited link receive
Mobile Prefix Advertisements messages with Prefix Information
Options, which give the valid lifetime and preferred lifetime for
available prefixes on the link [17].
A mobile node on a remote network SHOULD autoconfigure the same Mobile IPv6 arranges to propagate relevant prefix information
set of home addresses it would autoconfigure if it were attached to the mobile node when it is away from home, so that it may be
to the home network. To support this, the home agent monitors used in mobile node home address configuration, and in network
prefixes advertised by other routers on the home subnet and passes renumbering. To avoid possible security attacks from forged Mobile
the aggregate list of home subnet prefixes on to the mobile node in Prefix Advertisements all such Advertisements must be authenticated
Router Advertisements. to the mobile node by its home agent using IPsec [13, 11, 12] if a
security associate exists (i.e. unless the mobile node does not yet
have a home address configured).
9.7. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent, the
router maintains a Home Agents List recording information about all
other home agents on that link. This list is used in the dynamic
home agent address discovery mechanism, described in Section 9.8.
The information for the list is learned through receipt of the
periodic unsolicited multicast Router Advertisements from each other
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
maintained by each host for Neighbor Discovery [17].
On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [17], the home
agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery:
- 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 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 MUST 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 home agent'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 home
agent's Home Agents List, reset its lifetime and preference to
the values determined above.
- If the link-local address of the home agent sending this
Advertisement, as determined above, is not already present in
the Home Agents List maintained by the receiving home agent, and
the lifetime for the sending home agent, as determined above,
is non-zero, create a new entry in the list, and initialize its
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 home agent 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.
9.8. Dynamic Home Agent Address Discovery
A mobile node, while away from home, MAY use the dynamic home agent
address discovery mechanism in section 10.8 to attempt to discover
the address of one or more routers serving as home agents on its home
link. This discovery might become necessary, for example, if some
nodes on its home 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.8, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the "Mobile IPv6 Home-Agents" anycast
address [10] for its home IP subnet prefix, using its care-of address
as the Source Address of the packet. A home agent receiving such a
Home Agent Address Discovery Request message that is serving this
subnet (the home agent is configured with this anycast address on one
of its network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), with the
Source Address of the Reply packet set to one of the global unicast
addresses of the home agent. The Home Agent Addresses field in the
Reply message is constructed as follows:
- The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home
agent's own Home Agents List (Section 4.6). However, if this
home agent's own global IP address would be placed in the list
(as described below) as the first entry in the list, then this
home agent SHOULD NOT include its own address in the Home Agent
Addresses field in the Reply message. Not placing this home
agent's own IP address in the list will cause the receiving
mobile node to consider this home agent as the most preferred
home agent; otherwise, this home agent will be considered to be
preferred in its order given by its place in the list returned.
- The IP addresses in the Home Agent Addresses field SHOULD be
listed in order of decreasing preference value, based either
on the respective advertised preference from a Home Agent
Information option or on the default preference of 0 if no
preference is advertised (or on the configured home agent
preference for this home agent itself). The home agent with
the highest preference SHOULD be listed first in the Home Agent
Addresses field, and the home agent with the lowest preference
SHOULD be listed last.
- Among home agents with equal preference, their IP addresses
in the Home Agent Addresses field SHOULD be listed in an
order randomized with respect to other home agents with equal
preference, each time a Home Agent Address Discovery Reply
message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected
to include in the Home Agent Addresses field in the Reply
message. As described in Section 4.6, one Home Agents List
entry, identified by the home agent's link-local address,
exists for each home agent on the link; associated with that
list entry is one or more global IP addresses for this home
agent, learned through Prefix Information options with the
Router Address (R) bit is set, received in Router Advertisements
from this link-local address.
The selected global IP address for each home agent to include in
forming the Home Agent Addresses field in the Reply message MUST
be the global IP address of the respective home agent sharing a
prefix with the Destination IP address of the Request message;
if no such global IP address is known for some home agent, an
entry for that home agent MUST NOT be included in the Home Agent
Addresses field in the Reply message.
- In order to avoid the possibility of the Reply message packet
being fragmented (or rejected by an intermediate router with an
ICMP Packet Too Big message [5]), if the resulting total packet
size containing the complete list of home agents in the Home
Agent Addresses field would exceed the minimum IPv6 MTU [6], 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.
9.8.1. Aggregate List of Home Network Prefixes
A mobile node on a remote network SHOULD autoconfigure all of the
global IP addresses, which it would autoconfigure if it were attached
to its home network, from network prefixes representing network
addresses that are served by home agents. Site-local addresses MAY
be autoconfigured if the mobile node is roaming in a network on the
same site as its home addresses. Site-local addresses and addresses
not served by a home agent MUST NOT be autoconfigured, since they are
unusable in the remote network.
To support this, the home agent monitors prefixes advertised by
itself and other home agents routers on the home link, and passes
this aggregated list of relevant subnet prefixes on to the mobile
node in Mobile Prefix Advertisements.
The home agent SHOULD construct the aggregate list of home subnet The home agent SHOULD construct the aggregate list of home subnet
prefixes as follows: prefixes as follows:
- Copy prefix information defined in the home agent's AdvPrefixList - Copy prefix information defined in the home agent's AdvPrefixList
on the home subnet's interfaces to the aggregate list. Also on the home subnet's interfaces to the aggregate list. Also
apply any changes made to the AdvPrefixList on the home agent to apply any changes made to the AdvPrefixList on the home agent to
the aggregate list. the aggregate list.
- Check valid prefixes received in Router Advertisements - Check valid prefixes received in Router Advertisements
from the home network for consistency with the home agent's from the home network for consistency with the home agent's
AdvPrefixList, as specified in section 6.2.7 of RFC 2461 AdvPrefixList, as specified in section 6.2.7 of RFC 2461
(Neighbor Discovery [17]). Do not update the aggregate list with (Neighbor Discovery [17]). Do not update the aggregate list with
any information from received prefixes that fail this check. any information from received prefixes that fail this check.
- Add valid prefixes received in Router Advertisements from the - Check Router Advertisements which contain an `H' bit (from other
home network that are not yet in the aggregate list to the home agents) for valid prefixes that are not yet in the aggregate
aggregate list along with the value of their L and A flags. list, and if they are usable for autoconfiguration (`A' bit set,
Clear the R flag and zero the interface-id portion of the prefix and prefix length is valid for address autoconfiguration on the
field to prevent mobile nodes from treating another router's home subnet) add them and preserve the `L' flag value. Clear the
interface address as belonging to the home agent. Treat the `R' flag and zero the interface-id portion of the prefix field
lifetimes of these prefixes as "deprecating". to prevent mobile nodes from treating another router's interface
address as belonging to the home agent. Treat the lifetimes
of these prefixes as decrementing in real time, as defined in
section 6.2.7 of RFC 2461 [17].
- Do not perform consistency checks on valid prefixes received in - Do not perform consistency checks on valid prefixes received in
Router Advertisements on the home network that do not exist in Router Advertisements on the home network that do not exist in
the home agent's AdvPrefixList. Instead, if the prefixes already the home agent's AdvPrefixList. Instead, if the prefixes already
exist in the aggregate list, update the prefix lifetime fields in exist in the aggregate list, update the prefix lifetime fields in
the aggregate list according to the rules specified for hosts in the aggregate list according to the rules specified for hosts in
section 6.3.4 of RFC 2461 (Neighbor Discovery [17]) and section section 6.3.4 of RFC 2461 (Neighbor Discovery [17]) and section
5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [27]). 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [27]).
- If the L or A flag is set on valid prefixes received in a Router - If the L flag is set on valid prefixes received in a Router
Advertisement, and that prefix already exists in the aggregate Advertisement, and that prefix already exists in the aggregate
list, set the corresponding flag in the aggregate list. Ignore list, set the flag in the aggregate list. Ignore the flag if it
the received L or A flag if it is clear. is clear.
- Ignore the R flag and interface id portion of any prefix received
in a Router Advertisement.
- Delete prefixes from the aggregate list when their valid - Delete prefixes from the aggregate list when their valid
lifetimes expire. lifetimes expire.
The home agent uses the information in the aggregate list to The home agent uses the information in the aggregate list to
construct Router Advertisements, possibly including Binding construct Mobile Prefix Advertisements, possibly including Binding
Acknowledgement or Binding Request destination options, for delivery Acknowledgement or Binding Request destination options, for delivery
to a mobile node for which it is maintaining a current binding. to a mobile node for which it is maintaining a current binding.
It may be possible to construct an aggregate list by combining
information contained in the home agent's AdvPrefixList and its
Home Agent List used for Dynamic Home Agent Address Discovery
(Section 10.8).
9.8.2. Sending Changed Prefix Information to the Mobile Node 9.8.2. Scheduling Prefix Deliveries to the Mobile Node
A home agent serving some mobile node MUST schedule the delivery of A home agent serving a mobile node will schedule the delivery of new
new prefix information to the mobile node when any of the following prefix information to that mobile node when any of the following
conditions occur: conditions occur:
- A valid or preferred lifetime of a prefix in the aggregate list MUST:
of prefixes changes.
- The state of the flags for a prefix in the aggregate list
changes.
- A new prefix is introduced on the home link. - The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address
changes
- The mobile node requests the information with a Router - The mobile node requests the information with a Router
Solicitation (see section 10.16). Solicitation (see section 10.16).
The home agent determines these conditions based on its own MAY:
configuration as a router and based on the Router Advertisements that
it receives on the home link.
The home agent uses the following algorithm to determine when to send
prefix information to the mobile node.
- If a mobile node sends a solicitation, answer with everything.
- If a prefix changes state in a way that causes a mobile node's
address to go deprecated, send an advertisement right away.
- For any existing previx, if the mobile node's binding expires - A new prefix is added to the aggregate list
before the advertised Preferred Lifetime, do not schedule the
advertisement. The mobile node will get the revised information
in its next Binding Acknowledgement.
- If a prefix is added, or if it changes in any way that does not - The valid or preferred lifetime or the state of the flags changes
cause the mobile node's address to go deprecated, ensure that a for a prefix which is not used in any binding cache entry for
transmission is scheduled at time RAND_ADV_DELAY in the future. this mobile node
- If a prefix advertisement is scheduled, and a Binding Update The home agent uses the following algorithm to determine when to send
arrives, perform that advertisement and include the information prefix information to the mobile node.
in a Router Advertisement that has the Binding Acknowledgement as
a Destination Option. Remove the future scheduled advertisement.
The home agent uses the following algorithm to compute - If the mobile node has not received the prefix information within
RAND_ADV_DELAY, the offset from the current time for the the last HomeRtrAdvInterval seconds, then transmit the prefix
information. This MAY be done according to a periodically
scheduled transmission. scheduled transmission.
If there is a transmission already scheduled, then - If a mobile node sends a solicitation, answer right away.
if the current RAND_ADV_DELAY would cause another - If a prefix in the aggregate list that matches the mobile
transmission BEFORE the Preferred Lifetime of the node's home registration is added, or if its information changes
mobile node's home address derived from the prefix whose in any way that does not cause the mobile node's address to
advertisement information has changed, then go deprecated, ensure that a transmission is scheduled, and
calculate RAND_ADV_DELAY in order to randomize the time at which
the transmission is scheduled.
add the new information to be transmitted to the - If there are any uncknowledged changes to prefix information when
existing scheduled transmission -- return. a Binding Update arrives for the home registration, send a Mobile
Prefix Advertisement to the mobile node immediately. The Mobile
Prefix Advertisement SHOULD have the Binding Acknowledgement as a
Destination Option. If an advertisement was previously scheduled
for the mobile node, cancel that advertisement.
otherwise, - If a home registration expires, cancel any scheduled
advertisements to the mobile node.
continue with the following computation, and add the If the home agent already has scheduled the transmission of a Router
data from the existing scheduled transmission to the Advertisement to the mobile node, and if the freshly calculated
newly scheduled transmission, deleting the previously RAND_ADV_DELAY would cause another transmission BEFORE the Preferred
scheduled transmission event. Lifetime of the mobile node's home address derived from the prefix
whose advertisement information has changed, then add the new
information to be transmitted to the existing scheduled transmission.
In this case, the home agent does not perform the following algorithm
to schedule an advertisement to the mobile node.
If the mobile node's binding expires after the Preferred Lifetime, Otherwise, the home agent uses the following algorithm to compute
then compute a fresh value for RAND_ADV_DELAY, the offset from the current time
MAX_SCHEDULE_DELAY == for the scheduled transmission. If there is already a scheduled
min (MAX_PFX_ADV_DELAY, Preferred Lifetime) transmission, add the data from the existing scheduled transmission
to the newly scheduled transmission, deleting the previously
scheduled transmission event.
If the mobile node's binding expires before the Preferred Lifetime,
then return. The mobile node will get the revised information wth
its next Binding Acknowledgement. Otherwise, continue with the
following computation.
MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
for the newly advertised Preferred Lifetime. for the newly advertised Preferred Lifetime.
Then compute RAND_ADV_DELAY =
Then compute RAND_ADV_DELAY ==
MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt)
9.8.3. Tunneling Router Advertisements to the Mobile Node RAND_ADV_DELAY is the offset from the current time to be used
to schedule the necessary advertisement to the mobile node. The
computation is expected to alleviate bursts of advertisements when
prefix information changes. In addition, a home agent MAY further
reduce the rate of packet transmission by further delaying individual
advertisements, if needed to avoid overwhelming local network
resources.
When tunneling a Router Advertisement to the mobile node, the home 9.8.3. Sending Advertisements to the Mobile Node
agent MUST construct the packet as follows:
- The Source Address in the packet's IPv6 header MUST be set to the When sending a Mobile Prefix Advertisement to the mobile node, the
home agent's IP address to which the mobile node addressed its home agent MUST construct the packet as follows:
current home registration.
- The packet MUST be protected by IPsec [13, 11, 12] to guard - The Source Address in the packet's IPv6 header MUST be set to
against malicious Router Advertisements. The IPsec protection the home agent's IP address to which the mobile node addressed
MUST provide sender authentication, data integrity protection, its current home registration, or its default global home agent
and replay protection, covering the Router Advertisement. address if no binding exists.
- The packet MUST include a Binding Request destination option. - If a security association exists with the mobile node's address,
the packet MUST be protected by IPsec [13, 11, 12] to guard
against malicious Mobile Prefix Advertisements. The IPsec
protection MUST provide sender authentication, data integrity
protection, and replay protection, covering the Mobile Prefix
Advertisement.
- The Binding Request destination option MUST include a Unique - The advertisement MUST include a Binding Request destination
Identifier Sub-Option (Section 5.5), with the unique identifier option if this is the first advertisement for a home
in the sub-option data set to a value different than that in registration, or if there was a change in prefix information
any other Binding Request sent recently by this node. The word since the last acknowledged advertisement was sent to the mobile
"recently" here means within the maximum likely lifetime of a node for the home registration. The Binding Request destination
packet, including transit time from source to destination and option MUST include a Unique Identifier Sub-Option (Section 5.5),
time spent awaiting reassembly with other fragments of the same with the unique identifier in the sub-option data set to a value
packet, if fragmented. However, it is not required that a source different than that in any other Binding Request sent recently by
node know the maximum packet lifetime. Rather, it is assumed this home agent. It is assumed that this requirement can be met
that the requirement can be met by maintaining a simple 16-bit by maintaining a simple 16-bit "wrap-around" counter to generate
"wrap-around" counter to generate unique identifiers for Binding unique identifiers for Binding Requests that contain a Unique
Requests that contain a Unique Identifier Sub-Option, incremented Identifier Sub-Option, incremented each time a Binding Request
each time a Binding Request containing a Unique Identifier containing a Unique Identifier Sub-Option is sent.
Sub-Option is sent.
- The packet MUST be tunneled to the mobile node's primary care-of - If the advertisement was solicited, it should be destined
address using a Routing header, in the same way as any packet (and authenticated, if possible) to the source address of
sent to the mobile node originated by the home agent (rather than the solicitation. If it was triggered by prefix changes or
using IPv6 encapsulation, as would be used by the home agent for renumbering, the advertisement's destination will be the mobile
intercepted packets). node's home address in the binding which triggered the rule.
The home agent SHOULD periodically continue to retransmit this - The packet MUST be sent as any other unicast IPv6 packet. If a
tunneled packet to the mobile node, until it is acknowledged by care-of address is used, the packet will be delivered directly.
the receipt from the mobile node of a Binding Update matching If a binding exists, the home agent will send the packet with
the Binding Request in the packet (i.e., with matching Sequence a routing header containing the care-of address, as any other
Number). A Binding Update matches a Binding Request if it specifies packet sent to the mobile node originated by the home agent
a binding for the mobile node to which the Binding Request was sent (rather than using IPv6 encapsulation, as would be used by the
home agent for intercepted packets).
The home agent SHOULD periodically continue to retransmit an
unsolicited Advertisement to the mobile node, until it is
acknowledged by the receipt from the mobile node of a Binding Update
matching the Binding Request in the packet (i.e., with matching
Sequence Number). The home agent MUST wait PREFIX_ADV_TIMEOUT
before the first retransmission, and double the retransmission wait
time for every succeeding retransmission, up until a maximum of
PREFIX_ADV_RETRIES attempts. If the mobile node's bindings expire
before the matching Binding Update has been received, then the home
agent MUST NOT attempt any more retransmissions, even if not all
PREFIX_ADV_RETRIES have been retransmitted. After another Binding
Update is received from the mobile node, and if the mobile node has
not returned to the home network in the meantime, the home agent
SHOULD begin the process again of transmitting the unsolicited
Advertisement.
A Binding Update matches a Binding Request if it specifies a
binding for the mobile node to which the Binding Request was sent
and contains a Unique Identifier Sub-Option matching the unique and contains a Unique Identifier Sub-Option matching the unique
identifier sent in the Unique Identifier Sub-Option in the Binding identifier sent in the Unique Identifier Sub-Option in the Binding
Request. Request. In the solicited case, the mobile node will retransmit
solicitations until one is received; thus, the home agent SHOULD NOT
retransmit the responding advertisement.
If while the home agent is still retransmitting a Router If while the home agent is still retransmitting a Mobile Prefix
Advertisement to the mobile node, another condition as described Advertisement to the mobile node, another condition as described
above occurs on the home link causing another Router Advertisement above occurs on the home link causing another Prefix Advertisement to
to be tunneled to the mobile node, the home agent SHOULD combine any be sent to the mobile node, the home agent SHOULD combine any Prefix
Prefix Information options in the unacknowledged Router Advertisement Information options in the unacknowledged Mobile Prefix Advertisement
into the new Router Advertisement and then begin retransmitting the into the new Advertisement, discard the old Advertisement, and then
new Router Advertisement rather than the old one. When tunneling begin retransmitting the new one. according to the algorithm in
a new Router Advertisement, even if it contains Prefix Information sectino 9.8.2. The home agent MUST generate a new unique identifier
options sent previously in an unacknowledged tunneled Router
Advertisement, the home agent MUST generate a new unique identifer
for use in the Unique Identifier Sub-Option in the Binding Request for use in the Unique Identifier Sub-Option in the Binding Request
tunneled with the new Router Advertisement. tunneled with the new Mobile Prefix Advertisement.
Whenever a mobile node has a valid binding on a network other than
its home network, the home agent MUST tunnel a router advertisement
with all prefixes in the aggregate list to the mobile node at least
once per HomeRtrAdvInterval seconds, and upon receipt of a valid
Router Solicitation from the mobile node.
9.8.4. Lifetimes for Changed Prefixes 9.8.4. Lifetimes for Changed Prefixes
In addition, as described in Section 9.3, the lifetime returned by a As described in Section 9.1, the lifetime returned by the home
mobile node's home agent in its Binding Acknowledgement in response agent in a Binding Acknowledgement MUST be no greater than the
to registration of a new primary care-of address by the mobile node remaining valid lifetime for the subnet prefix in the mobile node's
MUST be no greater than the remaining valid lifetime for the subnet home address. Furthermore, as described in Section 10.9, Binding
prefix in the mobile node's home address. Furthermore, as described Updates sent by the mobile node to other nodes MUST use a lifetime no
in Section 10.8, Binding Updates sent by the mobile node to other greater than the remaining lifetime of its home registration of its
nodes MUST use a lifetime no greater than the remaining lifetime of primary care-of address. These limits on the binding lifetime serve
its home registration of its primary care-of address. These limits to prohibit use of a mobile node's home address after it becomes
on the binding lifetime serve to prohibit use of a mobile node's home invalid. The mobile node SHOULD further limit the lifetimes that it
address after it becomes invalid. The mobile node SHOULD further sends on any Binding Updates to be within the remaining preferred
limit the lifetimes that it sends on any Binding Updates to be within lifetime for the prefix in its home address.
the remaining preferred lifetime for the prefix in its home address.
When the lifetime for a changed prefix decreases, and the change
would cause cached bindings at correspondent nodes in the Binding
Update List to be stored past the newly shortened lifetime, the
mobile ndoe MUST issue a Binding Update to all such correspondent
nodes.
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:
skipping to change at page 77, line 11 skipping to change at page 86, line 11
- 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 [13]. determine what processing is required for the packet [13].
- As a special case for Mobile IP, if a Binding Update or
Binding Acknowledgement is being included in the packet, IPsec
authentication, integrity protection, and replay protection MUST
be applied to the packet [13, 11, 12], as defined in Section 4.4.
If the SPD check above has already indicated that authentication
and replay protection are required, this processing is sufficient
for the Mobile IP requirement that all packets containing Binding
Updates or Binding Acknowledgements be authenticated and covered
by replay protection. Otherwise, an implementation can force
the required IPsec processing on this individual packet by, for
example, 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 Destination Options header in which the Home Section 10.1. The Destination Options header in which the Home
Address option is inserted MUST appear in the packet before the Address option is inserted MUST appear in the packet after the
AH [11] (or ESP [12]) header, so that the Home Address option is Routing Header, if present, and before the AH [11] (or ESP [12])
processed by the destination node (and, possibly, intermediate header, so that the Home Address option is processed by the
routing nodes) before the AH or ESP header is processed. destination node (and, possibly, intermediate routing nodes)
before the AH or ESP header is processed.
- If a Binding Update is being included in the packet, it is - If a Binding Update is being included in the packet, it is
also added to a Destination Options header in the packet. The also added to a Destination Options header in the packet. The
Destination Options header in which the Binding Update option is Destination Options header in which the Binding Update option is
inserted MUST appear after the AH or ESP header. inserted MUST appear after the AH or ESP header.
- 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 authentication data MUST be calculated the AH or ESP header. The authentication data MUST be calculated
skipping to change at page 78, line 14 skipping to change at page 86, line 53
This allows, but does not require, the receiver of the packet This allows, but does not require, the receiver of the packet
containing the Binding Update to exchange the two fields of the containing the Binding Update to exchange the two fields of the
incoming packet, simplifying processing for all subsequent packet incoming packet, simplifying processing for all subsequent packet
headers. The mechanics of implementation do not absolutely headers. The mechanics of implementation do not absolutely
require such an exchange to occur; other implementation require such an exchange to occur; other implementation
strategies may be more appropriate, as long as the result of the strategies may be more appropriate, as long as the result of the
authentication calculation remain the same. authentication calculation remain the same.
In addition, when using any automated key management protocol [13] 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 (such as IKE [8]) to create any new SA (or SA bundle) while away
home (whether due to the inclusion of a Binding Update or Binding from home, a mobile node MUST take special care in its processing of
Acknowledgement in an outgoing packet, or otherwise), a mobile node the key management protocol. Otherwise, other nodes with which the
MUST take special care in its processing of the key management mobile node must communicate as part of the automated key management
protocol. Otherwise, other nodes with which the mobile node protocol processing may be unable to correctly deliver packets to
must communicate as part of the automated key management protocol the mobile node if they and/or the mobile node's home agent do
processing may be unable to correctly deliver packets to the mobile not then have a current Binding Cache entry for the mobile node.
node if they and/or the mobile node's home agent do not then have a For the default case of using IKE as the automated key management
current Binding Cache entry for the mobile node. For the default protocol [8, 13], such problems can be avoided by the following
case of using IKE as the automated key management protocol [8, 13], requirements on the use of IKE by a mobile node while away from home:
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 - The mobile node MUST use its care-of address as the Source
Address of all packets it sends as part of the key management Address of all packets it sends as part of the key management
protocol (without use of Mobile IP for these packets, as protocol (without use of Mobile IP for these packets, as
suggested in Section 10.1). suggested in Section 10.1).
- In addition, for all security associations bound to the mobile - In addition, for all security associations bound to the mobile
node's home address, the mobile node MUST include an ISAKMP node's home address established by way of IKE, the mobile node
Identification Payload [14] in the IKE exchange, giving the MUST include an ISAKMP Identification Payload [14] in the IKE
mobile node's home address as the initiator of the Security exchange, giving the mobile node's home address as the initiator
Association [22]. 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,
skipping to change at page 79, line 14 skipping to change at page 87, line 51
directing the packet to the mobile node's home address; the directing the packet to the mobile node's home address; the
processing of this last hop of the Routing header is entirely processing of this last hop of the Routing header is entirely
internal to the mobile node, since the care-of address and home internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node. address are both addresses within the mobile node.
- Packets sent by a correspondent node that has a Binding Cache - Packets sent by a correspondent node that has a Binding Cache
entry for the mobile node that contains an out-of-date care-of entry for the mobile node that contains an out-of-date care-of
address for the mobile node, will be sent by the correspondent address for the mobile node, will be sent by the correspondent
node using a Routing header, as described above. If the mobile node using a Routing header, as described above. If the mobile
node sent a Binding Update to a home agent on the link on which node sent a Binding Update to a home agent on the link on which
its previous care-of address is located (Section 10.9), and its previous care-of address is located (Section 10.10), and
if this home agent is still serving as a home agent for the if this home agent is still serving as a home agent for the
mobile node's previous care-of address, then such a packet will mobile node's previous care-of address, then such a packet will
be intercepted by this home agent, encapsulated using IPv6 be intercepted by this home agent, encapsulated using IPv6
encapsulation [4], and tunneled to the mobile node's new care-of encapsulation [4], and tunneled to the mobile node's new care-of
address (registered with this home agent). address (registered with this home agent).
For packets received by either the first or last of these three For packets received by either the first or last of these three
methods, the mobile node SHOULD send a Binding Update to the original methods, the mobile node SHOULD send a Binding Update to the original
sender of the packet, as described in Section 10.8, subject to the sender of the packet, as described in Section 10.9, subject to the
rate limiting defined in Section 10.11. The mobile node SHOULD rate limiting defined in Section 10.12. 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 [6], 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
skipping to change at page 80, line 10 skipping to change at page 88, line 43
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 facilities of IPv6 Neighbor Discovery, including Router Discovery and
and Neighbor Unreachability Detection, although the mobile node MAY Neighbor Unreachability Detection, although the mobile node SHOULD
supplement this mechanism with other information available to the supplement this mechanism with other information whenever it is
mobile node (e.g., from lower protocol layers). The description available to the mobile node (e.g., from lower protocol layers). The
here is based on the conceptual model of the organization and data description here is based on the conceptual model of the organization
structures defined by Neighbor Discovery [17]. and data structures defined by Neighbor Discovery [17].
Mobile nodes SHOULD use Router Discovery to discover new routers and Mobile nodes SHOULD use Router Discovery to discover new routers and
on-link subnet prefixes; a mobile node MAY send Router Solicitation on-link subnet prefixes; a mobile node MAY send Router Solicitation
messages, or MAY wait for unsolicited (periodic) multicast Router messages, or MAY wait for unsolicited (periodic) multicast Router
Advertisement messages, as specified for Router Discovery [17]. Advertisement messages, as specified for Router Discovery [17].
Based on received Router Advertisement messages, a mobile node (in Based on received Router Advertisement messages, a mobile node (in
the same way as any other node) maintains an entry in its Default the same way as any other node) maintains an entry in its Default
Router List for each router, and an entry in its Prefix List for each Router List for each router, and an entry in its Prefix List for each
subnet prefix, that it currently considers to be on-link. Each entry subnet prefix, that it currently considers to be on-link. Each entry
in these lists has an associated invalidation timer value (extracted in these lists has an associated invalidation timer value (extracted
from the Router Advertisement and Prefix Information options) used to from the Router Advertisement and Prefix Information options) used to
expire the entry when it becomes invalid. expire the entry when it becomes invalid.
While away from home, a mobile node SHOULD select one router from While away from home, a mobile node SHOULD select one router from
its Default Router List to use as its default router, and one subnet its Default Router List to use as its default router, and one subnet
skipping to change at page 80, line 36 skipping to change at page 89, line 20
from the Router Advertisement and Prefix Information options) used to from the Router Advertisement and Prefix Information options) used to
expire the entry when it becomes invalid. expire the entry when it becomes invalid.
While away from home, a mobile node SHOULD select one router from While away from home, a mobile node SHOULD select one router from
its Default Router List to use as its default router, and one subnet its Default Router List to use as its default router, and one subnet
prefix advertised by that router from its Prefix List to use as prefix advertised by that router from its Prefix List to use as
the subnet prefix in its primary care-of address. A mobile node the subnet prefix in its primary care-of address. A mobile node
MAY also have associated additional care-of addresses, using other MAY also have associated additional care-of addresses, using other
subnet prefixes from its Prefix List. The method by which a mobile subnet prefixes from its Prefix List. The method by which a mobile
node selects and forms a care-of address from the available subnet node selects and forms a care-of address from the available subnet
prefixes is described in Section 10.5. The mobile node registers prefixes is described in Section 10.6. The mobile node registers
its primary care-of address with its home agent, as described in its primary care-of address with its home agent, as described in
Section 10.6. Section 10.7.
While a mobile node is away from home and using some router as its While a mobile node is away from home and using some router as its
default router, it is important for the mobile node to be able to default router, it is important for the mobile node to be able to
quickly detect when that router becomes unreachable, so that it can quickly detect when that router becomes unreachable, so that it can
switch to a new default router and to a new primary care-of address. switch to a new default router and to a new primary care-of address.
Since some links (notably wireless) do not necessarily work equally Since some links (notably wireless) do not necessarily work equally
well in both directions, it is likewise important for the mobile well in both directions, it is likewise important for the mobile
node to detect when it becomes unreachable for packets sent from its node to detect when it becomes unreachable for packets sent from its
default router, so that the mobile node can take steps to ensure that default router, so that the mobile node can take steps to ensure that
any correspondent nodes attempting to communicate with it can still any correspondent nodes attempting to communicate with it can still
skipping to change at page 81, line 22 skipping to change at page 90, line 6
direction of reachability confirmation is needed. Confirmation direction of reachability confirmation is needed. Confirmation
that the mobile node is still reachable from the router is handled that the mobile node is still reachable from the router is handled
separately, as described below. separately, as described below.
For a mobile node to detect when it has become unreachable from its For a mobile node to detect when it has become unreachable from its
default router, the mobile node cannot efficiently rely on Neighbor default router, the mobile node cannot efficiently rely on Neighbor
Unreachability Detection alone, since the network overhead would be Unreachability Detection alone, since the network overhead would be
prohibitively high in many cases for a mobile node to continually prohibitively high in many cases for a mobile node to continually
probe its default router with Neighbor Solicitation messages even probe its default router with Neighbor Solicitation messages even
when it is not otherwise actively sending packets to it. Instead, when it is not otherwise actively sending packets to it. Instead,
a mobile node SHOULD consider receipt of any IPv6 packets from its when a mobile node receives any IPv6 packets from its current default
current default router as an indication that it is still reachable router at all, irrespective of the source IPv6 address, it SHOULD use
from the router. Both packets from the router's IP address and that as an indication that it is still reachable from the router.
(IPv6) packets from its link-layer address (e.g., those forwarded but
not originated by the router) SHOULD be considered.
Since the router SHOULD be sending periodic unsolicited multicast Since the router SHOULD be sending periodic unsolicited multicast
Router Advertisement messages, the mobile node will have frequent Router Advertisement messages, the mobile node will have frequent
opportunity to check if it is still reachable from its default opportunity to check if it is still reachable from its default
router, even in the absence of other packets to it from the router. router, even in the absence of other packets to it from the router.
If Router Advertisements that the mobile node receives include If Router Advertisements that the mobile node receives include
an Advertisement Interval option, the mobile node MAY use its an Advertisement Interval option, the mobile node MAY use its
Advertisement Interval field as an indication of the frequency with Advertisement Interval field as an indication of the frequency with
which it SHOULD expect to continue to receive future Advertisements which it SHOULD expect to continue to receive future Advertisements
from that router. This field specifies the minimum rate (the maximum from that router. This field specifies the minimum rate (the maximum
skipping to change at page 82, line 5 skipping to change at page 90, line 37
be correctly receiving Advertisements. be correctly receiving Advertisements.
On some types of network interfaces, the mobile node MAY also On some types of network interfaces, the mobile node MAY also
supplement this monitoring of Router Advertisements, by setting its supplement this monitoring of Router Advertisements, by setting its
network interface into "promiscuous" receive mode, so that it is able network interface into "promiscuous" receive mode, so that it is able
to receive all packets on the link, including those not link-level to receive all packets on the link, including those not link-level
addressed to it (i.e., disabling link-level address filtering). The addressed to it (i.e., disabling link-level address filtering). The
mobile node will then be able to detect any packets sent by the mobile node will then be able to detect any packets sent by the
router, in order to detect reachability from the router. This use of router, in order to detect reachability from the router. This use of
promiscuous mode may be useful on very low bandwidth (e.g., wireless) promiscuous mode may be useful on very low bandwidth (e.g., wireless)
links, but its use MUST be configurable on the mobile node. links, but its use MUST be configurable on the mobile node since it
is likely to consume additional energy resources.
If the above means do not provide indication that the mobile node is If the above means do not provide indication that the mobile node is
still reachable from its current default router (i.e., the mobile still reachable from its current default router (i.e., the mobile
node receives no packets from the router for a period of time), then node receives no packets from the router for a period of time), then
the mobile node SHOULD attempt to actively probe the router with the mobile node SHOULD attempt to actively probe the router with
Neighbor Solicitation messages, even if it is not otherwise actively Neighbor Solicitation messages, even if it is not otherwise actively
sending packets to the router. If it receives a solicited Neighbor sending packets to the router. If it receives a solicited Neighbor
Advertisement message in response from the router, then the mobile Advertisement message in response from the router, then the mobile
node can deduce that it is still reachable. It is expected that the node can deduce that it is still reachable. It is expected that the
mobile node will in most cases be able to determine its reachability mobile node will in most cases be able to determine its reachability
from the router by listening for packets from the router as described from the router by listening for packets from the router as described
above, and thus, such extra Neighbor Solicitation probes should above, and thus, such extra Neighbor Solicitation probes should
rarely be necessary. rarely be necessary.
With some types of networks, it is possible that additional With some types of networks, indications about link-layer mobility
indications about link-layer mobility can be obtained from might be obtained from lower-layer protocol or device driver software
lower-layer protocol or device driver software within the mobile within the mobile node. However, all link-layer mobility indications
node. However, a mobile node MUST NOT assume that all link-layer from lower layers do not necessarily indicate a movement of the
mobility indications from lower layers indicate a movement of the
mobile node to a new link, such that the mobile node would need to mobile node to a new link, such that the mobile node would need to
switch to a new default router and primary care-of address. For switch to a new default router and primary care-of address. For
example, movement of a mobile node from one cell to another in many example, movement of a mobile node from one cell to another in many
wireless LANs can be made transparent to the IP level through use of wireless LANs can be made transparent to the IP level through use of
a link-layer "roaming" protocol, as long as the different wireless a link-layer "roaming" protocol, as long as the different wireless
LAN cells all operate as part of the same IP link with the same LAN cells all operate as part of the same IP link with the same
subnet prefix. Upon lower-layer indication of link-layer mobility, subnet prefix. Upon lower-layer indication of link-layer mobility,
the mobile node MAY send Router Solicitation messages to determine if the mobile node MAY send Router Solicitation messages to determine if
new routers (and new on-link subnet prefixes) are present on its new new routers (and new on-link subnet prefixes) are present on its new
link. link.
skipping to change at page 82, line 50 skipping to change at page 91, line 31
node is reachable. For example, a mobile node MAY use signal node is reachable. For example, a mobile node MAY use signal
strength or signal quality information (with suitable hysteresis) for strength or signal quality information (with suitable hysteresis) for
its link with the available routers to decide when to switch to a new its link with the available routers to decide when to switch to a new
primary care-of address using that router rather than its current primary care-of address using that router rather than its current
default router (and current primary care-of address). Even though default router (and current primary care-of address). Even though
the mobile node's current default router may still be reachable in the mobile node's current default router may still be reachable in
terms of Neighbor Unreachability Detection, the mobile node MAY use terms of Neighbor Unreachability Detection, the mobile node MAY use
such lower-layer information to determine that switching to a new such lower-layer information to determine that switching to a new
default router would provide a better connection. default router would provide a better connection.
10.5. Forming New Care-of Addresses 10.5. 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.10. 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.
- If the Home Agent (H) bit in the Router Advertisement is not set,
skip all of the following steps. Mobile IPv6 requires no special
processing steps for this Router Advertisement.
- 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 MUST 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.6. Forming New Care-of Addresses
After detecting that it has moved from one link to another (i.e., its After detecting that it has moved from one link to another (i.e., its
current default router has become unreachable and it has discovered current default router has become unreachable and it has discovered
a new default router), a mobile node SHOULD form a new primary a new default router), a mobile node SHOULD form a new primary
care-of address using one of the on-link subnet prefixes advertised care-of address using one of the on-link subnet prefixes advertised
by the new router. A mobile node MAY form a new primary care-of by the new router. A mobile node MAY form a new primary care-of
address at any time, except that it MUST NOT do so too frequently. address at any time, except that it MUST NOT do so too frequently.
Specifically, a mobile node MUST NOT send a Binding Update about a Specifically, a mobile node MUST NOT send a Binding Update about a
new care-of address to its home agent (which is required to register new care-of address to its home agent (which is required to register
the new address as its primary care-of address) more often than once the new address as its primary care-of address) more often than once
skipping to change at page 84, line 16 skipping to change at page 94, line 13
MAY continue using the address without performing Duplicate Address MAY continue using the address without performing Duplicate Address
Detection, although it SHOULD in most cases (e.g., unless network Detection, although it SHOULD in most cases (e.g., unless network
bandwidth or battery consumption for communication is of primary bandwidth or battery consumption for communication is of primary
concern) begin Duplicate Address Detection asynchronously when it concern) begin Duplicate Address Detection asynchronously when it
begins use of the address, allowing the Duplicate Address Detection begins use of the address, allowing the Duplicate Address Detection
procedure to complete in parallel with normal communication using the procedure to complete in parallel with normal communication using the
address. address.
In addition, normal processing for Duplicate Address Detection In addition, normal processing for Duplicate Address Detection
specifies that, in certain cases, the node SHOULD delay sending the specifies that, in certain cases, the node SHOULD delay sending the
initial Neighbor Solication message of Duplicate Address Detection initial Neighbor Solicitation message of Duplicate Address Detection
by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27];
however, in this case, the mobile node SHOULD NOT perform such a however, in this case, the mobile node SHOULD NOT perform such a
delay in its use of Duplicate Address Detection, unless the mobile delay in its use of Duplicate Address Detection, unless the mobile
node is intializing after rebooting. node is initializing after rebooting.
10.6. Sending Binding Updates to the Home Agent 10.7. Sending Binding Updates to the Home Agent
After deciding to change its primary care-of address as described After deciding to change its primary care-of address as described
in Sections 10.4 and 10.5, a mobile node MUST register this care-of in Sections 10.4 and 10.6, a mobile node MUST register this care-of
address with its home agent in order to make this its primary care-of address with its home agent in order to make this its primary care-of
address. To do so, the mobile node sends a packet to its home agent address. To do so, the mobile node sends a packet to its home agent
containing a Binding Update option, with the packet constructed as containing a Binding Update option, with the packet constructed as
follows: follows:
- The Home Registration (H) bit MUST be set in the Binding Update. - The Home Registration (H) bit MUST be set in the Binding Update.
- The Acknowledge (A) bit MUST be set in the Binding Update. - The Acknowledge (A) bit MUST be set in the Binding Update.
- The packet MUST contain a Home Address option, giving the mobile - The packet MUST contain a Home Address option, giving the mobile
skipping to change at page 85, line 4 skipping to change at page 94, line 51
node's home agent to serve as a home agent for all home addresses node's home agent to serve as a home agent for all home addresses
for the mobile node based on all on-link subnet prefixes on the for the mobile node based on all on-link subnet prefixes on the
home link. Otherwise, this field MUST be set to zero. home link. Otherwise, this field MUST be set to zero.
- The value specified in the Lifetime field SHOULD be less than - The value specified in the Lifetime field SHOULD be less than
or equal to the remaining lifetime of the home address and the or equal to the remaining lifetime of the home address and the
care-of address specified for the binding. care-of address specified for the binding.
The Acknowledge (A) bit in the Binding Update requests the home The Acknowledge (A) bit in the Binding Update requests the home
agent to return a Binding Acknowledgement in response to this agent to return a Binding Acknowledgement in response to this
Binding Update. As described in Section 5.2, the mobile node SHOULD Binding Update. As described in Section 5.2, the mobile node
retransmit this Binding Update to its home agent until it receives SHOULD retransmit this Binding Update to its home agent until
a matching Binding Acknowledgement. Once reaching a retransmission it receives a matching Binding Acknowledgement. Once reaching a
timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile
continue to periodically retransmit the Binding Update at this rate node SHOULD continue to periodically retransmit the Binding Update
until acknowledged (or until it begins attempting to register a at this rate until acknowledged (or until it begins attempting to
different primary care-of address). register a different primary care-of address). See section 10.11 for
information about retransmitting Binding Updates.
The Prefix Length field in the Binding Update allows the mobile node The Prefix Length field in the Binding Update allows the mobile node
to request its home agent to serve all home addresses for the mobile to request its home agent to serve all home addresses for the mobile
node, as indicated by the interface identifier in the mobile node's node, as indicated by the interface identifier in the mobile node's
home address (the remaining low-order bits after the indicated subnet home address (the remaining low-order bits after the indicated subnet
prefix), together with each on-link subnet prefix on the home link. prefix), together with each on-link subnet prefix on the home link.
Until the lifetime of this registration expires, the home agent Until the lifetime of this registration expires, the home agent
considers itself the home agent for each such home address of the considers itself the home agent for each such home address of the
mobile node. As the set of on-link subnet prefixes on the home link mobile node. As the set of on-link subnet prefixes on the home link
changes over time, the home agent changes the set of home addresses changes over time, the home agent changes the set of home addresses
for this mobile node for which it is serving as the home agent. for this mobile node for which it is serving as the home agent.
When sending a Binding Update to its home agent, the mobile node MUST When sending a Binding Update to its home agent, the mobile node MUST
also create or update the corresponding Binding Update List entry, as also create or update the corresponding Binding Update List entry, as
specified in Section 10.8. specified in Section 10.9.
If the mobile node has additional home addresses using a different If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the packet containing a Binding Update to its home agent to register the
care-of address for each such other home address (or set of home care-of address for each such other home address (or set of home
addresses sharing an interface identifier). These additional Binding addresses sharing an interface identifier). These additional Binding
Updates MUST each be sent as a separate packet, since each MUST be Updates MUST each be sent as a separate packet. Each care-of address
protected by IPsec [13, 11, 12] to authenticate the Binding Update as MUST be authenticated within the Binding Update as coming from the
coming from the home address being bound, as defined in Section 4.4. home address being associated with the care-of address, as defined in
Section 4.4.
While the mobile node is away from home, it relies on the home agent While the mobile node is away from home, it relies on the home agent
to participate in Duplicate Address Detection (DAD) to defend its to participate in Duplicate Address Detection (DAD) to defend its
home address against stateless autoconfiguration performed by another home address against stateless autoconfiguration performed by another
node. Therefore, the mobile node SHOULD set the Duplicate Address node. Therefore, the mobile node SHOULD set the Duplicate Address
Detection (D) bit based on any requirements for DAD Detection that Detection (D) bit based on any requirements for DAD that would apply
would apply to the mobile node if it were at home [17, 27]. to the mobile node if it were at home [17, 27]. If the mobile
node's recent Binding Update was accepted by the home agent, and the
lifetime for that Binding Update has not yet expired, the mobile node
SHOULD NOT set the `D' bit in the new Binding Update; the home agent
will already be defending the home address(es) of the mobile node and
does not need to perform DAD again.
The home agent will only perform DAD for the mobile node's home The home agent will only perform DAD for the mobile node's home
address when the mobile node has supplied a valid binding between address when the mobile node has supplied a valid binding between
its home address and a care-of address. If some time elapses during its home address and a care-of address. If some time elapses during
which the mobile node has no binding at the home agent, it might be which the mobile node has no binding at the home agent, it might be
possible for another node to autoconfigure the mobile node's home possible for another node to autoconfigure the mobile node's home
address. Therefore, the mobile node MUST treat creation of a new address. Therefore, the mobile node MUST treat creation of a new
binding with the home agent using an existing home address the same binding with the home agent using an existing home address the same
as creation of a new home address. In the unlikely event that the as creation of a new home address. In the unlikely event that the
mobile node's home address is autoconfigured as the IPv6 address mobile node's home address is autoconfigured as the IPv6 address
of another network node on the home network, the home agent will of another network node on the home network, the home agent will
reply to the mobile node's subsequent Binding Update with a Binding reply to the mobile node's subsequent Binding Update with a Binding
Acknowledgement showing Status 138, Duplicate Address Detection Acknowledgement showing Status 138, Duplicate Address Detection
failed. See section 10.10 for information about retransmitting failed.
Binding Updates.
10.7. Dynamic Home Agent Address Discovery 10.8. Dynamic Home Agent Address Discovery
It is possible that when the mobile node needs to send a Binding Sometimes, when the mobile node needs to send a Binding Update to its
Update to its home agent to register its new primary care-of address, home agent to register its new primary care-of address, as described
as described in Section 10.6, the mobile node may not know the in Section 10.7, the mobile node may not know the address of any
address of any router on its home link that can serve as a home agent router on its home link that can serve as a home agent for it. For
for it. For example, some nodes on its home link may have been example, some nodes on its home link may have been reconfigured while
reconfigured while the mobile node has been away from home, such that the mobile node has been away from home, such that the router that
the router that was operating as the mobile node's home agent has was operating as the mobile node's home agent has been replaced by a
been replaced by a different router serving this role. different router serving this role.
In this case, the mobile node MAY use the dynamic home agent address In this case, the mobile node MAY attempt to discovery the address of
discovery mechanism to find the address of a suitable home agent on a suitable home agent on its home link. To do so, the mobile node
its home link. To do so, the mobile node sends an ICMP Home Agent sends an ICMP Home Agent Address Discovery Request message to the
Address Discovery Request message to the "Mobile IPv6 Home-Agents" "Mobile IPv6 Home-Agents" anycast address [10] for its home subnet
anycast address [10] for its home subnet prefix. This packet MUST prefix. This packet MUST NOT contain a Home Address option and must
NOT contain a Home Address option and must be sent using the mobile be sent using the mobile node's care-of address as the Source Address
node's care-of address as the Source Address in the packet's IP in the packet's IP header (the packet is sent from the care-of
header (the packet is sent from the care-of address, not using address, not using Mobile IP). As described in Section 9.8, the home
Mobile IP). As described in Section 9.2, the home agent on its home agent on its home link that receives this Request message will return
link that receives this Request message will return an ICMP Home an ICMP Home Agent Address Discovery Reply message, giving this home
Agent Address Discovery Reply message, giving this home agent's own agent's own global unicast IP address along with a list of the global
global unicast IP address along with a list of the global unicast IP unicast IP address of each other home agent operating on the home
address of each other home agent operating on the home link. link.
The mobile node, upon receiving this Home Agent Address Discovery The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to Reply message, MAY then send its home registration Binding Update to
the home agent address given as the IP Source Address of the packet the home agent address given as the IP Source Address of the packet
carrying the Reply message or to any of the unicast IP addresses carrying the Reply message or to any of the unicast IP addresses
listed in the Home Agent Addresses field in the Reply. For example, listed in the Home Agent Addresses field in the Reply. For example,
if necessary, the mobile node MAY attempt its home registration if necessary, the mobile node MAY attempt its home registration
with each of these home agents, in turn, by sending each a Binding with each of these home agents, in turn, by sending each a Binding
Update and waiting for the matching Binding Acknowledgement, until Update and waiting for the matching Binding Acknowledgement, until
its registration is accepted by one of these home agents. In trying its registration is accepted by one of these home agents. In trying
skipping to change at page 87, line 10 skipping to change at page 97, line 15
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 mechanism described attempt the dynamic home agent address discovery mechanism described
above. above.
10.8. Sending Binding Updates to Correspondent Nodes 10.9. 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.12). 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 in the Alternate Care-of Address
set to one of the care-of addresses currently in use by the mobile Sub-Option of the Binding Update) MUST be set to one of the care-of
node or to the mobile node's home address. addresses currently in use by the mobile node or to the mobile node's
home address.
If set to one of the mobile node's current care-of addresses (the If set to one of the mobile node's current care-of addresses (the
care-of address given MAY differ from the mobile node's primary care-of address given MAY differ from the mobile node's primary
care-of address), the Binding Update requests the correspondent node care-of address), the Binding Update requests the correspondent node
to create or update an entry for the mobile node in the correspondent to create or update an entry for the mobile node in the correspondent
node's Binding Cache to record this care-of address for use in node's Binding Cache to record this care-of address for use in
sending future packets to the mobile node. In this case, the value sending future packets to the mobile node. In this case, the value
specified in the Lifetime field sent in the Binding Update SHOULD be specified in the Lifetime field sent in the Binding Update SHOULD be
less than or equal to the remaining lifetime of the home address and less than or equal to the remaining lifetime of the home address and
the care-of address specified for the binding. the care-of address specified for the binding.
skipping to change at page 88, line 4 skipping to change at page 98, line 10
Update). Update).
- The initial lifetime of the binding, initialized from the - The initial lifetime of the binding, initialized from the
Lifetime field sent in the Binding Update. Lifetime field sent in the Binding Update.
- The remaining lifetime of the binding, also initialized from - The remaining lifetime of the binding, also initialized from
the Lifetime field sent in the Binding Update. This remaining the Lifetime field sent in the Binding Update. This remaining
lifetime value counts down and may also be reduced when the lifetime value counts down and may also be reduced when the
matching Binding Acknowledgement is received, based on the matching Binding Acknowledgement is received, based on the
Lifetime value specified in that Binding Acknowledgement, as Lifetime value specified in that Binding Acknowledgement, as
described in Section 10.12. When the remaining lifetime reaches described in Section 10.13. When the remaining lifetime reaches
zero, the Binding Update List entry MUST be deleted. zero, the Binding Update List entry MUST be deleted.
The mobile node MUST retain in its Binding Update List information The mobile node MUST retain in its Binding Update List information
about all Binding Updates sent, for which the lifetime of the binding about all Binding Updates sent, for which the lifetime of the binding
has not yet expired. However, when sending a Binding Update, if an has not yet expired. However, when sending a Binding Update, if an
entry already exists in the mobile node's Binding Update List for entry already exists in the mobile node's Binding Update List for
an earlier Binding Update sent to that same destination node, the an earlier Binding Update sent to that same destination node, the
existing Binding Update List entry is updated to reflect the new existing Binding Update List entry is updated to reflect the new
Binding Update rather than creating a new Binding Update List entry. Binding Update rather than creating a new Binding Update List entry.
In general, when a mobile node sends a Binding Update to its home When a mobile node sends a Binding Update to its home agent
agent to register a new primary care-of address (as described in to register a new primary care-of address (as described in
Section 10.6), the mobile node will also send a Binding Update to Section 10.7), the mobile node SHOULD also send a Binding Update
each other node for which an entry exists in the mobile node's to each other node for which an entry exists in the mobile node's
Binding Update List. Thus, other relevant nodes are generally kept Binding Update List, as detailed below. Thus, other relevant nodes
updated about the mobile node's binding and can send packets directly are generally kept updated about the mobile node's binding and can
to the mobile node using the mobile node's current care-of address. send packets directly to the mobile node using the mobile node's
current care-of address.
The mobile node, however, need not send these Binding Updates The mobile node, however, need not send these Binding Updates
immediately after configuring a new care-of address. For example, immediately after configuring a new care-of address. For example,
since the Binding Update is a destination option and can be included since the Binding Update is a destination option and can be included
in any packet sent by a mobile node, the mobile node MAY delay in any packet sent by a mobile node, the mobile node MAY delay
sending a new Binding Update to any correspondent node for a sending a new Binding Update to any correspondent node for a
short period of time, in hopes that the needed Binding Update short period of time, in hopes that the needed Binding Update
can be included in some packet that the mobile node sends to that can be included in some packet that the mobile node sends to that
correspondent node for some other reason (for example, as part of correspondent node for some other reason (for example, as part of
some TCP connection in use). In this case, when sending a packet some TCP connection in use). In this case, when sending a packet
to some correspondent node, the mobile node SHOULD check in its to some correspondent node, the mobile node SHOULD check in its
Binding Update List to determine if a new Binding Update to this Binding Update List to determine if a new Binding Update to this
correspondent node is needed, and SHOULD include the new Binding correspondent node is needed, and SHOULD include the new Binding
Update in this packet as necessary. Update in this packet as necessary.
In addition, when a mobile node receives a packet for which the In addition, when a mobile node receives a packet for which the
mobile node can deduce that the original sender of the packet has mobile node can deduce that the original sender of the packet either
no Binding Cache entry for the mobile node, or for which the mobile has no Binding Cache entry for the mobile node, or a stale entry
node can deduce that the original sender of the packet has an for the mobile node in its Binding Cache, the mobile node SHOULD
out-of-date care-of address for the mobile node in its Binding Cache, return a Binding Update to the sender giving its current care-of
the mobile node SHOULD return a Binding Update to the sender giving address (subject to the rate limiting defined in Section 10.12).
its current care-of address (subject to the rate limiting defined In particular, the mobile node SHOULD return a Binding Update in
in Section 10.11). In particular, the mobile node SHOULD return a response to receiving a packet that meets all of the following tests:
Binding Update in response to receiving a packet that meets all of
the following tests:
- The packet was tunneled using IPv6 encapsulation. - The packet was tunneled using IPv6 encapsulation.
- The Destination Address in the tunnel (outer) IPv6 header is - The Destination Address in the tunnel (outer) IPv6 header is
equal to any of the mobile node's care-of addresses. equal to any of the mobile node's care-of addresses.
- The Destination Address in the original (inner) IPv6 header - The Destination Address in the original (inner) IPv6 header
is equal to one of the mobile node's home addresses; or this is equal to one of the mobile node's home addresses; or this
Destination Address is equal to one of the mobile node's previous Destination Address is equal to one of the mobile node's previous
care-of addresses for which the mobile node has an entry in its care-of addresses for which the mobile node has an entry in its
Binding Update List, representing an unexpired Binding Update Binding Update List, representing an unexpired Binding Update
sent to a home agent on the link on which its previous care-of sent to a home agent on the link on which its previous care-of
address is located (Section 10.9). address is located (Section 10.10).
- The Source Address in the tunnel (outer) IPv6 header differs from - The Source Address in the tunnel (outer) IPv6 header differs from
the Source Address in the original (inner) IPv6 header. the Source Address in the original (inner) IPv6 header.
The destination address to which the Binding Update should be sent The destination address to which the Binding Update should be sent
in response to receiving a packet meeting all of the above tests is in response to receiving a packet meeting all of the above tests is
the Source Address in the original (inner) IPv6 header of the packet. the Source Address in the original (inner) IPv6 header of the packet.
The home address for which this Binding Update is sent should be the The home address for which this Binding Update is sent should be the
Destination Address of the original (inner) packet. Destination Address of the original (inner) packet.
skipping to change at page 89, line 36 skipping to change at page 99, line 42
period has reached MAX_BINDACK_TIMEOUT. period has reached MAX_BINDACK_TIMEOUT.
A mobile node MAY choose to keep its location private from certain A mobile node MAY choose to keep its location private from certain
correspondent nodes, and thus need not send new Binding Updates to correspondent nodes, and thus need not send new Binding Updates to
those correspondents. A mobile node MAY also send a Binding Update those correspondents. A mobile node MAY also send a Binding Update
to such a correspondent node to instruct it to delete any existing to such a correspondent node to instruct it to delete any existing
binding for the mobile node from its Binding Cache, as described in binding for the mobile node from its Binding Cache, as described in
Section 5.1. No other IPv6 nodes are authorized to send Binding Section 5.1. No other IPv6 nodes are authorized to send Binding
Updates on behalf of a mobile node. Updates on behalf of a mobile node.
10.9. Establishing Forwarding from a Previous Care-of Address 10.10. Establishing Forwarding from a Previous Care-of Address
When a mobile node connects to a new link and forms a new care-of When a mobile node connects to a new link and forms a new care-of
address, it MAY establish forwarding of packets from a previous address, it MAY establish forwarding of packets from a previous
care-of address to this new care-of address. To do so, the mobile care-of address to this new care-of address. To do so, the mobile
node sends a Binding Update to any home agent on the link on which node sends a Binding Update to any home agent on the link on which
the previous care-of address is located, indicating this previous the previous care-of address is located, indicating this previous
care-of address as the home address for the binding, and giving its care-of address as the home address for the binding, and giving its
new care-of address as the binding's care-of address. Such packet new care-of address as the binding's care-of address. Such packet
forwarding allows packets destined to the mobile node from nodes that forwarding allows packets destined to the mobile node from nodes that
have not yet learned the mobile node's new care-of address, to be have not yet learned the mobile node's new care-of address, to be
skipping to change at page 90, line 38 skipping to change at page 100, line 41
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.6). Alternatively, address from its Home Agents List (Section 4.6). Alternatively,
the mobile node MAY use dynamic home agent address discovery the mobile node MAY use dynamic home agent address discovery
(Section 10.7) to discover the global unicast address of a home agent (Section 10.8) to discover the global unicast address of a home agent
on this previous link, but it SHOULD use an address from its Home on this previous link, but it SHOULD use an address from its Home
Agents List if available for the prefix it used to form this previous Agents List if available for the prefix it used to form this previous
care-of address. care-of address.
As with any packet containing a Binding Update (see section 5.1), As with any packet containing a Binding Update (see section 5.1), the
the Binding Update packet to this home agent MUST meet the IPsec Binding Update packet to this home agent MUST meet the authentication
requirements for Binding Updates, defined in Section 4.4. requirements for Binding Updates, defined in Section 4.4.
10.10. Retransmitting Binding Updates 10.11. Retransmitting Binding Updates
When the mobile node sends a Binding Update, it has to determine When the mobile node sends a Binding Update, it has to determine
a value for the initial retransmission timer. If the mobile node a value for the initial retransmission timer. If the mobile node
is changing or updating an existing binding at the home agent, it is changing or updating an existing binding at the home agent, it
should use the specified value of INITIAL_BINDACK_TIMEOUT for this should use the specified value of INITIAL_BINDACK_TIMEOUT for this
initial retransmission timer. If on the other hand the mobile node initial retransmission timer. If on the other hand the mobile node
does not have an existing binding at the home agent, it SHOULD use a does not have an existing binding at the home agent, it SHOULD use a
value for the initial retransmission timer that is at least 1.5 times value for the initial retransmission timer that is at least 1.5 times
longer than (RetransTimer * DupAddrDetectTransmits). This value is longer than (RetransTimer * DupAddrDetectTransmits). This value is
likely to be substantially longer than the otherwise specified value likely to be substantially longer than the otherwise specified value
of INITIAL_BINDACK_TIMEOUT that would be used by the mobile node. of INITIAL_BINDACK_TIMEOUT that would be used by the mobile node.
This longer retransmission interval will allow the the home agent This longer retransmission interval will allow the the home agent
to complete the DAD procedure which is mandated in this case, as to complete the DAD procedure which is mandated in this case, as
detailed in section 10.6. detailed in section 10.7.
If, after sending a Binding Update in which the care-of address has If, after sending a Binding Update in which the care-of address has
changed and the Acknowledge (A) bit is set, a mobile node fails changed and the Acknowledge (A) bit is set, a mobile node fails
to receive a valid, matching Binding Acknowledgement within the to receive a valid, matching Binding Acknowledgement within the
selected initial retransmission interval, the mobile node SHOULD selected initial retransmission interval, the mobile node SHOULD
retransmit the Binding Update, until a Binding Acknowledgement is retransmit the Binding Update, until a Binding Acknowledgement is
received. Such a retransmitted Binding Update MUST use a Sequence received. Such a retransmitted Binding Update MUST use a Sequence
Number value greater than that used for the previous transmission of Number value greater than that used for the previous transmission of
this Binding Update. The retransmissions by the mobile node MUST this Binding Update. The retransmissions by the mobile node MUST
use an exponential back-off process, in which the timeout period use an exponential back-off process, in which the timeout period
is doubled upon each retransmission until either the node receives is doubled upon each retransmission until either the node receives
a Binding Acknowledgement or the timeout period reaches the value a Binding Acknowledgement or the timeout period reaches the value
MAX_BINDACK_TIMEOUT. MAX_BINDACK_TIMEOUT.
10.11. Rate Limiting for Sending Binding Updates 10.12. Rate Limiting for Sending Binding Updates
A mobile node MUST NOT send Binding Updates about the same binding to A mobile node MUST NOT send Binding Updates about the same binding to
any individual node more often than once per MAX_UPDATE_RATE seconds. any individual node more often than once per MAX_UPDATE_RATE seconds.
After sending MAX_FAST_UPDATES consecutive Binding Updates to a After sending MAX_FAST_UPDATES consecutive Binding Updates to a
particular node with the same care-of address, the mobile node SHOULD particular node with the same care-of address, the mobile node SHOULD
reduce its rate of sending Binding Updates to that node, to the rate reduce its rate of sending Binding Updates to that node, to the rate
of 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.13. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests: node MUST validate the packet according to the following tests:
- The packet meets the specific IPsec requirements for Binding - The packet meets the authentication requirements for Binding
Acknowledgements, defined in Section 4.4. Acknowledgements, defined in Section 4.4.
- The Option Length field in the Binding Acknowledgement option is - The Option Length field in the Binding Acknowledgement option is
greater than or equal to the length specified in Section 5.2. greater than or equal to the length specified in Section 5.2.
- The Sequence Number field matches the Sequence Number sent by the - The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding mobile node to this destination address in an outstanding Binding
Update. Update.
Any Binding Acknowledgement not satisfying all of these tests MUST be Any Binding Acknowledgement not satisfying all of these tests MUST be
skipping to change at page 92, line 49 skipping to change at page 102, line 53
the timer countdown beginning at the time that the Binding Update the timer countdown beginning at the time that the Binding Update
was sent. was sent.
- If the Status field indicates that the Binding Update was - If the Status field indicates that the Binding Update was
rejected (the Status field is greater than or equal to 128), then rejected (the Status field is greater than or equal to 128), then
the mobile node MUST delete the corresponding Binding Update List the mobile node MUST delete the corresponding Binding Update List
entry, and it MUST also stop retransmitting the Binding Update. entry, and it MUST also stop retransmitting the Binding Update.
Optionally, the mobile node MAY then take steps to correct the Optionally, the mobile node MAY then take steps to correct the
cause of the error and retransmit the Binding Update (with a new cause of the error and retransmit the Binding Update (with a new
Sequence Number value), subject to the rate limiting restriction Sequence Number value), subject to the rate limiting restriction
specified in Section 10.11. specified in Section 10.12.
10.13. Receiving Binding Requests 10.14. 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
care-of address registration at its home agent. When sending this care-of address registration at its home agent. When sending this
Binding Update, the mobile node MUST update its Binding Update List Binding Update, the mobile node MUST update its Binding Update List
in the same way as for any other Binding Update sent by the mobile in the same way as for any other Binding Update sent by the mobile
node. node.
skipping to change at page 93, line 27 skipping to change at page 103, line 31
case, the mobile node instead SHOULD return a Binding Update to the case, the mobile node instead SHOULD return a Binding Update to the
sender, in which the Lifetime field is set to zero and the care-of sender, in which the Lifetime field is set to zero and the care-of
address is set to the mobile node's home address. address is set to the mobile node's home address.
If the Binding Request for which the Binding Update is being returned If the Binding Request for which the Binding Update is being returned
contains a Unique Identifer Sub-Option, the Binding Update MUST also contains a Unique Identifer Sub-Option, the Binding Update MUST also
include a Unique Identifier Sub-Option. The unique identifier in the include a Unique Identifier Sub-Option. The unique identifier in the
Sub-Option Data field of the Unique Identifier Sub-Option MUST be Sub-Option Data field of the Unique Identifier Sub-Option MUST be
copied from the unique identifier carried in the Binding Request. copied from the unique identifier carried in the Binding Request.
10.14. Receiving ICMP Error Messages 10.15. Receiving ICMP Error Messages
The Option Type value for a Binding Update option specifies that The Option Type value for a Binding Update option specifies that
any node receiving this option that does not recognize the Option any node receiving this option that does not recognize the Option
Type SHOULD return an ICMP Parameter Problem, Code 2, message to Type SHOULD return an ICMP Parameter Problem, Code 2, message to
the sender of the packet containing the Binding Update option. If the sender of the packet containing the Binding Update option. If
a node sending a Binding Update receives such an ICMP error message a node sending a Binding Update receives such an ICMP error message
in response, it SHOULD record in its Binding Update List that future in response, it SHOULD record in its Binding Update List that future
Binding Updates SHOULD NOT be sent to this destination. Binding Updates SHOULD NOT be sent to this destination.
Likewise, although ALL IPv6 nodes (whether host or router, whether Likewise, although ALL IPv6 nodes (whether host or router, whether
skipping to change at page 94, line 5 skipping to change at page 104, line 7
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 Local Router Advertisement Messages 10.16. Sending Mobile Prefix Solicitations
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 MUST 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. Sending Tunneled Router Solicitations
When a mobile node has a home address that is about to become When a mobile node has a home address that is about to become
invalid, it tunnels a Router Solicitation to its home agent in invalid, it sends a Mobile Prefix Solicitation to its home agent
an attempt to acquire fresh routing prefix information. The new in an attempt to acquire fresh routing prefix information. The
information enables the mobile node to participate in renumbering new information also enables the mobile node to participate in
operations affecting the home network, as described in section 9.8. renumbering operations affecting the home network, as described in
section 9.6.
The mobile node SHOULD tunnel a Router Solicitation to the home agent The mobile node SHOULD send a Solicitation to the home agent when
when its home address will become invalid within MaxRtrAdvInterval its home address will become invalid within MaxRtrAdvInterval
seconds, where this value is acquired in a previous Router seconds, where this value is acquired in a previous Mobile Prefix
Advertisement from the home agent. If no such value is known, the Advertisement from the home agent. If no such value is known, the
value MAX_PFX_ADV_DELAY seconds is used instead. value MAX_PFX_ADV_DELAY seconds is used instead (see section 11).
The mobile node tunnels (using IPv6 encapsulation [4]) the
solicitation, including the following IPv6 header fields:
Outer src = care-of address
Outer dst = Home Agent's global address
Inner src = home address
Inner dst = Home Agent's global address
If the mobile node does not have a valid home address available for If the mobile node does not have a valid home address available for
use as the Inner src address, it MAY use the unspecified IPv6 address use as the IP source address, it MAY use its care-of address (but
(0:0:0:0:0:0:0:0). there will not be a security association between the Home Agent
and the care-of address for the corresponding Advertisement to be
authenticated).
This solicitation follows the same retransmission rules as already This solicitation follows the same retransmission rules specified for
specified for Router Solicitations [17], except that the initial Router Solicitations [17], except that the initial retransmission
retransmission interval is specified to be INITIAL_SOLICIT_TIMER. interval is specified to be INITIAL_SOLICIT_TIMER (see section 11).
10.17. Receiving Tunneled Router Advertisements 10.17. Receiving Mobile Prefix Advertisements
Section 9.8 describes the operation of a home agent to support Section 9.6 describes the operation of a home agent to support boot
renumbering a mobile node's home subnet while the mobile node is time configuration and renumbering a mobile node's home subnet while
away from home. The home agent tunnels certain Router Advertisement the mobile node is away from home. The home agent sends Mobile
messages to the mobile node while away from home, giving "important" Prefix Advertisement messages to the mobile node while away from
Prefix Information options that describe changes in the prefixes in home, giving "important" Prefix Information options that describe
use on the mobile node's home link. changes in the prefixes in 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 Mobile Prefix 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 Mobile Prefix
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. Otherwise, if
no such registrations have been made, it SHOULD be the mobile
node's stored home agent address, if one exists. Otherwise, if
the mobile node has not yet discovered its home agent's address,
it MUST NOT accept Mobile Prefix Advertisements.
- The packet MUST be protected by IPsec [13, 11, 12] to guard - The packet MUST be protected by IPsec [13, 11, 12] to guard
against malicious Router Advertisements. The IPsec protection against malicious prefix advertisements. The IPsec protection
MUST provide sender authentication, data integrity protection, MUST provide sender authentication, data integrity protection,
and replay protection, covering the Router Advertisement. and replay protection, covering the advertisement.
- The packet contains a Binding Request destination option.
- The Binding Request option contains a Unique Identifier
Sub-Option.
Any received tunneled Router Advertisement not meeting all of these Any received Mobile Prefix 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 Mobile Prefix Advertisement is not discarded according
according to the tests listed above, the mobile node MUST process the to the tests listed above, the mobile node MUST process the Prefix
Router Advertisement as if it were connected to its home link [17]. Information Options as if they arrived in a Router Advertisement
Such processing may result in the mobile node configuring a new home on the mobile node's home link [17]. Such processing may result
address, although due to separation between preferred lifetime and in the mobile node configuring a new home address, although due
valid lifetime, such changes should not affect most communication by to separation between preferred lifetime and valid lifetime, such
the mobile node, in the same way as for nodes that are at home. changes should not affect most communication by the mobile node, in
the same way as for nodes that are at home.
In processing the packet containing this Router Advertisement, the If the advertisement contains a Binding Request option, the mobile
mobile node SHOULD return to the home agent a Binding Update in node SHOULD return a Binding Update, which will be viewed by the
response to the Binding Request carried in the packet. The correct home agent as an acknowledgement of the corresponding Mobile Prefix
formation of this Binding Update by the mobile node and processing Advertisement, which it can cease transmitting.
of it by the home agent will be viewed by the home agent as an
acknowledgement of this Router Advertisement, confirming to it that
this Router Advertisement was received by the mobile node.
In addition, if processing of this Router Advertisement resulted in In addition, if processing of this Advertisement resulted in the
the mobile node configuring a new home address, and if the method mobile node configuring a new home address, and if the method used
used for this new home address configuration would require the mobile for this new home address configuration would require the mobile node
node to perform Duplicate Address Detection [27] for the new address to perform Duplicate Address Detection [27] for the new address if
if the mobile node were located at home, then the mobile node MUST the mobile node were located at home, then the mobile node MUST set
set the Duplicate Address Detection (D) bit in this Binding Update to the Duplicate Address Detection (D) bit in this Binding Update to
its home agent, to request the home agent to perform this Duplicate its home agent, to request the home agent to perform this Duplicate
Address Detection on behalf of the mobile node. Address Detection on behalf of the mobile node.
10.18. Using Multiple Care-of Addresses 10.18. Using Multiple Care-of Addresses
As described in Section 10.5, a mobile node MAY use more than one As described in Section 10.6, 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
address, it MUST register it with its home agent by sending it a address, it MUST register it with its home agent by sending it a
Binding Update with the Home Registration (H) and Acknowledge (A) Binding Update with the Home Registration (H) and Acknowledge (A)
bits set, as described in Section 10.6. bits set, as described in Section 10.7.
To assist with smooth handoffs, a mobile node SHOULD retain To assist with smooth handovers, a mobile node SHOULD retain
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.19. Routing Multicast Packets 10.19. 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
skipping to change at page 98, line 51 skipping to change at page 107, line 27
address. In many cases, Neighbor Solicitation by the mobile node address. In many cases, Neighbor Solicitation by the mobile node
for the home agent's address will not be necessary, since the mobile for the home agent's address will not be necessary, since the mobile
node may have already learned the home agent's link-layer address, node may have already learned the home agent's link-layer address,
for example from a Source Link-Layer Address option in the Router for example from a Source Link-Layer Address option in the Router
Advertisement from which it learned that its home address was on-link Advertisement from which it learned that its home address was on-link
and that the mobile node had thus returned home. If the mobile node and that the mobile node had thus returned home. If the mobile node
does Neighbor Solicitation to learn the home agent's link-layer does Neighbor Solicitation to learn the home agent's link-layer
address, in this special case of the mobile node returning home, the address, in this special case of the mobile node returning home, the
mobile node MUST unicast the packet, and in addition set the Source mobile node MUST unicast the packet, and in addition set the Source
Address of this Neighbor Solicitation to the unspecified address Address of this Neighbor Solicitation to the unspecified address
(0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home agent (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home
will be able to distinguish from a similar packet that would only be agent will be able to distinguish from a similar packet that would
used for DAD. only be used for DAD. The home agent will send a multicast Neighbor
Advertisement back to the mobile node with the Solicited flag ('S')
set to zero. The mobile node SHOULD accept this advertisement, and
set the state of the Neighbor Cache entry for the home agent to
REACHABLE.
The mobile node then sends its Binding Update using the home agent's The mobile node then sends its Binding Update using the home agent's
link-layer address, instructing its home agent to no longer serve link-layer address, instructing its home agent to no longer serve
as a home agent for it. By processing this Binding Update, the as a home agent for it. By processing this Binding Update, the
home agent will cease defending the mobile node's home address for home agent will cease defending the mobile node's home address for
Duplicate Address Detection and will no longer respond to Neighbor Duplicate Address Detection and will no longer respond to Neighbor
Solicitations for the mobile node's home address. The mobile node is Solicitations for the mobile node's home address. The mobile node
then the only node on the link using the mobile node's home address. is then the only node on the link receiving packets at the mobile
In addition, when returning home prior to the expiration of a current node's home address. In addition, when returning home prior to the
binding for its home address, and configuring its home address on its expiration of a current binding for its home address, and configuring
network interface on its home link, the mobile node MUST NOT perform its home address on its network interface on its home link, the
Duplicate Address Detection on its own home address, in order to mobile node MUST NOT perform Duplicate Address Detection on its own
avoid confusion or conflict with its home agent's use of the same home address, in order to avoid confusion or conflict with its home
address. If the mobile node returns home after the bindings for all agent's use of the same address. If the mobile node returns home
of its care-of addresses have expired, then it SHOULD perform DAD. after the bindings for all of its care-of addresses have expired,
then it SHOULD perform DAD.
After the Mobile Node sends the Binding Update, the Home Agent MUST
remove the Proxy Neighbor Cache entry for the Mobile Node and MAY
learn its link-layer address based on the link-layer packet or cached
information, or if that is not available, it SHOULD send a Neighbor
Solicitation with the target address equal to the Binding Update's
source IP address. The Mobile Node MUST then reply with a unicast
Neighbor Advertisement to the Home Agent with its link-layer address.
While the Mobile Node is waiting for a Binding Acknowledgement, it
MUST NOT respond to any Neighbor Solicitations other than those
originating from the IP address to which it sent the Binding Update.
After receiving the Binding Acknowledgement for its Binding Update After receiving the Binding Acknowledgement for its Binding Update
to its home agent, the mobile node MUST multicast onto the home to its home agent, the mobile node MUST multicast onto the home
link (to the all-nodes multicast address) a Neighbor Advertisement link (to the all-nodes multicast address) a Neighbor Advertisement
message [17], 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
skipping to change at page 100, line 13 skipping to change at page 108, line 44
Neighbor Unreachability Detection [17]. Neighbor Unreachability Detection [17].
11. Protocol Constants 11. Protocol Constants
INITIAL_BINDACK_TIMEOUT 1 second INITIAL_BINDACK_TIMEOUT 1 second
INITIAL_SOLICIT_TIMER 2 seconds INITIAL_SOLICIT_TIMER 2 seconds
MAX_BINDACK_TIMEOUT 256 seconds MAX_BINDACK_TIMEOUT 256 seconds
PREFIX_ADV_TIMEOUT 5 seconds
PREFIX_ADV_RETRIES 3 retransmissions
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 second interval
MAX_FAST_UPDATES 5 transmissions MAX_FAST_UPDATES 5 transmissions
MAX_ADVERT_REXMIT 3 transmissions MAX_ADVERT_REXMIT 3 transmissions
MAX_PFX_ADV_DELAY 1,000 seconds MAX_PFX_ADV_DELAY 1,000 seconds
HomeRtrAdvInterval 1,000 seconds HomeRtrAdvInterval 3,600 seconds
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; and - 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 ICMP message types, used as These destination options can sometimes take sub-options. The
part of the dynamic home agent address discovery mechanism: current sub-options are specified in section 5.5, "Mobile IPv6
Destination Option Sub-Options", and include the following:
0 Pad1 sub-option
1 PadN sub-option
2 Unique Identifier sub-option
3 Mobile Router Prefix Length sub-option
4 Alternate Care-of Address sub-option
In addition, this document defines four ICMP message types, two used
as part of the dynamic home agent address discovery mechanism and
two used in lieu of router solicitations and advertisements when the
mobile node is away from the home link:
- The Home Agent Address Discovery Request message, described in - The Home Agent Address Discovery Request message, described in
Section 5.6; and Section 5.6;
- The Home Agent Address Discovery Reply message, described in - The Home Agent Address Discovery Reply message, described in
Section 5.7. Section 5.7;
- The Mobile Prefix Solicitation message, described in Section 5.8;
and
- The Mobile Prefix Advertisement message, described in
Section 5.9.
This document also defines two new Neighbor Discovery [17] options, This document also defines two new Neighbor Discovery [17] options,
which must be assigned Option Type values within the option numbering which must be assigned Option Type values within the option numbering
space for Neighbor Discovery messages: space for Neighbor Discovery messages:
- The Advertisement Interval option, described in Section 6.3; and - 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.
A new space of predefined SPIs for Binding Security Associations must
be created for use with Binding Updates and Binding Acknowledgements.
This space is to be managed in a way identical to that specified
for IPsec [13]. Assignment of new SPIs in the reserved range 1-255
requires working group approval.
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 [10], used in the - The "Mobile IPv6 Home-Agents" anycast address [10], used in the
dynamic home agent address discovery mechanism described in dynamic home agent address discovery mechanism described in
Sections 9.2 and 10.7. Sections 9.8 and 10.8.
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
in packets addressed to a mobile node being delivered instead to packets addressed to a mobile node being delivered instead to its
its care-of address. This ability to change the routing of these care-of address. This ability to change the routing of these packets
packets could be a significant vulnerability if any packet containing could be a significant vulnerability if any packet containing a
a Binding Update option was not authenticated. Such use of "remote Binding Update option were not authenticated. Such use of "remote
redirection", for instance as performed by the Binding Update option, redirection", for instance as performed by the Binding Update option,
is widely understood to be a security problem in the current Internet is widely understood to be a security problem in the current Internet
if not authenticated [1]. if not authenticated [1].
The Binding Acknowledgement option also requires authentication, The Binding Acknowledgement option also requires authentication,
since, for example, an attacker could otherwise trick a mobile node since, for example, an attacker could otherwise trick a mobile node
into believing a different outcome from a registration attempt with into believing a different outcome from a registration attempt with
its home agent. its home agent.
No authentication is required for the Binding Request option, since No authentication is required for the Binding Request option, since
the use of this option does not modify or create any state in either the use of this option does not modify or create any state in either
the sender or the receiver. The Binding Request option does open the sender or the receiver. Issues with binding privacy stemming
some issues with binding privacy, but those issues can be dealt with from use of the Binding Request option can be dealt with either
either through existing IPsec encryption mechanisms or through use of through existing IPsec encryption mechanisms or through use of
firewalls. firewalls.
The existing IPsec replay protection mechanisms allow a "replay After the Sequence Number space of the Binding Update and Binding
protection window" to support receiving packets out of order. Acknowledgement options has been exhausted, the mobile node and the
Although appropriate for many forms of communication, Binding Updates home agent SHOULD renegotiate their security association in order to
MUST be applied only in the order sent. The Binding Update option prevent any possibility of replay attacks.
thus includes a Sequence Number field to provide this necessary
sequencing. The use of this Sequence Number together with IPsec
replay protection is similar in many ways, for example, to the the
sequence number in TCP. IPsec provides strong replay protection but
no ordering, and the sequence number provides ordering but need not
protect against replays such as may occur when the sequence number
wraps around.
13.2. Security for the Home Address Option 13.2. Security for the Home Address Option
No special authentication of the Home Address option is required, No special authentication of the Home Address option is required,
except that if the IPv6 header of a packet is covered by except that if the IPv6 header of a packet is covered by
authentication, then that authentication MUST also cover the Home authentication, then that authentication MUST also cover the Home
Address option; this coverage is achieved automatically by the Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option definition of the Option Type code for the Home Address option
(Section 5.4), since it indicates that the option is included in the (Section 5.4), since it indicates that the option is included in the
authentication computation. Thus, even when authentication is used authentication computation. Thus, even when authentication is used
skipping to change at page 103, line 31 skipping to change at page 113, line 24
The mobile computing environment is potentially very different from The mobile computing environment is potentially very different from
the ordinary computing environment. In many cases, mobile computers the ordinary computing environment. In many cases, mobile computers
will be connected to the network via wireless links. Such links will be connected to the network via wireless links. Such links
are particularly vulnerable to passive eavesdropping, active replay are particularly vulnerable to passive eavesdropping, active replay
attacks, and other active attacks. Furthermore, mobile computers attacks, and other active attacks. Furthermore, mobile computers
are more susceptible to loss or theft than stationary computers. are more susceptible to loss or theft than stationary computers.
Any secrets such as authentication or encryption keys stored on the Any secrets such as authentication or encryption keys stored on the
mobile computer are thus subject to compromise in ways generally not mobile computer are thus subject to compromise in ways generally not
common in the non-mobile environment. common in the non-mobile environment.
Users who have sensitive data that they do not wish others to have Users who have sensitive data that they wish to keep private
access to SHOULD use additional mechanisms (such as encryption) to SHOULD protect the data using additional mechanisms (such as
provide privacy protection, but such mechanisms are beyond the scope encryption [12]); such mechanisms are beyond the scope of this
of this document. Users concerned about traffic analysis SHOULD document. Users concerned about traffic analysis SHOULD consider
consider appropriate use of link encryption. If stronger location appropriate use of link encryption. If stronger location privacy
privacy is desired, the mobile node can create a tunnel to its home is desired, the mobile node MAY create a tunnel to its home agent.
agent. Then, packets destined for correspondent nodes will appear Then, packets destined for correspondent nodes will appear to emanate
to emanate from the home subnet, and it may be more difficult to from the home subnet, making it more difficult to pinpoint the
pinpoint the location of the mobile node. Such mechanisms are all location of the mobile node. Such mechanisms are all beyond the
beyond the scope of this document. scope of this document.
Whether or not the mobile node is away from home is likely to Whether or not the mobile node is away from home is likely to
influence the choice of security policy from the SPD. For instance, influence the choice of security policy from the SPD. For instance,
if a mobile node is connected to its home network and it communicates if a mobile node is connected to its home network and it communicates
with a correspondent node on its home network, no security may be with a correspondent node on its home network, no security may be
needed. If, on the other hand, the mobile node is attached to needed. If, on the other hand, the mobile node is attached to
foreign network and has sent a Binding Update to its home agent, then foreign network and has sent a Binding Update to its home agent, then
the mobile node may need to make use of security features in order to the mobile node may need to make use of security features in order to
communicate with that same correspondent node. communicate with that same correspondent node.
Changes from Previous Version of the Draft
This appendix briefly lists some of the major changes in this
draft relative to the previous version of this same draft,
draft-ietf-mobileip-ipv6-12.txt:
- Specified that the Home Address destination option MUST be
inserted between Routing Header and Fragment Header
- Specified that the Binding Update MUST be located after the IPsec