draft-ietf-mobileip-ipv6-15.txt   draft-ietf-mobileip-ipv6-16.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 Research Center Nokia Research Center
2 July 2001 22 March 2002
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-15.txt> <draft-ietf-mobileip-ipv6-16.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 64 skipping to change at page 1, line 64
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
4. Overview of Mobile IPv6 8 4. Overview of Mobile IPv6 8
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 4.1. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 8
4.2. New IPv6 Destination Options . . . . . . . . . . . . . . 11 4.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10
4.3. Alignment Requirements for New Destination Options . . . 12 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13
4.4. Authentication Requirements for Binding Update and 4.4. Alignment Requirements for New Destination Options . . . 13
Acknowledgement . . . . . . . . . . . . . . . . . . . 13 4.5. Security Design . . . . . . . . . . . . . . . . . . . . . 14
4.5. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 4.5.1. Security Threats . . . . . . . . . . . . . . . . 14
4.6. Conceptual Data Structures . . . . . . . . . . . . . . . 15 4.5.2. Security Features . . . . . . . . . . . . . . . . 15
4.7. Binding Management . . . . . . . . . . . . . . . . . . . 20 4.5.3. Securing Tunnels to and from the Home Agents . . 17
4.5.4. Securing Binding Updates to Home Agents . . . . . 17
4.5.5. Securing Binding Updates to Correspondent Nodes . 18
4.5.6. Preventing Denial-of-Service Attacks . . . . . . 22
4.5.7. Design Rationale . . . . . . . . . . . . . . . . 23
4.6. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 24
4.7. Conceptual Data Structures . . . . . . . . . . . . . . . 25
4.8. Binding Management . . . . . . . . . . . . . . . . . . . 30
5. New IPv6 Destination Options and Message Types 22 5. New IPv6 Destination Options and Message Types 31
5.1. Binding Update Option . . . . . . . . . . . . . . . . . . 22 5.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31
5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 26 5.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32
5.3. Binding Request Option . . . . . . . . . . . . . . . . . 30 5.1.2. Binding Request (BR) Message . . . . . . . . . . 33
5.4. Home Address Option . . . . . . . . . . . . . . . . . . . 32 5.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 35 5.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 35
5.5.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36 5.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 36
5.5.2. PadN . . . . . . . . . . . . . . . . . . . . . . 36 5.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 38
5.5.3. Unique Identifier . . . . . . . . . . . . . . . . 37 5.1.7. Binding Update (BU) Message . . . . . . . . . . . 40
5.5.4. Alternate Care-of Address . . . . . . . . . . . . 37 5.1.8. Binding Acknowledgement (BA) Message . . . . . . 44
5.6. Authentication Data . . . . . . . . . . . . . . . . . . . 38 5.1.9. Binding Missing (BM) Message . . . . . . . . . . 49
5.7. ICMP Home Agent Address Discovery Request Message . . . . 40 5.2. Mobility Header Parameters . . . . . . . . . . . . . . . 51
5.8. ICMP Home Agent Address Discovery Reply Message . . . . . 41 5.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51
5.9. ICMP Mobile Prefix Solicitation Message Format . . . . . 43 5.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52
5.10. ICMP Mobile Prefix Advertisement Message Format . . . . . 45 5.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53
5.2.5. Alternate Care-of Address . . . . . . . . . . . . 53
5.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54
5.2.7. Authentication Data . . . . . . . . . . . . . . . 54
5.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55
5.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58
5.4.1. Routing Header Packet format . . . . . . . . . . 58
5.4.2. Sending RH type 2 . . . . . . . . . . . . . . . . 59
5.4.3. Verification by receiver . . . . . . . . . . . . 60
5.4.4. Extension header ordering . . . . . . . . . . . . 60
5.4.5. Reversing type 2 routing headers . . . . . . . . 60
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 61
5.5.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . 62
5.5.2. PadN . . . . . . . . . . . . . . . . . . . . . . 62
5.6. ICMP Home Agent Address Discovery Request Message . . . . 63
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 64
5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 66
5.9. ICMP Mobile Prefix Advertisement Message Format . . . . . 68
6. Modifications to IPv6 Neighbor Discovery 47 6. Modifications to IPv6 Neighbor Discovery 70
6.1. Modified Router Advertisement Message Format . . . . . . 47 6.1. Modified Router Advertisement Message Format . . . . . . 70
6.2. Modified Prefix Information Option Format . . . . . . . . 48 6.2. Modified Prefix Information Option Format . . . . . . . . 71
6.3. New Advertisement Interval Option Format . . . . . . . . 50 6.3. New Advertisement Interval Option Format . . . . . . . . 73
6.4. New Home Agent Information Option Format . . . . . . . . 51 6.4. New Home Agent Information Option Format . . . . . . . . 74
6.5. Changes to Sending Router Advertisements . . . . . . . . 53 6.5. Changes to Sending Router Advertisements . . . . . . . . 76
6.6. Changes to Sending Router Solicitations . . . . . . . . . 54 6.6. Changes to Sending Router Solicitations . . . . . . . . . 77
7. Requirements for Types of IPv6 Nodes 56
7.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 56
7.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 56
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 56
7.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 57
8. Correspondent Node Operation 59
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 59
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 59
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 60
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 61
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 61
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 62
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 62
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 63
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 64
9. Home Agent Operation 67 7. Requirements for Types of IPv6 Nodes 79
9.1. Primary Care-of Address Registration . . . . . . . . . . 67 7.1. Requirements for All IPv6 Routers . . . . . . . . . . . . 79
9.2. Primary Care-of Address De-registration . . . . . . . . . 69 7.2. Requirements for IPv6 Home Agents . . . . . . . . . . . . 79
9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 70 7.3. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 80
9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 72 8. Correspondent Node Operation 82
9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 73 8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 82
9.6. Home Prefix Propagation . . . . . . . . . . . . . . . . . 74 8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 82
9.7. Receiving Router Advertisement Messages . . . . . . . . . 74 8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 83
9.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 76 8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 84
9.8.1. Aggregate List of Home Network Prefixes . . . . . 77 8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 84
9.8.2. Scheduling Prefix Deliveries to the Mobile Node . 79 8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 85
9.8.3. Sending Advertisements to the Mobile Node . . . . 80 8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 85
9.8.4. Lifetimes for Changed Prefixes . . . . . . . . . 82 8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 86
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 87
10. Mobile Node Operation 83 9. Home Agent Operation 89
10.1. Sending Packets While Away from Home . . . . . . . . . . 83 9.1. Primary Care-of Address Registration . . . . . . . . . . 89
10.2. Interaction with Outbound IPsec Processing . . . . . . . 84 9.2. Primary Care-of Address De-Registration . . . . . . . . . 92
10.3. Receiving Packets While Away from Home . . . . . . . . . 86 9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 92
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 87 9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 94
10.5. Receiving Local Router Advertisement Messages . . . . . . 90 9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 96
10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 91 9.6. Protecting Return Routability Packets . . . . . . . . . . 96
10.7. Sending Binding Updates to the Home Agent . . . . . . . . 93 9.7. Home Prefix Propagation . . . . . . . . . . . . . . . . . 96
10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 95 9.8. Receiving Router Advertisement Messages . . . . . . . . . 97
10.9. Sending Binding Updates to Correspondent Nodes . . . . . 96 9.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 98
10.10. Establishing Forwarding from a Previous Care-of Address . 99 9.9.1. Aggregate List of Home Network Prefixes . . . . . 100
10.11. Retransmitting Binding Updates . . . . . . . . . . . . . 100 9.9.2. Scheduling Prefix Deliveries to the Mobile Node . 101
10.12. Rate Limiting for Sending Binding Updates . . . . . . . . 100 9.9.3. Sending Advertisements to the Mobile Node . . . . 103
10.13. Receiving Binding Acknowledgements . . . . . . . . . . . 101 9.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 105
10.14. Receiving Binding Requests . . . . . . . . . . . . . . . 102
10.15. Receiving ICMP Error Messages . . . . . . . . . . . . . . 102
10.16. Sending Mobile Prefix Solicitations . . . . . . . . . . . 103
10.17. Receiving Mobile Prefix Advertisements . . . . . . . . . 104
10.18. Using Multiple Care-of Addresses . . . . . . . . . . . . 105
10.19. Routing Multicast Packets . . . . . . . . . . . . . . . . 105
10.20. Returning Home . . . . . . . . . . . . . . . . . . . . . 106
11. Protocol Constants 108 10. Mobile Node Operation 105
10.1. Sending Packets While Away from Home . . . . . . . . . . 105
10.2. Interaction with Outbound IPsec Processing . . . . . . . 107
10.3. Receiving Packets While Away from Home . . . . . . . . . 108
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 109
10.5. Receiving Local Router Advertisement Messages . . . . . . 112
10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 114
10.7. Sending Binding Updates to the Home Agent . . . . . . . . 115
10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 117
10.9. Sending Binding Updates to Correspondent Nodes . . . . . 118
10.10. Receiving RR Messages . . . . . . . . . . . . . . . . . . 121
10.11. Establishing Forwarding from a Previous Care-of Address . 122
10.12. Retransmitting Binding Updates . . . . . . . . . . . . . 123
10.13. Rate Limiting for Sending Binding Updates . . . . . . . . 124
10.14. Receiving Binding Acknowledgements . . . . . . . . . . . 124
10.15. Receiving Binding Requests . . . . . . . . . . . . . . . 125
10.16. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126
10.17. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126
10.18. Sending Mobile Prefix Solicitations . . . . . . . . . . . 126
10.19. Receiving Mobile Prefix Advertisements . . . . . . . . . 127
10.20. Using Multiple Care-of Addresses . . . . . . . . . . . . 128
10.21. Routing Multicast Packets . . . . . . . . . . . . . . . . 128
10.22. Returning Home . . . . . . . . . . . . . . . . . . . . . 129
12. IANA Considerations 109 11. Protocol Constants 131
13. Security Considerations 111 12. Future Extensions 132
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 111 12.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 132
13.2. Security for the Home Address Option . . . . . . . . . . 111 12.2. Triangular Routing and Unverified HAOs . . . . . . . . . 132
13.3. General Mobile Computing Issues . . . . . . . . . . . . . 112 12.3. New Authorization Methods beyond RR . . . . . . . . . . . 132
Acknowledgements 113 13. IANA Considerations 133
References 114 14. Security Considerations 134
14.1. Security for the Tunneling to and from the Home Agent . . 134
14.2. Security for the Binding Updates to the Home Agent . . . 135
14.3. Security for the Binding Updates to the Correspondent
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 135
14.4. Security for the Home Address Option . . . . . . . . . . 135
14.5. Firewall considerations . . . . . . . . . . . . . . . . . 136
A. Changes from Previous Version of the Draft 115 Acknowledgements 137
A.1. Changes from Draft Version ...-14 . . . . . . . . . . . . 115
A.2. Changes from Previous Versions of the Draft . . . . . . . 117
B. Remote Home Address Configuration 118 References 138
Chairs' Addresses 119 A. Changes from Previous Version of the Draft 140
A.1. Changes from Draft Version ...-15 . . . . . . . . . . . . 140
A.2. Changes from Previous Versions of the Draft . . . . . . . 142
Authors' Addresses 120 B. Remote Home Address Configuration 144
Chairs' Addresses 145
Authors' Addresses 146
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 3, line 9 skipping to change at page 3, line 9
- 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 unauthenticated node is allowed is a general problem any time an unauthenticated node is allowed
to 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) [25, 24, 26], together
with the opportunities provided by the design and deployment of a new with the opportunities provided by the design and deployment of a new
version of IP itself (IPv6) and the new protocol features offered version of IP itself (IPv6) and the new protocol features offered
by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4,
but the protocol is now fully integrated into IP and provides many but the protocol is now fully integrated into IP and provides many
improvements over Mobile IPv4. This section summarizes the major improvements over Mobile IPv4. This section summarizes the major
differences between Mobile IPv4 and Mobile IPv6: differences between Mobile IPv4 and Mobile IPv6:
- Support for what is known in Mobile IPv4 as "Route - Support for what is known in Mobile IPv4 as "Route
Optimization" [21] is now built in as a fundamental part Optimization" [27] is now built in as a fundamental part
of the protocol, rather than being added on as an optional of the protocol, rather than being added on as an optional
set of extensions that may not be supported by all nodes set of extensions that may not be supported by all nodes
as in Mobile IPv4. This integration of Route Optimization as in Mobile IPv4. This integration of Route Optimization
functionality allows direct routing from any correspondent functionality allows direct routing from any correspondent
node to any mobile node, without needing to pass through node to any mobile node, without needing to pass through
the mobile node's home network and be forwarded by its home the mobile node's home network and be forwarded by its home
agent, and thus eliminates the problem of "triangle routing" agent, and thus eliminates the problem of "triangle routing"
present in the base Mobile IPv4 protocol [19]. The Mobile IPv4 present in the base Mobile IPv4 protocol [25]. The Mobile IPv4
"registration" functionality and the Mobile IPv4 Route "registration" functionality and the Mobile IPv4 Route
Optimization functionality are performed by a single protocol Optimization functionality are performed by a single protocol
rather than two separate (and different) protocols. rather than two separate (and different) protocols.
- Support is also integrated into Mobile IPv6 -- and into IPv6 - Support is also integrated into Mobile IPv6 -- and into IPv6
itself -- for allowing mobile nodes and Mobile IP to coexist itself -- for allowing mobile nodes and Mobile IP to coexist
efficiently with routers that perform "ingress filtering" [7]. A efficiently with routers that perform "ingress filtering" [7]. A
mobile node now uses its care-of address as the Source Address in mobile node now uses its care-of address as the Source Address in
the IP header of packets it sends, allowing the packets to pass the IP header of packets it sends, allowing the packets to pass
normally through ingress filtering routers. The home address normally through ingress filtering routers. The home address
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 [20] and Address Autoconfiguration [35], 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.
- 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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
encapsulation, whereas Mobile IPv4 must use encapsulation for all encapsulation, whereas Mobile IPv4 must use encapsulation for all
packets. The use of a Routing header requires less additional packets. The use of a Routing header requires less additional
header bytes to be added to the packet, reducing the overhead header bytes to be added to the packet, reducing the overhead
of Mobile IP packet delivery. To avoid modifying the packet in of Mobile IP packet delivery. To avoid modifying the packet in
flight, however, packets intercepted and tunneled by a mobile flight, however, packets intercepted and tunneled by a mobile
node's home agent in Mobile IPv6 must still use encapsulation for node's home agent in Mobile IPv6 must still use encapsulation for
delivery to the mobile node. delivery to the mobile node.
- While a mobile node is away from home, its home agent intercepts - While a mobile node is away from home, its home agent intercepts
any packets for the mobile node that arrive at the home network, any packets for the mobile node that arrive at the home network,
using IPv6 Neighbor Discovery [17] rather than ARP [23] as is using IPv6 Neighbor Discovery [20] rather than ARP [29] as is
used in Mobile IPv4. The use of Neighbor Discovery improves used in Mobile IPv4. The use of Neighbor Discovery improves
the robustness of the protocol (e.g., due to the Neighbor the robustness of the protocol (e.g., due to the Neighbor
Advertisement "override" bit) and simplifies implementation Advertisement "override" bit) and simplifies implementation
of Mobile IP due to the ability to not be concerned with any of Mobile IP due to the ability to not be concerned with any
particular link layer as is required in ARP. particular link layer as is required in ARP.
- The use of IPv6 encapsulation (and the Routing header) removes - The use of IPv6 encapsulation (and the Routing header) removes
the need in Mobile IPv6 to manage "tunnel soft state", which was the need in Mobile IPv6 to manage "tunnel soft state", which was
required in Mobile IPv4 due to limitations in ICMP for IPv4. Due required in Mobile IPv4 due to limitations in ICMP for IPv4. Due
to the definition of ICMP for IPv6, the use of tunnel soft state to the definition of ICMP for IPv6, the use of tunnel soft state
is no longer required in IPv6 for correctly relaying ICMP error is no longer required in IPv6 for correctly relaying ICMP error
messages from within the tunnel back to the original sender of messages from within the tunnel back to the original sender of
the packet. the packet.
- The dynamic home agent address discovery mechanism in Mobile IPv6 - The dynamic home agent address discovery mechanism in Mobile IPv6
uses IPv6 anycast [10] and returns a single reply to the mobile uses IPv6 anycast [11] and returns a single reply to the mobile
node, rather than the corresponding Mobile IPv4 mechanism that node, rather than the corresponding Mobile IPv4 mechanism that
used IPv4 directed broadcast and returned a separate reply from used IPv4 directed broadcast and returned a separate reply from
each home agent on the mobile node's home link. The Mobile IPv6 each home agent on the mobile node's home link. The Mobile IPv6
mechanism is more efficient and more reliable, since only one mechanism is more efficient and more reliable, since only one
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
skipping to change at page 8, line 21 skipping to change at page 8, line 21
messages. messages.
Binding Security Association (BSA) Binding Security Association (BSA)
a security association established specifically a security association established specifically
for the purpose of producing and verifying for the purpose of producing and verifying
authentication data passed with a Binding Update authentication data passed with a Binding Update
destination option. destination option.
4. Overview of Mobile IPv6 4. Overview of Mobile IPv6
4.1. Basic Operation 4.1. New IPv6 Protocols
As mentioned in Section 4.2, Mobile IPv6 defines a new IPv6 protocol,
the Mobility Header. This protocol is used to carry the following
messages:
Home Test Init
The Home Test Init message is used to initiate the Return
Routability procedure from the mobile node to a correspondent
node. This procedure ensures that subsequence Binding Updates
are properly authorized to redirect the traffic of a particular
home address. The Home Test Init message is described in
detail in Section 5.1.3.
Care-of Test Init
The Care-of Test Init message is also used to initiate the
Return Routability procedure, for a particular care-of address.
The Care-of Test Init message is described in detail in
Section 5.1.4.
Home Test
The Home Test message carries a cookie which the mobile node
needs before it can properly authorize itself for sending a
Binding Update. This message is an answer to the Home Test
Init message, and is described in detail in Section 5.1.5.
Care-of Test
The Care-of Test message carries a cookie which the mobile node
needs before it can properly authorize itself for sending a
Binding Update. This message is an answer to the Care-of Test
Init message, and is described in detail in Section 5.1.6.
Binding Update
A Binding Update message is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked as
a "home registration". A home registration MUST be protected
with IPsec, while other Binding Updates MUST be protected with
an authenticator as described in Section 4.5. The Binding
Update message and its specific authentication requirements are
described in detail in Section 5.1.7.
Binding Acknowledgement
A Binding Acknowledgement message is used to acknowledge
receipt of a Binding Update, if an acknowledgement was
requested in the Binding Update. An acknowledgement of a home
registration MUST be protected with IPsec, while other Binding
Update acknowledgements MUST be protected with an authenticator
as described in Section 4.5. The Binding Acknowledgement
message and its specific authentication requirements are
described in detail in Section 5.1.8.
Binding Request
A Binding Request message is used to request a mobile node
to send to the requesting node a Binding Update containing
the mobile node's current binding. This message is typically
used by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication
is required for the Binding Request message. The Binding
Request message is described in detail in Section 5.1.2.
Binding Missing
The Binding Missing message is used by the correspondent node
to signal an inappropriate attempt to use the Home Address
Option without an existing binding. This message is described
in detail in Section 5.1.9.
Mobile IPv6 also defines a number of "parameters" for use within
these messages; if included, any parameters MUST appear after the
fixed portion of the option data specified in this document. The
presence of such parameters will be indicated by the Header Len
field within the message. When the Header Len is greater than the
length required for the message specified here, the remaining octets
are interpreted as parameters. The encoding and format of defined
parameters are described in Section 5.2.
Alignment requirements for the Mobility Header are same as for any
IPv6 protocol, i.e. they MUST be aligned on an 8-octet boundary.
We also require that the Mobility Header length is a multiple of 8
octets.
4.2. 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
of a mobile node's home address is the subnet prefix (or one of the of a mobile node's home address is the subnet prefix (or one of the
subnet prefixes) on the mobile node's home link (it is the mobile subnet prefixes) on the mobile node's home link (it is the mobile
node's home subnet prefix), packets addressed to it will be routed to node's home subnet prefix), packets addressed to it will be routed to
its home link. its home link.
skipping to change at page 8, line 46 skipping to change at page 10, line 37
with a mobile node while visiting a particular foreign link. The with a mobile node while visiting a particular foreign link. The
subnet prefix of a mobile node's care-of address is the subnet prefix subnet prefix of a mobile node's care-of address is the subnet prefix
(or one of the subnet prefixes) on the foreign link being visited by (or one of the subnet prefixes) on the foreign link being visited by
the mobile node; if the mobile node is connected to this foreign link the mobile node; if the mobile node is connected to this foreign link
while using that care-of address, packets addressed to this care-of while using that care-of address, packets addressed to this care-of
address will be routed to the mobile node in its location away from address will be routed to the mobile node in its location away from
home. home.
The association between a mobile node's home address and care-of The association between a mobile node's home address and care-of
address is known as a "binding" for the mobile node. A mobile node address is known as a "binding" for the mobile node. A mobile node
typically acquires its care-of address through stateless [27] or typically acquires its care-of address through stateless [35] or
stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [17]. Other methods to the methods of IPv6 Neighbor Discovery [20]. Other methods
of acquiring a care-of address are also possible, such as static of acquiring a care-of address are also possible, such as static
pre-assignment by the owner or manager of a particular foreign link, pre-assignment by the owner or manager of a particular foreign link,
but details of such other methods are beyond the scope of this but details of such other methods are beyond the scope of this
document. document.
While away from home, a mobile node registers one of its care-of While away from home, a mobile node registers one of its care-of
addresses with a router on its home link, requesting this router addresses with a router on its home link, requesting this router
to function as the "home agent" for the mobile node. This binding to function as the "home agent" for the mobile node. This binding
registration is done by the mobile node sending to the home agent registration is done by the mobile node sending to the home agent
a packet containing a "Binding Update" destination option; the a packet containing a "Binding Update" destination option; the
skipping to change at page 9, line 30 skipping to change at page 11, line 20
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.10 describes the mobile node's current care-of address. Section 10.11 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.20 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 the particular care-of address to implement any policy to determine the particular care-of address to
which it will tunnel each intercepted packet. The mobile node alone which it will tunnel each intercepted packet. The mobile node alone
controls the policy by which it selects the care-of addresses to controls the policy by which it selects the care-of addresses to
register with its home agent. register with its home agent.
skipping to change at page 9, line 55 skipping to change at page 11, line 45
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 allows a mobile node to dynamically discover the IP address of a
home agent on its home link with which it may register its (primary) home agent on its home link with which it may register its (primary)
care-of address while away from home. The mobile node sends an ICMP care-of address while away from home. The mobile node sends an ICMP
"Home Agent Address Discovery Request" message to the "Mobile IPv6 "Home Agent Address Discovery Request" message to the "Mobile IPv6
Home-Agents" anycast address for its own home subnet prefix [10] and Home-Agents" anycast address for its own home subnet prefix [11] and
thus reaches one of the (possibly many) routers on its home link thus reaches one of the (possibly many) routers on its home link
currently operating as a home agent. This home agent then returns an currently operating as a home agent. This home agent then returns an
ICMP "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
skipping to change at page 10, line 35 skipping to change at page 12, line 28
node communicating with a mobile node is referred to in this document node communicating with a mobile node is referred to in this document
as a "correspondent node" of the mobile node, and may itself be as a "correspondent node" of the mobile node, and may itself be
either a stationary node or a mobile node. either a stationary node or a mobile node.
Since a Binding Update, Binding Acknowledgement, and Binding Request Since a Binding Update, Binding Acknowledgement, and Binding Request
are each represented in a packet as an IPv6 destination option [6], are each represented in a packet as an IPv6 destination option [6],
they may be included in any IPv6 packet. Any of these options can be they may be included in any IPv6 packet. Any of these options can be
sent in either of two ways: sent in either of two ways:
- the messages can be included within any IPv6 packet carrying any - the messages can be included within any IPv6 packet carrying any
payload such as TCP [25] or UDP [24]. payload such as TCP [31] or UDP [30].
- the messages can be sent as a separate IPv6 packet containing - the messages can be sent as a separate IPv6 packet containing
no payload. In this case, the Next Header field in the last no payload. In this case, the Next Header field in the last
extension header in the packet is set to the value 59, to extension header in the packet is set to the value 59, to
indicate "No Next Header" [6]. indicate "No Next Header" [6].
Mobile IPv6 also defines one additional IPv6 destination option. Mobile IPv6 also defines one additional IPv6 destination option.
When a mobile node sends a packet while away from home, it will When a mobile node sends a packet while away from home, it will
generally set the Source Address in the packet's IPv6 header to one generally set the Source Address in the packet's IPv6 header to one
of its current care-of addresses, and will also include a "Home of its current care-of addresses, and will also include a "Home
skipping to change at page 11, line 13 skipping to change at page 13, line 5
non-mobile nodes. By also including the Home Address option in each non-mobile nodes. By also including the Home Address option in each
packet, the sending mobile node can communicate its home address to packet, the sending mobile node can communicate its home address to
the correspondent node receiving this packet, allowing the use of the correspondent node receiving this packet, allowing the use of
the care-of address to be transparent above the Mobile IPv6 support the care-of address to be transparent above the Mobile IPv6 support
level (e.g., at the transport layer). The inclusion of a Home level (e.g., at the transport layer). The inclusion of a Home
Address option in a packet affects only the correspondent node's Address option in a packet affects only the correspondent node's
receipt of this single packet; no state is created or modified in the receipt of this single packet; no state is created or modified in the
correspondent node as a result of receiving a Home Address option in correspondent node as a result of receiving a Home Address option in
a packet. a packet.
4.2. New IPv6 Destination Options 4.3. New IPv6 Destination Options
As mentioned in Section 4.1, the following four new IPv6 destination
options are defined for Mobile IPv6:
Binding Update
A Binding Update option is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked
as a "home registration". Any packet that includes a Binding
Update option MUST be protected by some authentication data
(see section 5.1), as defined in Section 4.4, to guard against
malicious Binding Updates. The Binding Update option and its
specific authentication requirements are described in detail in
Section 5.1.
Binding Acknowledgement
A Binding Acknowledgement option is used to acknowledge receipt
of a Binding Update, if an acknowledgement was requested
in the Binding Update. Any packet that includes a Binding
Acknowledgement option MUST be protected by some authentication
data (see section 5.2), as defined in Section 4.4, to guard
against malicious Binding Acknowledgements. The Binding
Acknowledgement option and its specific authentication
requirements are described in detail in Section 5.2.
Binding Request
A Binding Request option is used to request a mobile node to As mentioned in Section 4.2, the following new IPv6 destination
send to the requesting node a Binding Update containing the option is defined for Mobile IPv6:
mobile node's current binding. This option is typically used
by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication
is required for the Binding Request option. The Binding
Request option is described in detail in Section 5.3.
Home Address Home Address
A Home Address option is used in a packet sent by a mobile A Home Address option is used in a packet sent by a mobile
node to inform the recipient of that packet of the mobile node to inform the recipient of that packet of the mobile
node's home address. For packets sent by a mobile node while node's home address. For packets sent by a mobile node while
away from home, the mobile node generally uses one of its away from home, the mobile node generally uses one of its
care-of addresses as the Source Address in the packet's IPv6 care-of addresses as the Source Address in the packet's IPv6
header. By including a Home Address option in the packet, the header. By including a Home Address option in the packet, the
correspondent node receiving the packet is able to substitute correspondent node receiving the packet is able to substitute
the mobile node's home address for this care-of address when the mobile node's home address for this care-of address when
processing the packet, thus making the use of the care-of processing the packet, thus making the use of the care-of
address transparent to the correspondent node. If the IP address transparent to the correspondent node. If the IP
header of a packet carrying a Home Address option is covered header of a packet carrying a Home Address option is covered
by authentication, then the Home Address option MUST also be by authentication, then the Home Address option MUST also be
covered by this authentication, but no other authentication covered by this authentication, but no other authentication
is required for the Home Address option. See sections 10.2 is required for the Home Address option. See sections 10.2
and 5.4 for additional details about requirements for the and 5.3 for additional details about requirements for the
calculation and verification of the authentication data. The calculation and verification of the authentication data. The
Home Address option is described in detail in Section 5.4. Home Address option is described in detail in Section 5.3.
Mobile IPv6 also defines a number of "sub-options" for use within Mobile IPv6 also defines a number of "sub-options" for use within
these destination options; if included, any sub-options MUST destination options. If included, any sub-options MUST appear after
appear after the fixed portion of the option data specified in this the fixed portion of the option data specified in this document. The
document. The presence of such sub-options will be indicated by the presence of such sub-options will be indicated by the Option Length
Option Length field within the option. When the Option Length is field within the option. When the Option Length is greater than the
greater than the length required for the option specified here, the length required for the option specified here, the remaining octets
remaining octets are interpreted as sub-options. The encoding and are interpreted as sub-options. The encoding and format of defined
format of defined sub-options are described in Section 5.5. sub-options are described in Section 5.5.
4.3. Alignment Requirements for New Destination Options 4.4. Alignment Requirements for New Destination Options
IPv6 requires that options appearing in a Hop-by-Hop Options IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple of n octets from the start of the header, at an integer multiple of n octets from the start of the header,
for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within the alignment requirements, so that multi-octet values within the
Sub-Option Data field of each sub-option fall on natural boundaries. Sub-Option Data field of each sub-option fall on natural boundaries.
The alignment requirement of an option or sub-option is specified in The alignment requirement of an option or sub-option is specified in
skipping to change at page 13, line 5 skipping to change at page 14, line 10
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. Authentication Requirements for Binding Update and Acknowledgement 4.5. Security Design
Any packet that includes a Binding Update or Binding Acknowledgement 4.5.1. Security Threats
option has to contain some Authentication Data to guard against
malicious Binding Updates or Acknowledgements. The way that
the Authentication Data is computed has to provide sender
authentication, data integrity protection, and replay protection.
This section specifies requirements for which data is to be protected
when the Authentication Data Sub-Option is used to supply the
necessary authentication data for the Binding Update or Binding
Acknowledgement. Every IPv6 node which supports transmission or
reception of these destination options MUST support the computation
of the Authentication Data Sub-Option according to the rules in
this section. The Authentication Data Sub-Option MUST be the last
Sub-Option contained within any destination option in which the
Authentication Data Sub-Option occurs.
The Authentication Data covering a Binding Update or MUST be computed The MIPv6 protocol needs to protect itself against the following main
over a bitstring containing the following fields of the IPv6 header threats:
and destination options, in order:
- The IPv6 address of the destination of the packet, as seen by the 1. Threats against Binding Updates sent to home agents: a attacker
recipient might claim that a certain mobile node is currently at a
- Care-of Address, in the Source IP Address of the IPv6 header different location than it really is. If the home agent accepts
- The Home Address of the mobile node, from the Home Address the information sent to it as is, the mobile node might not get
destination option traffic destined to it, and other nodes might get traffic they
- Option Type of the Binding Update destination option didn't want.
- Option Length of the Binding Update destination option
- All flags of the Binding Update destination option
- Reserved Field of the Binding Update destination option
- Sequence Number Field of the Binding Update
- Lifetime of the Binding Update destination option
- The entire data from all Binding Update Sub-Options (except the
Authentication Data suboption), if any others exist
- The Type (i.e., the 8-bit value 0x04) and the Length of the
Authentication Data Sub-Option
- Security Parameters Index (SPI) of the Authentication Data
Sub-Option
When a Routing Header is used to deliver the Binding Update to 2. Threats against route optimization with correspondent nodes:
the receiving node, the address to be used for the Destination IP A malicious mobile node might lie about its home address. A
Address part of the computation will initially be located as the last malicious mobile node might send a correspondent node binding
component of the Routing Header. Otherwise, the address to be used updates in which the home address is set to the address of
will be the Destination IP Address in the IPv6 header of the outgoing another node, the victim. If the correspondent node accepted
packet. this forged binding update, then communications between the
correspondent node and the victim would be disrupted, because
packets that the correspondent node intended to send to the
victim would be sent to the wrong care-of address. This is a
threat to confidentiality as well as availability, because an
attacker might redirect packets meant for another node to itself
in order to learn the content of those packets.
When the Authentication Data Sub-Option is used with a Binding A malicious mobile node might lie about its care-of address. A
Acknowledgement, the Authentication Data MUST be computed over a malicious mobile node might send a correspondent node binding
bitstring containing the following data, in order: updates in which the care-of address is set to the address of
a victim node or an address within a victim network. If the
correspondent node accepted this forged binding update, then the
malicious mobile could trick the correspondent into sending data
to the victim node or the victim network; the correspondent's
replies to messages sent by the malicious mobile will be sent
to the victim host or network. This could be used to cause a
distributed denial of service attack; the malicious mobile could
trick a large number of servers so that they all send a large
amount of data to the same victim node or network. Several
variations of this threat are described elsewhere [1][33].
- The IPv6 address of the destination of the packet, as seen by the A malicious node might also send a large number of invalid
recipient binding updates to a victim correspondent node. If each invalid
- The Home Address of the sender binding update took a significant amount of resources (such as
- Option Type of the Binding Acknowledgement destination option CPU) to process before it could be recognized as invalid, then it
- Option Length of the Binding Acknowledgement might be possible to cause a denial of service attack by sending
- Status of the Binding Acknowledgement the correspondent so may invalid binding updates that it has no
- Sequence Number field of the Binding Acknowledgement resources left for other tasks.
- Lifetime field of the Binding Acknowledgement destination option
- Refresh field of the Binding Acknowledgement destination option
- The entire data from all Binding Acknowledgement Sub-Options
(except the Authentication Data suboption), if any others exist
- The Type (i.e., the 8-bit value 0x04) and the Length of the
Authentication Data Sub-Option
- Security Parameters Index (SPI) of the Authentication Data
Sub-Option
When a Home Address destination option is used to deliver the Binding An attacker might also replay an old binding update. An attacker
Acknowledgement to the receiving node, the Home Address of the sender might attempt to disrupt a mobile node's communications by
will be located in that destination option. Otherwise, the Home replaying a binding update that the node had sent earlier. If
Address of the sender will be located in the Source IP Address field the old binding update was accepted, packets destined for the
of the IPv6 header. mobile node would be sent to its old location and not its current
location.
If a Security Association applied to the packet for other reasons 3. Threats where MIPv6 correspondent node functionality is used
requires use of ESP [12], for example to encrypt the transport layer to launch reflection attacks against other parties [34] [23].
data carried in the packet, this use of ESP is not sufficient to The Home Address Option can be used to direct response traffic
satisfy the authentication requirements of Mobile IPv6. against a node whose IP address appears in the option, without
giving a possibility for ingress filtering to catch the forged
"return address".
Authentication Data assuring the integrity of Binding Updates and 4. Threats where the tunnels between the mobile node and the home
Binding Acknowledgement MAY, in some cases, instead be supplied by agent are attacked to make it appear like the mobile node is
other authentication mechanisms outside the scope of this document sending traffic while it is not.
(e.g., IPsec [13]). When alternative mechanisms are used, the same
data as indicated above MUST be included as part of the input data
stream for the authentication algorithm; however (according to the
requirements of the alternative authentication algorithm) the order
of the data elements in the input data stream MAY be changed from the
order specified within this section for use with the Authentication
Data Sub-Option (see section 5.5).
4.5. New IPv6 ICMP Messages 5. Threats where IPv6 Routing Header -- which is employed in
MIPv6 -- is used to circumvent IP-address based rules in
firewalls or to reflect traffic from other nodes. The generality
of the Routing Header allows the kind of usage that opens
vulnerabilities, even if the usage that MIPv6 needs is safe.
6. The security mechanisms of MIPv6 may also be attacked themselves,
e.g. in order to force the participants to execute expensive
cryptographic operations or allocate memory for the purpose of
keeping state.
Most of the above threats are concerned with denial of service. Some
of the threats also open up possibilities for man-in-the-middle,
hijacking, and impersonation attacks.
4.5.2. Security Features
This specification provides a number of security features. The main
features are:
- Protection of Binding Updates to home agents.
- Protection of Binding Updates to correspondent nodes.
- Protection against reflection attacks through the Home Address
Option.
- Protection of tunnels between the mobile node and the home agent.
- Preventing Routing Header vulnerabilities.
- Preventing Denial-of-Service attacks to the MIPv6 security
mechanisms themselves.
Protecting the Binding Updates to home agents and to correspondent
nodes require very different security solutions due to the different
situations. Mobile nodes and home agents know each other, and can
thus have a strong security association to reliably authenticate
the exchanged messages. In this environment, IPsec Encapsulating
Security Payload (ESP) can be used to implement the necessary
security features. See Section 4.5.5.
The protection of Binding Updates to correspondents is a much harder
problem for the traditional strong authentication approach. It is
expected that MIPv6 will be used on a global basis between nodes
belonging under different administrative domains, hence building
an authentication infrastructure to authenticate mobile nodes
and correspondent nodes would be a very demanding task. Thus, an
infrastructureless approach is necessary. Furthermore, making a
traditional authentication infrastructure keep track of correct
IP addresses for all hosts is either impossible or at least very
hard. That is, it isn't sufficient to authenticate mobile nodes,
authorization to claim right to use an address is needed.
A different approach is therefore necessary. The chosen method
verifies that the mobile node is ``live'' (that is, it responds to
probes) at its home and care-of addresses by performing a cookie
exchange with the addresses, and by requiring that the eventual
binding update is cryptographically bound to the sent cookies.
Some additional protection is provided by requiring the cookies be
protected by ESP when forwarded by the Home Agent to the mobile node.
This method limits the vulnerabilities to those attackers who are
on the path between the Home Agent and the correspondent node. As
adversaries on this path would be able to cause also other types of
attacks, this is seen as sufficient base security between mobile and
correspondent nodes.
Vulnerabilities relating to the use of correspondent nodes as
reflectors via the Home Address Option can be solved as follows. We
ensure that the mobile node is authorized to use a given home address
before HAO can be used. Such authorization is already performed in
the context of Route Optimization, and therefore this specification
limits the use of the HAO to the situation where the correspondent
node already has a binding cache entry for the given home address.
Tunnels between the mobile node and the home agent can be
protected by ensuring proper use of source addresses, and optional
cryptographic protection. These procedures are discussed in
Section 4.5.3.
Vulnerabilities related to the Routing Header can be prevented by
using a MIPv6 specific type of a Routing Header. This type provides
the necessary functionality but does not open vulnerabilities.
Denial-of-Service threats against MIPv6 security mechanisms
themselves concern mainly the Binding Update procedures with
correspondent nodes. The protocol has been designed to limit the
effects of such attacks, as will be described in Section 4.5.6.
4.5.3. Securing Tunnels to and from the Home Agents
Tunnels between the mobile node and the home agent need protection
so that it isn't possible for anyone to send traffic through the
home agent, pose as the mobile node, and escape detection through
traditional tracing mechanisms.
If Binding Updates sent to the home agents are secure, and the home
agent verifies the outer IP address corresponds to the current
location of the mobile node, this prevents attacks against the tunnel
from other IP addresses. This prevents attacks where the attacker
is controlled by ingress filtering, as well as attacks where the
attacker does not know the current care-of address of the mobile
node. Attackers who know the care-of address are not controlled by
ingress filtering could still send traffic through the home agent,
but they could also send spoofed packets without using a tunnel.
Encapsulating the tunneled traffic inside IPsec ESP offers an
optional mechanism to protect the confidentiality and integrity of
the traffic against on-path attackers.
4.5.4. Securing Binding Updates to Home Agents
Signaling between the mobile node and the home agent requires message
integrity, correct ordering and replay protection.
In order to have this protection, the mobile node and the home agent
must have a security association. IPsec Encapsulating Security
Payload (ESP) can be used to for integrity protection when a non-null
authentication algorithm is applied.
However, IPsec can provide replay protection only when dynamic
security association establishment is used. This may not always be
possible, and manual keying would be preferred in some cases. IPsec
also does not guarantee correct ordering of packets, only that they
have not been replayed. Because of this, Mobile IPv6 does not rely
on IPsec replay protection and provides its own mechanism inside the
Binding Update and Acknowledgement messages. A sequence number field
is used to ensure correct ordering and to prevent replay protection.
Both the mobile node and the home agent MUST use non-volatile memory
to store the sequence number so that a reboot does not prevent the
acceptance of new Binding Updates.
A sliding window scheme is used for the sequence numbers. Therefore
the protection against replays and reordering attacks works when
the attacker remembers up to a maximum of 2^31 Binding Updates.
The mobile node and the home agent MAY agree on a new key for the
security association before this many Binding Updates have been sent
if this is an issue.
Note that while the required non-volatile memory is an additional
burden in particular for the mobile node, the use of sequence numbers
reduces the number of roundtrips necessary for the update procedure
compared to other schemes that would not have required non-volatile
memory. Note also that implementations do not necessarily have to
write the non-volatile memory every time they send a Binding Update,
if they always write a somewhat larger sequence number to the memory
and only update the memory again once the used sequence numbers go
beyond this larger number. For instance, if the sequence number
starts at 0, the value 100 can be written to the memory so that
the next write can be done when the sequence numbers from 0 to 99
have been used. This reduces the need for frequent updates to the
non-volatile memory, which improves performance and may be necessary
in some cases to lengthen the lifetime of the used memory components.
In order to protect messages exchanged between the mobile node and
the home agent with IPsec, appropriate Security Policy Database (SPD)
entries must be created. We need to avoid the possibility that a
mobile node could use its security association to send a Binding
Update on behalf of another mobile node using the same home agent.
In order to do this, the SPD entries MUST unequivocally identify a
single SA for any given home address and home agent. In order for
the home address of the mobile node to be visible when the policy
check is made, the mobile node MUST use the Home Address Option in
Binding Updates sent to the home agent. The home address in the Home
Address Option and the Binding Update message MUST be equal and MUST
be checked by the home agent.
4.5.5. Securing Binding Updates to Correspondent Nodes
Binding Updates to correspondent nodes are protected using the Return
Routability (RR) method. This method uses the following principles:
- A cookie exchange verifies that the mobile node is ``live'' at
its addresses, or is at least able to receive traffic on them.
- Protecting the eventual binding update cryptographically using
the cookies.
- Requiring that the cookies be protected by ESP when forwarded by
the Home Agent to the mobile node.
- The use of symmetric exchanges were responses are sent to the
same address as the request was sent from, to avoid the use of
this protocol in reflection attacks.
- Stateless operation at correspondent nodes until they receive the
a binding update that can be authorized.
The RR protocol can be broken by an attacker on the route between the
home agent and the correspondent node, but not by attackers on the
network the mobile node is currently at and not from elsewhere on the
Internet.
Each correspondent node has a secret key, Kcn. This key does not
need to be shared with any other entity, so no key distribution
mechanism is needed for it. Each correspondent node also generates
a nonce, Nj, at regular intervals, for example every few minutes. A
correspondent node uses the same Kcn and Nj with all the mobiles it
is in communication with, so that it does not need to generate and
store a new Nj when a new mobile contacts it. Each value of Nj is
identified by the subscript j. This subscript is communicated in the
protocol, so that if Nj is replaced by N(j+1) part way through a run
of a protocol, the correspondent can distinguish messages that should
be checked against the old nonce from messages that should be checked
against the new nonce. Correspondent nodes keep both the current
value of Nj and a small set of previous values N(j-1), N(j-2), ...
Older values can be discarded, and messages using them will can be
rejected as replays.
Kcn can be either a fixed value or regularly updated. An update
of Kcn can be done at the same time as an update of Nj, so that j
identifies both the nonce and the key. A correspondent node can
generate a fresh Kcn each time that it boots to avoid the need for
secure persistent storage for Kcn.
The RR signaling happens as follows:
1. MN(HoA) -> CN: HoTI(HoA)
2. MN(CoA) -> CN: CoTI(CoA)
3. CN -> MN(HoA): HoT(K0, j)
4. CN -> MN(CoA): CoT(K1, l)
5. MN(CoA) -> CN: BU(HoA, CoA, MAC, j, l)
6. CN -> MN(CoA): BA(MAC)
7. CN -> MN(HoA): BR(MAC)
Messages 1 and 2 are sent simultaneously, as are messages 3 and
4. Message 5 actually creates a binding, and messages 6 and 7 are
optional. The messages are described in more detail below:
1. HoTI (Home Test Init) Message:
When a mobile nodes wants to perform route optimization it sends
a HoTI message to the correspondent node in order to initiate the
return routability verification for the Home Address.
MN(HoA) -> CN: HoA
This message tells the mobile node's home address to the
correspondent node. The address is used later to create a
cookie. This message is reverse tunneled through the Home Agent.
2. CoTI (Care-of Test Init) Message:
When a mobile nodes wants to perform route optimization it sends
a CoTI message to the correspondent node in order to initiate the
return routability verification for the care-of Address.
MN(CoA) -> CN: CoA
The second message is sent in parallel with the first one. It
tells the correspondent node the mobile node's care-of address,
which is later used to create a cookie. This message is sent
directly to the correspondent node.
3. HoT (Home Test) Message:
This message is sent in response to a HoTI message.
CN -> MN(HoA): K0, j
When the correspondent node receives the HoTI message, it
generates a cookie K0 as follows:
K0 = MAC_Kcn(HoA | Nj | 0)
The cookie and the value j are sent to the mobile node via the
Home Agent; it is an assumption of the protocol that the home
agent - mobile node route is secure. K0 also acts as a challenge
to test that the mobile can receive messages sent to its home
address.
The index j is carried along in the protocol to allow the CN
to later efficiently find the nonce value Nj that it used in
creating this cookie.
The notation used here is as follows. MAC_K(m) denotes a
message authentication code computed on message m with key K.
H(m) denotes a hash of message m. HMAC SHA1 function [15][21]
is used to compute the message authentication code, and SHA1
function [21] is used to compute the hash. The final ``0''
inside the MAC function is a 32-bit integer used to distinguish
home and care-of cookies from each other.
4. CoT (Care-of Test) Message:
This message is sent in response to a CoTI message.
CN -> MN(CoA): K1, i
The correspondent also sends a challenge to the mobile's care-of
address. When the correspondent node receives the CoTI message,
it generates a cookie K1 as follows:
K1 = MAC_Kcn(CoA | Ni | 1)
The cookie and the value i are sent directly the mobile node.
The final 1 inside the MAC function is a 32-bit integer, again
used for distinguishing home and care-of cookies from each other.
Again, an index is sent along the cookie in order to identify
the used nonce Ni. Note that i and j are likely to be the same
in HoT and CoT messages, except when nonce values happen to have
changed between the reception of HoT and the CoT messages.
5. BU (Binding Update) Message:
When the MN has received both the HoT and CoT is has the cookies
necessary to send the Binding Update.
MN(CoA) -> CN: BU, HoA, CoA,
MAC_Kbu(CoA | HoA | BU | 0),
j, i
The mobile node hashes together the challenges and to form a
session key (Kbu), and then uses this session key to authenticate
a binding update:
Kbu = H(K0 | K1)
The message contains j and i, so that the correspondent knows
which value of Nj and Ni to use to recompute the session key.
"BU" is the content of the BU message. Once the correspondent
node has verified the MAC, it can create a binding cache entry
for the mobile.
6. BA (Binding Acknowledgement) Message:
The Binding Update is optionally acknowledged by the
correspondent node.
CN -> MN(CoA): BA,
MAC_Kbu(CoA | HoA | BA | 0),
The correspondent node uses the same key (Kbu) to authenticate a
binding acknowledgement. "BA" is the content of the BA message.
7. BR (Binding Request) Message:
The correspondent node can optionally request a binding to be
refreshed using the Binding Request message. This message can be
authenticated using the same Kbu that was created earlier.
CN -> MN(HoA): BR,
MAC_Kbu(HoA | BR | 0),
"BR" is the content of the BR message.
This protocol also protects the participants against replayed binding
updates. The attacker can't replay the same message due to the
sequence number which is a part of the MIPv6 binding update itself,
and the attacker can't modify the binding update since the MAC would
not verify after that. Care must be taken when removing bindings
at the correspondent node, however. If a binding is removed either
due to garbage collection, request, or expiration and the nonce
used in its creation is still valid, an attacker can replay the old
binding update. This can be prevented by having the correspondent
node change the nonce often enough to ensure that the nonces used
when removed entries were created are no longer valid. If many such
deletions occur the correspondent can batch them together to avoid
having to increment the nonce index too often.
4.5.6. Preventing Denial-of-Service Attacks
The RR protocol has been designed with protection against resource
exhaustion Denial-of-Service attacks. In these attacks the victim
has only a limited amount of some resource (such as network bandwidth
or CPU cycles), and the attack consumes some of this resource. This
leaves the victim without enough resources to carry out other work.
The correspondent nodes do not have to retain any state about
individual mobile nodes until an authentic binding update arrives.
This is achieved through the use of the nonces and Kcn that are
not specific to individual mobile nodes. Yet the cookies are
specific, but they can be reconstructed based on the CoA and HoA
information that arrives with the binding update. This means that
the correspondent nodes are safe against memory exhaustion attacks
except where on-path attackers are concerned. Due to the use of
symmetric cryptography, the correspondent nodes are relatively safe
against CPU resource exhaustion attacks as well.
Nevertheless, as [1] describes, there are situations it is impossible
for the mobile and correspondent nodes to determine if they actually
need a binding or whether they just have been fooled into believing
so by an attacker. Therefore, it is necessary to treat situations
where such attacks are being made.
The binding updates that are used in mobile IPv6 are only an
optimization. A mobile node can communicate with a correspondent
node even if the correspondent refuses to accept any of its binding
updates. However, performance will suffer because packets from the
correspondent to the mobile will be routed via the mobile's home
agent rather than a more direct route. A correspondent can protect
itself against some of the resource exhaustion attacks by stopping
processing binding updates when it is flooded with a large number of
binding updates that fail the cryptographic integrity checks. If a
correspondent finds that it is spending more resources on checking
bogus binding updates than it is likely to save by accepting genuine
binding updates, then it can decide to reject all binding updates
without performing any cryptographic operations.
Additional information needed to make this decisions about responding
to requests will usually originate in layers above IP. For example,
TCP knows if the node has a queue of data that it is trying to send
to a peer. It is possible to produce a conforming implementation of
the protocols in this memo without making use of information from
higher protocol layers, but implementations MAY be able to manage
resources more effectively by making use of such information.
4.5.7. Design Rationale
The motivation for designing the RR protocol was to have sufficient
support for mobile IP, without creating major new security problems.
A protocol was needed against the new vulnerabilities introduced by
IP mobility. It was not our goal to protect against attacks that
were already possible before the introduction of IP mobility. This
protocol does not defend against an attacker who can monitor the home
agent to correspondent node path, as such attackers would in any case
be able to mount an active attack against the mobile node when it
is at its home location. The possibility of such attacks is not an
impediment to the deployment of mobile IP, because these attacks are
possible irrespective of whether mobile IP is in use or not.
This protocol also protects against denial of service attacks in
which the attacker pretends to be a mobile, but uses the victim's
address as the care of address, and so causes the correspondent
to send the victim traffic that it does not want. For example,
suppose that the correspondent is a news site that will send a
high-bandwidth stream of video to anyone who asks for it. Note that
the use of flow-control protocols such as TCP does not necessarily
defend against this type of attack, because the attacker can fake the
acknowledgements. Even keeping TCP initial sequence numbers secret
doesn't help, because the attacker can receive the first few segments
(including the ISN) at its own address, and then redirect the stream
to the victim's address. This protocol defends against these attacks
by only completing if packets sent by the correspondent to the care
of address are received and processed by an entity that is willing to
participate in the protocol. Normally, this will be the mobile node.
For further information about the design of RR and other protocols,
see [1] [33] [22] [23].
4.6. New IPv6 ICMP Messages
Mobile IPv6 also introduces four new ICMP message types, two for use Mobile IPv6 also introduces four new ICMP message types, two for use
in the dynamic home agent address discovery mechanism, and two for in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in 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.2, the following two new ICMP message types are
used for home agent address discovery: 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
in detail in Section 5.7. in detail in Section 5.6.
Home Agent Address Discovery Reply Home Agent Address Discovery Reply
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.8. described in detail in Section 5.7.
The next two message types are used for network renumbering The next two message types are used for network renumbering
and address configuration on the mobile node, as described in and address configuration on the mobile node, as described in
Section 9.6: Section 9.7:
Mobile Prefix Solicitation Mobile Prefix Solicitation
The ICMP Mobile Prefix Solicitation message is used by a mobile The ICMP Mobile Prefix Solicitation message is used by a mobile
node to request prefix information about the home subnet, in node to request prefix information about the home subnet, in
order to retrieve prefixes that are served by home agents and order to retrieve prefixes that are served by home agents and
can be used to configure one or more home addresses, or to can be used to configure one or more home addresses, or to
refresh home addresses before the expiration of their validity. refresh home addresses before the expiration of their validity.
This message is specified in Section 5.9. This message is specified in Section 5.8.
Mobile Prefix Advertisement Mobile Prefix Advertisement
The ICMP Mobile Prefix Advertisement is used by a home agent to The ICMP Mobile Prefix Advertisement is used by a home agent to
distribute information to a mobile node about prefixes on the distribute information to a mobile node about prefixes on the
home link which are available for use by the mobile node while 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 away from home. This message may be sent as a response to a
Mobile Prefix Solicitation, or due to network renumbering or Mobile Prefix Solicitation, or due to network renumbering or
other prefix changes as specified in Section 5.10 other prefix changes as specified in Section 9.9.3
4.6. Conceptual Data Structures 4.7. 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
MAY be implemented in any manner consistent with the external MAY be implemented in any manner consistent with the external
behavior described in this document, for example by being behavior described in this document, for example by being
combined with the node's Destination Cache as maintained by combined with the node's Destination Cache as maintained by
Neighbor Discovery [17]. When sending a packet, the Binding Neighbor Discovery [20]. When sending a packet, the Binding
Cache is searched before the Neighbor Discovery conceptual Cache is searched before the Neighbor Discovery conceptual
Destination Cache [17] (i.e., any Binding Cache entry for this Destination Cache [20] (i.e., any Binding Cache entry for this
destination SHOULD take precedence over any Destination Cache destination SHOULD take precedence over any Destination Cache
entry for the same destination). Each Binding Cache entry entry for the same destination). Each Binding Cache entry
conceptually contains the following fields: conceptually contains the following fields:
- The home address of the mobile node for which this is the - The home address of the mobile node for which this is the
Binding Cache entry. This field is used as the key for Binding Cache entry. This field is used as the key for
searching the Binding Cache for the destination address of searching the Binding Cache for the destination address of
a packet being sent. If the destination address of the a packet being sent. If the destination address of the
packet matches the home address in the Binding Cache entry, packet matches the home address in the Binding Cache entry,
this entry SHOULD be used in routing that packet. this entry SHOULD be used in routing that packet.
skipping to change at page 18, line 22 skipping to change at page 27, line 47
- 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.7 and 10.9), 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.10). this previous care-of address (Section 10.11).
- 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
skipping to change at page 19, line 12 skipping to change at page 28, line 39
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.15. destination, as described in Section 10.17.
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
Neighbor Discovery [17], although the Home Agents List MAY be Neighbor Discovery [20], although the Home Agents 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. described in this document.
Each home agent maintains a separate Home Agents List for Each home agent maintains a separate Home Agents List for
each link on which it is serving as a home agent; this list each link on which it is serving as a home agent; this list
is used by a home agent in the dynamic home agent address is used by a home agent in the dynamic home agent address
discovery mechanism. Each mobile node, while away from home, discovery mechanism. Each mobile node, while away from home,
also maintains a Home Agents List, to enable it to notify a also maintains a Home Agents List, to enable it to notify a
home agent on its previous link when it moves to a new link; a home agent on its previous link when it moves to a new link; a
mobile node MAY maintain a separate Home Agents List for each mobile node MAY maintain a separate Home Agents List for each
skipping to change at page 19, line 45 skipping to change at page 29, line 20
maintain a single list for all links. Each Home Agents List maintain a single list for all links. Each Home Agents List
entry conceptually contains the following fields: entry conceptually contains the following fields:
- The link-local IP address of a router on the link, that - The link-local IP address of a router on the link, that
this node currently believes is operating as a home agent this node currently believes is operating as a home agent
for that link. A new entry is created or an existing for that link. A new entry is created or an existing
entry is updated in the Home Agents List in response to entry is updated in the Home Agents List in response to
receipt of a valid Router Advertisement in which the Home receipt of a valid Router Advertisement in which the Home
Agent (H) bit is set. The link-local address of the home Agent (H) bit is set. The link-local address of the home
agent is learned through the Source Address of the Router agent is learned through the Source Address of the Router
Advertisements received from it [17]. Advertisements received from it [20].
- 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 [20].
Are there interactions with the new Router Are there interactions with the new Router
Advertisement stuff? 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
skipping to change at page 20, line 36 skipping to change at page 30, line 10
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 Can we delete the preference stuff? Is anyone using
it? it?
4.7. Binding Management 4.8. Binding Management
When a mobile node configures a new care-of address and decides to When a mobile node configures a new care-of address and decides to
use this new address as its primary care-of address, the mobile use this new address as its primary care-of address, the mobile
node registers this new binding with its home agent by sending node registers this new binding with its home agent by sending
the home agent a Binding Update. The mobile node indicates the home agent a Binding Update. The mobile node indicates
that an acknowledgement is needed for this Binding Update and that an acknowledgement is needed for this Binding Update and
continues to periodically retransmit it until acknowledged. The continues to periodically retransmit it until acknowledged. The
home agent acknowledges the Binding Update by returning a Binding home agent acknowledges the Binding Update by returning a Binding
Acknowledgement to the mobile node. Acknowledgement to the mobile node.
skipping to change at page 21, line 13 skipping to change at page 30, line 38
to the correspondent node, allowing it to cache the mobile node's to the correspondent node, allowing it to cache the mobile node's
binding for routing future packets to it. Although the mobile node binding for routing future packets to it. Although the mobile node
may request an acknowledgement for this Binding Update, it need not, may request an acknowledgement for this Binding Update, it need not,
since subsequent packets from the correspondent node will continue since subsequent packets from the correspondent node will continue
to be intercepted and tunneled by the mobile node's home agent, to be intercepted and tunneled by the mobile node's home agent,
effectively causing any needed Binding Update retransmission. effectively causing any needed Binding Update retransmission.
If the mobile node receives such a tunneled packet but does not have If the mobile node receives such a tunneled packet but does not have
a BSA with the correspondent node, the mobile node SHOULD initiate a BSA with the correspondent node, the mobile node SHOULD initiate
the process of establishing the necessary security association by the process of establishing the necessary security association by
following the procedures outlined in [?]. following the procedures outlined in Section 4.5
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.
skipping to change at page 22, line 10 skipping to change at page 31, line 36
packets can be achieved from the correspondent node to the mobile packets can be achieved from the correspondent node to the mobile
node. Routing packets directly to the mobile node's care-of address node. Routing packets directly to the mobile node's care-of address
also eliminates congestion at the mobile node's home agent and home also eliminates congestion at the mobile node's home agent and home
link. In addition, the impact of any possible failure of the home link. In addition, the impact of any possible failure of the home
agent, the home link, or intervening networks leading to or from the agent, the home link, or intervening networks leading to or from the
home link is reduced, since these nodes and links are not involved in home link is reduced, since these nodes and links are not involved in
the delivery of most packets to the mobile node. the delivery of most packets to the mobile node.
5. New IPv6 Destination Options and Message Types 5. New IPv6 Destination Options and Message Types
5.1. Binding Update Option 5.1. Mobility Header
The Binding Update destination option is used by a mobile node The Mobility Header is used by mobile nodes, correspondent nodes, and
to notify other nodes of a new care-of address for itself. As a home agents in all messaging related to the creation and management
destination option, it MAY be included in any existing packet being of bindings. The Mobility Header is an IPv6 protocol. Rules
sent to this same destination or MAY be sent in a packet by itself; regarding how it is sent and what addresses are used in the IPv6
a packet containing a Binding Update is sent in the same way as any header are given separately in Sections 5.1.2 to 5.1.9. Mobile nodes
packet sent by a mobile node (Section 10.1). MUST use reverse tunneling to send Mobility Header messages when the
source address is set to the home address of the mobile node.
The Binding Update option is encoded in type-length-value (TLV) 5.1.1. Format
format as follows:
The Mobility Header is identified by a Next Header value of 62 (XXX)
in the immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Proto | Header Len | MH Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto
8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the
IPv4 Protocol field [10].
This field is intended to be used by a future specification
of piggybacking binding messages on payload packets (see
Section 12.1).
Thus implementations conforming to this specification MUST set
the payload protocol type to NO_NXTHDR (59 decimal).
Header Len
8-bit unsigned integer. Length of the Mobility Header in units
of 8 octets, including the the Payload Proto, MH Type, Header
Len, Checksum, and Message Data fields.
MH Type
16-bit selector. Identifies the particular mobility message in
question. Legal values are defined in Sections 5.1.2 to 5.1.8.
An unrecognized MH Type field SHOULD cause an error to be sent
to the source.
Checksum
16-bit unsigned integer. This field contains the checksum
of the Mobility Header. The checksum is the 16-bit one's
complement of the one's complement sum of the entire Mobility
Header starting with the Payload Proto field, prepended with a
"pseudo-header" of IPv6 header fields, as specified in [IPv6,
section 8.1]. The Next Header value used in the pseudo-header
is 62 (XXX). For computing the checksum, the checksum field is
set to zero.
Message Data
A variable length field containing the data specific to the
indicated Mobility Header type.
5.1.2. Binding Request (BR) Message
The Binding Request (BR) message is used to request a mobile node's
binding from the mobile node. A packet containing a Binding Request
message is sent in the same way as any packet to a mobile node
(Section 8.9). When a mobile node receives a packet containing a
Binding Request message and there already exists a Binding Update
List entry for the source of the Binding Request, it MAY start
a Return Routability Procedure (see Section 4.5) if it believes
the amount of traffic with the correspondent justifies the use of
Route Optimization. Note that the mobile node SHOULD NOT respond
Binding Requests from previously unknown correspondent nodes due to
Denial-of-Service concerns.
The Binding Request message uses the MH Type value 0. When this
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved | Sequence # | | |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
Reserved
16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be initialized to zero by the
sender, and MUST be ignored by the receiver.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand. A
Binding Request MUST include the following parameter:
- Authentication Data parameter. This parameter contains a
cryptographic hash value which is used to ensure that it
has been sent by the correspondent node. The authenticator
covering a Binding Acknowledgement MUST be computed over
a bitstring containing the following fields of the IPv6
header and the Mobility Header, in order:
* The Home Address of the mobile node, from the
Destination Address field of the IPv6 header.
* The address of the correspondent node, from the Source
Address field of the IPv6 header.
* The contents of the Mobility Header, excluding the
Authenticator field (inside the Authentication Data
parameter) which is included as zeroes for the purposes
of calculating the Authenticator.
* Four bytes of zero. This is included for a potential
future extension.
The actual authenticator calculation over sequence of bits
is described in Section 4.5.
There MAY be additional information, associated with this
Binding Request message, that need not be present in all
Binding Requests sent. This use of MH parameters also allows
for future extensions to the format of the Binding Request
message to be defined. The encoding and format of defined
parameters are described in Section 5.2. The following
parameters are valid in a Binding Request message:
- Unique Identifier Parameter
If no actual parameters are present in this message, no padding is
necessary.
5.1.3. Home Test Init (HoTI) Message
The Home Test Init (HoTI) message is used to initiate the Return
Routability procedure from the mobile node to a correspondent node
(see Section 10.9). This message is always sent with the Source
Address set to the home address of the mobile node, Destination
Address set to the correspondent node's address, and is tunneled
through the home agent when the mobile node is away from home.
The HoTI message uses the MH Type value 1. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type Flags
198 = 0xC6 16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be initialized to zero by the
sender, and MUST be ignored by the receiver.
Option Length Parameters
8-bit unsigned integer. Length of the option, in octets, Variable-length field, of length such that the complete
excluding the Option Type and Option Length fields. This field Mobility Header is an integer multiple of 8 octets long.
MUST be set to 8 plus the total length of all sub-options Contains one or more TLV-encoded parameters. The receiver MUST
present, including their Sub-Option Type and Sub-Option Len ignore and skip any parameters which it does not understand.
fields.
There MAY be additional information, associated with this
message that need not be present in all HoTI messages. This
use of MH parameters also allows for future extensions to the
format of the HoTI message to be defined. The encoding and
format of defined parameters are described in Section 5.2. The
following parameters are valid in a HoTI message:
- Unique Identifier Parameter
If no actual parameters are present in this message, 4 bytes of Pad1
or PadN parameters are needed to make the length of the message a
multiple of 8.
The HoTI message SHOULD be protected by an IPsec policy that employs
ESP between the home agent and the mobile node.
A packet that includes a HoTI message MUST NOT include a Home Address
option.
5.1.4. Care-of Test Init (CoTI) Message
The Care-of Test Init (CoTI) message is used to initiate the Return
Routability procedure from the mobile node to a correspondent node
(see Section 10.9). This message is always sent with the Source
Address set to the care-of address of the mobile node, and is sent
directly to the correspondent node.
The CoTI message uses the MH Type value 2. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be initialized to zero by the
sender, and MUST be ignored by the receiver.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
There MAY be additional information, associated with this
message that need not be present in all CoTI messages. This
use of MH parameters also allows for future extensions to the
format of the CoTI message to be defined. The encoding and
format of defined parameters are described in Section 5.2. The
following parameters are valid in a CoTI message:
- Unique Identifier Parameter
If no actual parameters are present in this message, no padding is
necessary.
A packet that includes a CoTI message MUST NOT include a Home Address
option.
5.1.5. Home Test (HoT) Message
The Home Test (HoT) message is an answer to the HoTI message, and
is sent from the correspondent node to the mobile node (see Section
8.2). This message is always sent with the Destination Address set
to the home address of the mobile node, Source Address set to the
address of the correspondent node, and is tunneled through the home
agent when the mobile node is away from home.
The HoT message uses the MH Type value 3. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Home Nonce Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Cookie (128 bits) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
32-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be set to zero, otherwise an
error MUST be returned to the sender.
Home Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update. It
will allow the correspondent node to select the appropriate
challenge values to authenticate the binding update.
Home Cookie
This field contains the cookie K0 in the Return Routability
Procedure; it is the first of two cookies which are to be
processed to form a key which is then used to authenticate a
binding update.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
There MAY be additional information, associated with this
message that need not be present in all HoT messages. MH
parameters are used to carry that information. The encoding
and format of defined parameters are described in Section 5.2.
This use of MH parameters also allows for future extensions
to the format of the HoT message to be defined. This
specification does not define any optional parameters for the
HoT message.
If no actual parameters are present in this message, 4 bytes of Pad1
or PadN parameters are needed to make the length of the message a
multiple of 8.
The HoT message SHOULD be protected by an IPsec policy that employs
ESP between the home agent and the mobile node, in order to prevent
attackets e.g. on the same link as the MN to receive the Home
Cookie.
5.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is an answer to the CoTI message, and
is sent from the correspondent node to the mobile node (see Section
8.2). This message is always sent with the Source Address set to the
address of the correspondent node, the Destination Address set to
the care-of address of the mobile node, and is sent directly to the
mobile node.
The CoT message uses the MH Type value 4. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Care-of Nonce Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Care-of Cookie (128 bits) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
32-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be set to zero, otherwise an
error MUST be returned to the sender.
Care-of Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update. It
will allow the correspondent node to select the appropriate
challenge values to authenticate the binding update.
Care-of Cookie
This field contains the cookie K1 in the Return Routability
Procedure; it is the second of two cookies which are to be
processed to form a key which is then used to authenticate a
binding update.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
There MAY be additional information, associated with this
message that need not be present in all CoT messages. MH
parameters are used to carry that information. The encoding
and format of defined parameters are described in Section 5.2.
This use of MH parameters also allows for future extensions
to the format of the CoT message to be defined. This
specification does not define any optional parameters for the
CoT message.
If no actual parameters are present in this message, 4 bytes of Pad1
or PadN parameters are needed to make the length of the message a
multiple of 8.
5.1.7. Binding Update (BU) Message
The Binding Update (BU) message is used by a mobile node to notify
other nodes of a new care-of address for itself. A packet containing
a Binding Update message is sent with the Source Address set to the
care-of address of the mobile node and the Destination Address set to
the correspondent node's address.
The Binding Update message uses the MH Type value 5. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobile node to The Acknowledge (A) bit is set by the sending mobile node to
request a Binding Acknowledgement (Section 5.2) be returned request a Binding Acknowledgement (Section 5.1.8) be returned
upon receipt of the Binding Update. upon receipt of the Binding Update.
Home Registration (H) Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node The Home Registration (H) bit is set by the sending mobile node
to request the receiving node to act as this node's home agent. to request the receiving node to act as this node's home agent.
The destination of the packet carrying this option MUST be that The destination of the packet carrying this message MUST be
of a router sharing the same subnet prefix as the home address that of a router sharing the same subnet prefix as the home
of the mobile node in the binding (given by the Home Address address of the mobile node in the binding (given by the Home
field in the Home Address option in the packet). Address field in the Home Address option in the packet).
Single Address Only (S) Single Address Only (S)
If the `S' bit is set, the mobile node requests that the home If the `S' bit is set, the mobile node requests that the home
agent make no changes to any other Binding Cache entry except agent make no changes to any other Binding Cache entry except
for the particular one containing the home address specified in for the particular one containing the home address specified in
the Home Address option. This disables home agent processing the Home Address option. This disables home agent processing
for other related addresses, as is described in section 9.1. for other related addresses, as is described in Section 9.1.
Duplicate Address Detection (D) Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit is set by the sending The Duplicate Address Detection (D) bit is set by the sending
mobile node to request the receiving node (the mobile node's mobile node to request the receiving node (the mobile node's
home agent) to perform Duplicate Address Detection [27] on home agent) to perform Duplicate Address Detection [35] on
the mobile node's home link for the home address in this the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H) binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. If the Duplicate Address Detection performed by otherwise. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection Acknowledgement will be set to 138 (Duplicate Address Detection
failed). failed).
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Sequence # Sequence #
An 8-bit number used by the receiving node to sequence Binding A 16-bit number used by the receiving node to sequence Binding
Updates and by the sending node to match a returned Binding Updates and by the sending node to match a returned Binding
Acknowledgement with this Binding Update. Each Binding Update Acknowledgement with this Binding Update. Each Binding Update
sent by a mobile node MUST use a Sequence Number greater than sent by a mobile node MUST use a Sequence Number greater than
the Sequence Number value sent in the previous Binding Update the Sequence Number value sent in the previous Binding Update
(if any) to the same destination address (modulo 2**8, as (if any) to the same destination address (modulo 2**16, as
defined in Section 4.6). There is no requirement, however, defined in Section 4.7). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each that the Sequence Number value strictly increase by 1 with each
new Binding Update sent or received. new Binding Update sent or received. Both home agents and
correspondent nodes use the sequence number also to prevent
replay attacks.
Lifetime Lifetime
32-bit unsigned integer. The number of seconds remaining 32-bit unsigned integer. The number of seconds remaining
before the binding MUST be considered expired. A value of all before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST indicates that the Binding Cache entry for the mobile node MUST
be deleted. be deleted.
Sub-Options Home Address
Additional information, associated with this Binding Update This field tells the correspondent node the home address of the
option. This use of sub-options also allows for future mobile node.
extensions to the format of the Binding Update option to be
defined. The encoding and format of defined sub-options are
described in Section 5.5. The following sub-options are valid
in a Binding Update option:
- Unique Identifier Sub-Option Parameters
- Alternate Care-of Address Sub-Option Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand. A
Binding Update sent to a correspondent node MUST include the
following parameters:
- Authentication Data Sub-Option (see section 4.4 for - Nonce Indices parameter. This parameter contains
authentication requirements). information the correspondent node needs in order to find
the challenge values Nj and Ni.
The alignment requirement [6] for the Binding Update option is 4n+2. - Authentication Data parameter. This parameter contains a
cryptographic hash value which is used to ensure that it
has been sent by the same party who received the HoT and
CoT messages. The authenticator covering a Binding Update
MUST be computed over a bitstring containing the following
fields of the IPv6 header and the Mobility Header, in
order:
Any packet that includes a Binding Update option MUST also include * Care-of Address, in the Source Address field of the
a Home Address option. The home address of the mobile node in the IPv6 header
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
the packet.
Any packet that includes a Binding Update option MUST contain * The address of the correspondent node, in the
authentication data to guard against malicious Binding Updates. The Destination Address field of the IPv6 header.
computation for this authentication data MUST follow the rules in
Section 4.4. * The contents of the Mobility Header, excluding the
Authenticator field (within the Authentication Data
parameter) which is included as zeroes for the purposes
of calculating the Authenticator. Parameters of the
Mobility Header are included in the calculation.
* Four bytes of zero.
The actual authenticator calculation over sequence of bits
is described in Section 4.5.
There MAY be additional information, associated with this
Binding Update message, that need not be present in all Binding
Updates sent. This use of MH parameters also allows for future
extensions to the format of the Binding Update message to be
defined. The encoding and format of defined parameters are
described in Section 5.2. The following parameters are valid
in a Binding Update message:
- Unique Identifier Parameter
- Alternate Care-of Address Parameter
If no actual parameters are present in this message, 4 bytes of Pad1
or PadN parameters are needed to make the length of the message a
multiple of 8.
A Binding Update message to the correspondent node MUST NOT include
the Home Address option in order to avoid reflection attacks
described in Section 4.5. A Binding Update to the home agent MUST
include the Home Address option in order to allow for the use of
manually keyed IPsec in the protection of these messages.
When a packet contains both a Home Address Option and a Binding
Update message, the sender MUST use the same address in both. The
receiver MUST check for the equal values and MUST silently discard a
packet that does not pass this test.
The home address of the mobile node in the binding given in the
Binding Update message is that which was received as the value of the
Home Address field in the Home Address option in the packet.
The care-of address for the binding given in the Binding Update The care-of address for the binding given in the Binding Update
option is normally that which was received as the value in the Source message is normally that which was received as the value in the
Address field in the IPv6 header of the packet carrying the Binding Source Address field in the IPv6 header of the packet carrying the
Update option. However, a care-of address different from the Source Binding Update message. However, a care-of address different from
Address MAY be specified by including an Alternate Care-of Address the Source Address MAY be specified by including an Alternate Care-of
sub-option in the Binding Update option. In any case, the care-of Address parameter in the Binding Update message. In any case, the
address MUST NOT be any IPv6 address which is prohibited for use care-of address MUST NOT be any IPv6 address which is prohibited
within a Routing Header; thus multicast addresses, the unspecified for use within a Routing Header; thus multicast addresses, the
address, loop-back address, and link-local addresses are excluded. unspecified address, loop-back address, and link-local addresses
Binding Updates indicating any such excluded care-of address MUST be are excluded. Binding Updates indicating any such excluded care-of
silently discarded. address MUST be silently discarded.
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 parameter in the Binding Update message, 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 message 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 parameter
option is equal to 0, the Binding Update option indicates that any is equal to 0, the Binding Update message indicates that any existing
existing binding for the mobile node MUST be deleted. In each of binding for the mobile node MUST be deleted. In each of these cases,
these cases, a Binding Cache entry for the mobile node MUST NOT be a Binding Cache entry for the mobile node MUST NOT be created in
created in response to receiving the Binding Update. response to receiving the Binding Update.
When the care-of address is NOT equal to the home address, When the care-of address is NOT equal to the home address,
what if we just delete that particular care-of 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 parameter is stored by the mobile node in its Binding Update List
for that destination; the last Sequence Number value received from entry for that destination; the last Sequence Number value received
a mobile node in a Binding Update is stored by a correspondent node from a mobile node in a Binding Update is stored by a correspondent
in its Binding Cache entry for that mobile node. Thus, the mobile node in its Binding Cache entry for that mobile node. Thus, the
node's and the correspondent node's knowledge of the last sequence mobile node's and the correspondent node's knowledge of the last
number expire at the same time. If the sending mobile node has no sequence number expire at the same time. If the sending mobile node
Binding Update List entry, the Sequence Number may start at any has no Binding Update List entry, the Sequence Number may start at
value; if the receiving correspondent node has no Binding Cache entry any value; if the receiving correspondent node has no Binding Cache
for the sending mobile node, it MUST accept any Sequence Number value entry for the sending mobile node, it MUST accept any Sequence Number
in a received Binding Update from this mobile node. The mobile value in a received Binding Update from this mobile node. The mobile
node MUST NOT use the same Sequence Number in two different Binding node MUST NOT use the same Sequence Number in two different Binding
Updates to the same correspondent node, even if the Binding Updates Updates to the same correspondent node, even if the Binding Updates
provide care-of addresses for two different home addresses of the provide different care-of addresses.
mobile node.
The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Binding
Update option, these three bits are set to 110, indicating that any
IPv6 node processing this option that does not recognize the Option
Type must discard the packet and, only if the packet's Destination
Address was not a multicast address, return an ICMP Parameter
Problem, Code 2, message to the packet's Source Address; and that the
data within the option cannot change en-route to the packet's final
destination.
5.2. Binding Acknowledgement Option 5.1.8. Binding Acknowledgement (BA) Message
The Binding Acknowledgement destination option is used to acknowledge The Binding Acknowledgement message is used to acknowledge receipt
receipt of a Binding Update option (Section 5.1). When a node of a Binding Update message (Section 5.1.7). When a node receives
receives a packet containing a Binding Update option, with this a packet containing a Binding Update message, with this node being
node being the destination of the packet (only the destination node the destination of the packet, this node MUST return a Binding
processes the option since it is a destination option), this node Acknowledgement to the mobile node, if the Acknowledge (A) bit is
MUST return a Binding Acknowledgement to the source of the packet, set in the Binding Parameter carried in the Binding Update. The
if the Acknowledge (A) bit is set in the Binding Update. As a Binding Acknowledgement message is sent to the Source Address of the
destination option, this node MAY include the Binding Acknowledgement Binding Update message it is an answer to, with the source being the
in any existing packet being sent to the mobile node or MAY send it Destination Address from the Binding Update.
in a packet by itself. A packet containing a Binding Acknowledgement
is sent according to the rules in section 8.5.
The Binding Acknowledgement option is encoded in type-length-value The Binding Acknowledgement message has the MH Type value 6. When
(TLV) format as follows: this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | Reserved |
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Reserved | Sequence # | | Status | Reserved | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh | | Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options... | |
+-+-+-+-+-+-+-+-+-+-+-+- . .
. Parameters .
Option Type . .
| |
7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Length Reserved
8-bit unsigned integer. Length of the option, in octets, These fields are unused. They MUST be initialized to zero by
excluding the Option Type and Option Length fields. This field the sender and MUST be ignored by the receiver.
MUST be set to 11 plus the total length of all sub-options
present, including their Sub-Option Type and Sub-Option Len
fields.
Status Status
8-bit unsigned integer indicating the disposition of the 8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128 Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
0 Binding Update accepted 0
Binding Update accepted
Values of the Status field greater than or equal to 128 Values of the Status field greater than or equal to 128
indicate that the Binding Update was rejected by the receiving indicate that the Binding Update was rejected by the receiving
node. The following such Status values are currently defined: node. The following such Status values are currently defined:
128 Reason unspecified 128
130 Administratively prohibited
131 Insufficient resources Reason unspecified
132 Home registration not supported
133 Not home subnet 130
137 Not home agent for this mobile node
138 Duplicate Address Detection failed Administratively prohibited
139 No security association
141 Sequence number too small 131
Insufficient resources
132
Home registration not supported
133
Not home subnet
137
Not home agent for this mobile node
138
Duplicate Address Detection failed
141
Sequence number out of window
142
Route optimization unnecessary due to low traffic
143
Invalid authenticator
144
Too old Home Nonce Index
145
Too old Care-of Nonce Index
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" [32].
Sequence # 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 SHOULD retain the entry for this mobile node in its Binding
Cache. If the node sending the Binding Acknowledgement is Cache. Correspondent nodes should make an effort to honor
serving as the mobile node's home agent, the Lifetime period the lifetimes, since an entry that was garbage collected too
also indicates the period for which this node will continue early might cause subsequent packets from the mobile node to
this service; if the mobile node requires home agent service be dropped, if they contained the Home Address Option. While
from this node beyond this period, the mobile node MUST send a this situation is recoverable since an error message is sent
new Binding Update to it before the expiration of this period to the mobile node, it causes an unnecessary break in the
(even if it is not changing its primary care-of address), in communications.
order to extend the lifetime. The value of this field is
undefined if the Status field indicates that the Binding Update Correspondent nodes SHOULD also retain a BCE entry for the
was rejected. purposes of accepting Home Address Options somewhat longer than
they keep on using the entry for Route Optimization of outgoing
packets. This helps to avoid dropped packets, particularly
when clock drift can be a problem.
If the node sending the Binding Acknowledgement is serving
as the mobile node's home agent, the Lifetime period also
indicates the period for which this node will continue this
service; if the mobile node requires home agent service from
this node beyond this period, the mobile node MUST send a new
Binding Update to it before the expiration of this period (even
if it is not changing its primary care-of address), in order
to extend the lifetime. The value of this field is undefined
if the Status field indicates that the Binding Update was
rejected.
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
(the node caching the binding). If this node is serving as node caching the binding). If this node is serving as the
the mobile node's home agent, the Refresh value may be set, mobile node's home agent, the Refresh value may be set, for
for example, based on whether the node stores its Binding example, based on whether the node stores its Binding Cache
Cache in volatile storage or in nonvolatile storage. If the in volatile storage or in nonvolatile storage. Note that as
node sending the Binding Acknowledgement is not serving as the discussed in Section 4.5.4, home agents need to keep at least
mobile node's home agent, the Refresh period SHOULD be set some information about sequence numbers in non-volatile memory.
equal to the Lifetime period in the Binding Acknowledgement;
even if this node loses this cache entry due to a failure of
the node, packets from it can still reach the mobile node
through the mobile node's home agent, causing a new Binding
Update to this node to allow it to recreate this cache entry.
The value of this field is undefined if the Status field
indicates that the Binding Update was rejected.
Sub-Options If the node sending the Binding Acknowledgement is not
serving as the mobile node's home agent, the Refresh period
SHOULD be set equal to the Lifetime period in the Binding
Acknowledgement; even if this node loses this cache entry due
to a failure of the node, packets from it can still reach the
mobile node through the mobile node's home agent, causing a new
Binding Update to this node to allow it to recreate this cache
entry. The value of this field is undefined if the Status
field indicates that the Binding Update was rejected.
Additional information, associated with this Binding Parameters
Acknowledgement option. The Authentication Data sub-option MAY
be present, and other sub-options (not currently defined) MAY
be optionally included. See section 4.4 for authentication
requirements. This use of sub-options also allows for future
extensions to the format of the Binding Acknowledgement option
to be defined.
The alignment requirement [6] for the Binding Acknowledgement option Variable-length field, of length such that the complete
is 4n+3. Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
A Binding Acknowledgement sent by a correspondent node MUST
include the following parameter:
Any packet that includes a Binding Acknowledgement option MUST - Authentication Data parameter. This parameter contains a
contain authentication data to guard against malicious Binding cryptographic hash value which is used to ensure that it
Acknowledgements. The computation for this authentication data MUST has been sent by the correspondent node. The authenticator
follow the rules in Section 4.4. covering a Binding Acknowledgement MUST be computed over
a bitstring containing the following fields of the IPv6
header and the Mobility Header, in order:
If the node returning the Binding Acknowledgement accepted the * Care-of Address, in the Destination Address field of
Binding Update for which the Acknowledgement is being returned (the the IPv6 header
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 and MUST use this entry (which includes the care-of address
received in the Binding Update) in sending the packet containing the
Binding Acknowledgement to the mobile node. The details of sending
this packet (using a Routing header) to the mobile node are the same
as for sending any packet to a mobile node using a binding, as are
described in Section 8.9.
If the node returning the Binding Acknowledgement instead * The address of the correspondent node, in the Source
rejected the Binding Update (the value of the Status field in the Address field of the IPv6 header.
Acknowledgement is greater than or equal to 128), this node MUST
similarly use a Routing header in sending the packet containing the
Binding Acknowledgement, as described in Section 8.9, but MUST NOT
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
sending the packet containing the Binding Acknowledgement MUST be
copied from the care-of address received in the rejected Binding
Update; this node MUST NOT modify its Binding Cache in response
to receiving this rejected Binding Update and MUST ignore its
Binding Cache in sending the packet in which it returns this Binding
Acknowledgement. The packet is sent using a Routing header, routing
the packet to the home address of the rejected Binding Update by
way of the care-of address indicated in the packet containing the
Binding Update. When sending a Binding Acknowledgement to reject a
Binding Update, the Binding Acknowledgement MUST be sent in an IPv6
packet containing no payload (with the Next Header field in the last
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 contents of the Mobility Header, excluding the
indicate specific processing of the option [6]. For the Binding Authenticator field (inside the Authentication Data
Acknowledgement option, these three bits are set to 000, indicating parameter) which is included as zeroes for the purposes
that any IPv6 node processing this option that does not recognize the of calculating the Authenticator.
Option Type must skip over this option and continue processing the
header, and that the data within the option cannot change en-route to
the packet's final destination.
If the mobile node sends a sequence number which is not greater than * Four bytes of zero.
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 The actual authenticator calculation over sequence of bits
is described in Section 4.5.
The Binding Request destination option is used to request a mobile There MAY be additional information, associated with this
node's binding from the mobile node. As a destination option, it Binding Acknowledgement message, that need not be present in
MAY be included in any existing packet being sent to the mobile all Binding Acknowledgements sent. This use of MH parameters
node or MAY be sent in a packet by itself; a packet containing a also allows for future extensions to the format of the Binding
Binding Request option is sent in the same way as any packet to a Acknowledgement message to be defined. The encoding and format
mobile node (Section 8.9). When a mobile node receives a packet of defined parameters are described in Section 5.2. This
containing a Binding Request option, it SHOULD return a Binding specification does not define any parameters valid for the
Update (Section 5.1) to the source of the Binding Request. Binding Acknowledgement message.
The Binding Request option is encoded in type-length-value (TLV) If no actual parameters are present in this message, no padding is
format as follows: needed.
The Binding Acknowledgement is sent to the source address of the
Binding Update message, regardless of whether the Binding Update
succeeded or failed. No Routing Headers are inserted to the message.
If the mobile node sends a sequence number which is not within the
window of acceptable sequence numbers, 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
Ack Parameter.
5.1.9. Binding Missing (BM) Message
The Binding Missing (BM) message is used by the correspondent node
to signal an inappropriate attempt to use the Home Address Option
without an existing binding. A packet containing a Binding Missing
message is sent to the source address of the packet that contained
the Home Address Option i.e. to the care-of address of the mobile
node. The source address of the Binding Missing message is the
correspondent node's address.
When a mobile node receives a packet containing a Binding Missing
message, it should perform one of the following three actions:
- If the mobile node does not have a Binding Update List entry for
the source of the Binding Missing message, it MUST ignore the
message. This is necessary to prevent loss of resources spent on
the Route Optimization signaling due to spoofed Binding Missing
messages.
- If the mobile node does have a Binding Update List entry but
has recent upper layer progress information that indicates
communications with the correspondent node are progressing, it
MAY ignore the message. This can be done in order to limit the
damage that spoofed Binding Missing messages can cause to ongoing
communications.
- If the mobile node does have a Binding Update List entry but
no upper layer progress information, it MUST remove the entry
and route further communications through the home agent. It
may also optionally start a Return Routability Procedure (see
Section 4.5).
The Binding Missing message uses the MH Type value 7. When this
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be initialized to zero by the
sender, and MUST be ignored by the receiver.
Home Address
The home address that was contained in the Home Address Option.
The mobile node uses this information to determine which
binding does not exist, if there mobile node has several home
addresses.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
There MAY be additional information, associated with this
Binding Missing message, that need not be present in all
Binding Missings sent. This use of MH parameters also allows
for future extensions to the format of the Binding Missing
message to be defined. The encoding and format of defined
parameters are described in Section 5.2. This specification
does not define any parameters for the Binding Missing message.
If no actual parameters are present in this message, no padding is
needed.
5.2. Mobility Header Parameters
5.2.1. Format
In order to allow optional fields that may not be needed in every use
of any given Mobility Header, and to allow future extensions to the
format of these messages to be defined, any of the Mobility Header
messages defined in this document MAY include one or more parameters.
Such parameters are included in the data portion of the message
itself, after the fixed portion of the message data specified in
section 5.1.
The presence of such parameters will be indicated by the Header Len
of the Mobility Header.
These parameters are encoded within the remaining space of the
message data for that message, using a type-length-value (TLV) format
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Parameter Type | Parameter Len | Parameter Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type
8-bit identifier of the type of parameter. When processing a
Mobility Header containing a parameter for which the Parameter
Type value is not recognized by the receiver, the receiver MUST
quietly ignore and skip over the parameter, correctly handling
any remaining sub-options in the option.
Parameter Length
8-bit unsigned integer. Length of the Parameter Data field
of this parameter, in octets. The Parameter Len includes the
length of the Parameter Type and Parameter Len fields.
Parameter Data
Variable-length field. Parameter -Type-specific data.
Parameters MUST be aligned on an 8-byte boundary, and have a length
which is a multiple of 8.
The following subsections specify the Parameter types which are
currently defined for use in the Mobility Header.
Implementations MUST silently ignore any parameters that they do not
understand.
5.2.2. Pad1
Pad1 Parameter (alignment requirement: none)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 parameter is a special case -- it has
neither Parameter Len nor Parameter Data fields.
The Pad1 parameter is used to insert one octet of padding into the
Parameters area of a Mobility Header. If more than one octet of
padding is required, the PadN parameter, described next, should be
used, rather than multiple Pad1 parameters.
5.2.3. PadN
PadN Parameter (alignment requirement: none)
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Option Length | Sub-Options... | 1 | Parameter Len | Parameter Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type The PadN parameter is used to insert two or more octets of padding
into the Parameters area of some Mobility Header message. For N
octets of padding, the Parameter Len field contains the value N, and
the Parameter Data consists of N-2 zero-valued octets. Parameter
data MUST be ignored by the receiver.
8 5.2.4. Unique Identifier
Option Length Unique Identifier parameter (alignment requirement: 2n)
8-bit unsigned integer. Length of the option, in octets, 0 1 2 3
excluding the Option Type and Option Length fields. This field 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
MUST be set to 0 plus the total length of all sub-options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
present, including their Sub-Option Type and Sub-Option Len | 2 | 4 | Unique Identifier |
fields. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Options The Unique Identifier parameter is valid only in Binding Request and
Binding Update messages. The Unique Identifier field contains a
16-bit value that serves to uniquely identify a Binding Request among
those sent by this Source Address, and to allow the Binding Update
to identify the specific Binding Request to which it responds. This
matching of Binding Updates to Binding Requests is required in the
procedure for renumbering the home subnet while a mobile node is away
from home (Section 9.7).
Additional information, associated with this Binding Request 5.2.5. Alternate Care-of Address
option, that need not be present in all Binding Requests sent.
This use of sub-options also allows for future extensions to
the format of the Binding Request option to be defined. The
encoding and format of defined sub-options are described in
Section 5.5. The following sub-options are valid in a Binding
Request option:
- Unique Identifier Sub-Option Alternate Care-of Address parameter (alignment requirement: 8n+6)
There is no requirement for alignment [6] of the Binding Request 0 1 2 3
option. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The three highest-order bits of the Option Type are encoded to The Alternate Care-of Address parameter is valid only in Binding
indicate specific processing of the option [6]. For the Binding Update message. The Alternate Care-of Address field contains an
Request option, these three bits are set to 000, indicating that any address to use as the care-of address for the binding, rather than
IPv6 node processing this option that does not recognize the Option using the Source Address of the packet as the care-of address.
Type must skip over this option and continue processing the header,
and that the data within the option cannot change en-route to the
packet's final destination.
5.4. Home Address Option 5.2.6. Nonce Indices
Nonce Indices parameter (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices parameter is valid only in the Binding Update
message, and only when present together with an Authentication Data
parameter.
The Home Nonce Index field tells the correspondent node that receives
the message which of the challenge values (Nj) are to be used to
authenticate the Binding Update.
The Care-of Nonce Index field tells the correspondent node that
receives the message which of the challenge values (Ni) are to be
used to authenticate the Binding Update.
5.2.7. Authentication Data
Authentication Data parameter (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Data parameter is valid only in the Binding
Request, Binding Update, and Binding Acknowledgment messages.
The Security Parameters Index (SPI) field contains an arbitrary
32-bit value that uniquely identifies the used security association.
This document specifies only one legal value for the SPI field. This
value, 0, signifies that no security association is present and the
cryptographic context MUST be established temporarily only for the
duration of processing this message. Messages that contain other
values of the SPI field SHOULD be silently discarded.
The Authenticator field contains a 96-bit cryptographic hash
value. Rules for calculating this value are different for different
messages, and are described in Sections 5.1.2, 5.1.7 and 5.1.8.
5.3. Home Address Option
The Home Address destination option is used in a packet sent by a The Home Address destination option is used in a packet sent by a
mobile node while away from home, to inform the recipient of that mobile node while away from home, to inform the recipient of that
packet of the mobile node's home address. For packets sent by a packet of the mobile node's home address. For packets sent by a
mobile node while away from home, the mobile node generally uses mobile node while away from home, the mobile node generally uses one
one of its care-of addresses as the Source Address in the packet's of its care-of addresses as the Source Address in the packet's IPv6
IPv6 header. By including a Home Address option in the packet, the header. By including a Home Address option in the IPv6 Destination
correspondent node receiving the packet is able to substitute the Options header of the packet, the correspondent node receiving the
mobile node's home address for this care-of address when processing packet is able to substitute the mobile node's home address for this
the packet, thus making the use of the care-of address transparent to care-of address when processing the packet. This makes the use of
the correspondent node. Note that multicast addresses, link-local the care-of address transparent to the correspondent node. Note
addresses, loopback addresses, IPv4 mapped addresses, and the that multicast addresses, link-local addresses, loopback addresses,
unspecified address, MUST NOT be used within a Home Address option. IPv4 mapped addresses, and the unspecified address, MUST NOT be used
within a Home Address option.
The Home Address option is encoded in type-length-value (TLV) format The Home Address option is encoded in type-length-value (TLV) format
as follows: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 33, line 33 skipping to change at page 56, line 40
The Home Address option MUST be placed as follows: The Home Address option MUST be placed as follows:
- After the Routing Header, if that header is present - After the Routing Header, if that header is present
- Before the Fragment Header, if that header is present - Before the Fragment Header, if that header is present
- Before the AH Header or ESP Header, if either one of those - Before the AH Header or ESP Header, if either one of those
headers is present headers is present
No authentication of the Home Address option is required, except Due to the threat of reflection attacks through the use of this
that if the IPv6 header of a packet is covered by authentication, option, this specification requires that packets containing Home
then that authentication MUST also cover the Home Address option; Address Option MUST be dropped if there is no corresponding Binding
this coverage is achieved automatically by the definition of the Cache Entry for that home address with the currently registered
Option Type code for the Home Address option, since it indicates care-of address matching the source address of the packet. If the
that the data within the option cannot change en-route to the packet is dropped, the correspondent nodes SHOULD send the Binding
packet's final destination, and thus the option is included in the Missing message to the source address of the packet that contained
authentication computation. By requiring that any authentication of the Home Address Option (see Section 5.1.9). These messages SHOULD
the IPv6 header also cover the Home Address option, the security of be rate-limited.
the Source Address field in the IPv6 header is not compromised by
No additional authentication of the Home Address option is
required, except that if the IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the
Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en-route
to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication
of the IPv6 header also cover the Home Address option, the security
of the Source Address field in the IPv6 header is not compromised by
the presence of a Home Address option. Security issues related to the presence of a Home Address option. Security issues related to
the Home Address option are discussed further in Section 13. When the Home Address option are discussed further in Section 4.5. When
attempting to verify authentication data in a packet that contains attempting to verify authentication data in a packet that contains
a Home Address option, the receiving node MUST make the calculation a Home Address option, the receiving node MUST make the calculation
as if the care-of address were present in the Home Address option, as if the care-of address were present in the Home Address option,
and the home address were present in the source IPv6 address field and the home address were present in the source IPv6 address field
of the IPv6 header. This conforms with the calculation specified in of the IPv6 header. This conforms with the calculation specified in
section 10.2. section 10.2.
A packet MUST NOT contain more than one Home Address option, except A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] MAY contain a separate Home Address that an encapsulated packet [4] MAY contain a separate Home Address
option associated with each encapsulating IP header. option associated with each encapsulating IP header.
skipping to change at page 35, line 5 skipping to change at page 58, line 5
The three highest-order bits of the Option Type are encoded to The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Home Address indicate specific processing of the option [6]. For the Home Address
option, these three bits are set to 110, indicating that any IPv6 option, these three bits are set to 110, indicating that any IPv6
node processing this option that does not recognize the Option Type node processing this option that does not recognize the Option Type
must discard the packet and, only if the packet's Destination Address must discard the packet and, only if the packet's Destination Address
was not a multicast address, return an ICMP Parameter Problem, was not a multicast address, return an ICMP Parameter Problem,
Code 2, message to the packet's Source Address; and that the data Code 2, message to the packet's Source Address; and that the data
within the option cannot change en-route to the packet's final within the option cannot change en-route to the packet's final
destination. destination.
5.4. Routing Header type 2
Mobile IPv6 uses a routing header to carry the Home Address for
packets sent from a correspondent node to a mobile node, which the
Care of Address of the MN is carried in the IPv6 destination field.
This uses a different routing header type than what is defined
for ``regular'' IPv6 source routing to make it possible for e.g.,
firewalls to have different rules for source routing versus MIPv6.
This routing header type (type 2) is restricted to only carry one
IPv6 address and all IPv6 nodes which process it MUST verify that the
address contained in the routing header is the home address of the
node in order to prevent packets with this routing header type to be
forwarded after decrementing the segments left field.
5.4.1. Routing Header Packet format
The Type 2 Routing header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv4
Protocol field [10].
Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in
8-octet units, not including the first 8 octets. For the Type
2 Routing header, Hdr Ext Len is always 2.
Routing Type
2.
Segments Left
8-bit unsigned integer. Number of route segments remaining,
i.e., number of explicitly listed intermediate nodes still to
be visited before reaching the final destination. For the type
2 routing header, Segments left is always 1.
Reserved
32-bit reserved field. Initialized to zero for transmission;
ignored on reception.
Home Address
The Home Address of the destination Mobile Node.
5.4.2. Sending RH type 2
A correspondent node sends packets with a routing header based on the
content of the binding cache. Conceptually this is done by the IP
layer inspecting the binding cache and if there is an entry for the
destination address (the Home Address) then the IP layer inserts a
routing header of type 2 based on the ordering rules below and moves
the Home Address to the Home Address field in the RH and places the
Care of Address in the IPv6 destination field.
Note that following the above conceptually model in an implementation
creates some additional requirements for path MTU discovery since the
packetization layer (e.g., TCP and applications using UDP) need to be
aware of the size of the headers added by the IP layer on the sending
node.
The IP layer will insert the routing header before performing IPsec
processing. The IPsec Security Policy Database will be consulted
based on the IP source address and the final IP destination (which
will be in the routing header). The definition of AH ensures that
the AH calculation is done on the packet in the form it will have on
the receiver after advancing the routing header.
5.4.3. Verification by receiver
A node receiving a packet addressed to itself (i.e., one of the
node's addresses is in the IPv6 destination field) follows the next
header chain of headers and processes them. When it encounters a
routing header of type 2 during this processing it performs the
following checks. If any of these checks fail the node MUST silently
discard the packet.
- The node is a mobile node.
- The length field in the RH is exactly 2
- The segments left field in the RH is exactly 1
- The Home Address field in the RH is (one of) the node's Home
Address(es)
Once the above checks have been performed the routing header
processing. Conceptually this follows the same model as in RFC 2460
i.e. swap the IPv6 destination field with the Home Address field
in the RH, decrement segments left, and resubmit the packet to IP
for processing the next header. However, in the case of RH type 2
this can be simplified since it is known that the packet will not be
forwarded to a different node.
Since IPsec headers follow the Routing Header any IPsec processing
will operate on the packet with the HoA in the IP destination field
and segments left being zero. Thus AH will see the packet in the
same "shape" as the AH calculation on the sender.
5.4.4. Extension header ordering
Section 4.1 in RFC 2460 lists the extension header ordering. The
introduction of Routing Header type 2 potentially allows there to be
multiple routing headers in a single packet. If this is the case
the Routing Header type 2 should follow any Routing header of other
type but otherwise the order constraints for routing headers is
independent of their type and follows RFC 2460.
5.4.5. Reversing type 2 routing headers
In addition, the general procedures defined by IPv6 for Routing
headers suggest that a received Routing header MAY be automatically
"reversed" to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the received packet
is authenticated [6]. This MUST NOT be done to type 2 routing
headers.
5.5. Mobile IPv6 Destination Option Sub-Options 5.5. Mobile IPv6 Destination Option Sub-Options
In order to allow optional fields that may not be needed in every In order to allow future extensions to the format of MIPv6
use of any given Mobile IPv6 destination option, and to allow future destination options, any of the Mobile IPv6 destination options
extensions to the format of these destination options to be defined, defined in this document MAY include one or more sub-options.
any of the Mobile IPv6 destination options defined in this document
MAY include one or more sub-options.
Such sub-options are included in the data portion of the destination Such sub-options are included in the data portion of the destination
option itself, after the fixed portion of the option data specified option itself, after the fixed portion of the option data specified
for that particular destination option (Sections 5.1 through 5.4). for that particular destination option (Section 5.3). The presence
The presence of such sub-options will be indicated by the Option of such sub-options will be indicated by the Option Length field.
Length field. When the Option Length is greater than the standard When the Option Length is greater than the standard length defined
length defined for that destination option, the remaining octets are for that destination option, the remaining octets are interpreted as
interpreted as sub-options. sub-options.
These sub-options are encoded within the remaining space of the These sub-options are encoded within the remaining space of the
option data for that option, using a type-length-value (TLV) format option data for that option, using a type-length-value (TLV) format
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Sub-Option Data... |Sub-Option Type| Sub-Option Len| Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 20 skipping to change at page 62, line 18
Pad1 and PadN (defined below), which are used when necessary to align Pad1 and PadN (defined below), which are used when necessary to align
subsequent sub-options. The Pad1 and PadN sub-options are valid for subsequent sub-options. The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike the padding options all Mobile IPv6 destination options. Unlike the padding options
used in Hop-by-Hop Options header or Destination Options header [6], used in Hop-by-Hop Options header or Destination Options header [6],
there is no requirement for padding the total size of any Mobile IPv6 there is no requirement for padding the total size of any Mobile IPv6
destination option to a multiple of 8 octets in length, and the destination option to a multiple of 8 octets in length, and the
Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All
Mobile IPv6 sub-options defined in this document MUST be recognized Mobile IPv6 sub-options defined in this document MUST be recognized
by all Mobile IPv6 implementations. by all Mobile IPv6 implementations.
The following subsections specify the sub-option types which are
currently defined for use in Mobile IPv6 destination options.
5.5.1. Pad1 5.5.1. Pad1
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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 37, line 16 skipping to change at page 63, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Sub-Option Len| Sub-Option Data | 1 | Sub-Option Len| Sub-Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN sub-option is used to insert two or more octets of The PadN sub-option is used to insert two or more octets of
padding into the Sub-Options area of a Mobile IPv6 option. padding into the Sub-Options area of a Mobile IPv6 option.
For N octets of padding, the Sub-Option Len field contains For N octets of padding, the Sub-Option Len field contains
the value N-2, and the Sub-Option Data consists of N-2 the value N-2, and the Sub-Option Data consists of N-2
zero-valued octets. zero-valued octets.
5.5.3. Unique Identifier 5.6. ICMP Home Agent Address Discovery Request Message
Unique Identifier Sub-Option (alignment requirement: 2n)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier sub-option is valid only in Binding
Request and Binding Update destination options. The Unique
Identifier field contains a 16-bit value that serves to
uniquely identify a Binding Request among those sent by this
Source Address, and to allow the Binding Update to identify
the specific Binding Request to which it responds. This
matching of Binding Updates to Binding Requests is required
in the procedure for renumbering the home subnet while a
mobile node is away from home (Section 9.6).
5.5.4. Alternate Care-of Address
Alternate Care-of Address Sub-Option (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address sub-option is valid only in
Binding Update destination options. The Alternate Care-of
Address field contains an address to use as the care-of
address for the binding, rather than using the Source
Address of the packet as the care-of address.
5.6. Authentication Data
Authentication Data Sub-Option (alignment requirement: 8n+6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Authentication Data (variable length) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Data sub-option is valid in Binding
Update and Binding Acknowledgement destination options.
The Length of the sub-option is 4 plus the number of bytes
contained in the Authentication Data field.
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.
The Authentication Data field is a variable-length
field that contains data necessary to secure a Binding
Update or Binding Acknowledgment. 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.
5.7. 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.8 and 10.8. The mobile mechanism, as described in Sections 9.9 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 [11], 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 5 skipping to change at page 64, line 5
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Source Address of the Home Agent Address Discovery Request The Source Address of the Home Agent Address Discovery Request
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. The home agent then MUST return the Home Agent Address addresses. The home agent then MUST return the Home Agent Address
Discovery Reply message directly to the Source Address chosen by Discovery Reply message directly to the Source Address chosen by
the mobile node Note that, at the time of performing this dynamic the mobile node Note that, at the time of performing this dynamic
home agent address discovery, it is likely that the mobile node not home agent address discovery, it is likely that the mobile node not
registered with any home agent within the specified anycast group. registered with any home agent within the specified anycast group.
5.8. 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.8 and 10.8. address discovery mechanism, as described in Sections 9.9 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 [11], 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | |
skipping to change at page 43, line 5 skipping to change at page 66, 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.9. ICMP Mobile Prefix Solicitation Message Format 5.8. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node 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 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 message is to solicit a Mobile Prefix Advertisement from the home
agent, which will allow the mobile node to gather prefix information agent, which will allow the mobile node to gather prefix information
about its home network. This information can be used to configure about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [27], home address(es) by stateless address autoconfiguration [35],
or update address(es) according to changes in prefix information or update address(es) according to changes in prefix information
supplied by the home agent. supplied by the home agent.
The Mobile Prefix Solicitation is similar to the Router Solicitation The Mobile Prefix Solicitation is similar to the Router Solicitation
used in Neighbor Discovery [17], except it is routed from the mobile used in Neighbor Discovery [20], except it is routed from the mobile
node on the visited network to the home agent on the home network by node on the visited network to the home agent on the home network by
usual unicast routing rules. usual unicast routing rules.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 45 skipping to change at page 66, line 45
Destination Address Destination Address
The address of the mobile node's home agent. This home agent The address of the mobile node's home agent. This home agent
must be on the link which the mobile node wishes to learn must be on the link which the mobile node wishes to learn
prefix information about. prefix information about.
Hop Limit Hop Limit
Set to an initial hop limit value, and this message is routed Set to an initial hop limit value, and this message is routed
according to the rules of a typical unicast packet. A hop according to the rules of a typical unicast packet. A hop
limit of 64 is currently suggested [26]. limit of 64 is currently suggested [32].
Authentication Header Authentication Header
If a Security Association for the IP Authentication Header If a Security Association for the IP Authentication Header
exists between the sender and the destination address, then the exists between the sender and the destination address, then the
sender SHOULD include this header. [subject to change] sender SHOULD include this header. [subject to change]
ICMP Fields: ICMP Fields:
Type Type
skipping to change at page 45, line 5 skipping to change at page 68, line 5
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
5.10. ICMP Mobile Prefix Advertisement Message Format 5.9. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message to a A home agent will send a Mobile Prefix Advertisement message to a
mobile node to distribute prefix information about the home link mobile node to distribute prefix information about the home link
while the mobile node is traveling away from the home network. This while the mobile node is traveling away from the home network. This
will occur in response to a Mobile Prefix Solicitation with an will occur in response to a Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according to Advertisement, or by an unsolicited Advertisement sent according to
the rules in Section 5.10. the rules in Section 5.9.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
skipping to change at page 46, line 9 skipping to change at page 69, line 9
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
Options: Options:
Prefix Information Prefix Information
Each message contains one or more Prefix Information options, Each message contains one or more Prefix Information options,
which contain the prefix(es) the mobile node should configure which contain the prefix(es) the mobile node should configure
its home address(es) with. Section 9.6 describes which its home address(es) with. Section 9.7 describes which
prefixes should be advertised to the mobile node. prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2 The Prefix Information option is defined in Section 4.6.2
of [17], with modifications defined in Section 6.2 of this of [20], with modifications defined in Section 6.2 of this
specification. The home agent MUST use this modified Prefix specification. The home agent MUST use this modified Prefix
Information option to send the aggregate list of home network Information option to send the aggregate list of home network
prefixes as defined in Section 9.8.1. prefixes as defined in Section 9.9.1.
The Mobile Prefix Advertisement sent by the home agent MAY include The Mobile Prefix Advertisement sent by the home agent MAY include
the Source Link-layer Address option defined in RFC 2461 [17], or the the Source Link-layer Address option defined in RFC 2461 [20], or the
Advertisement Interval option specified in Section 6.3. Advertisement Interval option specified in Section 6.3.
Future versions of this protocol may define new option types. Home Future versions of this protocol may define new option types. Home
Agents MUST silently ignore any options they do not recognize and Agents MUST silently ignore any options they do not recognize and
continue processing the message. 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 [20] 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:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime | | Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [17]: specified for Neighbor Discovery [20]:
Home Agent (H) Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is indicate that the router sending this Router Advertisement is
also functioning as a Mobile IP home agent on this link. also functioning as a Mobile IP home agent on this link.
Reserved Reserved
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
skipping to change at page 48, line 14 skipping to change at page 71, 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.8 and 10.8). (Sections 9.9 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.10). address to its new care-of address (Section 10.11).
However, Neighbor Discovery [17] only advertises a router's However, Neighbor Discovery [20] only advertises a router's
link-local address, by requiring this address to be used as the IP link-local address, by requiring this address to be used as the IP
Source Address of each Router Advertisement. Source Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to easily Mobile IPv6 extends Neighbor Discovery to allow a router to easily
and efficiently advertise its global address, by the addition of a and efficiently advertise its global address, by the addition of a
single flag bit in the format of a Prefix Information option for single flag bit in the format of a Prefix Information option for
use in Router Advertisement messages. The format of the Prefix use in Router Advertisement messages. The format of the Prefix
Information option is as follows: Information option is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 48, line 52 skipping to change at page 71, line 52
| | | |
+ + + +
| | | |
+ Prefix + + Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [17]: specified for Neighbor Discovery [20]:
Router Address (R) Router Address (R)
1-bit router address flag. When set, indicates that the 1-bit router address flag. When set, indicates that the
Prefix field, in addition to advertising the indicated prefix, Prefix field, in addition to advertising the indicated prefix,
contains a complete IP address assigned to the sending router. contains a complete IP address assigned to the sending router.
This router IP address has the same scope and conforms to the This router IP address has the same scope and conforms to the
same lifetime values as the advertised prefix. This use of same lifetime values as the advertised prefix. This use of
the Prefix field is compatible with its use in advertising the Prefix field is compatible with its use in advertising
the prefix itself, since prefix advertisement uses only the the prefix itself, since prefix advertisement uses only the
skipping to change at page 49, line 29 skipping to change at page 72, line 29
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Router Address (R) bit. addition of the Router Address (R) bit.
In a solicited Router Advertisement, a home agent MUST, and all other In a solicited Router Advertisement, a home agent MUST, and all other
routers SHOULD, include at least one Prefix Information option with routers SHOULD, include at least one Prefix Information option with
the Router Address (R) bit set. Neighbor Discovery specifies that, the Router Address (R) bit set. Neighbor Discovery specifies that,
if including all options in a Router Advertisement causes the size of if including all options in a Router Advertisement causes the size of
the Advertisement to exceed the link MTU, multiple Advertisements can the Advertisement to exceed the link MTU, multiple Advertisements can
be sent, each containing a subset of the options [17]. In this case, be sent, each containing a subset of the options [20]. In this case,
at least one of these multiple Advertisements being sent instead at least one of these multiple Advertisements being sent instead
of a single larger solicited Advertisement, MUST include a Prefix of a single larger solicited Advertisement, MUST include a Prefix
Information option 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
skipping to change at page 50, line 41 skipping to change at page 73, line 41
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Advertisement Interval Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds, 32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited router Router Advertisement between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using messages sent by this router on this network interface. Using
the conceptual router configuration variables defined by the conceptual router configuration variables defined by
Neighbor Discovery [17], this field MUST be equal to the value Neighbor Discovery [20], this field MUST be equal to the value
MaxRtrAdvInterval, expressed in milliseconds. MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option in their Router Advertisements. A Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 10.4. in its movement detection algorithm, as described in Section 10.4.
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
skipping to change at page 51, line 49 skipping to change at page 74, line 49
ordering the addresses returned to a mobile node in the Home ordering the addresses returned to a mobile node in the Home
Agent Addresses field of a Home Agent Address Discovery Reply Agent Addresses field of a Home Agent Address Discovery Reply
message. Higher values mean more preferable. If this option message. Higher values mean more preferable. If this option
is not included in a Router Advertisement in which the Home is not included in a Router Advertisement in which the Home
Agent (H) bit is set, the preference value for this home agent Agent (H) bit is set, the preference value for this home agent
SHOULD be considered to be 0. Values greater than 0 indicate a SHOULD be considered to be 0. Values greater than 0 indicate a
home agent more preferable than this default value, and values home agent more preferable than this default value, and values
less than 0 indicate a less preferable home agent. less than 0 indicate a less preferable home agent.
The manual configuration of the Home Agent Preference value The manual configuration of the Home Agent Preference value
is described in Section 7.3. In addition, the sending home is described in Section 7.2. In addition, the sending home
agent MAY dynamically set the Home Agent Preference value, for agent MAY dynamically set the Home Agent Preference value, for
example basing it on the number of mobile nodes it is currently example basing it on the number of mobile nodes it is currently
serving or on its remaining resources for serving additional serving or on its remaining resources for serving additional
mobile nodes; such dynamic settings are beyond the scope of mobile nodes; such dynamic settings are beyond the scope of
this document. Any such dynamic setting of the Home Agent this document. Any such dynamic setting of the Home Agent
Preference, however, MUST set the preference appropriately, Preference, however, MUST set the preference appropriately,
relative to the default Home Agent Preference value of 0 that relative to the default Home Agent Preference value of 0 that
may be in use by some home agents on this link (i.e., a home may be in use by some home agents on this link (i.e., a home
agent not including a Home Agent Information option in its agent not including a Home Agent Information option in its
Router Advertisements will be considered to have a Home Agent Router Advertisements will be considered to have a Home Agent
skipping to change at page 53, line 7 skipping to change at page 76, line 7
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
If both the Home Agent Preference and Home Agent Lifetime are set If both the Home Agent Preference and Home Agent Lifetime are set
to their default values specified above, this option SHOULD NOT be to their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home included in the Router Advertisement messages sent by this home
agent. agent.
6.5. Changes to Sending Router Advertisements 6.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [17] limits routers to The Neighbor Discovery protocol specification [20] limits routers to
a minimum interval of 3 seconds between sending unsolicited multicast a minimum interval of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface Router Advertisement messages from any given network interface
(limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough "Routers generate Router Advertisements frequently enough
that hosts will learn of their presence within a few that hosts will learn of their presence within a few
minutes, but not frequently enough to rely on an absence minutes, but not frequently enough to rely on an absence
of advertisements to detect router failure; a separate of advertisements to detect router failure; a separate
Neighbor Unreachability Detection algorithm provides failure Neighbor Unreachability Detection algorithm provides failure
detection." detection."
skipping to change at page 56, line 13 skipping to change at page 79, line 13
care-of address might no longer be valid. care-of address might no longer be valid.
7. Requirements for Types of IPv6 Nodes 7. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions Mobile IPv6 places some special requirements on the functions
provided by different types of IPv6 nodes. This section summarizes provided by different types of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement those requirements, identifying the functionality each requirement
is intended to support. Further details on this functionality is is intended to support. Further details on this functionality is
provided in the following sections. provided in the following sections.
7.1. Requirements for All IPv6 Hosts and Routers 7.1. Requirements for All IPv6 Routers
Since any IPv6 node may at any time be a correspondent node of a
mobile node, either sending a packet to a mobile node or receiving a
packet from a mobile node, the following requirements apply to ALL
IPv6 nodes (whether host or router, whether mobile or stationary):
- Every IPv6 node MUST be able to process a Home Address option
received in any IPv6 packet.
- Every IPv6 node SHOULD be able to process a Binding Update option
received in a packet, and to return a Binding Acknowledgement
option if the Acknowledge (A) bit is set in the received Binding
Update.
- Every IPv6 node SHOULD be able to maintain a Binding Cache of the
bindings received in accepted Binding Updates.
7.2. Requirements for All IPv6 Routers
The following requirements apply to all IPv6 routers, even those not The following requirements apply to all IPv6 routers, even those not
serving as a home agent for Mobile IPv6: serving as a home agent for Mobile IPv6:
- 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 each of its Router Advertisements, to aid
detection by mobile nodes. The use of this option in Router movement detection by mobile nodes. The use of this option in
Advertisements MUST be configurable. Router 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 - Each router SHOULD include at least one prefix with the 'R' bit
set and with its full IP address in its router advertisements. set and with its full IP address in its router advertisements.
7.3. Requirements for IPv6 Home Agents - Filtering routers SHOULD be able to have different rules for
routing header type 2 than for other routing headers so that
type 2 can be allowed in order to allow Mobile IPv6 traffic
while still having the option to filter out other use of routing
headers.
7.2. 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
agent. Each such Binding Cache entry records the mobile node's agent. Each such Binding Cache entry records the mobile node's
skipping to change at page 57, line 29 skipping to change at page 80, line 16
packets in order to tunnel them to the primary care-of address packets in order to tunnel them to the primary care-of address
for the mobile node indicated in its binding in the home agent's for the mobile node indicated in its binding in the home agent's
Binding Cache. Binding Cache.
- Every home agent MUST be able to return a Binding Acknowledgement - Every home agent MUST be able to return a Binding Acknowledgement
option in response to a Binding Update option received with the option in response to a Binding Update option received with the
Acknowledge (A) bit set. Acknowledge (A) bit set.
- Every home agent MUST maintain a separate Home Agents List for - Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in each link on which it is serving as a home agent, as described in
Section 4.6. Section 4.7.
- 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 [11], and MUST be
able to participate in dynamic home agent address discovery able to participate in dynamic home agent address discovery
(Section 9.8). (Section 9.9).
- 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 - Every home agent SHOULD support sending ICMP Mobile
Prefix Advertisements, and SHOULD respond to Mobile Prefix Prefix Advertisements, and SHOULD respond to Mobile Prefix
Solicitations. Solicitations.
7.4. Requirements for IPv6 Mobile Nodes 7.3. 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.7, 10.9, and 10.10; and MUST options, as specified in Sections 10.7, 10.9, and 10.11; 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.13. as specified in Section 10.14.
- 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.8. 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.7.
- Every mobile node MUST support receiving Mobile Prefix - Every mobile node MUST support receiving Mobile Prefix
Advertisements and reconfiguring its home address based on the Advertisements and reconfiguring its home address based on the
prefix information contained therein. 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
skipping to change at page 59, line 39 skipping to change at page 82, line 39
the correspondent node above the level of the Home Address option the correspondent node above the level of the Home Address option
generation and processing. generation and processing.
8.2. Receiving Binding Updates 8.2. Receiving Binding Updates
Before accepting a Binding Update option received in any packet, the Before accepting a Binding Update option received in any packet, the
receiving node MUST validate the Binding Update according to the receiving node MUST validate the Binding Update according to the
following tests: following tests:
- The packet meets the specific authentication requirements for - The packet meets the specific authentication requirements for
Binding Updates, defined in Section 4.4. Binding Updates, defined in Section 4.5.
- 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.7.
- 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.7, this
Sequence Number comparison MUST be performed modulo 2**8. Sequence Number comparison MUST be performed modulo 2**8.
If the mobile node sends a sequence number which is not greater than If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the the sequence number from the last successful Binding Update, then the
receiving node MUST send back a Binding Acknowledgement with status receiving node MUST send back a Binding Acknowledgement with status
code 141, and the last accepted sequence number in the Sequence code 141, and the last accepted sequence number in the Sequence
Number field of the Binding Acknowledgement. Number field of the Binding Acknowledgement.
Any Binding Update which fails to satisfy all of these tests for any Any Binding Update which fails to satisfy all of these tests for any
other reason (than insufficiency of the Sequence Number) MUST be other reason (than insufficiency of the Sequence Number) MUST be
skipping to change at page 61, line 32 skipping to change at page 84, line 32
If the node accepts the Binding Update and creates or updates If the node accepts the Binding Update and creates or updates
an entry in its Binding Cache for this binding, and the `A' bit an entry in its Binding Cache for this binding, and the `A' bit
was set in the Binding Update, the Status field in the Binding was set in the Binding Update, the Status field in the Binding
Acknowledgement MUST be set to a value less than 128; if, on the Acknowledgement MUST be set to a value less than 128; if, on the
other hand the Binding Update is accepted and the `A' bit is not set, other hand the Binding Update is accepted and the `A' bit is not set,
the node SHOULD NOT send a Binding Acknowledgement. If the node the node SHOULD NOT send a Binding Acknowledgement. If the node
rejects the Binding Update and does not create or update an entry for rejects the Binding Update and does not create or update an entry for
this binding, a Binding Acknowledgement MUST be sent even if the `A' this binding, a Binding Acknowledgement MUST be sent even if the `A'
bit was not sent, and the Status field in the Binding Acknowledgement bit was not sent, and the Status field in the Binding Acknowledgement
MUST be set to a value greater than or equal to 128. Specific values MUST be set to a value greater than or equal to 128. Specific values
for the Status field are described in Section 5.2 and in the most for the Status field are described in Section 5.1.8 and in the most
recent "Assigned Numbers" [26]. recent "Assigned Numbers" [10].
The packet in which the Binding Acknowledgement is returned The packet in which the Binding Acknowledgement is returned
MUST meet the specific authentication requirements for Binding MUST meet the specific authentication requirements for Binding
Acknowledgements, defined in Section 4.4. Furthermore, if the packet Acknowledgements, defined in Section 4.5. Furthermore, if the packet
is to be sent to the mobile node at any address other than the mobile is to be sent to the mobile node at any address other than the mobile
node's home address, it MUST be sent using a Routing header (even if node's home address, it MUST be sent using a Routing header (even if
the binding was rejected). The intermediate IP address, to which the binding was rejected). The intermediate IP address, to which
the packet will be delivered immediately before the home address, is the packet will be delivered immediately before the home address, is
determined as follows: determined as follows:
- Whenever the Binding Update is accepted with a nonzero lifetime, - Whenever the Binding Update is accepted with a nonzero lifetime,
the routing header will be constructed using the care-of address the routing header will be constructed using the care-of address
as described in Section 8.9. as described in Section 8.9.
skipping to change at page 64, line 21 skipping to change at page 87, line 21
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 to the mobile node's home agent (the source of the tunnel). By
the definition of IPv6 encapsulation [4], the home agent (as the the definition of IPv6 encapsulation [4], the home agent (as the
encapsulating node) MUST relay certain ICMP error messages back encapsulating node) MUST relay certain ICMP error messages back
to the original sender of the packet, which in this case is the to the original sender of the packet, which in this case is the
correspondent node. 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.10 (e.g., node's previous care-of address as described in Section 10.11 (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]. The relayed packet MUST NOT back to the correspondent node [4]. The relayed packet MUST NOT
contain a routing header entry with the care-of address of the mobile contain a routing header entry with the care-of address of the mobile
node. node.
Thus, in all cases, any meaningful ICMP error messages caused Thus, in all cases, any meaningful ICMP error messages caused
skipping to change at page 67, line 39 skipping to change at page 89, line 50
Status field is set to 133 (not home subnet). Status field is set to 133 (not home subnet).
- Else, if the home agent chooses to reject the Binding Update for - Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for field is set to an appropriate value to indicate the reason for
the rejection. the rejection.
- Finally, if the Duplicate Address Detection (D) bit is set in - 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 ensure that Duplicate
Address Detection [27] on the mobile node's home link for the Address Detection [35] has been performed on the mobile node's
home address in this binding (before returning the Binding home link for the link-local address associated with the home
Acknowledgement). The address used for Duplicate Address address in this binding, and thus to ensure that no other node
Detection SHOULD be the mobile node's link-local address. Normal on the home link can possibly use the mobile node's home address
processing for Duplicate Address Detection specifies that, in (before returning the Binding Acknowledgement). The address
certain cases, the node SHOULD delay sending the initial Neighbor used for Duplicate Address Detection SHOULD be the mobile node's
Solicitation message of Duplicate Address Detection by a random link-local address. Normal processing for Duplicate Address
delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; however, Detection specifies that, in certain cases, the node SHOULD
in this case, the home agent SHOULD NOT perform such a delay. delay sending the initial Neighbor Solicitation message of
If this Duplicate Address Detection fails, then the home agent Duplicate Address Detection by a random delay between 0 and
MUST reject the Binding Update and SHOULD return a Binding MAX_RTR_SOLICITATION_DELAY [20, 35]; however, in this case, the
Acknowledgement to the mobile node, in which the Status field is home agent SHOULD NOT perform such a delay. If this Duplicate
set to 138 (Duplicate Address Detection failed). When the home Address Detection fails, then the home agent MUST reject the
agent sends a successful Binding Acknowledgement to the mobile Binding Update and SHOULD return a Binding Acknowledgement
node, in response to a Binding Update with the `D' bit set, the to the mobile node, in which the Status field is set to 138
home agent assures to the mobile node that its home address (Duplicate Address Detection failed). When the home agent sends
will continue to be valid at least as long as the mobile node a successful Binding Acknowledgement to the mobile node, in
transmits Binding Updates with new care-of addresses for that response to a Binding Update with the `D' bit set, the home agent
home address. assures to the mobile node that its home address will continue to
be valid at least as long as the mobile node transmits Binding
Updates with new care-of addresses for that home address.
If the home agent does not reject the Binding Update, then it becomes If the home agent does not reject the Binding Update, then it becomes
or remains the home agent for the mobile node. The home agent MUST or remains the home agent for the mobile node. The home agent MUST
then create a new entry in its Binding Cache for this mobile node (or then create a new entry in its Binding Cache for this mobile node (or
update its existing Binding Cache entry for this mobile node, if such update its existing Binding Cache entry for this mobile node, if such
an entry already exists). The home address of the mobile node is an entry already exists). The home address of the mobile node is
taken to be the value which, when the packet was originally received, taken to be the value which, when the packet was originally received,
was located in the Home Address field in the packet's Home Address was located in the Home Address field in the packet's Home Address
option. The care-of address for this Binding Cache entry is taken option. The care-of address for this Binding Cache entry is taken
to be the value which, when the packet was originally received, was to be the value which, when the packet was originally received, was
skipping to change at page 68, line 34 skipping to change at page 90, line 49
registration" MUST be excluded from the normal cache replacement registration" MUST be excluded from the normal cache replacement
policy used for the Binding Cache (Section 8.7) and MUST NOT be policy used for the Binding Cache (Section 8.7) and MUST NOT be
removed from the Binding Cache until the expiration of the Lifetime removed from the Binding Cache until the expiration of the Lifetime
period. period.
The lifetime for the Binding Cache entry MUST NOT be greater than the The lifetime for the Binding Cache entry MUST NOT be greater than the
remaining valid lifetime for the subnet prefix in the mobile node's remaining valid lifetime for the subnet prefix in the mobile node's
home address specified with the Binding Update, and MUST NOT be home address specified with the Binding Update, and MUST NOT be
greater than the Lifetime value specified in the Binding Update. The greater than the Lifetime value specified in the Binding Update. The
remaining valid lifetime for this prefix is determined by the home remaining valid lifetime for this prefix is determined by the home
agent based on its own Prefix List entry for this prefix [17]. agent based on its own Prefix List entry for this prefix [20].
If the `S' bit field in the Binding Update is zero, The Home Agent If the `S' bit field in the Binding Update is zero, The Home Agent
creates or updates Binding Cache entries for each of possible creates or updates Binding Cache entries for each of possible
several home addresses. The set of such home addresses is formed several home addresses. The set of such home addresses is formed
by replacing the routing prefix for the given home address with by replacing the routing prefix for the given home address with
all other routing prefixes that are supported by the home agent all other routing prefixes that are supported by the home agent
processing the Binding Update. The Home Agent creates such a processing the Binding Update. The Home Agent creates such a
separate primary care-of address registration for each such home separate primary care-of address registration for each such home
address. Note that the same considerations for Duplicate Address address. Note that the same considerations for Duplicate Address
Detection apply for each affected home address. The lifetime for Detection apply for each affected home address. The lifetime for
skipping to change at page 69, line 41 skipping to change at page 92, line 5
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.3 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.2. 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:
skipping to change at page 70, line 47 skipping to change at page 93, line 11
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
begins serving as the home agent for some mobile node (it did not begins serving as the home agent for some mobile node (it did not
already have a Binding Cache entry for this mobile node marked as a already have a Binding Cache entry for this mobile node marked as a
"home registration"), then the home agent MUST multicast onto the "home registration"), then the home agent MUST multicast onto the
home link a "gratuitous" Neighbor Advertisement message [17] on home link a "gratuitous" Neighbor Advertisement message [20] on
behalf of the mobile node. Specifically, the home agent performs the behalf of the mobile node. Specifically, the home agent performs the
following steps: following steps:
- The home agent examines the value of the `S' bit in the new "home - The home agent examines the value of the `S' bit in the new "home
registration" Binding Cache entry. If this bit is nonzero, registration" Binding Cache entry. If this bit is nonzero,
the following step is carried out only for the individual home the following step is carried out only for the individual home
address specified for this binding. If, instead, this bit is address specified for this binding. If, instead, this bit is
zero, then the following step is carried out for each address zero, then the following step is carried out for each address
for the mobile node formed from the interface identifier in for the mobile node formed from the interface identifier in
the mobile node's home address in this binding (the remaining the mobile node's home address in this binding (the remaining
low-order bits in the address after the configured subnet low-order bits in the address after the configured subnet
prefix), together with each one of the subnet prefixes currently prefix), together with each one of the subnet prefixes currently
considered by the home agent to be on-link (including both the considered by the home agent to be on-link (including both the
link-local and site-local prefix). link-local and site-local prefix).
- For each specific IP address for the mobile node determined - For each specific IP address for the mobile node determined
in the first step above, the home agent multicasts onto the in the first step above, the home agent multicasts onto the
home link (to the all-nodes multicast address) a Neighbor home link (to the all-nodes multicast address) a Neighbor
Advertisement message [17] on behalf of the mobile node, to Advertisement message [20] on behalf of the mobile node, to
advertise the home agent's own link-layer address for this IP advertise the home agent's own link-layer address for this IP
address. address.
All fields in each such Neighbor Advertisement message SHOULD be All fields in each such Neighbor Advertisement message SHOULD be
set in the same way they would be set by the mobile node itself set in the same way they would be set by the mobile node itself
if sending this Neighbor Advertisement while at home [17], with if sending this Neighbor Advertisement while at home [20], with
the following exceptions: the following exceptions:
* The Target Address in the Neighbor Advertisement message MUST * The Target Address in the Neighbor Advertisement message MUST
be set to the specific IP address for the mobile node. be set to the specific IP address for the mobile node.
* The Advertisement MUST include a Target Link-layer Address * The Advertisement MUST include a Target Link-layer Address
option specifying the home agent's link-layer address. option specifying the home agent's link-layer address.
* The Router (R) bit in the Advertisement MUST be copied from * The Router (R) bit in the Advertisement MUST be copied from
the corresponding bit in the home agent's Binding Cache entry the corresponding bit in the home agent's Binding Cache entry
skipping to change at page 72, line 5 skipping to change at page 94, line 21
associate the mobile node's address with the home agent's link associate the mobile node's address with the home agent's link
layer address, causing it to transmit any future packets for the layer address, causing it to transmit any future packets for the
mobile node normally destined to this address instead to the mobile mobile node normally destined to this address instead to the mobile
node's home agent. Since multicasts on the local link (such as node's home agent. Since multicasts on the local link (such as
Ethernet) are typically not guaranteed to be reliable, the home Ethernet) are typically not guaranteed to be reliable, the home
agent MAY retransmit this Neighbor Advertisement message up to agent MAY retransmit this Neighbor Advertisement message up to
MAX_ADVERT_REXMIT times to increase its reliability. It is still MAX_ADVERT_REXMIT times to increase its reliability. It is still
possible that some nodes on the home link will not receive any of possible that some nodes on the home link will not receive any of
these Neighbor Advertisements, but these nodes will eventually be these Neighbor Advertisements, but these nodes will eventually be
able to detect the link-layer address change for the mobile node's able to detect the link-layer address change for the mobile node's
home address, through use of Neighbor Unreachability Detection [17]. home address, through use of Neighbor Unreachability Detection [20].
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] to Binding Cache), the home agent uses IPv6 Neighbor Discovery [20] to
intercept unicast packets on the home link addressed to 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, and reply the home agent MUST act as a proxy for this mobile node, and reply
to 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
skipping to change at page 72, line 33 skipping to change at page 94, line 49
If such an entry exists in the home agent's Binding Cache, the home If such an entry exists in the home agent's Binding Cache, the home
agent MUST reply to the Neighbor Solicitation message with a Neighbor agent MUST reply to the Neighbor Solicitation message with a Neighbor
Advertisement message, giving the home agent's own link-layer address Advertisement message, giving the home agent's own link-layer address
as the link-layer address for the specified Target Address. In as the link-layer address for the specified Target Address. In
addition, the Router (R) bit in the Advertisement MUST be copied from addition, the Router (R) bit in the Advertisement MUST be copied from
the corresponding bit in the home agent's Binding Cache entry for the the corresponding bit in the home agent's Binding Cache entry for the
mobile node. Acting as a proxy in this way allows other nodes on mobile node. Acting as a proxy in this way allows other nodes on
the mobile node's home link to resolve the mobile node's IPv6 home the mobile node's home link to resolve the mobile node's IPv6 home
address, and allows the home agent to 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 [20].
9.4. 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.3. 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 [12] or ESP [13] header present in the packet.
In order to forward 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. When a home agent encapsulates registered with the home agent. When a home agent encapsulates
an intercepted packet for forwarding to the mobile node, the home an intercepted packet for forwarding to the mobile node, the home
agent sets the Source Address in the prepended tunnel IP header to agent sets the Source Address in the prepended tunnel IP header to
the home agent's own IP address, and sets the Destination Address the home agent's own IP address, and sets the Destination Address
in the tunnel IP header to the mobile node's primary care-of in the tunnel IP header to the mobile node's primary care-of
skipping to change at page 74, line 9 skipping to change at page 96, line 22
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's home address. Such reverse tunneled sent to it from a mobile node's home address. Such reverse tunneled
packets MAY be discarded unless accompanied by a valid AH or ESP packets MAY be discarded unless accompanied by a valid AH or ESP
header. This support for reverse tunneling allows mobile nodes to header. This support for reverse tunneling allows mobile nodes to
defeat certain kinds of traffic analysis. Requiring IPsec headers defeat certain kinds of traffic analysis. Requiring IPsec headers
on reverse tunneled packets allows the home agent to protect the on reverse tunneled packets allows the home agent to protect the
home network against unwarranted intrusions by malicious nodes home network against unwarranted intrusions by malicious nodes
masquerading as a mobile node with a home address on the network masquerading as a mobile node with a home address on the network
served by the home agent. served by the home agent.
9.6. Home Prefix Propagation 9.6. Protecting Return Routability Packets
IPv6 provides mechanisms as part of Neighbor Discovery [17] and The Return Routability procedure described in Section 4.5 assumes
Address Autoconfiguration [27] to aid in mobile node configuration that the confidentiality of the HoT message is protected as it is
tunneled from the home agent to the mobile node. Therefore, the home
agent MUST protect these packets using IPsec ESP with a non-null
encryption transform. It is also useful, but not required to protect
other RR related messages.
As described earlier, the Binding Update and Binding Acknowledgement
messages already need protection even if they are not tunneled. As
these messages employ the Mobility Header in a similar manner to
the RR messages, it is sufficient to set up IPsec Security Policy
Database in a manner that protects all traffic to the mobile node
and back with IPsec ESP if the protocol in the packet is Mobility
Header.
9.7. Home Prefix Propagation
IPv6 provides mechanisms as part of Neighbor Discovery [20] and
Address Autoconfiguration [35] to aid in mobile node configuration
when a mobile node turns on, and in renumbering a subnet, such as when a mobile node turns on, and in renumbering a subnet, such as
when a site switches to a new network service provider. when a site switches to a new network service provider.
In renumbering, new prefixes and addresses can be introduced for the In renumbering, new prefixes and addresses can be introduced for the
subnet and old ones can be deprecated and removed. These mechanisms subnet and old ones can be deprecated and removed. These mechanisms
are defined to work while all nodes using the old prefixes are at are defined to work while all nodes using the old prefixes are at
home, connected to the link using these prefixes. Mobile IPv6 home, connected to the link using these prefixes. Mobile IPv6
extends these mechanisms for the case in which one or more mobile extends these mechanisms for the case in which one or more mobile
nodes using the old prefixes are away from home and registered at the nodes using the old prefixes are away from home and registered at the
home agent while the renumbering takes place. home agent while the renumbering takes place.
In the IPv6 renumbering mechanism, nodes on the visited link receive In the IPv6 renumbering mechanism, nodes on the visited link receive
Mobile Prefix Advertisements messages with Prefix Information Mobile Prefix Advertisements messages with Prefix Information
Options, which give the valid lifetime and preferred lifetime for Options, which give the valid lifetime and preferred lifetime for
available prefixes on the link [17]. available prefixes on the link [20].
Mobile IPv6 arranges to propagate relevant prefix information Mobile IPv6 arranges to propagate relevant prefix information
to the mobile node when it is away from home, so that it may be to the mobile node when it is away from home, so that it may be
used in mobile node home address configuration, and in network used in mobile node home address configuration, and in network
renumbering. To avoid possible security attacks from forged Mobile renumbering. To avoid possible security attacks from forged Mobile
Prefix Advertisements all such Advertisements must be authenticated Prefix Advertisements all such Advertisements must be authenticated
to the mobile node by its home agent using IPsec [13, 11, 12] if a to the mobile node by its home agent using IPsec [14, 12, 13] if a
security associate exists (i.e. unless the mobile node does not yet security associate exists (i.e. unless the mobile node does not yet
have a home address configured). have a home address configured).
9.7. Receiving Router Advertisement Messages 9.8. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent, the For each link on which a router provides service as a home agent, the
router maintains a Home Agents List recording information about all router maintains a Home Agents List recording information about all
other home agents on that link. This list is used in the dynamic other home agents on that link. This list is used in the dynamic
home agent address discovery mechanism, described in Section 9.8. home agent address discovery mechanism, described in Section 9.9.
The information for the list is learned through receipt of the The information for the list is learned through receipt of the
periodic unsolicited multicast Router Advertisements from each other periodic unsolicited multicast Router Advertisements from each other
home agent on the link, in which the Home Agent (H) bit is set, in a home agent on the link, in which the Home Agent (H) bit is set, in a
manner similar to the Default Router List conceptual data structure manner similar to the Default Router List conceptual data structure
maintained by each host for Neighbor Discovery [17]. maintained by each host for Neighbor Discovery [20].
On receipt of a valid Router Advertisement, as defined in the On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [17], the home processing algorithm specified for Neighbor Discovery [20], the home
agent performs the following steps, in addition to any steps already agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery: required of it by Neighbor Discovery:
- If the Home Agent (H) bit in the Router Advertisement is not set, - If the Home Agent (H) bit in the Router Advertisement is not set,
skip all of the following steps. skip all of the following steps.
- If the Home Agent (H) bit in the Router Advertisement is not set, - If the Home Agent (H) bit in the Router Advertisement is not set,
and the sending node has an entry in the current Home Agents and the sending node has an entry in the current Home Agents
List, delete the corresponding entry. Subsequently, skip all of List, delete the corresponding entry. Subsequently, skip all of
the following steps. the following steps.
- Otherwise, extract the Source Address from the IP header of the - Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [17]. link of the home agent sending this Advertisement [20].
- Determine from the Router Advertisement the preference for this - Determine from the Router Advertisement the preference for this
home agent. If the Router Advertisement contains a Home Agent home agent. If the Router Advertisement contains a Home Agent
Information Option, then the preference is taken from the Home Information Option, then the preference is taken from the Home
Agent Preference field in the option; otherwise, the default Agent Preference field in the option; otherwise, the default
preference of 0 MUST be used. preference of 0 MUST be used.
- Determine from the Router Advertisement the lifetime for - Determine from the Router Advertisement the lifetime for
this home agent. If the Router Advertisement contains a Home this home agent. If the Router Advertisement contains a Home
Agent Information Option, then the lifetime is taken from Agent Information Option, then the lifetime is taken from
skipping to change at page 76, line 11 skipping to change at page 98, line 44
agent based on each Prefix Information option received in agent based on each Prefix Information option received in
this Advertisement in which the Router Address (R) bit is set this Advertisement in which the Router Address (R) bit is set
(Section 6.2). For each such global address determined from this (Section 6.2). For each such global address determined from this
Advertisement, add this global address to the list of global Advertisement, add this global address to the list of global
addresses for this home agent in this Home Agents List entry. addresses for this home agent in this Home Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for A home agent SHOULD maintain an entry in its Home Agents List for
each such valid home agent address until that entry's lifetime each such valid home agent address until that entry's lifetime
expires, after which time the entry MUST be deleted. expires, after which time the entry MUST be deleted.
9.8. Dynamic Home Agent Address Discovery 9.9. Dynamic Home Agent Address Discovery
A mobile node, while away from home, MAY use the dynamic home agent A mobile node, while away from home, MAY use the dynamic home agent
address discovery mechanism in section 10.8 to attempt to discover 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 the address of one or more routers serving as home agents on its home
link. This discovery might become necessary, for example, if some link. This discovery might become necessary, for example, if some
nodes on its home link have been reconfigured while the mobile node 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 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 the mobile node's home agent has been replaced by a different router
serving this role. serving this role.
As described in Section 10.8, a mobile node attempts dynamic home As described in Section 10.8, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the "Mobile IPv6 Home-Agents" anycast Discovery Request message to the "Mobile IPv6 Home-Agents" anycast
address [10] for its home IP subnet prefix, using its care-of address address [11] for its home IP subnet prefix, using its care-of address
as the Source Address of the packet. A home agent receiving such a as the Source Address of the packet. A home agent receiving such a
Home Agent Address Discovery Request message that is serving this Home Agent Address Discovery Request message that is serving this
subnet (the home agent is configured with this anycast address on one subnet (the home agent is configured with this anycast address on one
of its network interfaces) SHOULD return an ICMP Home Agent Address of its network interfaces) SHOULD return an ICMP Home Agent Address
Discovery Reply message to the mobile node (at its care-of address Discovery Reply message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), with the that was used as the Source Address of the Request message), with the
Source Address of the Reply packet set to one of the global unicast Source Address of the Reply packet set to one of the global unicast
addresses of the home agent. The Home Agent Addresses field in the addresses of the home agent. The Home Agent Addresses field in the
Reply message is constructed as follows: Reply message is constructed as follows:
- The Home Agent Addresses field SHOULD contain one global IP - The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home address for each home agent currently listed in this home
agent's own Home Agents List (Section 4.6). However, if this agent's own Home Agents List (Section 4.7). However, if this
home agent's own global IP address would be placed in the list home agent's own global IP address would be placed in the list
(as described below) as the first entry in the list, then this (as described below) as the first entry in the list, then this
home agent SHOULD NOT include its own address in the Home Agent home agent SHOULD NOT include its own address in the Home Agent
Addresses field in the Reply message. Not placing this home Addresses field in the Reply message. Not placing this home
agent's own IP address in the list will cause the receiving agent's own IP address in the list will cause the receiving
mobile node to consider this home agent as the most preferred mobile node to consider this home agent as the most preferred
home agent; otherwise, this home agent will be considered to be home agent; otherwise, this home agent will be considered to be
preferred in its order given by its place in the list returned. preferred in its order given by its place in the list returned.
- The IP addresses in the Home Agent Addresses field SHOULD be - The IP addresses in the Home Agent Addresses field SHOULD be
skipping to change at page 77, line 18 skipping to change at page 99, line 51
- Among home agents with equal preference, their IP addresses - Among home agents with equal preference, their IP addresses
in the Home Agent Addresses field SHOULD be listed in an in the Home Agent Addresses field SHOULD be listed in an
order randomized with respect to other home agents with equal order randomized with respect to other home agents with equal
preference, each time a Home Agent Address Discovery Reply preference, each time a Home Agent Address Discovery Reply
message is returned by this home agent. message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more - For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry, than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected then one of these global IP addresses SHOULD be selected
to include in the Home Agent Addresses field in the Reply to include in the Home Agent Addresses field in the Reply
message. As described in Section 4.6, one Home Agents List message. As described in Section 4.7, one Home Agents List
entry, identified by the home agent's link-local address, entry, identified by the home agent's link-local address,
exists for each home agent on the link; associated with that exists for each home agent on the link; associated with that
list entry is one or more global IP addresses for this home list entry is one or more global IP addresses for this home
agent, learned through Prefix Information options with the agent, learned through Prefix Information options with the
Router Address (R) bit is set, received in Router Advertisements Router Address (R) bit is set, received in Router Advertisements
from this link-local address. from this link-local address.
The selected global IP address for each home agent to include in The selected global IP address for each home agent to include in
forming the Home Agent Addresses field in the Reply message MUST forming the Home Agent Addresses field in the Reply message MUST
be the global IP address of the respective home agent sharing a be the global IP address of the respective home agent sharing a
skipping to change at page 77, line 45 skipping to change at page 100, line 26
being fragmented (or rejected by an intermediate router with an being fragmented (or rejected by an intermediate router with an
ICMP Packet Too Big message [5]), if the resulting total packet ICMP Packet Too Big message [5]), if the resulting total packet
size containing the complete list of home agents in the Home size containing the complete list of home agents in the Home
Agent Addresses field would exceed the minimum IPv6 MTU [6], the Agent Addresses field would exceed the minimum IPv6 MTU [6], the
home agent SHOULD reduce the number of home agent IP addresses home agent SHOULD reduce the number of home agent IP addresses
returned in the packet to the number of addresses that will fit returned in the packet to the number of addresses that will fit
without exceeding this limit. The home agent addresses returned without exceeding this limit. The home agent addresses returned
in the packet SHOULD be those from the complete list with the in the packet SHOULD be those from the complete list with the
highest preference. highest preference.
9.8.1. Aggregate List of Home Network Prefixes 9.9.1. Aggregate List of Home Network Prefixes
A mobile node on a remote network SHOULD autoconfigure all of the A mobile node on a remote network SHOULD autoconfigure all of the
global IP addresses, which it would autoconfigure if it were attached global IP addresses, which it would autoconfigure if it were attached
to its home network, from network prefixes representing network to its home network, from network prefixes representing network
addresses that are served by home agents. Site-local addresses MAY addresses that are served by home agents. Site-local addresses MAY
be autoconfigured if the mobile node is roaming in a network on the be autoconfigured if the mobile node is roaming in a network on the
same site as its home addresses. Site-local addresses and addresses same site as its home addresses. Site-local addresses and addresses
not served by a home agent MUST NOT be autoconfigured, since they are not served by a home agent MUST NOT be autoconfigured, since they are
unusable in the remote network. unusable in the remote network.
skipping to change at page 78, line 23 skipping to change at page 101, line 4
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 [20]). 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.
- Check Router Advertisements which contain an `H' bit (from other - Check Router Advertisements which contain an `H' bit (from other
home agents) for valid prefixes that are not yet in the aggregate home agents) for valid prefixes that are not yet in the aggregate
list, and if they are usable for autoconfiguration (`A' bit set, list, and if they are usable for autoconfiguration (`A' bit set,
and prefix length is valid for address autoconfiguration on the and prefix length is valid for address autoconfiguration on the
home subnet) add them and preserve the `L' flag value. Clear the home subnet) add them and preserve the `L' flag value. Clear the
`R' flag and zero the interface-id portion of the prefix field `R' flag and zero the interface-id portion of the prefix field
to prevent mobile nodes from treating another router's interface to prevent mobile nodes from treating another router's interface
address as belonging to the home agent. Treat the lifetimes address as belonging to the home agent. Treat the lifetimes
of these prefixes as decrementing in real time, as defined in of these prefixes as decrementing in real time, as defined in
section 6.2.7 of RFC 2461 [17]. section 6.2.7 of RFC 2461 [20].
- 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 [20]) and section
5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [27]). 5.5.3 of RFC 2462 (Stateless Address Autoconfiguration [35]).
- If the L 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 flag in the aggregate list. Ignore the flag if it list, set the flag in the aggregate list. Ignore the flag if it
is clear. is clear.
- 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 Mobile Prefix 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 It may be possible to construct an aggregate list by combining
information contained in the home agent's AdvPrefixList and its information contained in the home agent's AdvPrefixList and its
Home Agents List used for Dynamic Home Agent Address Discovery Home Agents List used for Dynamic Home Agent Address Discovery
(Section 10.8). (Section 10.8).
9.8.2. Scheduling Prefix Deliveries to the Mobile Node 9.9.2. Scheduling Prefix Deliveries to the Mobile Node
A home agent serving a mobile node will schedule the delivery of new A home agent serving a mobile node will schedule the delivery of new
prefix information to that mobile node when any of the following prefix information to that mobile node when any of the following
conditions occur: conditions occur:
MUST: MUST:
- The valid or preferred lifetime or the state of the flags changes - The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address for the prefix of the mobile node's registered home address
changes changes
skipping to change at page 79, line 22 skipping to change at page 102, line 4
A home agent serving a mobile node will schedule the delivery of new A home agent serving a mobile node will schedule the delivery of new
prefix information to that mobile node when any of the following prefix information to that mobile node when any of the following
conditions occur: conditions occur:
MUST: MUST:
- The valid or preferred lifetime or the state of the flags changes - The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address for the prefix of the mobile node's registered home address
changes 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.18).
MAY: MAY:
- A new prefix is added to the aggregate list - A new prefix is added to the aggregate list
- The valid or preferred lifetime or the state of the flags changes - The valid or preferred lifetime or the state of the flags changes
for a prefix which is not used in any binding cache entry for for a prefix which is not used in any binding cache entry for
this mobile node this mobile node
The home agent uses the following algorithm to determine when to send The home agent uses the following algorithm to determine when to send
skipping to change at page 80, line 47 skipping to change at page 103, line 26
MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt)
RAND_ADV_DELAY is the offset from the current time to be used RAND_ADV_DELAY is the offset from the current time to be used
to schedule the necessary advertisement to the mobile node. The to schedule the necessary advertisement to the mobile node. The
computation is expected to alleviate bursts of advertisements when computation is expected to alleviate bursts of advertisements when
prefix information changes. In addition, a home agent MAY further prefix information changes. In addition, a home agent MAY further
reduce the rate of packet transmission by further delaying individual reduce the rate of packet transmission by further delaying individual
advertisements, if needed to avoid overwhelming local network advertisements, if needed to avoid overwhelming local network
resources. resources.
9.8.3. Sending Advertisements to the Mobile Node 9.9.3. Sending Advertisements to the Mobile Node
When sending a Mobile Prefix Advertisement to the mobile node, the When sending a Mobile Prefix Advertisement to the mobile node, the
home agent MUST construct the packet as follows: home agent MUST construct the packet as follows:
- The Source Address in the packet's IPv6 header MUST be set to - The Source Address in the packet's IPv6 header MUST be set to
the home agent's IP address to which the mobile node addressed the home agent's IP address to which the mobile node addressed
its current home registration, or its default global home agent its current home registration, or its default global home agent
address if no binding exists. address if no binding exists.
- If a security association exists with the mobile node's address, - If a security association exists with the mobile node's address,
the packet MUST be protected by IPsec [13, 11, 12] to guard the packet MUST be protected by IPsec [14, 12, 13] to guard
against malicious Mobile Prefix Advertisements. The IPsec against malicious Mobile Prefix Advertisements. The IPsec
protection MUST provide sender authentication, data integrity protection MUST provide sender authentication, data integrity
protection, and replay protection, covering the Mobile Prefix protection, and replay protection, covering the Mobile Prefix
Advertisement. Advertisement.
- The advertisement MUST include a Binding Request destination - The advertisement MUST include a Binding Request destination
option if this is the first advertisement for a home option if this is the first advertisement for a home
registration, or if there was a change in prefix information registration, or if there was a change in prefix information
since the last acknowledged advertisement was sent to the mobile since the last acknowledged advertisement was sent to the mobile
node for the home registration. The Binding Request destination node for the home registration. The Binding Request destination
skipping to change at page 82, line 22 skipping to change at page 104, line 52
solicitations until one is received; thus, the home agent SHOULD NOT solicitations until one is received; thus, the home agent SHOULD NOT
retransmit the responding advertisement. retransmit the responding advertisement.
If while the home agent is still retransmitting a Mobile Prefix 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 Prefix Advertisement to above occurs on the home link causing another Prefix Advertisement to
be sent to the mobile node, the home agent SHOULD combine any Prefix be sent to the mobile node, the home agent SHOULD combine any Prefix
Information options in the unacknowledged Mobile Prefix Advertisement Information options in the unacknowledged Mobile Prefix Advertisement
into the new Advertisement, discard the old Advertisement, and then into the new Advertisement, discard the old Advertisement, and then
begin retransmitting the new one. according to the algorithm in begin retransmitting the new one. according to the algorithm in
section 9.8.2. The home agent MUST generate a new unique identifier section 9.9.2. The home agent MUST generate a new unique identifier
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 Mobile Prefix Advertisement. tunneled with the new Mobile Prefix Advertisement.
9.8.4. Lifetimes for Changed Prefixes 9.9.4. Lifetimes for Changed Prefixes
As described in Section 9.1, the lifetime returned by the home As described in Section 9.1, the lifetime returned by the home
agent in a Binding Acknowledgement MUST be no greater than the agent in a Binding Acknowledgement MUST be no greater than the
remaining valid lifetime for the subnet prefix in the mobile node's remaining valid lifetime for the subnet prefix in the mobile node's
home address. Furthermore, as described in Section 10.9, Binding home address. Furthermore, as described in Section 10.9, Binding
Updates sent by the mobile node to other nodes MUST use a lifetime no Updates sent by the mobile node to other nodes MUST use a lifetime no
greater than the remaining lifetime of its home registration of its greater than the remaining lifetime of its home registration of its
primary care-of address. These limits on the binding lifetime serve primary care-of address. These limits on the binding lifetime serve
to prohibit use of a mobile node's home address after it becomes to prohibit use of a mobile node's home address after it becomes
invalid. The mobile node SHOULD further limit the lifetimes that it invalid. The mobile node SHOULD further limit the lifetimes that it
skipping to change at page 83, line 42 skipping to change at page 106, line 12
the packet are then reversed in the node receiving the packet, the packet are then reversed in the node receiving the packet,
restoring the mobile node's home address to be the packet's restoring the mobile node's home address to be the packet's
Source Address before processing by higher protocol layers and Source Address before processing by higher protocol layers and
applications. applications.
- For short-term communication, particularly for communication that - For short-term communication, particularly for communication that
may easily be retried if it fails, the mobile node MAY choose may easily be retried if it fails, the mobile node MAY choose
to directly use one of its care-of addresses as the source of to directly use one of its care-of addresses as the source of
the packet, thus not requiring the use of a Home Address option the packet, thus not requiring the use of a Home Address option
in the packet. An example of this type of communication might in the packet. An example of this type of communication might
be DNS queries sent by the mobile node [15, 16]. Using the be DNS queries sent by the mobile node [17, 18]. Using the
mobile node's care-of address as the source for such queries will mobile node's care-of address as the source for such queries will
generally have a lower overhead than using the mobile node's generally have a lower overhead than using the mobile node's
home address, since no extra options need be used in either the home address, since no extra options need be used in either the
query or its reply, and all packets can be routed normally, query or its reply, and all packets can be routed normally,
directly between their source and destination without relying directly between their source and destination without relying
on Mobile IP. If the mobile node has no particular knowledge on Mobile IP. If the mobile node has no particular knowledge
that the communication being sent fits within this general type that the communication being sent fits within this general type
of communication, however, the mobile node SHOULD NOT use its of communication, however, the mobile node SHOULD NOT use its
care-of address as the source of the packet in this way. care-of address as the source of the packet in this way.
skipping to change at page 84, line 39 skipping to change at page 107, line 12
network interface on which the mobile node will transmit the network interface on which the mobile node will transmit the
packet. packet.
By using the care-of address as the Source Address in the IPv6 By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through any Address option, the packet will be able to safely pass through any
router implementing ingress filtering [7]. router implementing ingress filtering [7].
10.2. Interaction with Outbound IPsec Processing 10.2. Interaction with Outbound IPsec Processing
This section sketches the interaction between outbound Mobile IP This section sketches the interaction between outbound Mobile
processing and outbound IP Security (IPsec) processing for IP processing and outbound IP Security (IPsec) processing for
packets sent by a mobile node while away from home. Any specific packets sent by a mobile node while away from home. Any specific
implementation MAY use algorithms and data structures other than implementation MAY use algorithms and data structures other than
those suggested here, but its processing MUST be consistent with the those suggested here, but its processing MUST be consistent with the
effect of the operation described here and with the relevant IPsec effect of the operation described here and with the relevant IPsec
specifications. In the steps described below, it is assumed that specifications. In the steps described below, it is assumed that
IPsec is being used in transport mode [13] and that the mobile node IPsec is being used in transport mode [14] and that the mobile node
is using its home address as the source for the packet (from the is using its home address as the source for the packet (from the
point of view of higher protocol layers or applications, as described point of view of higher protocol layers or applications, as described
in Section 10.1): in Section 10.1):
- The packet is created by higher layer protocols and applications - The packet is created by higher layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IP (e.g., by TCP) as if the mobile node were at home and Mobile IP
were not being used. Mobile IP is transparent to such higher were not being used. Mobile IP is transparent to such higher
layers. layers.
- As part of outbound packet processing in IP, the packet is - As part of outbound packet processing in IP, the packet is
compared against the IPsec Security Policy Database (SPD) to compared against the IPsec Security Policy Database (SPD) to
determine what processing is required for the packet [13]. determine what processing is required for the packet [14].
- 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 is either
a Home Address option into the packet, replacing the Source using reverse tunneling or route optimization to reach the
Address in the packet's IP header with a care-of address suitable correspondent node.
for the link on which the packet is being sent, as described in
If reverse tunneling is used, the packet is constructed in the
normal manner and then tunneled through through the home agent.
If route optimization is in use, the mobile node inserts a Home
Address option into the packet, replacing the Source 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
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 after the Address option is inserted MUST appear in the packet after the
Routing Header, if present, and before the AH [11] (or ESP [12]) Routing Header, if present, and before the AH [12] (or ESP [13])
header, so that the Home Address option is processed by the header, so that the Home Address option is processed by the
destination node (and, possibly, intermediate routing nodes) destination node before the AH or ESP header is processed.
before the AH or ESP header is processed.
- If a Binding Update is being included in the packet, it is
also added to a Destination Options header in the packet. The
Destination Options header in which the Binding Update option is
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
the AH or ESP header. The authentication data MUST be calculated in the AH or ESP header. The AH authentication data MUST be
as if the following were true: calculated as if the following were true:
* the IPv6 source address in the IPv6 header contains the * the IPv6 source address in the IPv6 header contains the
mobile node's home address, mobile node's home address,
* the Home Address field of the Home Address destination option * the Home Address field of the Home Address destination option
(section 5.4) contains the new care-of address. (section 5.3) contains the new care-of address.
This allows, but does not require, the receiver of the packet - This allows, but does not require, the receiver of the
containing the Binding Update to exchange the two fields of the packet containing a Home Address Option to exchange the two
incoming packet, simplifying processing for all subsequent packet fields of the incoming packet, simplifying processing for all
headers. The mechanics of implementation do not absolutely subsequent packet headers. The mechanics of implementation
require such an exchange to occur; other implementation do not absolutely require such an exchange to occur; other
strategies may be more appropriate, as long as the result of the implementation strategies may be more appropriate, as long as the
authentication calculation remain the same. result of the authentication calculation remain the same.
In addition, when using any automated key management protocol [13] In addition, when using any automated key management protocol [14]
(such as IKE [8]) to create any new SA (or SA bundle) while away (such as IKE [8]) to create any new SA (or SA bundle) while away
from home, a mobile node MUST take special care in its processing of from home, a mobile node MUST take special care in its processing of
the key management protocol. Otherwise, other nodes with which the the key management protocol. Otherwise, other nodes with which the
mobile node must communicate as part of the automated key management mobile node must communicate as part of the automated key management
protocol processing may be unable to correctly deliver packets to protocol processing may be unable to correctly deliver packets to
the mobile node if they and/or the mobile node's home agent do the mobile node if they and/or the mobile node's home agent do
not then have a current Binding Cache entry for the mobile node. not then have a current Binding Cache entry for the mobile node.
For the default case of using IKE as the automated key management For the default case of using IKE as the automated key management
protocol [8, 13], such problems can be avoided by the following protocol [8][14], such problems can be avoided by the following
requirements on the use of IKE by a mobile node while away from home: 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 established by way of IKE, the mobile node node's home address established by way of IKE, the mobile node
MUST include an ISAKMP Identification Payload [14] in the IKE MUST include an ISAKMP Identification Payload [16] in the IKE
exchange, giving the mobile node's home address as the initiator exchange, giving the mobile node's home address as the initiator
of the Security Association [22]. of the Security Association [28].
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 86, line 51 skipping to change at page 109, line 24
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.10), and its previous care-of address is located (Section 10.11), 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.9, subject to sender of the packet, as described in Section 10.9, subject to
the rate limiting defined in Section 10.12. The mobile node MUST the rate limiting defined in Section 10.13. The mobile node MUST
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 MUST process the received packet in the header), the mobile node MUST process the received packet in
manner defined for the type of IPv6 Routing header used [6], which the manner defined for the type of IPv6 Routing header used (see
will result in the packet being processed normally by upper-layer Section 5.4), which will result in the packet being processed
protocols within the mobile node, as if it had been addressed (only) normally by upper-layer protocols within the mobile node, as if it
to the mobile node's home address. had been addressed (only) to the mobile node's home address.
In addition, the general procedures defined by IPv6 for Routing
headers suggest that a received Routing header MAY be automatically
"reversed" to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the received packet is
authenticated [6]. If this is done for upper-layer protocol response
packets sent by a mobile node while away from home, the mobile
node SHOULD NOT include its own care-of address, which appears in
the Routing header of the received packet, in the reversed route
for the response packet. If the received Routing header contained
no additional hops (other than the mobile node's home address and
care-of address), then any upper-layer protocol response packet
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 det