view Side-By-Side changes
IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Rice University
Charles Perkins
Nokia Research Center
2 July 2001
22 March 2002
Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-15.txt>
<draft-ietf-mobileip-ipv6-16.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents, valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies the operation of mobile computers using IPv6.
Each mobile node is always identified by its home address, regardless
of its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current
location. IPv6 packets addressed to a mobile node's home address are
transparently routed to its care-of address. The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address, and to then send any packets destined for the
mobile node directly to it at this care-of address. To support this
operation, Mobile IPv6 defines four new IPv6 destination options,
including one that MUST be supported in packets received by any node,
whether mobile or stationary.
Johnson and Perkins Expires 2 January 22 September 2002 [Page i]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Comparison with Mobile IP for IPv4 3
3. Terminology 6
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7
4. Overview of Mobile IPv6 8
4.1. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 8
4.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
4.2. 10
4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 11
4.3. 13
4.4. Alignment Requirements for New Destination Options . . . 12
4.4. Authentication Requirements for Binding Update and
Acknowledgement 13
4.5. Security Design . . . . . . . . . . . . . . . . . . . . 13
4.5. New IPv6 ICMP Messages . 14
4.5.1. Security Threats . . . . . . . . . . . . . . . . 14
4.6. Conceptual Data Structures
4.5.2. Security Features . . . . . . . . . . . . . . . . 15
4.7.
4.5.3. Securing Tunnels to and from the Home Agents . . 17
4.5.4. Securing Binding Management 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 . . . . . . . . . . . 20
5. . . . . . 23
4.6. New IPv6 Destination Options and Message Types 22
5.1. Binding Update Option ICMP Messages . . . . . . . . . . . . . . . . . 24
4.7. Conceptual Data Structures . 22
5.2. Binding Acknowledgement Option . . . . . . . . . . . . . 26
5.3. . 25
4.8. Binding Request Option Management . . . . . . . . . . . . . . . . . . . 30
5.4. Home Address Option
5. New IPv6 Destination Options and Message Types 31
5.1. Mobility Header . . . . . . . . . . . . . . . . . . . 32
5.5. Mobile IPv6 Destination Option Sub-Options . . 31
5.1.1. Format . . . . . 35
5.5.1. Pad1 . . . . . . . . . . . . . . . . 32
5.1.2. Binding Request (BR) Message . . . . . . 36
5.5.2. PadN . . . . 33
5.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34
5.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 36
5.5.3. Unique Identifier 35
5.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 36
5.1.6. Care-of Test (CoT) Message . . . 37
5.5.4. Alternate Care-of Address . . . . . . . . 38
5.1.7. Binding Update (BU) Message . . . . 37
5.6. Authentication Data . . . . . . . 40
5.1.8. Binding Acknowledgement (BA) Message . . . . . . 44
5.1.9. Binding Missing (BM) Message . . . . . . 38
5.7. ICMP Home Agent Address Discovery Request Message . . . . 40
5.8. ICMP Home Agent Address Discovery Reply Message 49
5.2. Mobility Header Parameters . . . . . 41
5.9. ICMP Mobile Prefix Solicitation Message Format . . . . . 43
5.10. ICMP Mobile Prefix Advertisement Message Format . . . . . 45
6. Modifications to IPv6 Neighbor Discovery 47
6.1. Modified Router Advertisement Message 51
5.2.1. Format . . . . . . 47
6.2. Modified Prefix Information Option Format . . . . . . . . 48
6.3. New Advertisement Interval Option Format . . . . . . . 51
5.2.2. Pad1 . 50
6.4. New Home Agent Information Option Format . . . . . . . . 51
6.5. Changes to Sending Router Advertisements . . . . . . . . 53
6.6. Changes to Sending Router Solicitations . . . . . 52
5.2.3. PadN . . . . 54
Johnson and Perkins Expires 2 January 2002 [Page ii]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
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 . . . . . . . . . . . 52
5.2.4. Unique Identifier . 56
7.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 56
7.4. Requirements for IPv6 Mobile Nodes . . . 53
5.2.5. Alternate Care-of Address . . . . . . . . . . . 57 . 53
Johnson and Perkins Expires 2 January 22 September 2002 [Page iii] ii]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
8. Correspondent Node Operation 59
8.1. Receiving Packets from a Mobile Node . . . . . . . 22 March 2002
5.2.6. Nonce Indices . . . 59
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . 54
5.2.7. Authentication Data . 59
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . 54
5.3. Home Address Option . 60
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 61
8.5. Sending Binding Acknowledgements . . . . 55
5.4. Routing Header type 2 . . . . . . . . 61
8.6. Sending Binding Requests . . . . . . . . . . 58
5.4.1. Routing Header Packet format . . . . . . 62
8.7. Cache Replacement Policy . . . . 58
5.4.2. Sending RH type 2 . . . . . . . . . . . . 62
8.8. Receiving ICMP Error Messages . . . . 59
5.4.3. Verification by receiver . . . . . . . . . . 63
8.9. Sending Packets to a Mobile Node . . 60
5.4.4. Extension header ordering . . . . . . . . . . 64
9. Home Agent Operation 67
9.1. Primary Care-of Address Registration . . 60
5.4.5. Reversing type 2 routing headers . . . . . . . . 67
9.2. Primary Care-of Address De-registration 60
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 61
5.5.1. Pad1 . . 69
9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 70
9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 72
9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 73
9.6. Home Prefix Propagation . . . . 62
5.5.2. PadN . . . . . . . . . . . . . 74
9.7. Receiving Router Advertisement Messages . . . . . . . . . 74
9.8. Dynamic 62
5.6. ICMP Home Agent Address Discovery Request Message . . . . 63
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . . 76
9.8.1. Aggregate List of Home Network Prefixes 64
5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 77
9.8.2. Scheduling Prefix Deliveries to the 66
5.9. ICMP Mobile Node Prefix Advertisement Message Format . 79
9.8.3. Sending Advertisements to the Mobile Node . . . . 80
9.8.4. Lifetimes for Changed Prefixes 68
6. Modifications to IPv6 Neighbor Discovery 70
6.1. Modified Router Advertisement Message Format . . . . . . 70
6.2. Modified Prefix Information Option Format . . . 82
10. Mobile Node Operation 83
10.1. Sending Packets While Away from Home . . . . . 71
6.3. New Advertisement Interval Option Format . . . . . 83
10.2. Interaction with Outbound IPsec Processing . . . 73
6.4. New Home Agent Information Option Format . . . . 84
10.3. Receiving Packets While Away from Home . . . . 74
6.5. Changes to Sending Router Advertisements . . . . . 86
10.4. Movement Detection . . . 76
6.6. Changes to Sending Router Solicitations . . . . . . . . . 77
7. Requirements for Types of IPv6 Nodes 79
7.1. Requirements for All IPv6 Routers . . . . . . . 87
10.5. Receiving Local Router Advertisement Messages . . . . . 79
7.2. Requirements for IPv6 Home Agents . 90
10.6. Forming New Care-of Addresses . . . . . . . . . . . 79
7.3. Requirements for IPv6 Mobile Nodes . . . 91
10.7. Sending Binding Updates to the Home Agent . . . . . . . . 93
10.8. Dynamic Home Agent Address Discovery 80
Johnson and Perkins Expires 22 September 2002 [Page iii]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
8. Correspondent Node Operation 82
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 95
10.9. Sending 82
8.2. Receiving Binding Updates to Correspondent Nodes . . . . . 96
10.10. Establishing Forwarding from a Previous Care-of Address . 99
10.11. Retransmitting . . . . . . . . . . 82
8.3. Requests to Cache a Binding Updates . . . . . . . . . . . . . 100
10.12. Rate Limiting for Sending . . 83
8.4. Requests to Delete a Binding Updates . . . . . . . . 100
10.13. Receiving . . . . . . 84
8.5. Sending Binding Acknowledgements . . . . . . . . . . . 101
10.14. Receiving . 84
8.6. Sending Binding Requests . . . . . . . . . . . . . . . 102
10.15. . 85
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 85
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 102
10.16. 86
8.9. Sending Packets to a Mobile Prefix Solicitations Node . . . . . . . . . . . 103
10.17. Receiving Mobile Prefix Advertisements . 87
9. Home Agent Operation 89
9.1. Primary Care-of Address Registration . . . . . . . . . 104
10.18. Using Multiple . 89
9.2. Primary Care-of Addresses Address De-Registration . . . . . . . . . 92
9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 105
10.19. Routing Multicast 92
9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 94
9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 96
9.6. Protecting Return Routability Packets . . . . . . . . . 105
10.20. Returning . 96
9.7. Home Prefix Propagation . . . . . . . . . . . . . . . . . 96
9.8. Receiving Router Advertisement Messages . . . . 106
11. Protocol Constants 108
12. IANA Considerations 109
Johnson and Perkins Expires 2 January 2002 [Page iv]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
13. Security Considerations 111
13.1. Binding Updates, Acknowledgements, and Requests . . . . . 111
13.2. Security for the 97
9.9. Dynamic Home Agent Address Option Discovery . . . . . . . . . . 111
13.3. General Mobile Computing Issues 98
9.9.1. Aggregate List of Home Network Prefixes . . . . . 100
9.9.2. Scheduling Prefix Deliveries to the Mobile Node . 101
9.9.3. Sending Advertisements to the Mobile Node . . . . 103
9.9.4. Lifetimes for Changed Prefixes . . . 112
Acknowledgements 113
References 114
A. Changes from Previous Version of the Draft 115
A.1. Changes from Draft Version ...-14 . . . . . . 105
10. Mobile Node Operation 105
10.1. Sending Packets While Away from Home . . . . . . 115
A.2. Changes from Previous Versions of the Draft . . . . 105
10.2. Interaction with Outbound IPsec Processing . . . 117
B. Remote . . . . 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 Configuration Discovery . . . . . . . . . . 117
10.9. Sending Binding Updates to Correspondent Nodes . . . . . 118
Chairs' Addresses 119
Authors'
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 120 . . . . . . . . . . . . 128
10.21. Routing Multicast Packets . . . . . . . . . . . . . . . . 128
10.22. Returning Home . . . . . . . . . . . . . . . . . . . . . 129
11. Protocol Constants 131
Johnson and Perkins Expires 2 January 22 September 2002 [Page v] iv]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
1. Introduction
This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support 22 March 2002
12. Future Extensions 132
12.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 132
12.2. Triangular Routing and Unverified HAOs . . . . . . . . . 132
12.3. New Authorization Methods beyond RR . . . . . . . . . . . 132
13. IANA Considerations 133
14. Security Considerations 134
14.1. Security 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 Tunneling to and 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
destination IP address. In order Home Agent . . 134
14.2. Security for the Binding Updates to continue 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
Acknowledgements 137
References 138
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
B. Remote Home Address Configuration 144
Chairs' Addresses 145
Authors' Addresses 146
Johnson and Perkins Expires 22 September 2002 [Page v]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
1. Introduction
This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support
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
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
destination IP address. In order to continue communication in spite
of its movement, a mobile node could change its IP address each time
it moves to a new link, but the mobile node would then not be able
to maintain transport and higher-layer connections when it changes
location. Mobility support in IPv6 is particularly important, as
mobile computers are likely to account for a majority or at least a
substantial fraction of the population of the Internet during the
lifetime of IPv6.
The protocol operation defined here, known as Mobile IPv6, allows a
mobile node to move from one link to another without changing the
mobile node's IP address. A mobile node is always addressable by
its "home address", an IP address assigned to the mobile node within
its home subnet prefix on its home link. Packets may be routed to
the mobile node using this address regardless of the mobile node's
current point of attachment to the Internet, and the mobile node may
continue to communicate with other nodes (stationary or mobile) after
moving to a new link. The movement of a mobile node away from its
home link is thus transparent to transport and higher-layer protocols
and applications.
The Mobile IPv6 protocol is just as suitable for mobility across
homogeneous media as for mobility across heterogeneous media. For
example, Mobile IPv6 facilitates node movement from one Ethernet
segment to another as well as it facilitates node movement from an
Ethernet segment to a wireless LAN cell, with the mobile node's IP
address remaining unchanged in spite of such movement.
One can think of the Mobile IPv6 protocol as solving the
network-layer mobility management problem. Some mobility management
applications -- for example, handover among wireless transceivers,
each of which covers only a very small geographic area -- have been
solved using link-layer techniques. For example, in many current
wireless LAN products, link-layer mobility mechanisms allow a
"handover" of a mobile node from one cell to another, reestablishing
link-layer connectivity to the node in each new location. Within
the natural limitations imposed by link-management solutions, and as
long as such handover occurs only within cells of the mobile node's
home link, such link-layer mobility mechanisms MAY offer faster
convergence and lower overhead than Mobile IPv6. Extensions to the
Mobile IPv6 protocol have been proposed to support a more local,
hierarchical form of mobility management, but such extensions are
beyond the scope of this document.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 1]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
The protocol specified in this document solves the problem of
transparently routing packets to and from mobile nodes while away
from home. However, it does not attempt to solve all general
problems related to the use of mobile computers or wireless networks.
In particular, this protocol does not attempt to solve:
- Handling links with partial reachability, or unidirectional
connectivity, such as are often found in wireless networks. Some
aspects of this problem are addressed by the movement detection
procedure described in Section 10.4, but no attempt has been made
to fully solve this problem in its general form. Most aspects of
this problem can be solved by the workaround of restricting such
networks to only one router per link, although there are still
possible hidden terminal problems when two nodes on the same
link (on opposite sides of the router) attempt to communicate
directly.
- Access control on a link being visited by a mobile node. This
is a general problem any time an unauthenticated node is allowed
to connect to any link layer. It is independent of whether the
connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP
address on the link.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 2]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
2. Comparison with Mobile IP for IPv4
The design of Mobile IP support in IPv6 (Mobile IPv6) represents a
natural combination of the experiences gained from the development
of Mobile IP support in IPv4 (Mobile IPv4) [19, 18, 20], [25, 24, 26], together
with the opportunities provided by the design and deployment of a new
version of IP itself (IPv6) and the new protocol features offered
by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4,
but the protocol is now fully integrated into IP and provides many
improvements over Mobile IPv4. This section summarizes the major
differences between Mobile IPv4 and Mobile IPv6:
- Support for what is known in Mobile IPv4 as "Route
Optimization" [21] [27] is now built in as a fundamental part
of the protocol, rather than being added on as an optional
set of extensions that may not be supported by all nodes
as in Mobile IPv4. This integration of Route Optimization
functionality allows direct routing from any correspondent
node to any mobile node, without needing to pass through
the mobile node's home network and be forwarded by its home
agent, and thus eliminates the problem of "triangle routing"
present in the base Mobile IPv4 protocol [19]. [25]. The Mobile IPv4
"registration" functionality and the Mobile IPv4 Route
Optimization functionality are performed by a single protocol
rather than two separate (and different) protocols.
- Support is also integrated into Mobile IPv6 -- and into IPv6
itself -- for allowing mobile nodes and Mobile IP to coexist
efficiently with routers that perform "ingress filtering" [7]. A
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
normally through ingress filtering routers. The home address
of the mobile node is carried in the packet in a Home Address
destination option, allowing the use of the care-of address in
the packet to be transparent above the IP layer. The ability
to correctly process a Home Address option in a received packet
is required in all IPv6 nodes, whether mobile nor stationary,
whether host or router.
- The use of IPv6 destination options allows all Mobile IPv6
control traffic to be piggybacked on any existing IPv6 packets,
whereas in Mobile IPv4 and its Route Optimization extensions,
separate UDP packets were required for each control message.
- The use of the care-of address as the Source Address in each
packet's IP header also simplifies routing of multicast packets
sent by a mobile node. With Mobile IPv4, the mobile node
had to tunnel multicast packets to its home agent in order to
transparently use its home address as the source of the multicast
packets. With Mobile IPv6, the use of the Home Address option
allows the home address to be used but still be compatible with
Johnson and Perkins Expires 2 January 22 September 2002 [Page 3]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
multicast routing that is based in part on the packet's Source
Address.
- There is no longer any need to deploy special routers as
"foreign agents" as are used in Mobile IPv4. In Mobile IPv6,
mobile nodes make use of IPv6 features, such as Neighbor
Discovery [17] [20] and Address Autoconfiguration [27], [35], to operate in
any location away from home without any special support required
from its local router.
- The movement detection mechanism in Mobile IPv6 provides
bidirectional confirmation of a mobile node's ability to
communicate with its default router in its current location
(packets that the router sends are reaching the mobile node, and
packets that the mobile node sends are reaching the router).
This confirmation provides a detection of the "black hole"
situation that may exist in some wireless environments where the
link to the router does not work equally well in both directions,
such as when the mobile node has moved out of good wireless
transmission range from the router. The mobile node may then
attempt to find a new router and begin using a new care-of
address if its link to its current router is not working well.
In contrast, in Mobile IPv4, only the forward direction (packets
from the router are reaching the mobile node) is confirmed,
allowing the black hole condition to persist.
- Most packets sent to a mobile node while away from home in
Mobile IPv6 are sent using an IPv6 Routing header rather than IP
encapsulation, whereas Mobile IPv4 must use encapsulation for all
packets. The use of a Routing header requires less additional
header bytes to be added to the packet, reducing the overhead
of Mobile IP packet delivery. To avoid modifying the packet in
flight, however, packets intercepted and tunneled by a mobile
node's home agent in Mobile IPv6 must still use encapsulation for
delivery to the mobile node.
- While a mobile node is away from home, its home agent intercepts
any packets for the mobile node that arrive at the home network,
using IPv6 Neighbor Discovery [17] [20] rather than ARP [23] [29] as is
used in Mobile IPv4. The use of Neighbor Discovery improves
the robustness of the protocol (e.g., due to the Neighbor
Advertisement "override" bit) and simplifies implementation
of Mobile IP due to the ability to not be concerned with any
particular link layer as is required in ARP.
- The use of IPv6 encapsulation (and the Routing header) removes
the need in Mobile IPv6 to manage "tunnel soft state", which was
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
is no longer required in IPv6 for correctly relaying ICMP error
Johnson and Perkins Expires 2 January 22 September 2002 [Page 4]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
messages from within the tunnel back to the original sender of
the packet.
- The dynamic home agent address discovery mechanism in Mobile IPv6
uses IPv6 anycast [10] [11] and returns a single reply to the mobile
node, rather than the corresponding Mobile IPv4 mechanism that
used IPv4 directed broadcast and returned a separate reply from
each home agent on the mobile node's home link. The Mobile IPv6
mechanism is more efficient and more reliable, since only one
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
replies is required by the protocol.
- Mobile IPv6 defines an Advertisement Interval option on
Router Advertisements (equivalent to Agent Advertisements in
Mobile IPv4), allowing a mobile node to decide for itself how
many Router Advertisements (Agent Advertisements) it is willing
to miss before declaring its current router unreachable.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 5]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3.1. General Terms
IP Internet Protocol Version 6 (IPv6).
node A device that implements IP.
router A node that forwards IP packets not explicitly
addressed to itself.
host Any node that is not a router.
link A communication facility or medium over which nodes
can communicate at the link layer, such as an
Ethernet (simple or bridged). A link is the layer
immediately below IP.
interface A node's attachment to a link.
subnet prefix
A bit string that consists of some number of initial
bits of an IP address.
interface identifier
A number used to identify a node's interface on a
link. The interface identifier is the remaining
low-order bits in the node's IP address after the
subnet prefix.
link-layer address
A link-layer identifier for an interface, such as
IEEE 802 addresses on Ethernet links.
packet An IP header plus payload.
Security Association
a security object shared between two nodes which
includes the data mutually agreed on for operation
of some cryptographic algorithm (typically including
a key, as defined above).
Security Policy Database (SPD)
A database of security associations selectable by
rulesets (policies) that determine the packets for
which each security association is to be applied.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 6]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
3.2. Mobile IPv6 Terms
home address An IP address assigned to a mobile node within its
home link.
home subnet prefix
The IP subnet prefix corresponding to a mobile
node's home address.
home link The link on which a mobile node's home subnet prefix
is defined. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home
address to its home link.
mobile node A node that can change its point of attachment from
one link to another, while still being reachable via
its home address.
movement A change in a mobile node's point of attachment to
the Internet such that it is no longer connected to
the same link as it was previously. If a mobile
node is not currently attached to its home link, the
mobile node is said to be "away from home".
correspondent node
A peer node with which a mobile node is
communicating. The correspondent node may be either
mobile or stationary.
foreign subnet prefix
Any IP subnet prefix other than the mobile node's
home subnet prefix.
foreign link Any link other than the mobile node's home link.
home agent A router on a mobile node's home link with which
the mobile node has registered its current care-of
address. While the mobile node is away from home,
the home agent intercepts packets on the home
link destined to the mobile node's home address,
encapsulates them, and tunnels them to the mobile
node's registered care-of address.
care-of address
An IP address associated with a mobile node while
visiting a foreign link; the subnet prefix of this
IP address is a foreign subnet prefix. Among the
multiple care-of addresses that a mobile node
may have at a time (e.g., with different subnet
prefixes), the one registered with the mobile node's
home agent is called its "primary" care-of address.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 7]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
binding The association of the home address of a mobile node
with a care-of address for that mobile node, along
with the remaining lifetime of that association.
Binding Key
a key used for authenticating Binding Update
messages.
Binding Security Association (BSA)
a security association established specifically
for the purpose of producing and verifying
authentication data passed with a Binding Update
destination option.
4. Overview of Mobile IPv6
4.1. Basic Operation
A mobile node is always addressable by its home address, whether it New IPv6 Protocols
As mentioned in Section 4.2, Mobile IPv6 defines a new IPv6 protocol,
the Mobility Header. This protocol is currently attached used to its home link or carry the following
messages:
Home Test Init
The Home Test Init message is away used to initiate the Return
Routability procedure from home. While
a the mobile node is at home, packets addressed to its home address a correspondent
node. This procedure ensures that subsequence Binding Updates
are
routed properly authorized to it using conventional Internet routing mechanisms in the
same way as if the node were never mobile. Since redirect the subnet prefix traffic of a mobile node's particular
home address address. The Home Test Init message is the subnet prefix (or one of the
subnet prefixes) on the mobile node's home link (it described in
detail in Section 5.1.3.
Care-of Test Init
The Care-of Test Init message is the mobile
node's home subnet prefix), packets addressed to it will be routed also used to
its home link.
While initiate the
Return Routability procedure, for a mobile node is attached to some foreign link away from home,
it is also addressable by one or more particular care-of addresses, in addition
to its home address. A care-of address
The Care-of Test Init message is an IP address associated
with described in detail in
Section 5.1.4.
Home Test
The Home Test message carries a cookie which the mobile node while visiting a particular foreign link. The
subnet prefix of
needs before it can properly authorize itself for sending a mobile node's care-of address is the subnet prefix
(or one of the subnet prefixes) on the foreign link being visited by
the mobile node; if the mobile node
Binding Update. This message is connected to this foreign link
while using that care-of address, packets addressed to this care-of
address will be routed an answer to the mobile node in its location away from
home.
The association between a mobile node's home address Home Test
Init message, and care-of
address is known as described in detail in Section 5.1.5.
Care-of Test
The Care-of Test message carries a "binding" for cookie which the mobile node. A mobile node
typically acquires its care-of address through stateless [27] or
stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [17]. Other methods
of acquiring a care-of address are also possible, such as static
pre-assignment by the owner or manager of
needs before it can properly authorize itself for sending a particular foreign link,
but details of such other methods are beyond the scope of this
document.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 8]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
While away from home, a mobile node registers one of its care-of
addresses with a router on its home link, requesting this router 22 March 2002
Binding Update. This message is an answer to function as the "home agent" for the mobile node. This binding
registration Care-of Test
Init message, and is done described in detail in Section 5.1.6.
Binding Update
A Binding Update message is used by the a mobile node sending to the home agent
a packet containing notify
a "Binding Update" destination option; the
home agent then replies to the mobile correspondent node by returning a packet
containing a "Binding Acknowledgement" destination option. The
care-of address in this binding registered with its home agent is
known as or the mobile node's "primary care-of address". The mobile
node's home agent thereafter uses proxy Neighbor Discovery to
intercept any IPv6 packets addressed of its
current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address (or home addresses) on the is marked as
a "home registration". A home link, 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 tunnels each
intercepted packet 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 mobile node's primary care-of address.
To tunnel each intercepted packet, the Binding Update. An acknowledgement of a home agent encapsulates the
packet using IPv6 encapsulation [4],
registration MUST be protected with the outer IPv6 header
addressed 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 the mobile node's primary care-of address.
When request 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
previous care-of address
to be tunneled send to the mobile node's care-of
address. Since the purpose of requesting node a Binding Update is to establish
exactly this kind of tunneling, it is specified to be used (at
least temporarily) for tunnels originating at containing
the mobile node's
previous care-of address, in exactly the same way that it current binding. This message is typically
used
for establishing tunnels from the mobile node's home address by a correspondent node to the refresh a cached binding for a
mobile node's current care-of address. Section 10.10 describes node, when the cached binding is in active use of but the Binding Update
binding's lifetime is close to expiration. No authentication
is required for this purpose. the Binding Request message. The Binding
Request message is described in detail in Section 10.18 discusses 5.1.2.
Binding Missing
The Binding Missing message is used by the reasons why it may be desirable for
a mobile correspondent node
to signal an inappropriate attempt to use more than one care-of address at the same
time. However, a mobile node's primary care-of address Home Address
Option without an existing binding. This message is distinct
among 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 that this document. The
presence of such parameters will be indicated by the home agent maintains only a single care-of
address registered Header Len
field within the message. When the Header Len is greater than the
length required for each mobile node, the message specified here, the remaining octets
Johnson and always tunnels a mobile
node's packets intercepted from its home link to this mobile node's
registered primary care-of address. Perkins Expires 22 September 2002 [Page 9]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
are interpreted as parameters. The home agent thus need not
implement encoding and format of defined
parameters are described in Section 5.2.
Alignment requirements for the Mobility Header are same as for any policy to determine
IPv6 protocol, i.e. they MUST be aligned on an 8-octet boundary.
We also require that the particular care-of address to
which it will tunnel each intercepted packet. The Mobility Header length is a multiple of 8
octets.
4.2. Basic Operation
A mobile node alone
controls the policy is always addressable by which its home address, whether it selects the care-of addresses
is currently attached to
register with its home agent.
It link or is possible that while away from home. While
a mobile node is away from at home, some nodes
on packets addressed to its home link may be reconfigured, such that address are
routed to it using conventional Internet routing mechanisms in the router that was
operating
same way as if the node were never mobile. Since the subnet prefix
of a mobile node's home agent address is replaced by a different
router serving this role. In this case, the subnet prefix (or one of the
subnet prefixes) on the mobile node may not
know node's home link (it is the IP address of its own mobile
node's home agent. Mobile IPv6 provides a
mechanism, known as "dynamic subnet prefix), packets addressed to it will be routed to
its home agent address discovery", that
allows link.
While a mobile node is attached to dynamically discover the IP address of a
home agent on its home some foreign link with which away from home,
it may register is also addressable by one or more care-of addresses, in addition
to its (primary) home address. A care-of address is an IP address associated
with a mobile node while away from home. visiting a particular foreign link. The
subnet prefix of a mobile node sends an ICMP
"Home Agent Address Discovery Request" message to the "Mobile IPv6
Home-Agents" anycast node's care-of address for its own home is the subnet prefix [10] and
Johnson and Perkins Expires 2 January 2002 [Page 9]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
thus reaches
(or one of the (possibly many) routers subnet prefixes) on its home the foreign link
currently operating as a home agent. This home agent then returns an
ICMP "Home Agent Address Discovery Reply" message to being visited by
the mobile node,
including a list of home agents on node; if the home link. This list of home
agents mobile node is maintained by each home agent on the home connected to this foreign link through use
of
while using that care-of address, packets addressed to this care-of
address will be routed to the Home Agent (H) bit mobile node in each home agent's periodic unsolicited
multicast Router Advertisements. its location away from
home.
The Binding Update and Binding Acknowledgement destination options,
together with a "Binding Request" destination option, are also used
to allow IPv6 nodes communicating with association between a mobile node, to dynamically
learn node's home address and cache care-of
address is known as a "binding" for the mobile node's binding. When sending a packet node. A mobile node
typically acquires its care-of address through stateless [35] or
stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according
to any the methods of IPv6 destination, Neighbor Discovery [20]. Other methods
of acquiring a care-of address are also possible, such as static
pre-assignment by the owner or manager of a particular foreign link,
but details of such other methods are beyond the scope of this
document.
While away from home, a mobile node checks registers one of its cached bindings for an
entry care-of
addresses with a router on its home link, requesting this router
to function as the "home agent" for the packet's destination address. If a cached mobile node. This binding for
this destination address
registration is found, done by the mobile node uses an IPv6 Routing
header [6] (instead of IPv6 encapsulation) sending to route the home agent
a packet containing a "Binding Update" destination option; the
home agent then replies to the mobile node by way of the returning a packet
containing a "Binding Acknowledgement" destination option. The
care-of address indicated in this
binding. If, instead, the sending node has no cached binding for
this destination address, the node sends registered with its home agent is
known as the packet normally (with
no Routing header), mobile node's "primary care-of address". The mobile
Johnson and Perkins Expires 22 September 2002 [Page 10]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
node's home agent thereafter uses proxy Neighbor Discovery to
intercept any IPv6 packets addressed to the packet is subsequently intercepted mobile node's home
address (or home addresses) on the home link, and
tunneled by tunnels each
intercepted packet to the mobile node's primary care-of address.
To tunnel each intercepted packet, the home agent as described above. Any
node communicating encapsulates the
packet using IPv6 encapsulation [4], with the outer IPv6 header
addressed to the mobile node's primary care-of address.
When a mobile node is referred moves from one care-of address to in this document
as a "correspondent node" of new care-of
address on a new link, it is desirable for packets arriving at the mobile node, and may itself
previous care-of address to be
either a stationary node or a tunneled to the mobile node.
Since a Binding Update, Binding Acknowledgement, and Binding Request
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
sent in either of two ways:
- the messages can be included within any IPv6 packet carrying any
payload such as TCP [25] or UDP [24].
- node's care-of
address. Since the messages can be sent as purpose of a separate IPv6 packet containing
no payload. In this case, the Next Header field in the last
extension header in the packet Binding Update is set to the value 59, to
indicate "No Next Header" [6].
Mobile IPv6 also defines one additional IPv6 destination option.
When a mobile node sends a packet while away from home, establish
exactly this kind of tunneling, it will
generally set the Source Address in the packet's IPv6 header is specified to one
of its current care-of addresses, and will also include a "Home
Address" destination option in the packet, giving be used (at
least temporarily) for tunnels originating at the mobile node's
home address. Many routers implement security policies such as
"ingress filtering" [7] that do not allow forwarding of packets
that have a Source Address which appears topologically incorrect.
By using the
previous care-of address as the IPv6 header Source Address,
the packet will be able to pass normally through such routers,
yet ingress filtering rules will still be able to locate the true
topological source of the packet address, in exactly the same way as packets that it is used
for establishing tunnels from
non-mobile nodes. By also including the Home Address option in each
Johnson and Perkins Expires 2 January 2002 [Page 10]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
packet, the sending mobile node can communicate its node's home address to the correspondent node receiving this packet, allowing
mobile node's current care-of address. Section 10.11 describes the
use of the Binding Update for this purpose.
Section 10.20 discusses the reasons why it may be desirable for
a mobile node to use more than one care-of address to be transparent above the Mobile IPv6 support
level (e.g., at the transport layer). The inclusion of a Home
Address option in same
time. However, a packet affects only the correspondent mobile node's
receipt of this single packet; no state primary care-of address is created or modified distinct
among these in that the
correspondent node as a result of receiving a Home Address option in home agent maintains only a packet.
4.2. New IPv6 Destination Options
As mentioned in Section 4.1, the following four new IPv6 destination
options are defined single care-of
address registered for Mobile IPv6:
Binding Update
A Binding Update option is used by a each mobile node to notify node, and always tunnels a correspondent node or the mobile
node's home agent of packets intercepted from its
current binding. The Binding Update sent home link to the this mobile node's
registered primary care-of address. The home agent thus need not
implement any policy to register its primary determine the particular care-of address to
which it will tunnel each intercepted packet. The mobile node alone
controls the policy by which it selects the care-of addresses to
register with its home agent.
It is marked
as a "home registration". Any packet possible that includes while 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 mobile node is away from home, some nodes
on its
specific authentication requirements are described in detail in
Section 5.1.
Binding Acknowledgement
A Binding Acknowledgement option home link may be reconfigured, such that the router that was
operating as the mobile node's home agent is used to acknowledge receipt
of replaced by a Binding Update, if an acknowledgement was requested
in different
router serving this role. In this case, the Binding Update. Any packet that includes mobile node may not
know the IP address of its own home agent. Mobile IPv6 provides a Binding
Acknowledgement option MUST be protected by some authentication
data (see section 5.2),
mechanism, known 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 "dynamic home agent address discovery", that
allows a mobile node to
send to dynamically discover the requesting node IP address of a Binding Update containing the
home agent on its home link with which it may register its (primary)
care-of address while away from home. The mobile node's current binding. This option is typically used
by a correspondent node sends an ICMP
"Home Agent Address Discovery Request" message to refresh a cached binding the "Mobile IPv6
Home-Agents" anycast address for its own home subnet prefix [11] and
thus reaches one of the (possibly many) routers on its home link
currently operating as a home agent. This home agent then returns an
ICMP "Home Agent Address Discovery Reply" message to the mobile node, when
including a list of home agents on the cached binding home link. This list of home
agents is in active use but maintained by each home agent on the
binding's lifetime is close to expiration. No authentication
is required for home link through use
of the Binding Request option. The Binding
Request option is described in detail Home Agent (H) bit in Section 5.3. each home agent's periodic unsolicited
multicast Router Advertisements.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 11]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Home Address
A Home Address option is used in 22 March 2002
The Binding Update and Binding Acknowledgement destination options,
together with a packet sent by "Binding Request" destination option, are also used
to allow IPv6 nodes communicating with a mobile
node node, to inform the recipient of that packet of dynamically
learn and cache the mobile node's home address. For packets sent by binding. When sending a packet
to any IPv6 destination, a mobile node while
away from home, the mobile node generally uses one of checks its
care-of addresses as the Source Address in cached bindings for an
entry for the packet's IPv6
header. By including destination address. If a Home Address option in the packet, cached binding for
this destination address is found, the
correspondent node receiving uses an IPv6 Routing
header [6] (instead of IPv6 encapsulation) to route the packet is able to substitute
the mobile node's home address for this care-of address when
processing the packet, thus making the use node by way of the care-of address transparent to indicated in this
binding. If, instead, the correspondent node. If sending node has no cached binding for
this destination address, the node sends the IP
header of a packet carrying a Home Address option is covered
by authentication, then the Home Address option MUST also be
covered by this authentication, but normally (with
no other authentication
is required for the Home Address option. See sections 10.2 Routing header), and 5.4 for additional details about requirements for the
calculation packet is subsequently intercepted and verification of
tunneled by the authentication data. The
Home Address option is mobile node's home agent as described above. Any
node communicating with a mobile node is referred to in detail in Section 5.4.
Mobile IPv6 also defines this document
as a number "correspondent node" of "sub-options" for use within
these the mobile node, and may itself be
either a stationary node or a mobile node.
Since a Binding Update, Binding Acknowledgement, and Binding Request
are each represented in a packet as an IPv6 destination options; if included, option [6],
they may be included in any sub-options MUST
appear after the fixed portion IPv6 packet. Any of the option data specified these options can be
sent in this
document. The presence either of two ways:
- the messages can be included within any IPv6 packet carrying any
payload such sub-options will as TCP [31] or UDP [30].
- the messages can be indicated by sent as a separate IPv6 packet containing
no payload. In this case, the
Option Length Next Header field within in the option. When last
extension header in the Option Length packet is
greater than set to the length required for value 59, to
indicate "No Next Header" [6].
Mobile IPv6 also defines one additional IPv6 destination option.
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
of its current care-of addresses, and will also include a "Home
Address" destination option specified here, in the
remaining octets are interpreted packet, giving the mobile node's
home address. Many routers implement security policies such as sub-options. The encoding and
format
"ingress filtering" [7] that do not allow forwarding of defined sub-options are described in Section 5.5.
4.3. Alignment Requirements for New Destination Options
IPv6 requires packets
that options appearing in have a Hop-by-Hop Options
header or Destination Options Source Address which appears topologically incorrect.
By using the care-of address as the IPv6 header be aligned in a Source Address,
the packet so that
multi-octet values within will be able to pass normally through such routers,
yet ingress filtering rules will still be able to locate the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple true
topological source of n octets the packet in the same way as packets from
non-mobile nodes. By also including the start Home Address option in each
packet, the sending mobile node can communicate its home address to
the correspondent node receiving this packet, allowing the use of
the header,
for n = 1, 2, 4, or 8) [6]. care-of address to be transparent above the Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within support
level (e.g., at the
Sub-Option Data field of each sub-option fall on natural boundaries. transport layer). The alignment requirement inclusion of an a Home
Address option or sub-option is specified in
this document using a packet affects only the standard notation used correspondent node's
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
a packet.
Johnson and Perkins Expires 22 September 2002 [Page 12]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
4.3. New IPv6 Destination Options
As mentioned in Section 4.2, the following new IPv6 destination
option is defined for Mobile IPv6:
Home Address
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's home address. For packets sent by a mobile node while
away from home, the mobile node generally uses one of its
care-of addresses as the Source Address in the packet's IPv6
header. By including a Home Address option in the packet, the
correspondent node receiving the packet is able to substitute
the mobile node's home address for this care-of address when
processing the packet, thus making the use of the care-of
address transparent to the correspondent node. If the IP
header of a packet carrying a Home Address option is covered
by authentication, then the Home Address option MUST also be
covered by this authentication, but no other authentication
is required for the Home Address option. See sections 10.2
and 5.3 for additional details about requirements for the
calculation and verification of the authentication data. The
Home Address option is described in detail in Section 5.3.
Mobile IPv6 also defines a number of "sub-options" for use within
destination options. If included, any sub-options MUST appear after
the fixed portion of the option data specified in this document. The
presence of such sub-options will be indicated by the Option Length
field within the option. When the Option Length is greater than the
length required for the option specified here, the remaining octets
are interpreted as sub-options. The encoding and format of defined
sub-options are described in Section 5.5.
4.4. Alignment Requirements for New Destination Options
IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple of n octets from the start of the header,
for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within the
Sub-Option Data field of each sub-option fall on natural boundaries.
The alignment requirement of an option or sub-option is specified in
this document using the standard notation used elsewhere for IPv6
alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets.
For example:
Johnson and Perkins Expires 22 September 2002 [Page 13]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header,
plus 2 octets.
Johnson and Perkins Expires 2 January 2002 [Page 12]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
4.4. Authentication Requirements for Binding Update and Acknowledgement
Any packet that includes a Binding Update or Binding Acknowledgement
option has to contain some Authentication Data
4.5. Security Design
4.5.1. Security Threats
The MIPv6 protocol needs to guard protect itself against the following main
threats:
1. Threats against
malicious Binding Updates or Acknowledgements. The way that
the Authentication Data is computed has sent to provide sender
authentication, data integrity protection, and replay protection.
This section specifies requirements for which data home agents: a attacker
might claim that a certain mobile node is to be protected
when currently at a
different location than it really is. If the Authentication Data Sub-Option is used to supply home agent accepts
the
necessary authentication data for information sent to it as is, the Binding Update or Binding
Acknowledgement. Every IPv6 mobile node might not get
traffic destined to it, and other nodes might get traffic they
didn't want.
2. Threats against route optimization with correspondent nodes:
A malicious mobile node might lie about its home address. A
malicious mobile node might send a correspondent node binding
updates in which supports transmission or
reception of these destination options MUST support the computation home address is set to the address of
another node, the Authentication Data Sub-Option according to victim. If the rules in correspondent node accepted
this section. The Authentication Data Sub-Option MUST be forged binding update, then communications between the last
Sub-Option contained within any destination option in which
correspondent node and the
Authentication Data Sub-Option occurs.
The Authentication Data covering a Binding Update or MUST victim would be computed
over a bitstring containing the following fields of disrupted, because
packets that the IPv6 header
and destination options, in order:
- The IPv6 address of correspondent node intended to send to the destination of
victim would be sent to the packet, wrong care-of address. This is a
threat to confidentiality as seen by the
recipient
- Care-of Address, well as availability, because an
attacker might redirect packets meant for another node to itself
in order to learn the Source IP Address of the IPv6 header
- The Home Address content of the those packets.
A malicious mobile node, from the Home Address
destination option
- Option Type of the Binding Update destination option
- Option Length of node might lie about its care-of address. A
malicious mobile node might send a correspondent node binding
updates in which the Binding Update destination option
- All flags of care-of address is set to the Binding Update destination option
- Reserved Field address of
a victim node or an address within a victim network. If the Binding Update destination option
- Sequence Number Field of
correspondent node accepted this forged binding update, then the Binding Update
- Lifetime of
malicious mobile could trick the Binding Update destination option
- The entire correspondent into sending 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 victim node or the receiving node, victim network; the address correspondent's
replies to be used for the Destination IP
Address part of messages sent by the computation malicious mobile will initially be located as the last
component of the Routing Header. Otherwise, the address sent
to the victim host or network. This could be used
will be the Destination IP Address in the IPv6 header to cause a
distributed denial of service attack; the outgoing
packet.
When the Authentication Data Sub-Option is used with malicious mobile could
trick a Binding
Acknowledgement, the Authentication Data MUST be computed over large number of servers so that they all send a
bitstring containing large
amount of data to the following data, in order:
Johnson and Perkins Expires 2 January 2002 [Page 13]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
- The IPv6 address same victim node or network. Several
variations of the destination this threat are described elsewhere [1][33].
A malicious node might also send a large number of the packet, invalid
binding updates to a victim correspondent node. If each invalid
binding update took a significant amount of resources (such as seen
CPU) to process before it could be recognized as invalid, then it
Johnson and Perkins Expires 22 September 2002 [Page 14]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
might be possible to cause a denial of service attack by sending
the
recipient
- correspondent so may invalid binding updates that it has no
resources left for other tasks.
An attacker might also replay an old binding update. An attacker
might attempt to disrupt a mobile node's communications by
replaying a binding update that the node had sent earlier. If
the old binding update was accepted, packets destined for the
mobile node would be sent to its old location and not its current
location.
3. Threats where MIPv6 correspondent node functionality is used
to launch reflection attacks against other parties [34] [23].
The Home Address of the sender
- Option Type of the Binding Acknowledgement destination option
- Option Length of the Binding Acknowledgement
- Status of the Binding Acknowledgement
- Sequence Number field of the Binding Acknowledgement
- Lifetime field of can be used to direct response traffic
against a node whose IP address appears in the Binding Acknowledgement destination option
- Refresh field of option, without
giving a possibility for ingress filtering to catch the Binding Acknowledgement destination option
- The entire data from all Binding Acknowledgement Sub-Options
(except forged
"return address".
4. Threats where the Authentication Data suboption), if any others exist
- The Type (i.e., tunnels between the 8-bit value 0x04) mobile node and the Length of the
Authentication Data Sub-Option
- Security Parameters Index (SPI) of home
agent are attacked to make it appear like the Authentication Data
Sub-Option
When a Home Address destination option mobile node is
sending traffic while it is not.
5. Threats where IPv6 Routing Header -- which is employed in
MIPv6 -- is used to deliver the Binding
Acknowledgement circumvent IP-address based rules in
firewalls or to reflect traffic from other nodes. The generality
of the receiving node, Routing Header allows the Home Address kind of the sender
will be located in usage that destination option. Otherwise, opens
vulnerabilities, even if the Home
Address usage that MIPv6 needs is safe.
6. The security mechanisms of the sender will MIPv6 may also be located attacked themselves,
e.g. in the Source IP Address field
of the IPv6 header.
If a Security Association applied to the packet for other reasons
requires use of ESP [12], for example order to encrypt force the transport layer
data carried in the packet, this use of ESP is not sufficient participants to
satisfy the authentication requirements of Mobile IPv6.
Authentication Data assuring execute expensive
cryptographic operations or allocate memory for the integrity purpose of Binding Updates and
Binding Acknowledgement MAY, in some cases, instead be supplied by
other authentication mechanisms outside the scope
keeping state.
Most of this document
(e.g., IPsec [13]). When alternative mechanisms are used, the same
data as indicated above MUST be included as part threats are concerned with denial of service. Some
of the input data
stream threats also open up possibilities for the authentication algorithm; however (according 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 the
requirements home agents.
- Protection of Binding Updates to correspondent nodes.
- Protection against reflection attacks through the alternative authentication algorithm) the order Home Address
Option.
- Protection of tunnels between the data elements in mobile node and 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
Mobile IPv6 also introduces four new ICMP message types, two for use
in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in
general in Section 4.1, the following two new ICMP message types are
used for home agent address discovery:
Home Agent Address Discovery Request
The ICMP Home Agent Address Discovery Request message is used
by a mobile node to initiate the dynamic home agent address agent.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 14] 15]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
discovery mechanism. When attempting a home registration, the
mobile node may use this mechanism 22 March 2002
- Preventing Routing Header vulnerabilities.
- Preventing Denial-of-Service attacks to discover the address of
one or more routers currently operating as MIPv6 security
mechanisms themselves.
Protecting the Binding Updates to home agents on its
home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described
in detail in Section 5.7.
Home Agent Address Discovery Reply
The ICMP Home Agent Address Discovery Reply message is used by
a home agent and to respond correspondent
nodes require very different security solutions due to a mobile node using the dynamic home
agent address discovery mechanism. When a different
situations. Mobile nodes and home agent receives
a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving agents know each other, and can
thus have a list
of the routers on strong security association to reliably authenticate
the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.8.
The next two message types are exchanged messages. In this environment, IPsec Encapsulating
Security Payload (ESP) can be used for network renumbering
and address configuration on to implement the mobile node, as described in necessary
security features. See Section 9.6:
Mobile Prefix Solicitation 4.5.5.
The ICMP Mobile Prefix Solicitation message protection of Binding Updates to correspondents is used by a mobile
node to request prefix information about much harder
problem for the home subnet, in
order to retrieve prefixes traditional strong authentication approach. It is
expected that are served by home agents and
can MIPv6 will be used on a global basis between nodes
belonging under different administrative domains, hence building
an authentication infrastructure to configure one or more home addresses, 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
refresh home addresses before the expiration of their validity.
This message authenticate mobile nodes,
authorization to claim right to use an address is specified in Section 5.9.
Mobile Prefix Advertisement needed.
A different approach is therefore necessary. The ICMP Mobile Prefix Advertisement chosen method
verifies that the mobile node is used ``live'' (that is, it responds to
probes) at its home and care-of addresses by performing a home agent to
distribute information cookie
exchange with the addresses, and by requiring that the eventual
binding update is cryptographically bound to a mobile node about prefixes on the
home link which are available for use 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 while
away from home. node.
This message may be sent as a response method limits the vulnerabilities to a
Mobile Prefix Solicitation, or due those attackers who are
on the path between the Home Agent and the correspondent node. As
adversaries on this path would be able to network renumbering or cause also other prefix changes types of
attacks, this is seen as specified in Section 5.10
4.6. Conceptual Data Structures
This document describes sufficient base security between mobile and
correspondent nodes.
Vulnerabilities relating to the Mobile IPv6 protocol 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 terms
the context of Route Optimization, and therefore this specification
limits the
following three conceptual data structures:
Binding Cache
A cache, maintained by each IPv6 node, use of bindings the HAO to the situation where the correspondent
node already has a binding cache entry for other
nodes. A separate Binding Cache SHOULD the given home address.
Tunnels between the mobile node and the home agent can be maintained
protected by each
IPv6 node for each ensuring proper use of its IPv6 addresses. The Binding Cache source addresses, and optional
cryptographic protection. These procedures are discussed in
Section 4.5.3.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 15] 16]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
MAY 22 March 2002
Vulnerabilities related to the Routing Header can be implemented in any manner consistent 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 external
behavior
effects of such attacks, as will be described in this document, for example by being
combined with Section 4.5.6.
4.5.3. Securing Tunnels to and from the node's Destination Cache as maintained by
Neighbor Discovery [17]. When sending a packet, Home Agents
Tunnels between the Binding
Cache is searched before mobile node and the Neighbor Discovery conceptual
Destination Cache [17] (i.e., any Binding Cache entry for this
destination SHOULD take precedence over any Destination Cache
entry home agent need protection
so that it isn't possible for anyone to send traffic through the same destination). Each
home agent, pose as the mobile node, and escape detection through
traditional tracing mechanisms.
If Binding Cache entry
conceptually contains Updates sent to the home agents are secure, and the following fields:
- The home
agent verifies the outer IP address corresponds to the current
location of the mobile node for which node, this is prevents attacks against the
Binding Cache entry. tunnel
from other IP addresses. This field prevents attacks where the attacker
is used controlled by ingress filtering, as well as attacks where the key for
searching the Binding Cache for
attacker does not know the destination current care-of address of
a packet being sent. If the destination address of mobile
node. Attackers who know the
packet matches care-of address are not controlled by
ingress filtering could still send traffic through the home address in 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 Cache entry,
this entry SHOULD be used in routing that packet.
- The care-of address for Updates to Home Agents
Signaling between the mobile node indicated by and the home address field in agent requires message
integrity, correct ordering and replay protection.
In order to have this Binding Cache entry. If protection, the destination address of a packet being routed by a mobile node matches and the home address in this entry, the packet
SHOULD agent
must have a security association. IPsec Encapsulating Security
Payload (ESP) can be routed used to this care-of address, as described in
Section 8.9, for packets originated by this node, or in
Section 9.4, if this node integrity protection when a non-null
authentication algorithm is the mobile node's home agent
and the packet was intercepted by it on the home link.
- A lifetime value, indicating the remaining lifetime
for this Binding Cache entry. The lifetime value applied.
However, IPsec can provide replay protection only when dynamic
security association establishment is
initialized from the Lifetime field used. This may not always be
possible, and manual keying would be preferred in the Binding Update some cases. IPsec
also does not guarantee correct ordering of packets, only that created or last modified this Binding Cache entry.
Once the lifetime on this entry expires, the entry MUST be
deleted from the Binding Cache.
- A flag indicating whether or they
have not this Binding Cache entry
is a "home registration" entry.
- A flag indicating whether or been replayed. Because of this, Mobile IPv6 does not this Binding Cache entry
represents a mobile node that should be advertised as a
router in proxy Neighbor Advertisements sent by this node rely
on IPsec replay protection and provides its behalf. This flag is only valid if own mechanism inside the
Binding
Cache entry indicates that this is a "home registration"
entry.
- The length of the routing prefix for the home address.
This Update and Acknowledgement messages. A sequence number field
is only valid if the "home registration" flag is
set on this Binding Cache entry.
- The maximum value of used to ensure correct ordering and to prevent replay protection.
Both the Sequence Number field received
in previous Binding Updates for this mobile node home
address. The Sequence Number field is 8 bits long, and all comparisons between Sequence Number values the home agent MUST use non-volatile memory
Johnson and Perkins Expires 2 January 22 September 2002 [Page 16] 17]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
MUST be performed modulo 2**8. For example, using an
implementation in 22 March 2002
to store the C programming language, sequence number so that a Sequence
Number value A is greater than another Sequence Number
value B if ((char)((a) - (b)) > 0), if reboot does not prevent the "int" data type
acceptance of new Binding Updates.
A sliding window scheme is a 8-bit signed integer.
- Recent usage information used for this Binding Cache entry, as
needed to implement the cache replacement policy in use in sequence numbers. Therefore
the Binding Cache protection against replays and reordering attacks works when
the attacker remembers up to assist in determining whether a maximum of 2^31 Binding Request should be sent when Updates.
The mobile node and the lifetime home agent MAY agree on this
entry nears expiration.
- The Binding Security Association (BSA) to be be used when
authenticating Binding Updates that are received a new key for the
security association before this
Binding Cache entry.
- The Binding Security Association (BSA) to be be used when
calculating authentication data for inclusion in Binding
Acknowledgements in response to many Binding Updates that are
received for have been sent
if this Binding Cache entry.
An entry is an issue.
Note that while the required non-volatile memory is an additional
burden in a node's Binding Cache particular for which the node is
serving as a home agent is marked as a "home registration"
entry and SHOULD NOT be deleted by mobile node, the home agent until use of sequence numbers
reduces the
expiration number of its binding lifetime. Other Binding Cache
entries MAY be replaced at any 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 by any reasonable local
cache replacement policy but SHOULD NOT be unnecessarily
deleted. The they send a Binding Cache for any one of Update,
if they always write a node's IPv6
addresses may contain 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 most one entry 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 each mobile node
home address. The contents of a node's Binding Cache MUST NOT frequent updates to the
non-volatile memory, which improves performance and may be changed necessary
in response some cases to a Home Address option in a received
packet. The contents of all of a node's Binding Cache entries,
for each lengthen the lifetime of its IPv6 addresses, 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 cleared when created. We need to avoid the node
reboots.
Binding Update List
A list, maintained by each possibility that a
mobile node, recording information
for each node could use its security association to send a Binding
Update sent by this on behalf of another mobile node, for which the
Lifetime sent in that Binding Update has not yet expired. The
Binding Update List includes all bindings sent by node using the mobile
node: those to correspondent nodes, those same home agent.
In order to do this, the mobile node's SPD entries MUST unequivocally identify a
single SA for any given home agent, address and those to a home agent on agent. In order for
the link on which home address of the mobile node's previous care-of address node to be visible when the policy
check is located. However,
for multiple made, the mobile node MUST use the Home Address Option in
Binding Updates sent to the same destination
address, home agent. The home address in the Binding Update List contains only Home
Address Option and the most recent Binding Update (i.e., with message MUST be equal and MUST
be checked by the greatest Sequence Number value)
sent home agent.
4.5.5. Securing Binding Updates to that destination. The Correspondent Nodes
Binding Update List MAY be
implemented in any manner consistent with Updates to correspondent nodes are protected using the external behavior
described in this document. Each Binding Update List entry
conceptually contains Return
Routability (RR) method. This method uses the following fields: 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.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 17] 18]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
- Requiring that the cookies be protected by ESP when forwarded by
the Home Agent to the mobile node.
- The IP address use of the node symmetric exchanges were responses are sent to which a Binding Update the
same address as the request was
sent. That node might still have a Binding Cache entry
created or updated from this Binding Update, if the Binding
Update was successfully received by that node (e.g., not
lost by the network) and if that node has not deleted the
entry before its expiration (e.g., sent from, to reclaim space avoid the use of
this protocol in its
Binding Cache for other entries). reflection attacks.
- The home address for which Stateless operation at correspondent nodes until they receive the
a binding update that Binding Update was sent.
This will can be one of authorized.
The RR protocol can be broken by an attacker on the following:
* route between the mobile node's
home addresses for typical Binding
Updates (Sections 10.7 agent and 10.9), or
* the correspondent node, but not by attackers on the
network the mobile node's previous care-of address for Binding
Updates sent to establish forwarding node is currently at and not from elsewhere on the mobile
node's previous care-of address by
Internet.
Each correspondent node has a home agent from
this previous care-of address (Section 10.10).
- The care-of address sent in that Binding Update. secret key, Kcn. This
value key does not
need to be shared with any other entity, so no key distribution
mechanism is necessary needed for the mobile it. Each correspondent node to determine if 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
has sent
is in communication with, so that it does not need to generate and
store a Binding Update giving its new care-of address to
this destination after changing its care-of address.
- The initial Nj when a new mobile contacts it. Each value of Nj is
identified by the Lifetime field sent in that
Binding Update.
- The remaining lifetime of that binding. subscript j. This lifetime subscript is
initialized from the Lifetime value sent communicated in the Binding
Update and
protocol, so that if Nj is decremented until it reaches zero, at which
time this entry MUST replaced by N(j+1) part way through a run
of a protocol, the correspondent can distinguish messages that should
be deleted checked against the old nonce from messages that should be checked
against the Binding Update
List.
- The maximum new nonce. Correspondent nodes keep both the current
value of the Sequence Number field sent in
previous Binding Updates to this destination. The Sequence
Number field is 8 bits long, Nj and all comparisons between
Sequence Number a small set of previous values MUST N(j-1), N(j-2), ...
Older values can be performed modulo 2**8. For
example, discarded, and messages using an implementation in the C programming
language, them will can be
rejected as replays.
Kcn can be either a Sequence Number value A is greater than another
Sequence Number fixed value B if ((char)((a) - (b)) > 0), if or regularly updated. An update
of Kcn can be done at the
"char" data type is a 8-bit signed integer.
- The same time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting
restriction for sending Binding Updates.
- The state an update of any retransmissions needed for this Binding
Update, if Nj, so that j
identifies both the Acknowledge (A) bit was set in this Binding
Update. This state includes nonce and the key. A correspondent node can
generate a fresh Kcn each time remaining until that it boots to avoid the
next retransmission attempt need for the Binding Update,
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 the 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:
Johnson and Perkins Expires 2 January 22 September 2002 [Page 18] 19]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
current state of the exponential back-off mechanism for
retransmissions.
- A flag that, when set, indicates that future Binding
Updates should not be sent to this destination. The 22 March 2002
1. HoTI (Home Test Init) Message:
When a mobile node sets this flag in the Binding Update List
entry when it receives an ICMP Parameter Problem, Code 2,
error message in response nodes wants to perform route optimization it sends
a Binding Update sent HoTI message to that
destination, as described the correspondent node in Section 10.15. order to initiate the
return routability verification for the Home Agents List
A list, maintained by each home agent and each Address.
MN(HoA) -> CN: HoA
This message tells the mobile node,
recording information about each node's home agent from which this
node has received address to the
correspondent node. The address is used later to create a Router Advertisement in which
cookie. This message is reverse tunneled through the Home
Agent (H) bit is set, for which Agent.
2. CoTI (Care-of Test Init) Message:
When a mobile nodes wants to perform route optimization it sends
a CoTI message to the remaining lifetime for
this list entry (defined below) has not yet expired. The
home agents list is thus similar correspondent node in order to initiate the Default Router
List conceptual data structure maintained by each host
return routability verification for
Neighbor Discovery [17], although the Home Agents List MAY be
implemented care-of Address.
MN(CoA) -> CN: CoA
The second message is sent in any manner consistent parallel with the external behavior
described in this document.
Each home agent maintains a separate Home Agents List for
each link on first one. It
tells the correspondent node the mobile node's care-of address,
which it is serving as a home agent; this list is later used by a home agent in the dynamic home agent address
discovery mechanism. Each mobile node, while away from home,
also maintains to create a Home Agents List, cookie. This message is sent
directly to enable it the correspondent node.
3. HoT (Home Test) Message:
This message is sent in response to notify a
home agent on its previous link when HoTI message.
CN -> MN(HoA): K0, j
When the correspondent node receives the HoTI message, it moves to a new link;
generates a cookie K0 as follows:
K0 = MAC_Kcn(HoA | Nj | 0)
The cookie and the value j are sent to the mobile node MAY maintain a separate via the
Home Agents List for each
link to which Agent; it is (or has recently) connected, or it MAY
maintain a single list for all links. Each Home Agents List
entry conceptually contains the following fields:
- The link-local IP address an assumption of a router on the link, protocol that
this the home
agent - mobile node currently believes route is operating secure. K0 also acts as a home agent
for challenge
to test that link. A new entry is created or an existing
entry the mobile can receive messages sent to its home
address.
The index j is updated carried along in the Home Agents List in response protocol to
receipt of a valid Router Advertisement in which allow the Home
Agent (H) bit is set. CN
to later efficiently find the nonce value Nj that it used in
creating this cookie.
The link-local address 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 the home
agent message m. HMAC SHA1 function [15][21]
is learned through used to compute the Source Address of the Router
Advertisements received from it [17].
- One or more global IP addresses for this home agent,
learned through Prefix Information options with
the Router Address (R) bit set, received in Router
Advertisements from this link-local address. Global
addresses for the router in a Home Agents List entry MUST
be deleted once the prefix associated with that address message authentication code, and SHA1
function [21] is
no longer valid [17]. used to compute the hash. The final ``0''
Johnson and Perkins Expires 2 January 22 September 2002 [Page 19] 20]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Are there interactions with 22 March 2002
inside the new Router
Advertisement stuff?
- The remaining lifetime of this Home Agents List entry. If MAC function is a Home Agent Information Option 32-bit integer used to distinguish
home and care-of cookies from each other.
4. CoT (Care-of Test) Message:
This message is present sent in response to a Router
Advertisement received from CoTI message.
CN -> MN(CoA): K1, i
The correspondent also sends a home agent, challenge to the lifetime of mobile's care-of
address. When the Home Agents List entry representing that home agent
is initialized from correspondent node receives the Home Agent Lifetime field in CoTI message,
it generates a cookie K1 as follows:
K1 = MAC_Kcn(CoA | Ni | 1)
The cookie and the
option; otherwise, value i are sent directly the lifetime mobile node.
The final 1 inside the MAC function is initialized a 32-bit integer, again
used for distinguishing home and care-of cookies from each other.
Again, an index is sent along the
Router Lifetime field cookie in order to identify
the received Router Advertisement.
The Home Agents List entry lifetime is decremented until it
reaches zero, at which time this entry MUST used nonce Ni. Note that i and j are likely to be deleted from the Home Agents List.
- The preference for this home agent; higher same
in HoT and CoT messages, except when nonce values
indicate a more preferable home agent. The preference
value is taken from happen to have
changed between the Home Agent Preference field (a
signed, twos-complement integer) in reception of HoT and the CoT messages.
5. BU (Binding Update) Message:
When the MN has received Router
Advertisement, if both the Router Advertisement contains a Home
Agent Information Option, HoT and CoT is otherwise set has the cookies
necessary to send the
default value of 0. A home agent uses this preference in
ordering Binding Update.
MN(CoA) -> CN: BU, HoA, CoA,
MAC_Kbu(CoA | HoA | BU | 0),
j, i
The mobile node hashes together the Home Agents List returned in an ICMP Home
Agent Address Discovery message in response challenges and to form a mobile
node's initiation of dynamic home agent address discovery.
A mobile node
session key (Kbu), and then uses this preference in determining which
of the home agents on its previous link to notify when it
moves session key to authenticate
a new link.
Can we delete binding update:
Kbu = H(K0 | K1)
The message contains j and i, so that the preference stuff? Is anyone using
it?
4.7. Binding Management
When a mobile node configures a new care-of address correspondent knows
which value of Nj and decides Ni to use this new address as its primary care-of address, to recompute the mobile session key.
"BU" is the content of the BU message. Once the correspondent
node registers this new binding with its home agent by sending has verified the home agent MAC, it can create a Binding Update. The mobile node indicates
that an acknowledgement is needed binding cache entry
for this Binding Update and
continues to periodically retransmit it until acknowledged. The
home agent acknowledges the mobile.
6. BA (Binding Acknowledgement) Message:
The Binding Update is optionally acknowledged by returning a Binding
Acknowledgement to the mobile
correspondent node.
When a mobile node receives a packet tunneled to it from its home
agent, the mobile
CN -> MN(CoA): BA,
Johnson and Perkins Expires 22 September 2002 [Page 21]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
MAC_Kbu(CoA | HoA | BA | 0),
The correspondent node uses that as an indication that the original
sending same key (Kbu) to authenticate a
binding acknowledgement. "BA" is the content of the BA message.
7. BR (Binding Request) Message:
The correspondent node has no can optionally request a binding to be
refreshed using the Binding Cache entry for Request message. This message can be
authenticated using the mobile
node, 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 correspondent node MAC would otherwise have sent
not verify after that. Care must be taken when removing bindings
at the
packet directly correspondent node, however. If a binding is removed either
due to garbage collection, request, or expiration and the mobile 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 using a Routing header. 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
mobile node 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 a Binding Security Association (BSA) been designed with that
correspondent node, protection against resource
exhaustion Denial-of-Service attacks. In these attacks the mobile node thus returns victim
has only a Binding Update
to 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 node, allowing it nodes do not have to cache 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 node's 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.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 20] 22]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
binding 22 March 2002
Nevertheless, as [1] describes, there are situations it is impossible
for routing future packets to it. Although the mobile node
may request an acknowledgement for this Binding Update, it need not,
since subsequent packets from the and correspondent node will continue nodes to be intercepted and tunneled by the mobile node's home agent,
effectively causing any needed Binding Update retransmission.
If the mobile node receives such determine if they actually
need a tunneled packet but does not binding or whether they just have
a BSA with the correspondent node, the mobile node SHOULD initiate
the process of establishing the necessary security association been fooled into believing
so by
following the procedures outlined 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 correspondent mobile node can communicate with a Binding Cache entry for a mobile correspondent
node
may refresh this binding, for example even if the binding's lifetime
is near expiration, by sending a Binding Request correspondent refuses to accept any of its binding
updates. However, performance will suffer because packets from the
correspondent to the mobile
node. Normally, a correspondent node will only refresh be routed via the mobile's home
agent rather than a Binding
Cache entry in this way if more direct route. A correspondent can protect
itself against some of the resource exhaustion attacks by stopping
processing binding updates when it is actively communicating flooded with a large number of
binding updates that fail the
mobile node and has indications, such as an open TCP connection to
the mobile node, cryptographic integrity checks. If a
correspondent finds that it will continue 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 communication decisions about responding
to requests will usually originate in layers above IP. For example,
TCP knows if the
future. When a mobile node receives has a Binding Request, queue of data that it replies by
returning is trying to send
to a Binding Update peer. It is possible to produce a conforming implementation of
the node sending the Binding Request.
A mobile node may protocols in this memo without making use of information from
higher protocol layers, but implementations MAY be able to manage
resources more than one care-of address at effectively by making use of such information.
4.5.7. Design Rationale
The motivation for designing the same time,
although only one care-of address may be registered RR protocol was to have sufficient
support for it at its
home agent as its primary care-of address. The mobile node's 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 will tunnel all intercepted packets for the mobile to correspondent node path, as such attackers would in any case
be able to its
(single) registered primary care-of address, but mount an active attack against the mobile node
will accept packets that when it receives
is at any of its current care-of
addresses. Use home location. The possibility of more than one care-of address by a mobile node
may be useful, for example, such attacks is not an
impediment to improve smooth handover when the
mobile node moves from one wireless link to another. If each deployment of mobile IP, because these wireless links is connected to the Internet through a separate
base station, such that the wireless transmission range from the
two base stations overlap, the attacks are
possible irrespective of whether mobile node may be able to remain
connected to both links while IP is in the area use or not.
This protocol also protects against denial of overlap. In this case, service attacks in
which the mobile node could acquire attacker pretends to be a new care-of mobile, but uses the victim's
address on as the new link
before moving out care of transmission range address, and disconnecting from so causes the
old link. The mobile node may thus still accept packets at its
old care-of address while it works to update its home agent and correspondent nodes, notifying them of its new care-of address on
to send the
new link.
Since correspondent nodes cache bindings, victim traffic that it is expected does not want. For example,
suppose that the correspondent nodes usually is a news site that will route packets directly send a
high-bandwidth stream of video to the mobile
node's care-of address, so anyone who asks for it. Note that
the home agent is rarely involved
with packet transmission to the mobile node. This is essential for
scalability and reliability, and for minimizing overall network load.
By caching the care-of address use of a mobile node, optimal routing flow-control protocols such as TCP does not necessarily
defend against this type of
packets can be achieved from the correspondent node to the mobile
node. Routing packets directly to the mobile node's care-of address
also eliminates congestion at the mobile node's home agent and home
link. In addition, attack, because the impact of any possible failure of attacker can fake the home
Johnson and Perkins Expires 2 January 22 September 2002 [Page 21] 23]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
agent, 22 March 2002
acknowledgements. Even keeping TCP initial sequence numbers secret
doesn't help, because the home link, or intervening networks leading attacker can receive the first few segments
(including the ISN) at its own address, and then redirect the stream
to or from the
home link is reduced, since victim's address. This protocol defends against these nodes and links are not involved in attacks
by only completing if packets sent by the delivery correspondent to the care
of most packets address are received and processed by an entity that is willing to
participate in the protocol. Normally, this will be the mobile node.
5.
For further information about the design of RR and other protocols,
see [1] [33] [22] [23].
4.6. New IPv6 Destination Options ICMP Messages
Mobile IPv6 also introduces four new ICMP message types, two for use
in the dynamic home agent address discovery mechanism, and Message Types
5.1. Binding Update Option two for
renumbering and mobile configuration mechanisms. As discussed in
general in Section 4.2, the following two new ICMP message types are
used for home agent address discovery:
Home Agent Address Discovery Request
The Binding Update destination option ICMP Home Agent Address Discovery Request message is used
by a mobile node to notify other nodes of a new care-of initiate the dynamic home agent address for itself. As
discovery mechanism. When attempting a
destination option, it MAY be included in any existing packet being
sent to home registration, the
mobile node may use this same destination mechanism to discover the address of
one or MAY be sent more routers currently operating as home agents on its
home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described
in a packet detail in Section 5.6.
Home Agent Address Discovery Reply
The ICMP Home Agent Address Discovery Reply message is used by itself;
a packet containing home agent to respond to a Binding Update mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is sent
described in detail in Section 5.7.
The next two message types are used for network renumbering
and address configuration on the same way mobile node, as any
packet sent described in
Section 9.7:
Mobile Prefix Solicitation
The ICMP Mobile Prefix Solicitation message is used by a mobile
node (Section 10.1).
The Binding Update option is encoded to request prefix information about the home subnet, in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type
198 = 0xC6
Option Length
8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field
MUST be set
order to 8 plus the total length of all sub-options
present, including their Sub-Option Type and Sub-Option Len
fields.
Acknowledge (A)
The Acknowledge (A) bit is set retrieve prefixes that are served by the sending mobile node to
request a Binding Acknowledgement (Section 5.2) be returned
upon receipt of the Binding Update. home agents and
Johnson and Perkins Expires 2 January 22 September 2002 [Page 22] 24]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Home Registration (H) 22 March 2002
can be used to configure one or more home addresses, or to
refresh home addresses before the expiration of their validity.
This message is specified in Section 5.8.
Mobile Prefix Advertisement
The Home Registration (H) bit ICMP Mobile Prefix Advertisement is set used by the sending a home agent to
distribute information to a mobile node
to request about prefixes on the receiving node to act as this node's
home agent.
The destination of link which are available for use by the packet carrying this option MUST mobile node while
away from home. This message may be that
of sent as a router sharing the same subnet response to a
Mobile Prefix Solicitation, or due to network renumbering or
other prefix changes as specified in Section 9.9.3
4.7. Conceptual Data Structures
This document describes the home address
of the mobile node Mobile IPv6 protocol in terms of the binding (given
following three conceptual data structures:
Binding Cache
A cache, maintained by the Home Address
field each IPv6 node, of bindings for other
nodes. A separate Binding Cache SHOULD be maintained by each
IPv6 node for each of its IPv6 addresses. The Binding Cache
MAY be implemented in any manner consistent with the Home Address option external
behavior described in this document, for example by being
combined with the packet).
Single Address Only (S)
If node's Destination Cache as maintained by
Neighbor Discovery [20]. When sending a packet, the `S' bit Binding
Cache is set, the mobile node requests that searched before the home
agent make no changes to Neighbor Discovery conceptual
Destination Cache [20] (i.e., any other Binding Cache entry except for this
destination SHOULD take precedence over any Destination Cache
entry for the particular one containing same destination). Each Binding Cache entry
conceptually contains the following fields:
- The home address specified in of the Home Address option. This disables home agent processing mobile node for other related addresses, as is described in section 9.1.
Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit which this is set by the sending
mobile node to request
Binding Cache entry. This field is used as the receiving node (the mobile node's
home agent) to perform Duplicate Address Detection [27] on key for
searching the mobile node's home link Binding Cache for the home destination address in this
binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. of
a packet being sent. If the Duplicate Address Detection performed by destination address of the home agent fails,
packet matches the Status field home address in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection
failed).
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST Cache entry,
this entry SHOULD be ignored by the receiver.
Sequence #
An 8-bit number used by in routing that packet.
- The care-of address for the receiving mobile node to sequence Binding
Updates and indicated by
the sending node to match a returned Binding
Acknowledgement with home address field in this Binding Update. Each Binding Update
sent Cache entry. If
the destination address of a packet being routed by a mobile
node MUST use a Sequence Number greater than matches the Sequence Number value sent home address in this entry, the previous Binding Update
(if any) packet
SHOULD be routed to the same destination address (modulo 2**8, this care-of address, as
defined described in
Section 4.6). There 8.9, for packets originated by this node, or in
Section 9.4, if this node is no requirement, however,
that the Sequence Number value strictly increase mobile node's home agent
and the packet was intercepted by 1 with each
new Binding Update sent or received.
Lifetime
32-bit unsigned integer. The number of seconds remaining
before it on the binding MUST be considered expired. A value of all home link.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 23] 25]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
one bits (0xffffffff) indicates infinity. 22 March 2002
- A value of zero
indicates that lifetime value, indicating the Binding Cache entry remaining lifetime
for the mobile node MUST
be deleted.
Sub-Options
Additional information, associated with this Binding Update
option. This use of sub-options also allows for future
extensions to Cache entry. The lifetime value is
initialized from the format of Lifetime field in the Binding Update option to
that created or last modified this Binding Cache entry.
Once the lifetime on this entry expires, the entry MUST be
defined. The encoding and format of defined sub-options are
described in Section 5.5. The following sub-options are valid
in a
deleted from the Binding Update option:
- Unique Identifier Sub-Option
- Alternate Care-of Address Sub-Option Cache.
- Authentication Data Sub-Option (see section 4.4 for
authentication requirements).
The alignment requirement [6] for the A flag indicating whether or not this Binding Update option Cache entry
is 4n+2.
Any packet that includes a "home registration" entry.
- A flag indicating whether or not this Binding Update option MUST also include Cache entry
represents a Home Address option. The home address of the mobile node in the
binding given in the Binding Update option is that which was received should be advertised as the value of the Home Address field in the Home Address option a
router in proxy Neighbor Advertisements sent by this node
on its behalf. This flag is only valid if the packet.
Any packet Binding
Cache entry indicates that includes this is a Binding Update option MUST contain
authentication data to guard against malicious Binding Updates. "home registration"
entry.
- The
computation for this authentication data MUST follow length of the rules in
Section 4.4.
The care-of address routing prefix for the binding given in the Binding Update
option home address.
This field is normally that which was received as only valid if the "home registration" flag is
set on this Binding Cache entry.
- The maximum value in of the Source
Address Sequence Number field received
in the IPv6 header of the packet carrying the previous Binding
Update option. However, a care-of address different from the Source
Address MAY Updates for this mobile node home
address. The Sequence Number field is 8 bits long,
and all comparisons between Sequence Number values
MUST be specified by including performed modulo 2**8. For example, using an Alternate Care-of Address
sub-option
implementation in the Binding Update option. In any case, C programming language, a Sequence
Number value A is greater than another Sequence Number
value B if ((char)((a) - (b)) > 0), if the care-of
address MUST NOT be any IPv6 address which "int" data type
is prohibited a 8-bit signed integer.
- Recent usage information for this Binding Cache entry, as
needed to implement the cache replacement policy in use
within a Routing Header; thus multicast addresses, in
the unspecified
address, loop-back address, Binding Cache and link-local addresses are excluded. to assist in determining whether a
Binding Updates indicating any such excluded care-of address MUST Request should be
silently discarded.
If sent when the care-of address lifetime on this
entry nears expiration.
- The Binding Security Association (BSA) to be be used when
authenticating Binding Updates that are received for the binding (specified either in an
Alternate Care-of Address sub-option in the this
Binding Update option, if
present, or Cache entry.
- The Binding Security Association (BSA) to be be used when
calculating authentication data for inclusion in the Source Address field Binding
Acknowledgements in the packet's IPv6 header)
is equal response to the home address of the mobile node, the Binding Update
option indicates Updates that any existing binding are
received for this Binding Cache entry.
An entry in a node's Binding Cache for which the mobile node MUST is
serving as a home agent is marked as a "home registration"
entry and SHOULD NOT be deleted. Likewise, if deleted by the Lifetime field in home agent until the
expiration of its binding lifetime. Other Binding Update Cache
entries MAY be replaced at any time by any reasonable local
Johnson and Perkins Expires 2 January 22 September 2002 [Page 24] 26]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
option is equal to 0, the 22 March 2002
cache replacement policy but SHOULD NOT be unnecessarily
deleted. The Binding Update option indicates that Cache for any
existing binding one of a node's IPv6
addresses may contain at most one entry for the each mobile node MUST be deleted. In each
home address. The contents of
these cases, a node's Binding Cache entry for the mobile node MUST NOT
be
created changed in response to receiving the Binding Update.
When the care-of address is NOT equal to the home address,
what if we just delete that particular care-of address?
The last Sequence Number value sent to a destination Home Address option in a received
packet. The contents of all of a node's Binding
Update is stored by Cache entries,
for each of its IPv6 addresses, must be cleared when the mobile node in its
reboots.
Binding Update List entry
for that destination; the last Sequence Number value received from
a
A list, maintained by each mobile node in a node, recording information
for each Binding Update is stored sent by a correspondent node
in its Binding Cache entry this mobile node, for which the
Lifetime sent in that Binding Update has not yet expired. The
Binding Update List includes all bindings sent by the mobile node. Thus,
node: those to correspondent nodes, those to the mobile node's
home agent, and those to a home agent on the correspondent node's knowledge of link on which the last sequence
number expire at
mobile node's previous care-of address is located. However,
for multiple Binding Updates sent to the same time. If destination
address, the sending mobile node has no Binding Update List entry, contains only the most recent
Binding Update (i.e., with the greatest Sequence Number may start at value)
sent to that destination. The Binding Update List MAY be
implemented in any
value; if manner consistent with the receiving correspondent node has no external behavior
described in this document. Each Binding Cache Update List entry
for
conceptually contains the sending mobile node, it MUST accept any Sequence Number value
in following fields:
- The IP address of the node to which a received Binding Update was
sent. That node might still have a Binding Cache entry
created or updated from this mobile node. The mobile
node MUST NOT use Binding Update, if the same Sequence Number in two different Binding
Updates to
Update was successfully received by that node (e.g., not
lost by the same correspondent node, even network) and if that node has not deleted the
entry before its expiration (e.g., to reclaim space in its
Binding Updates
provide care-of addresses Cache for two different home addresses of the
mobile node. other entries).
- The three highest-order bits home address for which that Binding Update was sent.
This will be one of the Option Type are encoded to
indicate specific processing of following:
* the option [6]. For mobile node's home addresses for typical Binding
Updates (Sections 10.7 and 10.9), or
* the mobile node's previous care-of address for Binding
Update option, these three bits are set
Updates sent to 110, indicating that any
IPv6 node processing establish forwarding from the mobile
node's previous care-of address by a home agent from
this option previous care-of address (Section 10.11).
- The care-of address sent in that does not recognize the Option
Type must discard Binding Update. This
value is necessary for the packet and, only mobile node to determine if the packet's Destination
Address was not it
has sent 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 Binding Update giving its new care-of address to the packet's final
destination.
this destination after changing its care-of address.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 25] 27]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
5.2. Binding Acknowledgement Option 22 March 2002
- The Binding Acknowledgement destination option is used to acknowledge
receipt of a Binding Update option (Section 5.1). When a node
receives a packet containing a Binding Update option, with this
node being the destination initial value of the packet (only the destination node
processes the option since it is a destination option), this node
MUST return a Lifetime field sent in that
Binding Acknowledgement to the source Update.
- The remaining lifetime of the packet,
if the Acknowledge (A) bit that binding. This lifetime is set
initialized from the Lifetime value sent in the Binding Update. As a
destination option,
Update and is decremented until it reaches zero, at which
time this node MAY include entry MUST be deleted from the Binding Acknowledgement
in any existing packet being sent to Update
List.
- The maximum value of the mobile node or MAY send it
in a packet by itself. A packet containing a Binding Acknowledgement
is Sequence Number field sent according to the rules in section 8.5.
The
previous Binding Acknowledgement option Updates to this destination. The Sequence
Number field is encoded in 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
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Reserved | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type
7
Option Length
8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type bits long, and Option Length fields. This field
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
8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined:
0 Binding Update accepted
Johnson and Perkins Expires 2 January 2002 [Page 26]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Values of the Status field greater than or equal to 128
indicate that the Binding Update was rejected by the receiving
node. The following such Status values are currently defined:
128 Reason unspecified
130 Administratively prohibited
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
139 No security association
141 comparisons between
Sequence number too small
Up-to-date Number values of the Status field are to MUST be specified performed modulo 2**8. For
example, using an implementation in the most recent "Assigned Numbers" [26].
Sequence #
The C programming
language, a Sequence Number in the Binding Acknowledgement value A is copied
from the greater than another
Sequence Number field in value B if ((char)((a) - (b)) > 0), if the
"char" data type is a 8-bit signed integer.
- The time at which a Binding Update being
acknowledged, for use by the mobile node in matching was last sent to this
Acknowledgement with an outstanding
destination, as needed to implement the rate limiting
restriction for sending Binding Update.
Lifetime Updates.
- The granted lifetime, in seconds, state of any retransmissions needed for which this node will
attempt to retain Binding
Update, if the entry for this mobile node Acknowledge (A) bit was set in its this Binding
Cache. If
Update. This state includes the node sending time remaining until the Binding Acknowledgement is
serving as
next retransmission attempt for the mobile node's home agent, Binding Update, and the Lifetime period
also indicates
current state of the period exponential back-off mechanism for which
retransmissions.
- A flag that, when set, indicates that future Binding
Updates should not be sent to this destination. The
mobile node will continue sets this service; if flag in the Binding Update List
entry when it receives an ICMP Parameter Problem, Code 2,
error message in response to a Binding Update sent to that
destination, as described in Section 10.17.
Home Agents List
A list, maintained by each home agent and each mobile node requires node,
recording information about each home agent service from which this
node beyond this period, the mobile node MUST send has received a
new Binding Update to it before the expiration of this period
(even if it is not changing its primary care-of address), Router Advertisement in
order to extend which the lifetime. The value of this field Home
Agent (H) bit is
undefined if the Status field indicates that the Binding Update
was rejected.
Refresh
The recommended interval, in seconds, at set, for which the mobile
node SHOULD send a new Binding Update to this node in order
to "refresh" the mobile node's binding in remaining lifetime for
this node's Binding
Cache. This refreshing of the binding is useful in case the
node fails and loses its cache state. list entry (defined below) has not yet expired. The Refresh period
home agents list is
determined by thus similar to the node sending Default Router
List conceptual data structure maintained by each host for
Neighbor Discovery [20], although the Binding Acknowledgement
(the node caching Home Agents List MAY be
implemented in any manner consistent with the binding). If external behavior
described in this node document.
Each home agent maintains a separate Home Agents List for
each link on which it is serving as
the mobile node's a home agent, the Refresh value may be set,
for example, based on whether the node stores its Binding
Cache in volatile storage or in nonvolatile storage. If the agent; this list
Johnson and Perkins Expires 2 January 22 September 2002 [Page 27] 28]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
node sending the Binding Acknowledgement 22 March 2002
is not serving as the
mobile node's used by a home agent, the Refresh period SHOULD be set
equal to the Lifetime period agent in the Binding Acknowledgement;
even if this node loses this cache entry due to a failure of
the dynamic home agent address
discovery mechanism. Each mobile node, packets while away from home,
also maintains a Home Agents List, to enable it can still reach the mobile node
through the mobile node's to notify a
home agent, causing agent on its previous link when it moves to a new Binding
Update to this link; a
mobile node MAY maintain a separate Home Agents List for each
link to allow which it to recreate this cache entry. is (or has recently) connected, or it MAY
maintain a single list for all links. Each Home Agents List
entry conceptually contains the following fields:
- The value link-local IP address of this field is undefined if a router on the Status field
indicates link, that the Binding Update was rejected.
Sub-Options
Additional information, associated with
this Binding
Acknowledgement option. The Authentication Data sub-option MAY
be present, and other sub-options (not node currently defined) MAY
be optionally included. See section 4.4 for authentication
requirements. This use of sub-options also allows believes is operating as a home agent
for future
extensions to the format of that link. A new entry is created or an existing
entry is updated in the Binding Acknowledgement option Home Agents List in response to be defined.
The alignment requirement [6] for
receipt of a valid Router Advertisement in which the Binding Acknowledgement option Home
Agent (H) bit is 4n+3.
Any packet that includes a Binding Acknowledgement option MUST
contain authentication data to guard against malicious Binding
Acknowledgements. set. The computation for this authentication data MUST
follow the rules in Section 4.4.
If link-local address of the node returning home
agent is learned through the Binding Acknowledgement accepted Source Address of the
Binding Update Router
Advertisements received from it [20].
- One or more global IP addresses for which the Acknowledgement is being returned (the
value of this home agent,
learned through Prefix Information options with
the Status field Router Address (R) bit set, received in the Acknowledgement is less than 128), Router
Advertisements from this node will have an entry link-local address. Global
addresses for the mobile node router in its Binding
Cache and MUST use this a Home Agents List entry (which includes MUST
be deleted once the care-of prefix associated with that address
received in the Binding Update) in sending the packet containing the
Binding Acknowledgement to is
no longer valid [20].
Are there interactions with the mobile node. new Router
Advertisement stuff?
- The details remaining lifetime of sending this packet (using Home Agents List entry. If
a Routing header) to the mobile node are the same
as for sending any packet to Home Agent Information Option is present in a mobile node using Router
Advertisement received from a binding, as are
described in Section 8.9.
If the node returning the Binding Acknowledgement instead
rejected home agent, the Binding Update (the value lifetime of
the Status Home Agents List entry representing that home agent
is initialized from the Home Agent Lifetime field in the
Acknowledgement is greater than or equal to 128), this node MUST
similarly use a Routing header in sending
option; otherwise, the packet containing lifetime is initialized from the
Binding Acknowledgement, as described in Section 8.9, but MUST NOT
use its Binding Cache
Router Lifetime field in forming the IP header or Routing header
in received Router Advertisement.
The Home Agents List entry lifetime is decremented until it
reaches zero, at which time this packet. Rather, entry MUST be deleted from
the care-of address used by Home Agents List.
- The preference for this node home agent; higher values
indicate a more preferable home agent. The preference
value is taken from the Home Agent Preference field (a
signed, twos-complement integer) in
sending the packet containing received Router
Advertisement, if the Binding Acknowledgement MUST be
copied from Router Advertisement contains a Home
Agent Information Option, and is otherwise set to the care-of address received
default value of 0. A home agent uses this preference in
ordering the rejected Binding
Update; this node MUST NOT modify its Binding Cache Home Agents List returned in an ICMP Home
Agent Address Discovery message in response to receiving a mobile
node's initiation of dynamic home agent address discovery.
A mobile node uses this rejected Binding Update and MUST ignore its
Binding Cache in sending the packet preference in determining which it returns this Binding
Johnson and Perkins Expires 2 January 22 September 2002 [Page 28] 29]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Acknowledgement. The packet is sent using a Routing header, routing
the packet to 22 March 2002
of the home address of agents on its previous link to notify when it
moves to a new link.
Can we delete the rejected preference stuff? Is anyone using
it?
4.8. Binding Update by
way of the Management
When a mobile node configures a new care-of address indicated in and decides to
use this new address as its primary care-of address, the packet containing mobile
node registers this new binding with its home agent by sending
the home agent a Binding Update. When sending a The mobile node indicates
that an acknowledgement is needed for this Binding Acknowledgement Update and
continues to reject a
Binding Update, periodically retransmit it until acknowledged. The
home agent acknowledges the Binding Update by returning a Binding
Acknowledgement MUST be sent in an IPv6 to the mobile node.
When a mobile node receives a packet containing tunneled to it from its home
agent, the mobile node uses that as an indication that the original
sending correspondent node has no payload (with Binding Cache entry for the Next Header field in mobile
node, since the last
extension header in correspondent node would otherwise have sent the
packet set to indicate "No Next Header" [6]).
The three highest-order bits of the Option Type are encoded directly to
indicate specific processing of the option [6]. For mobile node using a Routing header. If the
mobile node has a Binding
Acknowledgement option, these three bits are set to 000, indicating Security Association (BSA) with that any IPv6
correspondent node, the mobile node processing this option that does not recognize thus returns a Binding Update
to the
Option Type must skip over this option and continue processing correspondent node, allowing it to cache the
header, and that mobile node's
binding for routing future packets to it. Although the data within mobile node
may request an acknowledgement for this Binding Update, it need not,
since subsequent packets from the option cannot change en-route correspondent node will continue
to be intercepted and tunneled by the packet's final destination. mobile node's home agent,
effectively causing any needed Binding Update retransmission.
If the mobile node sends receives such a sequence number which is tunneled packet but does not greater than
the sequence number from the last successful Binding Update, then the
home agent MUST send back have
a Binding Acknowledgement BSA with status code
141, and the last accepted sequence number in correspondent node, the Sequence Number
field mobile node SHOULD initiate
the process of establishing the Binding Acknowledgement.
Johnson and Perkins Expires 2 January 2002 [Page 29]
INTERNET-DRAFT Mobility Support necessary security association by
following the procedures outlined in IPv6 2 July 2001
5.3. Binding Request Option
The Section 4.5
A correspondent node with a Binding Request destination option is used to request Cache entry for a mobile
node's binding from node
may refresh this binding, for example if the mobile node. As binding's lifetime
is near expiration, by sending a destination option, it
MAY be included in any existing packet being sent Binding Request to the mobile
node or MAY be sent in a packet by itself;
node. Normally, a packet containing correspondent node will only refresh a Binding Request option is sent
Cache entry in the same this way if it is actively communicating with the
mobile node and has indications, such as any packet an open TCP connection to a
the mobile node (Section 8.9). node, that it will continue this communication in the
future. When a mobile node receives a packet
containing a Binding Request option, Request, it SHOULD return replies by
returning a Binding Update (Section 5.1) to the source of node sending the Binding Request.
A mobile node may use more than one care-of address at the same time,
although only one care-of address may be registered for it at its
home agent as its primary care-of address. The Binding Request option is encoded mobile node's home
agent will tunnel all intercepted packets for the mobile node to its
Johnson and Perkins Expires 22 September 2002 [Page 30]
INTERNET-DRAFT Mobility Support in type-length-value (TLV)
format as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Option Type | Option Length | Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Option Type
8
Option Length
8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field
MUST be set to 0 plus IPv6 22 March 2002
(single) registered primary care-of address, but the total length of all sub-options
present, including their Sub-Option Type and Sub-Option Len
fields.
Sub-Options
Additional information, associated with this Binding Request
option, mobile node
will accept packets that need not be present in all Binding Requests sent.
This use of sub-options also allows for future extensions to
the format it receives at any of the Binding Request option to be defined. The
encoding and format its current care-of
addresses. Use of defined sub-options are described in
Section 5.5. The following sub-options are valid in more than one care-of address by a Binding
Request option:
- Unique Identifier Sub-Option
There is no requirement mobile node
may be useful, for alignment [6] of the Binding Request
option.
The three highest-order bits of example, to improve smooth handover when the Option Type are encoded
mobile node moves from one wireless link to
indicate specific processing another. If each of the option [6]. For the Binding
Request option,
these three bits are set wireless links is connected to 000, indicating that any
IPv6 node processing this option that does not recognize the Option
Johnson and Perkins Expires 2 January 2002 [Page 30]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Type must skip over this option and continue processing the header,
and Internet through a separate
base station, such that the data within wireless transmission range from the option cannot change en-route to
two base stations overlap, the
packet's final destination.
Johnson and Perkins Expires 2 January 2002 [Page 31]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
5.4. Home Address Option
The Home Address destination option is used in a packet sent by a mobile node while away from home, may be able to inform remain
connected to both links while in the recipient of that
packet area of overlap. In this case,
the mobile node's home address. For packets sent by a
mobile node while away could acquire a new care-of address on the new link
before moving out of transmission range and disconnecting from home, the
old link. The mobile node generally uses
one may thus still accept packets at its
old care-of address while it works to update its home agent and
correspondent nodes, notifying them of its new care-of addresses as the Source Address in the packet's
IPv6 header. By including a Home Address option in the packet, address on the
new link.
Since correspondent node receiving the packet nodes cache bindings, it is able expected that
correspondent nodes usually will route packets directly to substitute the mobile
node's home address for this care-of address when processing address, so that the packet, thus making home agent is rarely involved
with packet transmission to the use of mobile node. This is essential for
scalability and reliability, and for minimizing overall network load.
By caching the care-of address transparent to of a mobile node, optimal routing of
packets can be achieved from the correspondent node to the mobile
node. Note that multicast addresses, link-local
addresses, loopback addresses, IPv4 mapped addresses, and Routing packets directly to the
unspecified address, MUST NOT be mobile node's care-of address
also eliminates congestion at the mobile node's home agent and 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
home link is reduced, since these nodes and links are not involved in
the delivery of most packets to the mobile node.
5. New IPv6 Destination Options and Message Types
5.1. Mobility Header
The Mobility Header is used within a Home Address option. by mobile nodes, correspondent nodes, and
home agents in all messaging related to the creation and management
of bindings. The Home Address option Mobility Header is encoded an IPv6 protocol. Rules
regarding how it is sent and what addresses are used in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the IPv6
header are given separately in Sections 5.1.2 to 5.1.9. Mobile nodes
MUST use reverse tunneling to send Mobility Header messages when the
source address is set to the home address of the mobile node.
Johnson and Perkins Expires 22 September 2002 [Page 31]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
5.1.1. Format
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 | Option Type Header Len | Option Length MH Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+ + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ Home Address +
| |
+ +
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type
201 = 0xC9
Option Length
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 option, Mobility Header in units
of 8 octets,
excluding including the Option Type the Payload Proto, MH Type, Header
Len, Checksum, and Option Length Message Data fields. This
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
MUST SHOULD cause an error to be set sent
to 16 plus the total length source.
Checksum
16-bit unsigned integer. This field contains the checksum
of all sub-options
present, including their Sub-Option Type and Sub-Option Len
fields.
Home Address the Mobility Header. The home address checksum is the 16-bit one's
complement of the mobile node sending one's complement sum of the packet. 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
Johnson and Perkins Expires 2 January 22 September 2002 [Page 32]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Sub-Options
Additional information, associated with this Home Address
option, that need not be present in all Home Address options
sent. This use of sub-options also allows for future
extensions to 22 March 2002
is 62 (XXX). For computing the format of checksum, the Home Address option checksum field is
set to be
defined. Currently, no valid sub-options are defined for use
in a Home Address option.
The alignment requirement [6] for zero.
Message Data
A variable length field containing the Home Address option is 8n+6.
The inclusion of a Home Address option in a packet affects data specific to the
receiving
indicated Mobility Header type.
5.1.2. Binding Request (BR) Message
The Binding Request (BR) message is used to request a mobile node's processing of only this single packet; no state
binding from the mobile node. A packet containing a Binding Request
message is
created or modified sent in the receiving node same way as any packet to a result of receiving a
Home Address option in a packet. In particular, the presence of mobile node
(Section 8.9). When a
Home Address option in mobile node receives a received packet MUST NOT alter the contents
of the receiver's containing a
Binding Cache Request message and MUST NOT cause any changes in there already exists a Binding Update
List entry for the
routing source of subsequent packets sent by this receiving node.
The Home Address option MUST be placed as follows:
- After the Routing Header, if that header is present
- Before the Fragment Header, Binding Request, it MAY start
a Return Routability Procedure (see Section 4.5) if that header is present
- Before it believes
the AH Header or ESP Header, if either one of those
headers is present
No authentication amount of traffic with the Home Address option is required, except
that if correspondent justifies the IPv6 header use of a packet is covered by authentication,
then
Route Optimization. Note that authentication MUST also cover the Home Address option; 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 coverage
value is achieved automatically by the definition of indicated in the
Option MH Type code for field, the Home Address option, since it indicates
that format of the data within Message
Data field in the option cannot change en-route 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
packet's final destination,
sender, and thus the option is included in MUST be ignored by the
authentication computation. By requiring that any authentication receiver.
Parameters
Variable-length field, of length such that the IPv6 header also cover the Home Address option, the security 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 Source Address field following parameter:
Johnson and Perkins Expires 22 September 2002 [Page 33]
INTERNET-DRAFT Mobility Support in the IPv6 header is not compromised by
the presence of 22 March 2002
- Authentication Data parameter. This parameter contains a Home Address option. Security issues related
cryptographic hash value which is used to ensure that it
has been sent by the Home Address option are discussed further in Section 13. When
attempting to verify authentication data in correspondent node. The authenticator
covering a packet that contains Binding Acknowledgement MUST be computed over
a Home Address option, bitstring containing the receiving node MUST make following fields of the calculation
as if IPv6
header and the care-of address were present Mobility Header, in the order:
* The Home Address option,
and of the home address were present in mobile node, from the
Destination Address field of the source IPv6 header.
* The address of the correspondent node, from the Source
Address field of the IPv6 header. This conforms with
* 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 specified over sequence of bits
is described in
section 10.2.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] Section 4.5.
There MAY contain a separate Home Address
option be additional information, associated with each encapsulating IP header.
Johnson and Perkins Expires 2 January 2002 [Page 33]
INTERNET-DRAFT Mobility Support this
Binding Request message, that need not be present in IPv6 2 July 2001
The three highest-order bits all
Binding Requests sent. This use of MH parameters also allows
for future extensions to the Option Type are encoded format of the Binding Request
message to
indicate specific processing 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 option [6]. For Return
Routability procedure from the Home Address
option, these three bits are set mobile node to 110, indicating that any IPv6 a correspondent node processing this option that does not recognize
(see Section 10.9). This message is always sent with the Option Type
must discard Source
Address set to the packet and, only if home address of the packet's mobile node, Destination
Address
was not a multicast address, return an ICMP Parameter Problem,
Code 2, message set to the packet's Source Address; correspondent node's address, and that the data
within is tunneled
through the option cannot change en-route to home agent when the packet's final
destination. mobile node is away from home.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 34]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
5.5. Mobile IPv6 Destination Option Sub-Options
In order 22 March 2002
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST be initialized to allow optional fields zero by the
sender, and MUST be ignored by the receiver.
Parameters
Variable-length field, of length such that may 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 needed additional information, associated with this
message that need not be present in every all HoTI messages. This
use of any given Mobile IPv6 destination option, and to allow MH parameters also allows for future extensions to the
format of these destination options the HoTI message to be defined,
any defined. The encoding and
format of the Mobile IPv6 destination options 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 document
MAY include one message, 4 bytes of Pad1
or more sub-options.
Such sub-options PadN parameters are included in needed to make the data portion length of the destination
option itself, after the fixed portion message a
multiple of the option data specified
for that particular destination option (Sections 5.1 through 5.4). 8.
The presence of such sub-options will HoTI message SHOULD be indicated protected by an IPsec policy that employs
ESP between the Option
Length field. When home agent and the Option Length 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 greater than used to initiate the standard
length defined for that destination option, Return
Routability procedure from the remaining octets are
interpreted as sub-options.
These sub-options are encoded within mobile node to a correspondent node
Johnson and Perkins Expires 22 September 2002 [Page 35]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
(see Section 10.9). This message is always sent with the remaining space Source
Address set to the care-of address of the
option data for that option, using a type-length-value (TLV) 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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Sub-Option Data...
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type
8-bit identifier of the type of sub-option. When processing
a Mobile IPv6 destination option containing a sub-option
Reserved
16-bit field reserved for
which future flags. These flag bits are
reserved for future use, and MUST be initialized to zero by the Sub-Option Type value is not recognized
sender, and MUST be ignored by the
receiver, 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 SHOULD quietly MUST
ignore and skip over the
sub-option, correctly handling any remaining sub-options 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
option.
Sub-Option Length
8-bit unsigned integer. Length
format of the Sub-Option Data field CoTI message to be defined. The encoding and
format of this sub-option, defined parameters are described in octets. Section 5.2. The Sub-Option Len does not
include the length of the Sub-Option Type and Sub-Option Len
fields.
Sub-Option Data
Variable-length field. Sub-Option-Type-specific data.
As with IPv6 options appearing
following parameters are valid in a Hop-by-Hop Options header
or Destination Options header [6], individual sub-options within
a Mobile IPv6 destination option may have specific alignment
requirements, to ensure CoTI message:
- Unique Identifier Parameter
If no actual parameters are present in this message, no padding is
necessary.
A packet that multi-octet values within Sub-Option
Data fields fall on natural boundaries. includes a CoTI message MUST NOT include a Home Address
option.
5.1.5. Home Test (HoT) Message
The alignment requirement Home Test (HoT) message is an answer to the HoTI message, and
is sent from the correspondent node to the mobile node (see Section
Johnson and Perkins Expires 2 January 22 September 2002 [Page 35] 36]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
of each sub-option 22 March 2002
8.2). This message is specified as part of always sent with the definition of each
sub-option below.
Each section above defining Destination Address set
to the Mobile IPv6 destination options
specifies which home address of the defined sub-options is valid for that
destination option. In addition, there are two padding sub-options,
Pad1 mobile node, Source Address set to the
address of the correspondent node, and PadN (defined below), which are used is tunneled through the home
agent when necessary to align
subsequent sub-options. the mobile node is away from home.
The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike HoT message uses the padding options
used in Hop-by-Hop Options header or Destination Options header [6],
there MH Type value 3. When this value is no requirement for padding
indicated in the total size of any Mobile IPv6
destination option to a multiple MH Type field, the format of 8 octets the Message Data field
in length, and the
Pad1 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 PadN sub-options SHOULD NOT MUST be used for this purpose. All
Mobile IPv6 sub-options defined in this document set to zero, otherwise an
error MUST be recognized returned to the sender.
Home Nonce Index
This field will be echoed back by all Mobile IPv6 implementations.
The following subsections specify the sub-option types which are
currently defined for use mobile node to the
correspondent node in Mobile IPv6 destination options.
5.5.1. Pad1
Pad1 Sub-Option (alignment requirement: none)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! a subsequent binding update. It
will allow the format of correspondent node to select the Pad1 sub-option is a special
case -- appropriate
challenge values to authenticate the binding update.
Home Cookie
This field contains the cookie K0 in the Return Routability
Procedure; it has neither Sub-Option Len nor Sub-Option Data
fields.
The Pad1 sub-option is used to insert one octet of padding
into the Sub-Options area first of two cookies which are to be
processed to form a Mobile IPv6 option. If more
than one octet of padding key which is required, the PadN sub-option,
described next, should be used, rather than multiple Pad1
sub-options.
5.5.2. PadN
PadN Sub-Option (alignment requirement: none) then used to authenticate a
binding update.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 36] 37]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
0 1
0 1 2 3 4 5 6 7 22 March 2002
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Sub-Option Len| Sub-Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - octets long.
Contains one or more TLV-encoded parameters. The PadN sub-option is 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 insert two or more octets of
padding into the Sub-Options area carry that information. The encoding
and format of a Mobile IPv6 option.
For N octets defined parameters are described in Section 5.2.
This use of padding, the Sub-Option Len field contains
the value N-2, and MH parameters also allows for future extensions
to the Sub-Option Data consists format of N-2
zero-valued octets.
5.5.3. Unique Identifier
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 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 Binding
Request and Binding Update destination options. The Unique
Identifier field contains a 16-bit value that serves this message, 4 bytes of Pad1
or PadN parameters are needed to
uniquely identify make the length of the message a Binding Request among those sent
multiple of 8.
The HoT message SHOULD be protected by this
Source Address, an IPsec policy that employs
ESP between the home agent and to allow the Binding Update mobile node, in order to identify prevent
attackets e.g. on the specific Binding Request same link as the MN to which it responds. This
matching of Binding Updates receive the Home
Cookie.
5.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is an answer to Binding Requests the CoTI message, and
is required
in sent from the procedure for renumbering correspondent node to the home subnet while a mobile node (see Section
8.2). This message is away from home (Section 9.6).
5.5.4. Alternate Care-of always sent with the Source Address
Alternate Care-of set to the
address of the correspondent node, the Destination Address Sub-Option (alignment requirement: 8n+6) set to
the care-of address of the mobile node, and is sent directly to the
mobile node.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 37] 38]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
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 22 March 2002
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Care-of Nonce Index | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Care-of Cookie (128 bits) |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate
| |
. .
. 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 Address sub-option is valid only Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in
Binding Update destination options. The Alternate a subsequent binding update. It
will allow the correspondent node to select the appropriate
challenge values to authenticate the binding update.
Care-of
Address Cookie
This field contains an address to use as the care-of
address for cookie K1 in the binding, rather than using Return Routability
Procedure; it is the Source
Address 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 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 complete
Mobility Header is an integer multiple of 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Authentication Data (variable length) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ octets long.
Contains one or more TLV-encoded parameters. The Authentication Data sub-option is valid in Binding
Update receiver MUST
ignore 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 skip any parameters which it does 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 understand.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 38] 39]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
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 22 March 2002
There MAY be sent on the
wire.
The Authentication Data field is a variable-length
field additional information, associated with this
message that contains data necessary to secure a Binding
Update or Binding Acknowledgment. The field must need not be
an integral multiple of 32 bits present in length. all CoT messages. MH
parameters are used to carry that information. The details encoding
and format of the authentication data computation defined parameters are described in Section 4.4. 5.2.
This field may include explicit padding,
depending upon use of MH parameters also allows for future extensions
to the requirements format of the algorithm selected by CoT message to be defined. This
specification does not define any optional parameters for the SPI.
Johnson and Perkins Expires 2 January 2002 [Page 39]
INTERNET-DRAFT Mobility Support
CoT message.
If no actual parameters are present in IPv6 2 July 2001
5.7. ICMP Home Agent Address Discovery Request 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 ICMP Home Agent Address Discovery Request Binding Update (BU) message is used by a mobile node to initiate the dynamic home agent notify
other nodes of a new care-of address discovery
mechanism, as described in Sections 9.8 and 10.8. The mobile
node sends for itself. A packet containing
a Home Agent Address Discovery Request Binding Update message is sent with the Source Address set to the
"Mobile IPv6 Home-Agents" anycast
care-of address for its own home subnet
prefix [10], and one of the home agents there responds to the mobile node with a Home Agent and the Destination Address Discovery Reply set to
the correspondent node's address.
The Binding Update message giving a list uses the MH Type value 5. When this value
is indicated in the MH Type field, the format of the routers on Message Data
field in the mobile node's home link serving Mobility Header is as home agents.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Sequence # | Code Reserved | Checksum
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
150 <To Be Assigned by IANA>
Code
0
Checksum
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson and Perkins Expires 22 September 2002 [Page 40]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
Acknowledge (A)
The ICMP checksum [5].
Identifier
An identifier Acknowledge (A) bit is set by the sending mobile node to aid in matching
request a Binding Acknowledgement (Section 5.1.8) be returned
upon receipt of the Binding Update.
Home Agent Address Discovery
Reply messages to this Registration (H)
The Home Agent Address Discovery Request
message.
Reserved
This field Registration (H) bit is unused. It MUST be initialized to zero set by the
sender and MUST be ignored by sending mobile node
to request the receiver. receiving node to act as this node's home agent.
The Source Address destination of the Home Agent Address Discovery Request
message packet carrying this message MUST be one
that of a router sharing the same subnet prefix as the mobile node's current care-of
addresses. The home agent then MUST return
address of the mobile node in the binding (given by the Home Agent
Address
Discovery Reply message directly to field in the Source Home Address chosen by option in the mobile node Note that, at packet).
Single Address Only (S)
If the time of performing this dynamic
home agent address discovery, it `S' bit is likely that set, the mobile node not
registered with any requests that the home
agent within make no changes to any other Binding Cache entry except
for the particular one containing the home address specified anycast group.
Johnson and Perkins Expires 2 January 2002 [Page 40]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
5.8. ICMP Home Agent Address Discovery Reply Message
The ICMP
the Home Agent Address Discovery Reply message is used by a
home agent to respond to a mobile node using the dynamic option. This disables home agent
address discovery mechanism, processing
for other related addresses, as is described in Sections 9.8 and 10.8. Section 9.1.
Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit is set by the sending
mobile node sends a Home Agent Address Discovery Request message to request the "Mobile IPv6 Home-Agents" anycast address for its own home
subnet prefix [10], and one of the receiving node (the mobile node's
home agents there responds agent) to the
mobile node with a Home Agent perform Duplicate Address Discovery Reply message giving
a list of the routers Detection [35] on
the mobile node's home link serving as home
agents.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
151 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Identifier
The identifier from for the invoking Home Agent Address Discovery
Request message.
Johnson and Perkins Expires 2 January 2002 [Page 41]
INTERNET-DRAFT Mobility Support home address in IPv6 2 July 2001
Reserved this
binding. This field bit is unused. It MUST be initialized to zero by only valid when the
sender Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be ignored by the receiver.
Home Agent Addresses
A list of addresses of home agents on set
otherwise. If the Duplicate Address Detection performed by
the home link for agent fails, the
mobile node. The number of addresses present Status field in the list returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection
failed).
Reserved
This field is
indicated unused. It MUST be initialized to zero by the remaining length of
sender and MUST be ignored by the IPv6 packet carrying receiver.
Sequence #
A 16-bit number used by the Home Agent Address Discovery Reply message. receiving node to sequence Binding
Updates and by the sending node to match a returned Binding
Acknowledgement with this Binding Update. Each Binding Update
sent by a mobile node MUST use a Sequence Number greater than
the Sequence Number value sent in the previous Binding Update
(if any) to the same destination address (modulo 2**16, as
defined in Section 4.7). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each
Johnson and Perkins Expires 2 January 22 September 2002 [Page 42] 41]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
5.9. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is 22 March 2002
new Binding Update sent by a mobile node
to its or received. Both home agent while it is away from home. agents and
correspondent nodes use the sequence number also to prevent
replay attacks.
Lifetime
32-bit unsigned integer. The purpose number of seconds remaining
before the
message is to solicit a Mobile Prefix Advertisement from binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero
indicates that the home
agent, which will allow Binding Cache entry for the mobile node to gather prefix information
about its home network. This information can MUST
be used to configure deleted.
Home Address
This field tells the correspondent node the home address(es) by stateless address autoconfiguration [27], of the
mobile node.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or update address(es) according more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand. A
Binding Update sent to changes in prefix a correspondent node MUST include the
following parameters:
- Nonce Indices parameter. This parameter contains
information
supplied by the home agent.
The Mobile Prefix Solicitation is similar correspondent node needs in order to find
the Router Solicitation challenge values Nj and Ni.
- Authentication Data parameter. This parameter contains a
cryptographic hash value which is used in Neighbor Discovery [17], except to ensure that it is routed from
has been sent by the mobile
node on same party who received the visited network to HoT and
CoT messages. The authenticator covering a Binding Update
MUST be computed over a bitstring containing the home agent on following
fields of the IPv6 header and the Mobility Header, in
order:
* Care-of Address, in the home network by
usual unicast routing rules.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields: Source Address field of the
IPv6 header
* The mobile node's care-of address. address of the correspondent node, in the
Destination Address field of the IPv6 header.
* The address contents of the mobile node's home agent. This home agent
must be on Mobility Header, excluding the link which
Authenticator field (within the mobile node wishes to learn
prefix information about.
Hop Limit
Set to an initial hop limit value, and this message Authentication Data
parameter) which is routed
according to included as zeroes for the rules purposes
of a typical unicast packet. A hop
limit calculating the Authenticator. Parameters of 64 is currently suggested [26].
Authentication Header
If a Security Association for the IP Authentication
Mobility Header
exists between the sender and the destination address, then are included in the
sender SHOULD include this header. [subject to change]
ICMP Fields: calculation.
* Four bytes of zero.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 43] 42]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Type
152 <To Be Assigned by IANA>
Code
0
Checksum 22 March 2002
The ICMP checksum [5].
Reserved
This field actual authenticator calculation over sequence of bits
is unused. It MUST described in Section 4.5.
There MAY be initialized 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 zero by the
sender and MUST be ignored by format of the receiver.
Johnson Binding Update message to be
defined. The encoding and Perkins Expires 2 January 2002 [Page 44]
INTERNET-DRAFT Mobility Support format of defined parameters are
described in Section 5.2. The following parameters are valid
in IPv6 2 July 2001
5.10. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message 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
mobile node
multiple of 8.
A Binding Update message to distribute prefix information about the home link
while the mobile correspondent node is traveling away from MUST NOT include
the home network. This
will occur Home Address option in response order to a Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according avoid reflection attacks
described in Section 4.5. A Binding Update to the rules home agent MUST
include the Home Address option in Section 5.10.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source 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 agent's address as of the mobile node would
expect to see it (i.e. same prefix)
Destination Address
If this in the binding given in the
Binding Update message is a response to a Mobile Prefix
Solicitation, that which was received as the Source value of the
Home Address field from that
packet. For unsolicited messages, in the mobile node's Home Address option in the packet.
The care-of address SHOULD be used, if it is currently
registered with for the home agent. Otherwise, binding given in the
mobile node's home address SHOULD be used.
Authentication Header
This Binding Update
message is normally that which was received as the value in the
Source Address field in the IPv6 header MUST be sent, unless of the mobile node
has not yet configured, and is using its packet carrying the
Binding Update message. However, a care-of
address. [subject to change]
ICMP Fields:
Type
153 <To Be Assigned address different from
the Source Address MAY be specified by IANA>
Code
0
Checksum
The ICMP checksum [5].
Options:
Johnson and Perkins Expires 2 January 2002 [Page 45]
INTERNET-DRAFT Mobility Support including an Alternate Care-of
Address parameter in IPv6 2 July 2001
Prefix Information
Each message contains one or more Prefix Information options,
which contain the prefix(es) Binding Update message. In any case, the mobile node should configure
its home address(es) with. Section 9.6 describes
care-of address MUST NOT be any IPv6 address which
prefixes should is prohibited
for use within a Routing Header; thus multicast addresses, the
unspecified address, loop-back address, and link-local addresses
are excluded. Binding Updates indicating any such excluded care-of
address MUST be advertised to silently discarded.
If the mobile node.
The Prefix Information option is defined care-of address for the binding (specified either in Section 4.6.2
of [17], with modifications defined an
Alternate Care-of Address parameter in Section 6.2 of this
specification. The home agent MUST use this modified Prefix
Information option to send the aggregate list of home network
prefixes as defined Binding Update message, if
present, or in Section 9.8.1.
The Mobile Prefix Advertisement sent by the home agent MAY include the Source Link-layer Address option defined field in RFC 2461 [17], or the
Advertisement Interval option specified in Section 6.3.
Future versions packet's IPv6 header)
is equal to the home address of this protocol may define new option types. Home
Agents MUST silently ignore the mobile node, the Binding Update
message indicates that any options they do not recognize and
continue processing existing binding for the message. mobile node MUST
Johnson and Perkins Expires 2 January 22 September 2002 [Page 46] 43]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
6. Modifications to IPv6 Neighbor Discovery
6.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies 22 March 2002
be deleted. Likewise, if the format of Lifetime field in the Router Advertisement Binding parameter
is equal to 0, the Binding Update message [17] by indicates that any existing
binding for the addition mobile node MUST be deleted. In each of these cases,
a single flag bit Binding Cache entry for the mobile node MUST NOT be created in
response to indicate that receiving the router sending Binding Update.
When the Advertisement message care-of address is serving as a NOT equal to the home
agent on this link. address,
what if we just delete that particular care-of address?
The format of the Router Advertisement message last Sequence Number value sent to a destination in a Binding
parameter 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents stored by the following changes over that originally
specified for Neighbor Discovery [17]:
Home Agent (H)
The Home Agent (H) bit is set mobile node in a Router Advertisement to
indicate its Binding Update List
entry for that destination; the router sending this Router Advertisement is
also functioning as a Mobile IP home agent on this link.
Reserved
Reduced last Sequence Number value received
from a 6-bit field to mobile node in a 5-bit field to account Binding Update is stored by a correspondent
node in its Binding Cache entry for that mobile node. Thus, the
addition of the Home Agent (H) bit.
Johnson
mobile node's and Perkins Expires 2 January 2002 [Page 47]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
6.2. Modified Prefix Information Option Format
Mobile IPv6 requires the correspondent node's knowledge of a router's global address for two
reasons:
- To allow a home agent (a router) to learn the address of all
other home agents on last
sequence number expire at the link same time. If the sending mobile node
has no Binding Update List entry, the Sequence Number may start at
any value; if the receiving correspondent node has no Binding Cache
entry for which the sending mobile node, it is providing home
agent service, for use MUST accept any Sequence Number
value in building its Home Agents List as
part of the dynamic home agent address discovery mechanism
(Sections 9.8 and 10.8).
- To allow a received Binding Update from this mobile node. The mobile
node to send a MUST NOT use the same Sequence Number in two different Binding Update
Updates to a router on the link on which its previous same correspondent node, even if the Binding Updates
provide different care-of address addresses.
5.1.8. Binding Acknowledgement (BA) Message
The Binding Acknowledgement message is located, for
purposes of establishing forwarding from this previous care-of
address used to its new care-of address acknowledge receipt
of a Binding Update message (Section 10.10).
However, Neighbor Discovery [17] only advertises 5.1.7). When a router's
link-local address, by requiring node receives
a packet containing a Binding Update message, with this address to be used as node being
the IP
Source Address destination of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow the packet, this node MUST return a router Binding
Acknowledgement to easily
and efficiently advertise its global address, by the addition of a
single flag mobile node, if the Acknowledge (A) bit is
set in the format Binding Parameter carried in the Binding Update. The
Binding Acknowledgement message is sent to the Source Address of a Prefix Information option for
use the
Binding Update message it is an answer to, with the source being the
Destination Address from the Binding Update.
Johnson and Perkins Expires 22 September 2002 [Page 44]
INTERNET-DRAFT Mobility Support in Router Advertisement messages. IPv6 22 March 2002
The Binding Acknowledgement message has the MH Type value 6. When
this value is indicated in the MH Type field, the format of the Prefix
Information option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length Reserved | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | Preferred Lifetime Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+ +
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents
Reserved
These fields are unused. They MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Status
8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving
node. The following changes over such Status values are currently defined:
0
Binding Update accepted
Values of the Status field greater than or equal to 128
indicate that originally
specified for Neighbor Discovery [17]: the Binding Update was rejected by the receiving
node. The following such Status values are currently defined:
128
Reason unspecified
130
Administratively prohibited
131
Insufficient resources
Johnson and Perkins Expires 2 January 22 September 2002 [Page 48] 45]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Router 22 March 2002
132
Home registration not supported
133
Not home subnet
137
Not home agent for this mobile node
138
Duplicate Address (R)
1-bit router address flag. When set, indicates that the
Prefix field, in addition Detection failed
141
Sequence number out of window
142
Route optimization unnecessary due to advertising low traffic
143
Invalid authenticator
144
Too old Home Nonce Index
145
Too old Care-of Nonce Index
Up-to-date values of the indicated prefix,
contains a complete IP address assigned Status field are to be specified in
the sending router.
This router IP address has most recent "Assigned Numbers" [32].
Sequence #
The Sequence Number in the same scope and conforms to Binding Acknowledgement is copied
from the
same lifetime values as Sequence Number field in the advertised prefix. This Binding Update being
acknowledged, for use of by the Prefix field is compatible mobile node in matching this
Acknowledgement with an outstanding Binding Update.
Lifetime
The granted lifetime, in seconds, for which this node will
SHOULD retain the entry for this mobile node in its use Binding
Cache. Correspondent nodes should make an effort to honor
Johnson and Perkins Expires 22 September 2002 [Page 46]
INTERNET-DRAFT Mobility Support in advertising IPv6 22 March 2002
the prefix itself, lifetimes, since prefix advertisement uses only an entry that was garbage collected too
early might cause subsequent packets from the
leading number Prefix bits specified by mobile node to
be dropped, if they contained the Prefix Length
field. Interpretation of Home Address Option. While
this flag bit situation is thus independent
of recoverable since an error message is sent
to the processing required for mobile node, it causes an unnecessary break in the On-Link (L) and Autonomous
Address-Configuration (A) flag bits.
Reserved1
Reduced from a 6-bit field to
communications.
Correspondent nodes SHOULD also retain a 5-bit field to account BCE entry for the
addition
purposes of the Router Address (R) bit.
In a solicited Router Advertisement, a home agent MUST, and all other
routers SHOULD, include at least one Prefix Information option with
the Router accepting Home Address (R) bit set. Neighbor Discovery specifies that,
if including all options in a Router Advertisement causes Options somewhat longer than
they keep on using the size entry for Route Optimization of
the Advertisement outgoing
packets. This helps to exceed the link MTU, multiple Advertisements avoid dropped packets, particularly
when clock drift can be sent, each containing a subset of problem.
If the options [17]. In this case,
at least one of these multiple Advertisements being sent instead
of a single larger solicited Advertisement, MUST include a Prefix
Information option with node sending the Router Address (R) bit set.
All routers SHOULD include at least one Prefix Information option
with Binding Acknowledgement is serving
as the Router Address (R) bit set, in each unsolicited multicast
Router Advertisement that they send. If multiple Advertisements
are being sent instead of a single larger unsolicited multicast
Advertisement, at least one of these multiple Advertisements SHOULD
include a Prefix Information option with mobile node's home agent, the Router Address (R) bit
set.
Johnson and Perkins Expires 2 January 2002 [Page 49]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
6.3. New Advertisement Interval Option Format
Mobile IPv6 defines 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 Advertisement Interval option, used in
Router Advertisement messages
Binding Update to advertise the interval at which it before the
sending router sends unsolicited multicast Router Advertisements.
The format expiration of the Advertisement Interval option this period (even
if it 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
8-bit unsigned integer. The length of the option (including
the type and length fields) not changing its primary care-of address), in units of 8 octets. order
to extend the lifetime. The value of this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by undefined
if the
sender and MUST be ignored by Status field indicates that the receiver.
Advertisement Interval
32-bit unsigned integer. Binding Update was
rejected.
Refresh
The maximum time, recommended interval, in milliseconds,
between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using seconds, at which the conceptual router configuration variables defined by
Neighbor Discovery [17], mobile
node SHOULD send a new Binding Update to this field MUST be equal node in order
to "refresh" the value
MaxRtrAdvInterval, expressed mobile node's binding in milliseconds.
Routers MAY include this option node's Binding
Cache. This refreshing of the binding is useful in their Router Advertisements. A
mobile case the
node receiving a Router Advertisement containing fails and loses its cache state. The Refresh period is
determined by the node sending the Binding Acknowledgement (the
node caching the binding). If this option
SHOULD utilize node is serving as the specified Advertisement Interval
mobile node's home agent, the Refresh value may be set, for that router
in
example, based on whether the node stores its movement detection algorithm, as described Binding Cache
in Section 10.4.
This option MUST be silently ignored for other Neighbor Discovery
messages.
Johnson and Perkins Expires 2 January 2002 [Page 50]
INTERNET-DRAFT Mobility Support volatile storage or in IPv6 2 July 2001
6.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used nonvolatile storage. Note that as
discussed in
Router Advertisement messages sent by a Section 4.5.4, home agent agents need to advertise keep at least
some information specific to this router's functionality as a home agent.
The format of about sequence numbers in non-volatile memory.
If the Home Agent Information option node sending the Binding Acknowledgement is not
serving 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
8-bit unsigned integer. The length of the option (including mobile node's home agent, the type and length fields) in units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST Refresh period
SHOULD be initialized set equal to zero by the
sender and MUST be ignored by the receiver.
Home Agent Preference
16-bit signed, twos-complement integer. The preference for the home agent sending this Router Advertisement, for use Lifetime period in
ordering the addresses returned 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 in through the Home
Agent Addresses field of a Home Agent Address Discovery Reply
message. Higher values mean more preferable. If this option
is not included in mobile node's home agent, causing a Router Advertisement in which the Home
Agent (H) bit is set, the preference value for new
Binding Update to this home agent
SHOULD be considered node to be 0. Values greater than 0 indicate a
home agent more preferable than allow it to recreate this default value, and values
less than 0 indicate a less preferable home agent. cache
entry. The manual configuration of the Home Agent Preference value
is described in Section 7.3. In addition, the sending home
agent MAY dynamically set the Home Agent Preference value, for
example basing it on the number of mobile nodes it is currently
serving or on its remaining resources for serving additional
mobile nodes; such dynamic settings are beyond the scope of this document. Any such dynamic setting of field is undefined if the Home Agent
Preference, however, MUST set Status
field indicates that the preference appropriately, Binding Update was rejected.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 51] 47]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
relative to the default Home Agent Preference value 22 March 2002
Parameters
Variable-length field, of 0 length such that
may be in use by some home agents on this link (i.e., a home
agent 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 including understand.
A Binding Acknowledgement sent by a Home Agent Information option in its
Router Advertisements will be considered to have correspondent node MUST
include the following parameter:
- Authentication Data parameter. This parameter contains a Home Agent
Preference
cryptographic hash value of 0).
Home Agent Lifetime
16-bit unsigned integer. which is used to ensure that it
has been sent by the correspondent node. The lifetime associated with authenticator
covering a Binding Acknowledgement MUST be computed over
a bitstring containing the
home agent in units following fields of seconds. The default value is the same
as IPv6
header and the Router Lifetime, as specified Mobility Header, in order:
* Care-of Address, in the main body Destination Address field of
the
Router Advertisement message. IPv6 header
* The maximum value corresponds
to 18.2 hours. A value address of 0 MUST NOT be used. the correspondent node, in the Source
Address field of the IPv6 header.
* The Home Agent
Lifetime applies only to this router's usefulness contents of the Mobility Header, excluding the
Authenticator field (inside the Authentication Data
parameter) which is included as a home
agent; it does not apply to information contained zeroes for the purposes
of calculating the Authenticator.
* Four bytes of zero.
The actual authenticator calculation over sequence of bits
is described in other
message fields or options.
Home agents Section 4.5.
There MAY include be additional information, associated with this option
Binding Acknowledgement message, that need not be present in their Router Advertisements.
all Binding Acknowledgements sent. This option MUST NOT use of MH parameters
also allows for future extensions to the format of the Binding
Acknowledgement message to be included in a Router Advertisement defined. The encoding and format
of defined parameters are described in which
the Home Agent (H) bit (see Section 6.1) is 5.2. This
specification does not set. define any parameters valid for the
Binding Acknowledgement message.
If no actual parameters are present in this option message, no padding is not included in a Router Advertisement in which the Home Agent (H)
bit
needed.
The Binding Acknowledgement is set, the lifetime for this home agent MUST be considered sent to be
the same as the Router Lifetime in source address of the Router Advertisement.
This option MUST be silently ignored for other Neighbor Discovery
messages.
If both
Binding Update message, regardless of whether the Home Agent Preference and Home Agent Lifetime Binding Update
succeeded or failed. No Routing Headers are set inserted to their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this message.
If the mobile node sends a sequence number which is not within the
window of acceptable sequence numbers, then the home
agent. agent MUST send
back a Binding Acknowledgement with status code 141, and the last
Johnson and Perkins Expires 2 January 22 September 2002 [Page 52] 48]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
6.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [17] limits routers to
a minimum interval 22 March 2002
accepted sequence number in the Sequence Number field of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface
(limited the Binding
Ack Parameter.
5.1.9. Binding Missing (BM) Message
The Binding Missing (BM) message is used by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough
that hosts will learn of their presence within a few
minutes, but not frequently enough the correspondent node
to rely on signal an absence
of advertisements inappropriate attempt to detect router failure; use the Home Address Option
without an existing binding. A packet containing a separate
Neighbor Unreachability Detection algorithm provides failure
detection."
This limitation, however, Binding Missing
message is not suitable sent to providing timely
movement detection for mobile nodes. Mobile nodes detect their
own movement by learning the presence source address of new routers as the mobile
node moves into wireless transmission range of them (or physically
connects to a new wired network), and by learning packet that previous
routers are no longer reachable. Mobile nodes MUST be able to
quickly detect when they move contained
the Home Address Option i.e. to a link served by a new router, so
that they can acquire a new the care-of address and send Binding Updates
to register this care-of address with their home agent and to notify
correspondent nodes as needed.
Thus, to provide good support for of the mobile nodes, Mobile IPv6 relaxes
this limit such that routers MAY send unsolicited multicast Router
Advertisements more frequently. In particular, on network interfaces
where
node. The source address of the router Binding Missing message is expecting to provide service to visiting the
correspondent node's address.
When a mobile
nodes (e.g., wireless network interfaces), or on which it is serving
as node receives a home agent to packet containing a Binding Missing
message, it should perform one or more mobile nodes (who may return home and
need to hear its Advertisements), of the router SHOULD be configured
with following three actions:
- If the mobile node does not have a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value,
to allow sending of unsolicited multicast Router Advertisements more
often. Recommended values Binding Update List entry for these limits are:
- MinRtrAdvInterval 0.05 seconds
- MaxRtrAdvInterval 1.5 seconds
Use
the source of these modified limits the Binding Missing message, it MUST be configurable, and specific
knowledge of ignore the type
message. This is necessary to prevent loss of network interface in use SHOULD 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 taken
into account done in configuring these limits for each network interface.
When sending unsolicited multicast Router Advertisements more
frequently than the standard order to limit on unsolicited multicast
Advertisement frequency, the sending router need not include all
options in each of these Advertisements,
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 SHOULD include at
least one Prefix Information option with MUST remove the Router Address (R) bit
set (Section 6.2) in each. entry
and route further communications through the home agent. It
may also optionally start a Return Routability Procedure (see
Section 4.5).
Johnson and Perkins Expires 2 January 22 September 2002 [Page 53] 49]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
6.6. Changes to Sending Router Solicitations
In addition to 22 March 2002
The Binding Missing message uses the limit on routers sending unsolicited multicast
Router Advertisement messages (Section 6.5), Neighbor Discovery
defines limits on nodes sending Router Solicitation messages, such
that a node SHOULD send no more than 3 Router Solicitations, and that
these 3 transmissions SHOULD be spaced at least 4 seconds apart.
However, these limits prevent a mobile node from finding a new
default router (and thus a new care-of address) quickly as it moves
about.
Mobile IPv6 relaxes MH Type value 7. When this limit such that, while a mobile node is away
from home, it MAY send Router Solicitations more frequently. The
following limits for sending Router Solicitations are recommended for
mobile nodes while away from home:
- A mobile node that
value is not configured with any current care-of
address (e.g., indicated in the mobile node has moved since its previous
care-of address was configured), MAY send more than MH Type field, the defined
Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router
Solicitations.
- The rate at which a mobile node sends Router Solicitations MUST
be limited, although a mobile node MAY send Router Solicitations
more frequently than the defined Neighbor Discovery limit of
RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST
be configurable, and specific knowledge format of the type of network
interface in use SHOULD be taken into account Message
Data field in configuring this
limit for each network interface. A recommended minimum interval the Mobility Header is 1 second.
- After sending at most MAX_RTR_SOLICITATIONS Router Solicitations,
a mobile node as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future flags. These flag bits are
reserved for future use, and MUST reduce the rate at which it sends subsequent
Router Solicitations. Subsequent Router Solicitations SHOULD be sent using a binary exponential backoff mechanism, doubling
the interval between consecutive Router Solicitations, up initialized to a
maximum interval. The maximum interval MUST be configurable and
SHOULD be chosen appropriately based on the characteristics of zero by the type of network interface in use.
- While still searching for a new default router
sender, and care-of
address, a mobile node MUST NOT increase be ignored by the rate at which it
sends Router Solicitations unless it has received a positive
indication (such as from lower network layers) receiver.
Home Address
The home address that it has moved
to a new link. After successfully acquiring a new care-of
address, was contained in the Home Address Option.
The mobile node SHOULD also increase the rate at uses this information to determine which
it will send Router Solicitations when it next begins searching
for a new default router and care-of address.
- A
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 currently configured 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 a care-of address
SHOULD NOT send Router Solicitations 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 default router 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.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 54] 50]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
on it current link, until its movement detection algorithm
(Section 10.4) determines that it has moved and that its current
care-of address might no longer be valid.
Johnson and Perkins Expires 2 January 22 March 2002 [Page 55]
INTERNET-DRAFT
If no actual parameters are present in this message, no padding is
needed.
5.2. Mobility Support Header Parameters
5.2.1. Format
In order to allow optional fields that may not be needed in IPv6 2 July 2001
7. Requirements for Types every use
of IPv6 Nodes
Mobile IPv6 places some special requirements on any given Mobility Header, and to allow future extensions to the functions
provided by different types
format of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement
is intended these messages to support. Further details on be defined, any of the Mobility Header
messages defined in this functionality is
provided document MAY include one or more parameters.
Such parameters are included in the following sections.
7.1. Requirements for All IPv6 Hosts and Routers
Since any IPv6 node may at any time be a correspondent node data portion 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 message
itself, after the fixed portion of the message data specified in any IPv6 packet.
- Every IPv6 node SHOULD
section 5.1.
The presence of such parameters will be able to process a Binding Update option
received in a packet, and to return a Binding Acknowledgement
option if indicated by the Acknowledge (A) bit is set in Header Len
of the received Binding
Update.
- Every IPv6 node SHOULD be able to maintain a Binding Cache Mobility Header.
These parameters are encoded within the remaining space of the
bindings received in accepted Binding Updates.
7.2. Requirements
message data for All IPv6 Routers
The following requirements apply to all IPv6 routers, even those not
serving 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 home agent
Mobility Header containing a parameter for Mobile IPv6:
- Every IPv6 router SHOULD be able to send an Advertisement
Interval option in its Router Advertisements, to aid movement
detection which the Parameter
Type value is not recognized by mobile nodes. The use of this option in Router
Advertisements the receiver, the receiver MUST be configurable.
- Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at
quietly ignore and skip over the faster rate described parameter, correctly handling
any remaining sub-options in
Section 6.5. The use the option.
Parameter Length
8-bit unsigned integer. Length of the Parameter Data field
of this faster rate 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 configurable.
- each router SHOULD include at least one prefix with the 'R' bit
set aligned on an 8-byte boundary, and with its full IP address in its router advertisements.
7.3. Requirements for IPv6 Home Agents
In order for have a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function
as length
which is a home agent for the mobile node. The following additional multiple of 8.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 56] 51]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
requirements apply to all IPv6 routers capable of serving as a home
agent:
- Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as 22 March 2002
The following subsections specify the home
agent. Each such Binding Cache entry records the mobile node's
binding with its primary care-of address and is marked as a "home
registration".
- Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery) addressed to a mobile node for Parameter types which it is are
currently serving as the home agent, on that mobile node's home
link, while the mobile node is away from home.
- Every home agent MUST be able to encapsulate such intercepted
packets in order to tunnel them to the primary care-of address defined for the mobile node indicated in its binding use in the home agent's
Binding Cache.
- Every home agent Mobility Header.
Implementations MUST be able to return a Binding Acknowledgement
option in response to a Binding Update option received with 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
Acknowledge (A) bit set.
- Every home agent MUST maintain format of the Pad1 parameter is a separate Home Agents List for
each link on which special case -- it has
neither Parameter Len nor Parameter Data fields.
The Pad1 parameter is serving as a home agent, as described in
Section 4.6.
- Every home agent MUST be able to accept packets addressed used to insert one octet of padding into the "Mobile IPv6 Home-Agents" anycast address for the subnet
on which it is serving as
Parameters area of a home agent [10], and MUST Mobility Header. If more than one octet of
padding is required, the PadN parameter, described next, should be
able to participate in dynamic home agent address discovery
(Section 9.8).
used, rather than multiple Pad1 parameters.
5.2.3. PadN
PadN Parameter (alignment requirement: none)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - Every home agent SHOULD support a configuration mechanism to
allow a system administrator - - - - - - -
| 1 | Parameter Len | Parameter Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN parameter is used to manually set insert two or more octets of padding
into the value to be sent
by this home agent in Parameters area of some Mobility Header message. For N
octets of padding, the Home Agent Preference Parameter Len field of contains the Home
Agent Information Option in Router Advertisements that it sends.
- Every home agent SHOULD support sending ICMP Mobile
Prefix Advertisements, value N, and SHOULD respond to Mobile Prefix
Solicitations.
7.4. Requirements for IPv6 Mobile Nodes
Finally,
the following requirements apply to all IPv6 nodes capable Parameter Data consists of functioning as mobile nodes:
- Every IPv6 mobile node N-2 zero-valued octets. Parameter
data MUST be able to perform IPv6
decapsulation [4]. ignored by the receiver.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 57] 52]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
5.2.4. Unique Identifier
Unique Identifier parameter (alignment requirement: 2n)
0 1 2 July 2001
- Every IPv6 mobile node MUST support sending Binding Update
options, as specified in Sections 10.7, 10.9, and 10.10; and MUST
be able to receive and process Binding Acknowledgement options,
as specified in Section 10.13.
- Every IPv6 mobile node MUST support use of the dynamic home agent
address discovery mechanism, as described 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 | 4 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier parameter is valid only in Section 10.8.
- Every IPv6 mobile node MUST maintain 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 List in
which it records
to identify the IP address of each other node specific Binding Request to which it
has sent a responds. This
matching of Binding Update, Updates to Binding Requests is required in the
procedure for which renumbering the Lifetime sent in that
binding has not yet expired.
- Every IPv6 mobile node MUST support receiving a Binding Request
option, by responding with home subnet while a Binding Update option.
- Every IPv6 mobile node MUST support sending packets containing a
Home Address option; this option MUST be included in all packets
sent while is away
from home, if the packet would otherwise have
been sent with the mobile node's home (Section 9.7).
5.2.5. Alternate Care-of Address
Alternate Care-of Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address parameter is valid only in Binding
Update message. The Alternate Care-of Address field contains an
address to use as the IP care-of address for the binding, rather than
using the Source
Address.
- Every IPv6 mobile node MUST maintain a Home Agents List, Address of the packet as
described in Section 4.6.
- Every mobile node MUST support receiving Mobile Prefix
Advertisements and reconfiguring its home address based on the
prefix information contained therein. care-of address.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 58] 53]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
5.2.6. Nonce Indices
Nonce Indices parameter (alignment requirement: 8n+6)
0 1 2 July 2001
8. Correspondent Node Operation
A correspondent node is any node communicating with a mobile node. 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 correspondent node, itself, may be stationary or mobile, Nonce Indices parameter is valid only in the Binding Update
message, and may
possibly also be functioning as a home agent for Mobile IPv6. only when present together with an Authentication Data
parameter.
The
procedures in this section thus apply to all IPv6 nodes.
8.1. Receiving Packets from a Mobile Node
Packets sent by a mobile node while away from home generally include
a Home Address option. When any Nonce Index field tells the correspondent node that receives a packet containing
a Home Address option, it MUST process
the option in a manner
consistent with exchanging message which of the Home Address field from challenge values (Nj) are to be used to
authenticate the Home
Address option into Binding Update.
The Care-of Nonce Index field tells the IPv6 header, replacing correspondent node that
receives the original value message which of the Source Address field there. However, any actual modifications challenge values (Ni) are to be
used to authenticate the Source Address field 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 packet's IPv6 header 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 carried
out established temporarily only for the
Johnson and Perkins Expires 22 September 2002 [Page 54]
INTERNET-DRAFT Mobility Support in such a fashion that further processing of such a packet after
all IPv6 options 22 March 2002
duration of processing (e.g., at the transport layer) does not
need to know this message. Messages that contain other
values of the original Source Address was SPI field SHOULD be silently discarded.
The Authenticator field contains a care-of address,
or that the 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 was is used in the packet.
Since the sending a packet sent by a
mobile node uses its home address at the transport
layer when sending such a packet, while away from home, to inform the use recipient of that
packet of the care-of address
and Home Address option is transparent to both the mobile node's home address. For packets sent by a
mobile node and while away from home, the correspondent mobile node above the level generally uses one
of its care-of addresses as the Home Source Address option
generation and processing.
8.2. Receiving Binding Updates
Before accepting in the packet's IPv6
header. By including a Binding Update Home Address option received in any the IPv6 Destination
Options header of the packet, the
receiving correspondent node MUST validate the Binding Update according to receiving the
following tests:
- The
packet meets is able to substitute the specific authentication requirements mobile node's home address for
Binding Updates, defined in Section 4.4.
- The packet MUST contain a Home Address option.
- The Option Length field in this
care-of address when processing the Binding Update option is greater
than or equal to packet. This makes the length specified in Section 5.1.
- The Sequence Number field in use of
the Binding Update option is greater
than care-of address transparent to the Sequence Number received in correspondent node. Note
that multicast addresses, link-local addresses, loopback addresses,
IPv4 mapped addresses, and the previous Binding Update
for this home unspecified address, if any. As noted in Section 4.6, this
Sequence Number comparison MUST NOT be performed modulo 2**8.
If the mobile node sends used
within a sequence number which Home Address option.
The Home Address option is not greater than
the sequence number from encoded in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type
201 = 0xC9
Option Length
8-bit unsigned integer. Length of the last successful Binding Update, then option, in octets,
excluding the
receiving node MUST send back a Binding Acknowledgement with status Option Type and Option Length fields. This field
Johnson and Perkins Expires 2 January 22 September 2002 [Page 59] 55]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
code 141, and the last accepted sequence number in 22 March 2002
MUST be set to 16 plus the Sequence
Number field total length of all sub-options
present, including their Sub-Option Type and Sub-Option Len
fields.
Home Address
The home address of the Binding Acknowledgement.
Any Binding Update which fails to satisfy mobile node sending the packet.
Sub-Options
Additional information, associated with this Home Address
option, that need not be present in all Home Address options
sent. This use of these tests sub-options also allows for any
other reason (than insufficiency future
extensions to the format of the Sequence Number) MUST Home Address option to be
silently ignored, and
defined. Currently, no valid sub-options are defined for use
in a Home Address option.
The alignment requirement [6] for the Home Address option is 8n+6.
The inclusion of a Home Address option in a packet carrying affects the Binding Update MUST be
discarded.
In
receiving node's processing of only this section, the care-of address refers to the IPv6 address,
which was originally located single packet; no state is
created or modified in the IPv6 header when receiving node as a result of receiving a
Home Address option in a packet. In particular, the presence of a
Home Address option in a received packet was
transmitted by MUST NOT alter the mobile node.
If contents
of the receiver's Binding Update is valid according to the tests above, then Cache and MUST NOT cause any changes in the
Binding Update is processed further
routing of subsequent packets sent by this receiving node.
The Home Address option MUST be placed as follows:
- If After the Lifetime specified in Routing Header, if that header is present
- Before the Binding Update Fragment Header, if that header is nonzero and present
- Before the specified Care-of Address AH Header or ESP Header, if either one of those
headers is not equal present
Due to the home address
for threat of reflection attacks through the binding, then use of this
option, this specification requires that packets containing Home
Address Option MUST be dropped if there is a request to cache a binding no corresponding Binding
Cache Entry for that home address with the mobile node. currently registered
care-of address matching the source address of the packet. If the Home Registration (H) bit
packet is set in dropped, the
Binding Update, correspondent nodes SHOULD send the Binding Update is processed according to the
procedure specified in Section 9.1; otherwise, it is processed
according
Missing message to the procedure specified in Section 8.3.
- If source address of the Lifetime specified in packet that contained
the Binding Update is zero or the
specified Care-of Home Address matches Option (see Section 5.1.9). These messages SHOULD
be rate-limited.
No additional authentication of the home address for Home Address option is
required, except that if the
binding, IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the
Home Address option; this coverage is a request to delete achieved automatically by the mobile node's
cached binding. If
definition of the Option Type code for the Home Registration (H) bit is set Address option, since
Johnson and Perkins Expires 22 September 2002 [Page 56]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
it indicates that the
Binding Update, data within the Binding Update is processed according option cannot change en-route
to the
procedure specified in Section 9.2; otherwise, it is processed
according to packet's final destination, and thus the procedure specified option is included in Section 8.4.
8.3. Requests to Cache a Binding
When a node receives a Binding Update, it MUST validate it and
determine
the type authentication computation. By requiring that any authentication
of Binding Update according to the steps described IPv6 header also cover the Home Address option, the security
of the Source Address field in Section 8.2. This section describes the processing IPv6 header is not compromised by
the presence of a valid
Binding Update that requests a node Home Address option. Security issues related to cache a mobile node's binding,
for which
the Home Registration (H) bit is not set Address option are discussed further in the Binding
Update.
In this case, Section 4.5. When
attempting to verify authentication data in a packet that contains
a Home Address option, the receiving node SHOULD create a new entry in its
Binding Cache for this mobile node (or update its existing Binding
Cache entry for this mobile node, MUST make the calculation
as if such an entry already exists).
The new Binding Cache entry records the association between this
home care-of address were present in the Home Address option,
and the care-of home address for were present in the binding. The lifetime
for source IPv6 address field
of the Binding Cache entry is initialized from IPv6 header. This conforms with the Lifetime field calculation specified in the Binding Update, although this lifetime
section 10.2.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] MAY be
reduced by contain a separate Home Address
option associated with each encapsulating IP header.
The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Home Address
option, these three bits are set to 110, indicating that any IPv6
node caching processing this option that does not recognize the binding; Option Type
must discard the lifetime for packet and, only if the Binding
Cache entry MUST NOT be greater than packet's Destination Address
was not a multicast address, return an ICMP Parameter Problem,
Code 2, message to the Lifetime value specified in packet's Source Address; and that the data
within the option cannot change en-route to the packet's final
destination.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 60] 57]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
5.4. Routing Header type 2 July 2001
the Binding Update. Any Binding Cache entry MUST be deleted after
the expiration of this lifetime in the Binding Cache entry.
8.4. Requests to Delete
Mobile IPv6 uses a Binding
When routing header to carry the Home Address for
packets sent from a correspondent node receives to a Binding Update, it MUST validate it and
determine mobile node, which the type
Care of Address of Binding Update according to the steps described MN is carried in Section 8.2. This section describes the processing of a valid
Binding Update that requests IPv6 destination field.
This uses a node different routing header type than what is defined
for ``regular'' IPv6 source routing to delete a mobile node's binding
from its Binding Cache, 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 Home Registration (H) bit is
not set
address contained in the Binding Update. In this case, routing header is the home address of the receiving
node MUST
delete any existing entry in its Binding Cache for order to prevent packets with this mobile node.
8.5. Sending Binding Acknowledgements
When any node receives a packet containing a Binding Update option
in which the Acknowledge (A) bit is set, it MUST return a Binding
Acknowledgement option acknowledging receipt of routing header type to be
forwarded after decrementing the Binding Update.
If segments left field.
5.4.1. Routing Header Packet format
The Type 2 Routing header has the node accepts following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8-bit selector. Identifies the Binding Update and creates or updates
an entry in its Binding Cache for this binding, and type of header immediately
following the `A' bit
was set in Routing header. Uses the Binding Update, same values as the Status IPv4
Protocol field in [10].
Hdr Ext Len
8-bit unsigned integer. Length of the Binding
Acknowledgement MUST be set to a value less than 128; if, on Routing header in
8-octet units, not including the
other hand first 8 octets. For the Binding Update Type
2 Routing header, Hdr Ext Len is accepted always 2.
Routing Type
2.
Johnson and Perkins Expires 22 September 2002 [Page 58]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
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 `A' bit final destination. For the type
2 routing header, Segments left is not set, 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 SHOULD NOT send sends packets with a Binding Acknowledgement. If routing header based on the node
rejects
content of the Binding Update binding cache. Conceptually this is done by the IP
layer inspecting the binding cache and does not create or update if there is an entry for
this binding, the
destination address (the Home Address) then the IP layer inserts a Binding Acknowledgement MUST be sent even if
routing header of type 2 based on the `A'
bit was not sent, ordering rules below and moves
the Status field in the Binding Acknowledgement
MUST be set to a value greater than or equal Home Address to 128. Specific values
for the Status Home Address field are described in Section 5.2 the RH and in places the most
recent "Assigned Numbers" [26].
The packet
Care of Address in which the Binding Acknowledgement is returned
MUST meet IPv6 destination field.
Note that following the specific authentication requirements for Binding
Acknowledgements, defined above conceptually model in Section 4.4. Furthermore, if an implementation
creates some additional requirements for path MTU discovery since the packet
is
packetization layer (e.g., TCP and applications using UDP) need to be sent to
aware of the mobile node at any address other than size of the mobile
node's home address, it MUST be sent using a Routing header (even if headers added by the binding was rejected). The intermediate IP address, to which layer on the packet sending
node.
The IP layer will be delivered immediately before the home address, is
determined as follows:
- Whenever the Binding Update is accepted with a nonzero lifetime, insert the routing header before performing IPsec
processing. The IPsec Security Policy Database will be constructed using consulted
based on the care-of IP source address
as described in Section 8.9.
- Otherwise, if and the Source final IP Address of destination (which
will be in the packet containing routing header). The definition of AH ensures that
the Binding Update, AH calculation is legal for inclusion done on the packet in a Routing Header, the routing header form it will be constructed using that IP address.
Note that multicast addresses, link-local addresses, loopback
addresses, IPv4 mapped addresses, and have on
the unspecified address, receiver after advancing the routing header.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 61] 59]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
MUST NOT be used within 22 March 2002
5.4.3. Verification by receiver
A node receiving a Routing Header for packet addressed to itself (i.e., one of the Binding
Acknowledgement.
- Otherwise, if
node's addresses is in the Binding Update has a zero lifetime but IPv6 destination field) follows the
Source IP address is not allowable for use within next
header chain of headers and processes them. When it encounters a
routing header of type 2 during this processing it performs the Routing
Header,
following checks. If any of these checks fail the Binding Acknowledgment node MUST be sent to silently
discard the mobile
node's home address.
In response to a Binding Update, a packet.
- The node MAY send is a Binding
Acknowledgement even when mobile node.
- The length field in the 'A' bit RH is not set exactly 2
- The segments left field in the Binding
Update. This would happen, for instance, if a mobile node attempted
to send a Binding Update with the 'H' bit set to a correspondent
node.
8.6. Sending Binding Requests
Entries RH is exactly 1
- The Home Address field in a node's Binding Cache MUST be deleted when their lifetime
expires. If such an entry the RH is still (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 active use RFC 2460
i.e. swap the IPv6 destination field with the Home Address field
in sending packets
to a mobile node, the next RH, decrement segments left, and resubmit the packet sent to IP
for processing the mobile node will be
routed normally to next header. However, in the mobile node's home link, where it will case of RH type 2
this can be
intercepted and tunneled to simplified since it is known that the mobile node. The mobile node packet will
then return a Binding Update to the sender, allowing it not be
forwarded to create a new Binding Cache entry for sending future packets to the mobile different node. Communication with
Since IPsec headers follow the mobile node continues uninterrupted,
but Routing Header any IPsec processing
will operate on the forwarding of this packet through with the mobile node's home
agent creates additional overhead HoA in the IP destination field
and latency segments left being zero. Thus AH will see the packet in delivering packets
to the mobile node. Such routing paths could, for instance,
temporarily or permanently disrupt any negotiated Quality of Service
reservations which had been made by
same "shape" as the mobile node AH calculation on its home
network.
If the sender knows that the Binding Cache entry is still sender.
5.4.4. Extension header ordering
Section 4.1 in active
use, it MAY send a Binding Request option to RFC 2460 lists the mobile node in
an attempt to avoid this overhead and latency due extension header ordering. The
introduction of Routing Header type 2 potentially allows there to deleting and
recreating the Binding Cache entry. Since a Binding Request is a
destination option, it may, for example, be included
multiple routing headers in any packet
already being sent to the mobile node, such as a packet that single packet. If this is part the case
the Routing Header type 2 should follow any Routing header of ongoing TCP communication with other
type but otherwise the mobile node. When 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 mobile
node receives a packet from some sender containing a Binding Request
option, it returns a Binding Update option to general procedures defined by IPv6 for Routing
headers suggest that sender, giving its
current binding and a new lifetime.
8.7. Cache Replacement Policy
Conceptually, a node maintains received Routing header MAY be automatically
"reversed" to construct a separate timer Routing header for each entry in its
Binding Cache. When creating or updating a Binding Cache entry use in any response to a received and accepted Binding Update, the node sets the
timer for this entry to
packets sent by upper-layer protocols, if the specified Lifetime period. Any entry in
a node's Binding Cache received packet
is authenticated [6]. This MUST NOT be deleted after the expiration of the done to type 2 routing
headers.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 62] 60]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
Lifetime specified in 22 March 2002
5.5. Mobile IPv6 Destination Option Sub-Options
In order to allow future extensions to the Binding Update from which format of MIPv6
destination options, any of the entry was
created or last updated.
Each node's Binding Cache will, by necessity, have a finite size.
A node Mobile IPv6 destination options
defined in this document MAY use any reasonable local policy for managing include one or more sub-options.
Such sub-options are included in the space
within its Binding Cache, except data portion of the destination
option itself, after the fixed portion of the option data specified
for that any entry marked as a "home
registration" particular destination option (Section 9.1) MUST NOT 5.3). The presence
of such sub-options will be deleted from the cache
until indicated by the expiration of its lifetime period. Option Length field.
When such a "home
registration" entry is deleted, in addition the home agent MUST also
cease intercepting packets on Option Length is greater than the mobile node's home link addressed
to standard length defined
for that destination option, the mobile node (Section 9.3), just remaining octets are interpreted as if
sub-options.
These sub-options are encoded within the mobile node had
deregistered its primary care-of address (see Section 9.2).
When attempting to add a new "home registration" entry in response
to a Binding Update with the Home Registration (H) bit set, if
insufficient space exists (and sufficient remaining space cannot be reclaimed)
in the node's Binding Cache, the node MUST reject the Binding
Update and SHOULD return a Binding Acknowledgement to the sending
mobile node, in which of the Status field is set to 131 (insufficient
resources). When otherwise attempting to add a new entry to its
Binding Cache, a node MAY, if needed, choose to drop any entry
already in its Binding Cache, other than a "home registration"
entry, in order to make space
option data for the new entry. For example, that option, using a
"least-recently used" (LRU) strategy for cache entry replacement
among entries not marked type-length-value (TLV) format
as a "home registration" is likely to
work well unless the size follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type
8-bit identifier of the Binding Cache is substantially
insufficient.
Any binding dropped from a node's Binding Cache due to lack type of cache
space will be rediscovered and a new cache entry created, if the
binding is still in active use by the node for sending packets. If
the node sends a packet to sub-option. When processing
a Mobile IPv6 destination option containing a sub-option for
which it has dropped the
entry from its Binding Cache, the packet will be routed normally,
leading to the mobile node's home link. There, the packet will be
intercepted Sub-Option Type value is not recognized by the mobile node's home agent and tunneled to
receiver, the
mobile node's current primary care-of address. As when a Binding
Cache entry is initially created, this indirect routing to receiver SHOULD quietly ignore and skip over the mobile
node through its home agent will result
sub-option, correctly handling any remaining sub-options in the mobile node sending
a Binding Update to this sending node when it receives
option.
Sub-Option Length
8-bit unsigned integer. Length of the tunneled
packet, allowing it to add an entry again for Sub-Option Data field
of this destination mobile
node to its Binding Cache.
8.8. Receiving ICMP Error Messages
When a correspondent node sends a packet to a mobile node, if the
correspondent node has a Binding Cache entry for sub-option, in octets. The Sub-Option Len does not
include the destination
address length of the packet, then the correspondent node uses Sub-Option Type and Sub-Option Len
fields.
Sub-Option Data
Variable-length field. Sub-Option-Type-specific data.
As with IPv6 options appearing in a Routing Hop-by-Hop Options header
or Destination Options header [6], individual sub-options within
a Mobile IPv6 destination option may have specific alignment
requirements, to deliver the packet to the mobile node through the care-of
address in the binding recorded in ensure that multi-octet values within Sub-Option
Data fields fall on natural boundaries. The alignment requirement
of each sub-option is specified as part of the Binding Cache entry. Any ICMP definition of each
sub-option below.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 63] 61]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
error message caused by the packet on its way to the mobile node will
be returned normally to 22 March 2002
Each section above defining the correspondent node.
On Mobile IPv6 destination options
specifies which of the other hand, if defined sub-options is valid for that
destination option. In addition, there are two padding sub-options,
Pad1 and PadN (defined below), which are used when necessary to align
subsequent sub-options. The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike the correspondent node has padding options
used in Hop-by-Hop Options header or Destination Options header [6],
there is no Binding Cache
entry requirement for padding the mobile node, the packet will be routed total size of any Mobile IPv6
destination option to a multiple of 8 octets in length, and the mobile
node's home link. There, it will
Pad1 and PadN sub-options SHOULD NOT be intercepted used for this purpose. All
Mobile IPv6 sub-options defined in this document MUST be recognized
by all Mobile IPv6 implementations.
5.5.1. Pad1
Pad1 Sub-Option (alignment requirement: none)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! the mobile node's
home agent, encapsulated, and tunneled to the mobile node's primary
care-of address. Any ICMP error message caused by format of the packet on
its way Pad1 sub-option is a special
case -- it has neither Sub-Option Len nor Sub-Option Data
fields.
The Pad1 sub-option is used to insert one octet of padding
into the mobile node while in Sub-Options area of a Mobile IPv6 option. If more
than one octet of padding is required, the tunnel, will PadN sub-option,
described next, should be transmitted used, rather than multiple Pad1
sub-options.
5.5.2. PadN
PadN Sub-Option (alignment requirement: none)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Sub-Option Len| Sub-Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN sub-option is used to the mobile node's home agent (the source insert two or more octets of
padding into the tunnel). By
the definition Sub-Options area of a Mobile IPv6 encapsulation [4], option.
For N octets of padding, the home agent (as Sub-Option Len field contains
the
encapsulating node) MUST relay certain ICMP error messages back
to value N-2, and the original sender Sub-Option Data consists of the packet, which N-2
zero-valued octets.
Johnson and Perkins Expires 22 September 2002 [Page 62]
INTERNET-DRAFT Mobility Support in this case IPv6 22 March 2002
5.6. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is the
correspondent node.
Likewise, if a packet for used by a
mobile node arrives at to initiate the mobile node's
previous link and is intercepted there by a dynamic home agent for the mobile
node's previous care-of address discovery
mechanism, as described in Section 10.10 (e.g.,
the Sections 9.9 and 10.8. The mobile
node moved after sends a Home Agent Address Discovery Request message to the packet was sent), that
"Mobile IPv6 Home-Agents" anycast address for its own home agent
will encapsulate subnet
prefix [11], and tunnel one of the packet home agents there responds to the mobile node's new
care-of address. As above, any ICMP error
node with a Home Agent Address Discovery Reply message caused by giving a list
of the
packet while in this tunnel will be returned to that home agent (the
source of routers on the tunnel), which MUST relay certain mobile node's home link serving as home agents.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
150 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP error messages
back checksum [5].
Identifier
An identifier to the correspondent node [4]. The relayed packet MUST NOT
contain a routing header entry with the care-of address of the mobile
node.
Thus, aid in all cases, any meaningful ICMP error matching Home Agent Address Discovery
Reply messages caused
by packets from a correspondent node to a mobile node will this Home Agent Address Discovery Request
message.
Reserved
This field is unused. It MUST be
returned to the correspondent node. If the correspondent node
receives persistent ICMP Destination Unreachable messages after
sending packets initialized to a mobile node based on an entry in its Binding
Cache, zero by the correspondent node
sender and MUST delete this Binding Cache
entry. If the correspondent node subsequently transmits another
packet to be ignored by the mobile node, receiver.
The Source Address of the Home Agent Address Discovery Request
message packet will MUST be routed to the mobile
node's home link, intercepted by the mobile node's home agent, and
tunneled to one of the mobile node's primary current care-of address using IPv6
encapsulation.
addresses. The mobile node will home agent then MUST return a Binding Update to the correspondent node, allowing it Home Agent Address
Discovery Reply message directly to recreate a (correct) Binding
Cache entry for the mobile node.
8.9. Sending Packets to a Mobile Node
Before sending any packet, Source Address chosen by
the sending mobile node SHOULD examine its
Binding Cache for an entry for Note that, at the destination time of performing this dynamic
home agent address to which the
packet discovery, it is being sent. If the sending node has a Binding Cache entry
for this address, the sending node SHOULD use a Routing header to
route likely that the packet to this mobile node (the destination node) by way
of the care-of address in not
registered with any home agent within the binding recorded in that Binding Cache
entry. For example, assuming use of a Type 0 Routing header [6], if specified anycast group.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 64] 63]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
no other use of a Routing header 22 March 2002
5.7. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is involved in the routing of this
packet, the used by a
home agent to respond to a mobile node sets using the fields dynamic home agent
address discovery mechanism, as described in the packet's IPv6 header Sections 9.9 and Routing header as follows:
- 10.8.
The Destination mobile node sends a Home Agent Address in Discovery Request message
to the packet's "Mobile IPv6 header is set Home-Agents" anycast address for its own home
subnet prefix [11], and one of the home agents there responds to the
mobile node's care-of address copied from the Binding Cache
entry.
- The Routing header is initialized to contain a single route
segment, node with an a Home Agent Address Discovery Reply message giving
a list of the routers on the mobile node's home address (the
original destination address to which the packet was being sent).
Following the definition of a link serving as home
agents.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
151 <To Be Assigned by IANA>
Code
0 Routing header [6], this packet
will be routed to
Checksum
The ICMP checksum [5].
Identifier
The identifier from the mobile node's care-of address, where it will invoking Home Agent Address Discovery
Request message.
Johnson and Perkins Expires 22 September 2002 [Page 64]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
Reserved
This field is unused. It MUST be delivered initialized to zero by the mobile node (the mobile node has associated
sender and MUST be ignored by the
care-of address with its network interface). Normal processing receiver.
Home Agent Addresses
A list of addresses of home agents on the Routing header by home link for the
mobile node will then proceed as follows:
- node. The mobile node swaps the Destination Address number of addresses present in the packet's
IPv6 header and list is
indicated by the Address specified in remaining length of the Routing header.
This results in IPv6 packet carrying
the packet's IP Destination Home Agent Address being set to
the mobile node's home address.
- Discovery Reply message.
Johnson and Perkins Expires 22 September 2002 [Page 65]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
5.8. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node then resubmits the packet
to its IPv6 module for
further processing, "looping back" the packet inside the mobile
node. Since the mobile node recognizes its own home address as
one agent while it is away from home. The purpose of its current IP addresses, the packet
message is processed further
within the mobile node, in to solicit a Mobile Prefix Advertisement from the same way then as if home
agent, which will allow the mobile node was at home.
If, instead, the sending node has no Binding Cache entry for the
destination to gather prefix information
about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [35],
or update address(es) according to which changes in prefix information
supplied by the packet home agent.
The Mobile Prefix Solicitation is being sent, the sending
node simply sends the packet normally, with no Routing header. If similar to the destination node is not a mobile node (or Router Solicitation
used in Neighbor Discovery [20], except it is a routed from the mobile
node that
is currently at home), on the packet will be delivered directly visited network to this
node and processed normally by it. If, however, the destination node
is a mobile node that is currently away from home, home agent on the packet will
be intercepted by the mobile node's home agent and tunneled (using
IPv6 encapsulation [4]) to the network by
usual unicast routing rules.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The mobile node's current primary care-of
address, as described in Section 9.4. address.
Destination Address
The address of the mobile node will then send
a Binding Update to node's home agent. This home agent
must be on the sending node, as described in Section 10.9,
allowing link which the sending mobile node wishes to create a Binding Cache entry for its use
in sending subsequent packets learn
prefix information about.
Hop Limit
Set to an initial hop limit value, and this mobile node.
It message is possible that a correspondent node, having no knowledge
of the mobile node's care-of address, would still (for reasons
unspecified here but not necessarily related to mobility) attempt
to deliver a packet, either routed
according to or by way of the mobile node's home
address, by using rules of a routing header. typical unicast packet. A hop
limit of 64 is currently suggested [32].
Authentication Header
If the correspondent node
subsequently accepts a Binding Update and creates a Binding Cache
entry Security Association for the mobile node, IP Authentication Header
exists between the sender and the destination address, then afterwards, the routing header used
sender SHOULD include this header. [subject to change]
ICMP Fields:
Johnson and Perkins Expires 2 January 22 September 2002 [Page 65] 66]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001 22 March 2002
Type
152 <To Be Assigned by the corresponding node which includes the mobile node's home
address SHOULD also include the mobile node's care-of address. IANA>
Code
0
Checksum
The
correspondent node SHOULD put the mobile node's care-of address as
the intermediate node address immediately preceding the mobile node's
home address. When the care-of address is the first intermediate
node address, this implies that the care-of address ICMP checksum [5].
Reserved
This field is to unused. It MUST be placed
in the Destination Address of initialized to zero by the IPv6 header,
sender and the mobile
node's home address is the first entry in the type 0 routing header.
Otherwise, the correspondent node MUST insert the mobile node's
care-of address immediately before the home address entry in be ignored by the
routing header. receiver.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 66] 67]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
9. Home Agent Operation
9.1. Primary Care-of Address Registration
When a node receives 22 March 2002
5.9. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Binding Update, it MUST validate it and
determine the type of Binding Update according Mobile Prefix Advertisement message to the steps described
in Section 8.2. This section describes the processing of a valid
Binding Update that requests the receiving
mobile node to serve as its home
agent, registering its primary care-of address.
To begin processing the Binding Update, distribute prefix information about the home agent MUST perform
the following sequence of tests:
- If link
while the mobile node is not a router that implements home agent
functionality, then the node MUST reject traveling away from the Binding Update and
SHOULD return home network. This
will occur in response to a Binding Acknowledgement Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according to
the mobile node, rules in
which Section 5.9.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The home agent's address as the Status field mobile node would
expect to see it (i.e. same prefix)
Destination Address
If this message is set a response to 132 (home registration not
supported).
- Else, if the home address for a Mobile Prefix
Solicitation, the binding (the Home Source Address field
in from that
packet. For unsolicited messages, the packet's Home Address option) is not an on-link IPv6 mobile node's
care-of address SHOULD be used, if it is currently
registered with respect to the home agent's current Prefix List,
then agent. Otherwise, the
mobile node's home agent address SHOULD be used.
Authentication Header
This header MUST reject be sent, unless the Binding Update mobile node
has not yet configured, and SHOULD
return a Binding Acknowledgement is using its care-of
address. [subject to the mobile node, change]
ICMP Fields:
Type
153 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Options:
Johnson and Perkins Expires 22 September 2002 [Page 68]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
Prefix Information
Each message contains one or more Prefix Information options,
which contain the
Status field is set to 133 (not home subnet).
- Else, if the home agent chooses to reject prefix(es) the Binding Update for
any other reason (e.g., insufficient resources to serve another mobile node as a home agent), then the should configure
its home agent SHOULD return a
Binding Acknowledgement to the mobile node, in address(es) with. Section 9.7 describes which the Status
field is set to an appropriate value
prefixes should be advertised to indicate the reason for
the rejection.
- Finally, if the Duplicate Address Detection (D) bit mobile node.
The Prefix Information option is set defined in
the Binding Update, Section 4.6.2
of [20], with modifications defined in Section 6.2 of this
specification. The home agent MUST perform Duplicate
Address Detection [27] on use this modified Prefix
Information option to send the mobile node's aggregate list of home link for network
prefixes as defined in Section 9.9.1.
The Mobile Prefix Advertisement sent by the home address in this binding (before returning agent MAY include
the Binding
Acknowledgement). The address used for Duplicate Source Link-layer Address
Detection SHOULD be option defined in RFC 2461 [20], or the mobile node's link-local address. Normal
Advertisement Interval option specified in Section 6.3.
Future versions of this protocol may define new option types. Home
Agents MUST silently ignore any options they do not recognize and
continue processing for Duplicate Address Detection specifies that, the message.
Johnson and Perkins Expires 22 September 2002 [Page 69]
INTERNET-DRAFT Mobility Support in
certain cases, IPv6 22 March 2002
6. Modifications to IPv6 Neighbor Discovery
6.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the node SHOULD delay sending format of the initial Neighbor
Solicitation Router Advertisement
message of Duplicate Address Detection [20] by the addition of a random
delay between 0 and MAX_RTR_SOLICITATION_DELAY [17, 27]; however,
in this case, single flag bit to indicate that
the home agent SHOULD NOT perform such a delay.
If this Duplicate Address Detection fails, then router sending the Advertisement message is serving as a home
agent
MUST reject the Binding Update and SHOULD return a Binding
Acknowledgement to on this link. The format of the mobile node, in which Router Advertisement message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the Status field following changes over that originally
specified for Neighbor Discovery [20]:
Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to 138 (Duplicate Address Detection failed). When
indicate that the router sending this Router Advertisement is
also functioning as a Mobile IP home agent sends on this link.
Reserved
Reduced from a successful Binding Acknowledgement to the mobile
node, in response 6-bit field to a Binding Update with the `D' bit set, the
home agent assures 5-bit field to account for the mobile node that its home address
addition of the Home Agent (H) bit.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 67] 70]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
will continue to be valid at least as long as the mobile node
transmits Binding Updates with new care-of addresses 22 March 2002
6.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address for that two
reasons:
- To allow a home address.
If agent (a router) to learn the address of all
other home agent does not reject agents on the Binding Update, then link for which it becomes
or remains the is providing home
agent service, for use in building its Home Agents List as
part of the mobile node. The dynamic home agent MUST
then create address discovery mechanism
(Sections 9.9 and 10.8).
- To allow a new entry in its Binding Cache for this mobile node (or
update its existing to send a Binding Cache entry Update to a router on
the link on which its previous care-of address is located, for
purposes of establishing forwarding from this mobile node, if such
an entry already exists). The home previous care-of
address of the mobile node is
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
option. The its new care-of address for (Section 10.11).
However, Neighbor Discovery [20] only advertises a router's
link-local address, by requiring this Binding Cache entry is taken address to be used as the value which, when the packet was originally received, was
located either in the Alternate Care-of Address sub-option in the
Binding Update option, if present, or from the IP
Source Address field
in the packet's of each Router Advertisement.
Mobile IPv6 header, otherwise.
The home agent MUST mark this Binding Cache entry as extends Neighbor Discovery to allow a "home
registration" router to indicate that easily
and efficiently advertise its global address, by the node is serving as addition of a home
agent for this binding. Binding Cache entries marked as a "home
registration" MUST be excluded from
single flag bit in the normal cache replacement
policy used format of a Prefix Information option for the Binding Cache (Section 8.7) and MUST NOT be
removed from the Binding Cache until the expiration
use in Router Advertisement messages. The format of the Prefix
Information option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime
period.
The lifetime for the Binding Cache entry MUST NOT be greater than |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the
remaining valid lifetime following changes over that originally
specified for Neighbor Discovery [20]:
Johnson and Perkins Expires 22 September 2002 [Page 71]
INTERNET-DRAFT Mobility Support in IPv6 22 March 2002
Router Address (R)
1-bit router address flag. When set, indicates that the subnet prefix
Prefix field, in addition to advertising the mobile node's
home indicated prefix,
contains a complete IP address specified with assigned to the Binding Update, sending router.
This router IP address has the same scope and MUST NOT be
greater than conforms to the Lifetime value specified
same lifetime values as the advertised prefix. This use of
the Prefix field is compatible with its use in advertising
the Binding Update. The
remaining valid lifetime for this prefix is determined itself, since prefix advertisement uses only the
leading number Prefix bits specified by the home
agent based on its own Prefix List entry for Length
field. Interpretation of this prefix [17].
If the `S' flag bit field in the Binding Update is zero, The Home Agent
creates or updates Binding Cache entries for each of possible
several home addresses. The set thus independent
of such home addresses is formed
by replacing the routing prefix for the given home address with
all other routing prefixes that are supported by the home agent processing required for the Binding Update. The Home Agent creates such On-Link (L) and Autonomous
Address-Configuration (A) flag bits.
Reserved1
Reduced from a
separate primary care-of address registration 6-bit field to a 5-bit field to account for each such home
address. Note that the same considerations for Duplicate
addition of the Router Address
Detection apply for each affected (R) bit.
In a solicited Router Advertisement, a home address. The lifetime for
the each Binding Cache entry MUST NOT be greater than the minimum
remaining valid lifetime for agent MUST, and all subnet prefixes on the mobile
node's home link. If the value of the Lifetime field specified by other
routers SHOULD, include at least one Prefix Information option with
the mobile node Router Address (R) bit set. Neighbor Discovery specifies that,
if including all options in its Binding Update is greater than this prefix
lifetime, a Router Advertisement causes the home agent MUST decrease size of
the binding lifetime to less
than or equal Advertisement to exceed the prefix valid lifetime. The home agent MAY
further decrease the specified lifetime for link MTU, multiple Advertisements can
be sent, each containing a subset of the binding, for example
based on options [20]. In this case,
at least one of these multiple Advertisements being sent instead
of a local policy. The resulting lifetime is stored by single larger solicited Advertisement, MUST include a Prefix
Information option with the
home agent Router Address (R) bit set.
All routers SHOULD include at least one Prefix Information option
with the Router Address (R) bit set, in each unsolicited multicast
Router Advertisement that they send. If multiple Advertisements
are being sent instead of a single larger unsolicited multicast
Advertisement, at least one of these multiple Advertisements SHOULD
include a Prefix Information option with the Binding Cache entry, and this Binding Cache entry Router Address (R) bit
set.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 68] 72]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
MUST be deleted by 22 March 2002
6.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the home agent after interval at which the expiration of this
lifetime.
Regardless
sending router sends unsolicited multicast Router Advertisements.
The format of the setting Advertisement Interval option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
8-bit unsigned integer. The length of the 'A' bit in the Binding Update, the
home agent MUST return a Binding Acknowledgement to option (including
the mobile node,
constructed as follows:
- type and length fields) in units of 8 octets. The Status field MUST be set to a value indicating success; of
this
value MUST be less than 128. The only currently defined success
Status value is 0, indicating simply that the Binding Update was
accepted.
- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.
- The Lifetime 1.
Reserved
This field is unused. It MUST be set initialized to zero by the remaining lifetime for
the binding as set
sender and MUST be ignored by the home agent receiver.
Advertisement Interval
32-bit unsigned integer. The maximum time, in its "home registration"
Binding Cache entry for milliseconds,
between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using
the mobile node, as described above.
- The Refresh conceptual router configuration variables defined by
Neighbor Discovery [20], this field MUST be set to a value less than or equal to the Lifetime value being returned in the Binding Update. If the
home agent stores the Binding Cache entry
MaxRtrAdvInterval, expressed in nonvolatile storage
(that survives the crash or other failure of the home agent),
then the Refresh field SHOULD be set to the same value as the
Lifetime field; otherwise, the home agent milliseconds.
Routers MAY set the Refresh
field to a value less than the Lifetime field, to indicate that
the include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option
SHOULD attempt to refresh its home registration
at the indicated shorter interval (although the home agent will
still retain utilize the registration for the Lifetime period, even if
the mobile node does not refresh its registration within the
Refresh period).
In addition, the home agent MUST follow the procedure defined specified Advertisement Interval for that router
in
Section 9.3 to intercept packets on the mobile node's home link
addressed to the mobile node, while the home agent is serving its movement detection algorithm, as the
home agent for this mobile node.
9.2. Primary Care-of Address De-registration
When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described in Section 8.2. 10.4.
This section describes the processing of a valid
Binding Update that requests the receiving node to no longer serve as
its home agent, de-registering its primary care-of address.
To begin processing the Binding Update, the home agent option MUST perform
the following test:
- If the receiving node has no entry in its Binding Cache be silently ignored for this
mobile node that is marked as a "home registration", then this other Neighbor Discovery
messages.
Johnson and Perkins Expires 2 January 22 September 2002 [Page 69] 73]
INTERNET-DRAFT Mobility Support in IPv6 2 July 2001
node MUST reject the Binding Update and SHOULD return 22 March 2002
6.4. New Home Agent Information Option Format
Mobile IPv6 defines a Binding
Acknowledgement to the mobile node, new Home Agent Information option, used in which the Status field is
set to 137 (not home agent for this mobile node).
If the
Router Advertisement messages sent by a home agent does not reject the Binding Update as described
above, then it MUST delete any existing entry in its Binding Cache
for to advertise
information specific to this mobile node, and proceed router's functionality as follows.
The home agent MUST return a Binding Acknowledgement to home agent.
The format of the mobile
node, constructed Home Agent Information option is as follows:
- The Status field MUST be set to a value indicating success (the
value MUST be less than 128).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent P