view Side-By-Side changes
IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Rice University
Charles E. Perkins
Nokia Research Center
Jari Arkko
Ericsson
1 May June 2002
Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-17.txt>
<draft-ietf-mobileip-ipv6-18.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.
This document specifies the operation of the IPv6 Internet with mobile computers using IPv6.
computers. 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 a
new IPv6 protocol and a new destination option. All IPv6 nodes,
whether mobile or stationary, MUST support communications with mobile
nodes.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page i]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Comparison with Mobile IP for IPv4 2
3. Terminology 4 3
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5 3
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 6 4
4. Overview of Mobile IPv6 9 7
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 7
4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 12 9
4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13 10
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14 10
4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 15
4.6. Binding Management . . . . . . . . . . . . . . . . . . . 16 11
5. Overview of Mobile IPv6 Security 17 12
5.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Tunnels to and from the Home Agents . . . . . . . . . . . 20
5.4. Binding Updates to Home Agents . . . . . . . . . . . . . 20
5.5. 12
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 21
5.5.1. 12
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 22
5.5.2. 13
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 23
5.5.3. 13
5.2.3. Cookies . . . . . . . . . . . . . . . . . . . . . 23
5.5.4. 14
5.2.4. Cryptographic Functions . . . . . . . . . . . . . 24
5.5.5. 14
5.2.5. Return Routability Procedure . . . . . . . . . . 24
5.5.6. 14
5.2.6. Applying Return Routability for Correspondent
Bindings . . . . . . . . . . . . . . . . . 28
5.5.7. 18
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 29
5.5.8. 20
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 30
5.5.9. Preventing Denial-of-Service Attacks 20
5.3. Payload Packets . . . . . . . . . . . . . . 30
5.5.10. Correspondent Binding Procedure Extensibility . . 31 . . . . . 21
6. New IPv6 Protocols, Message Types, and Destination Option 31 21
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31 21
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32 22
6.1.2. Binding Refresh Request (BRR) Message . . . . . . 33 23
6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34 24
6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 36 26
6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 37 27
6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 39
Johnson, Perkins, Arkko Expires 1 November 2002 [Page ii]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 28
6.1.7. Binding Update (BU) Message . . . . . . . . . . . 41 29
6.1.8. Binding Acknowledgement (BA) Message . . . . . . 45 32
6.1.9. Binding Error (BE) Message . . . . . . . . . . . 49 34
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 51 35
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51 35
Johnson, Perkins, Arkko Expires 1 December 2002 [Page ii]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52 36
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52 37
6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53 37
6.2.5. Alternate Care-of Address . . . . . . . . . . . . 53 38
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54 38
6.2.7. Binding Authorization Data . . . . . . . . . . . 54 39
6.2.8. Binding Refresh Advice . . . . . . . . . . . . . 39
6.3. Home Address Destination Option . . . . . . . . . . . . . 55 40
6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58 42
6.4.1. Routing Header Packet format . . . . . . . . . . 58 42
6.5. ICMP Home Agent Address Discovery Request Message . . . . 59 43
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 61 45
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 63 47
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 65 49
7. Modifications to IPv6 Neighbor Discovery 67 51
7.1. Modified Router Advertisement Message Format . . . . . . 67 51
7.2. Modified Prefix Information Option Format . . . . . . . . 68 52
7.3. New Advertisement Interval Option Format . . . . . . . . 70 54
7.4. New Home Agent Information Option Format . . . . . . . . 71 55
7.5. Changes to Sending Router Advertisements . . . . . . . . 73 57
7.6. Changes to Sending Router Solicitations . . . . . . . . . 74 58
8. Requirements for Types of IPv6 Nodes 75 59
8.1. General Requirements for All IPv6 Hosts and Routers Nodes . . . . . . . 75 . . 59
8.2. Route Optimization Requirements for All IPv6 Nodes . . . 59
8.3. Requirements for All IPv6 Routers . . . . . . . . . . . . 75
8.3. 60
8.4. Requirements for IPv6 Home Agents . . . . . . . . . . . . 76
8.4. 61
8.5. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 77 62
9. Correspondent Node Operation 78 63
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 78 63
9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 79 64
9.2.1. Processing Mobility Header (MH) Messages . . . . 79 64
9.2.2. Receiving Packets with Home Address Destination
Option . . . . . . . . . . . . . . . . . . 80 65
9.3. Return Routability Procedure . . . . . . . . . . . . . . 80 66
9.3.1. Receiving HoTI Home Test Init Messages . . . . . . . . . . . . . 81 66
9.3.2. Receiving CoTI Care-of Test Init Messages . . . . . . . . . . . . . 81 66
9.3.3. Sending HoT Home Test Messages . . . . . . . . . . . . . . 82 67
9.3.4. Sending CoT Care-of Test Messages . . . . . . . . . . . . . . 82 67
9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 82 67
9.4.1. Receiving Binding Updates . . . . . . . . . . . . 82 67
9.4.2. Requests to Cache a Binding . . . . . . . . . . . 84 69
9.4.3. Requests to Delete a Binding . . . . . . . . . . 84 69
9.4.4. Sending Binding Acknowledgements . . . . . . . . 85 70
9.4.5. Sending Binding Refresh Requests . . . . . . . . 86 71
9.4.6. Sending Binding Error Messages . . . . . . . . . 87
Johnson, Perkins, Arkko Expires 1 November 2002 [Page iii]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 71
9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 87 71
9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 88 72
9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 89 73
Johnson, Perkins, Arkko Expires 1 December 2002 [Page iii]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
10. Home Agent Operation 90 74
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 90 74
10.2. Primary Care-of Address Registration . . . . . . . . . . 91 75
10.3. Primary Care-of Address De-Registration . . . . . . . . . 94 79
10.4. Intercepting Packets for a Mobile Node . . . . . . . . . 95 80
10.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 97 81
10.6. Handling Reverse Tunneled Packets from a Mobile Node . . 98 83
10.7. Protecting Return Routability Packets . . . . . . . . . . 99 83
10.8. Receiving Router Advertisement Messages . . . . . . . . . 99 84
10.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 101 85
10.9.1. Aggregate List of Home Network Prefixes . . . . . 102 87
10.9.2. Scheduling Prefix Deliveries to the Mobile Node . 104 89
10.9.3. Sending Advertisements to the Mobile Node . . . . 106 90
10.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 107 91
11. Mobile Node Operation 107 91
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 107 91
11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 110 93
11.2.1. Sending Packets While Away from Home . . . . . . 110 93
11.2.2. Interaction with Outbound IPsec Processing . . . 112 96
11.2.3. Receiving Packets While Away from Home . . . . . 114 97
11.2.4. Routing Multicast Packets . . . . . . . . . . . . 116 99
11.3. Home Agent and Prefix Management . . . . . . . . . . . . 116 100
11.3.1. Receiving Local Router Advertisement Messages . . 116 100
11.3.2. Dynamic Home Agent Address Discovery . . . . . . 118 101
11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 119 102
11.3.4. Receiving Mobile Prefix Advertisements . . . . . 120 103
11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 121 104
11.4.1. Movement Detection . . . . . . . . . . . . . . . 121 104
11.4.2. Forming New Care-of Addresses . . . . . . . . . . 124 107
11.4.3. Using Multiple Care-of Addresses . . . . . . . . 125 108
11.5. Return Routability Procedure . . . . . . . . . . . . . . 126 109
11.5.1. Sending Home and Care-of Test Init Messages . . . 126 109
11.5.2. Receiving Return Routability Messages . . . . . . 126 109
11.5.3. Retransmitting in the Return Routability Procedure 128 111
11.5.4. Rate Limiting for Return Routability Procedure . 128 111
11.6. Processing Bindings . . . . . . . . . . . . . . . . . . . 128 111
11.6.1. Sending Binding Updates to the Home Agent . . . . 128 111
11.6.2. Correspondent Binding Procedure . . . . . . . . . 130 114
11.6.3. Receiving Binding Acknowledgements . . . . . . . 133 117
11.6.4. Receiving Binding Refresh Requests . . . . . . . 134 118
11.6.5. Receiving Binding Error Messages . . . . . . . . 135 119
11.6.6. Forwarding from a Previous Care-of Address . . . 136 120
11.6.7. Returning Home . . . . . . . . . . . . . . . . . 137 121
11.6.8. Retransmitting Binding Updates . . . . . . . . . 139 123
11.6.9. Rate Limiting Binding Updates . . . . . . . . . . 140 124
11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 140 124
12. Protocol Constants 125
13. IANA Considerations 126
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page iv]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
12. Protocol Constants 141
13. IANA Considerations 142
14. Security Considerations 143 127
14.1. Security for the Tunneling to and from the Home Agent Threats . . 143
14.2. Security for the Binding Updates to the Home Agent . . . 144
14.3. Security for the Binding Updates to the Correspondent
Nodes . . . . . . . . . . . . . . . . . . . . 127
14.2. Features . . . . 144
14.4. Security for the Home Address Destination Option . . . . 145
14.5. Firewall considerations . . . . . . . . . . . . . . . . 129
14.3. Binding Updates to Home Agent . 145 . . . . . . . . . . . . . 130
14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 132
14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 132
14.4.2. Offered Protection . . . . . . . . . . . . . . . 132
14.4.3. Comparison to Regular IPv6 Communications . . . . 133
14.4.4. Return Routability Replays . . . . . . . . . . . 135
14.4.5. Return Routability Denial-of-Service . . . . . . 135
14.5. Tunneling via the Home Agent . . . . . . . . . . . . . . 136
14.6. Home Address Destination Option . . . . . . . . . . . . . 137
14.7. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 138
Acknowledgements 146 138
References 147 140
A. State Machine for the Correspondent Binding Procedure 150
B. Changes from Previous Version of the Draft 159
B.1. Changes from Draft Version 16 . . 142
A.1. Main State Machine . . . . . . . . . . . . 159
B.2. Changes from Draft Version 15 . . . . . . . 143
A.2. Return Routability Procedure . . . . . . . 161
B.3. Changes from Earlier Versions of the Draft . . . . . . . 162 149
B. Changes from Previous Version of the Draft 153
C. Remote Home Address Configuration 164
D. Future Extensions 165
D.1. 154
C.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 165
D.2. 154
C.2. Triangular Routing and Unverified Home Addresses . . . . 166
D.3. 154
C.3. New Authorization Methods beyond Return Routability . . . 166 155
C.4. Security and Dynamically Generated Home Addresses . . . . 155
C.5. Remote Home Address Configuration . . . . . . . . . . . . 155
Chairs' Addresses 167 157
Authors' Addresses 167 157
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page v]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
1. Introduction
This document specifies how the operation of mobile computers using IPv6 Internet Protocol Version 6 (IPv6) [6]. operates with mobile
computers. Without specific support for mobility in IPv6, IPv6 [11],
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. link. 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 defined in this document, 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 Internet. The mobile node may
also 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, Perkins, Arkko Expires 1 November 2002 [Page 1]
INTERNET-DRAFT Mobility Support in IPv6 1 May 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 IP 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 (but
see Section 11.4.1).
- Access control on a link being visited by a mobile node.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 1]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- Local or hierarchical forms of mobility management (similar to
many current link-layer mobility management solutions).
- Assistance for adaptive applications
- Mobile routers
- Service Discovery
- Distinguishing between packets lost due to bit errors vs.
network congestion
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) [25, 24, 26], [20, 21, 22], 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. improvements. This section summarizes the major differences
between Mobile IPv4 and Mobile IPv6:
- 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, to operate in any
location without any special support required from the local
router.
- Support for what is known in Mobile IPv4 as "Route
Optimization" [27] "route
optimization" [23] 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 [25]. The Mobile IPv4
"registration" functionality and the
- Mobile IPv4 Route
Optimization functionality are performed by IPv6 route optimization can operate securely even without
pre-arranged security associations. It is expected that route
optimization can be deployed on a single protocol
rather than two separate (and different) protocols. global scale between all mobile
nodes and correspondent nodes.
- Support is also integrated into Mobile IPv6 -- and into IPv6
itself -- for allowing Route Optimization route
optimization to coexist efficiently with routers that perform
"ingress filtering" [7]. A mobile
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 2]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
node uses its [24]. Both the current care-of address as and
the Source Address home address can be carried in the
IP header of packets it sends, packets, 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 or stationary, whether
host or router.
- 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 In Mobile IPv4, IPv6, the mobile node
had does not have 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 agent. The inclusion of the Home Address option
allows the home address to be used but still be in
packets is compatible with 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
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 2]
INTERNET-DRAFT Mobility Support in Mobile IPv4. In Mobile IPv6,
mobile nodes make use of IPv6 features, such as Neighbor
Discovery [20] and Address Autoconfiguration [33], to operate in
any location away from home without any special support required
from the local router. 1 June 2002
- 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. location.
- 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 reducing the amount of resulting overhead compared
to Mobile IPv4 must use encapsulation for all
packets. IPv4.
- Mobile IPv6 is decoupled from any particular link layer, as it
uses IPv6 Neighbor Discovery [12] instead of ARP. This also
improves the robustness of the protocol.
- The use of a Routing header requires less additional
header bytes to be added to IPv6 encapsulation (and the packet, reducing Routing header) removes
the overhead
of Mobile IP packet delivery. To avoid modifying the packet in
flight, however, packets intercepted and tunneled by a mobile
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 3]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
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 [20] rather than ARP [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 decouples Mobile IP from any
particular link layer, unlike in ARP.
- The use of IPv6 encapsulation (and the Routing header) removes
the need in 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
messages from within the tunnel back to the original sender of
the packet. state".
- The dynamic home agent address discovery mechanism in Mobile IPv6
uses IPv6 anycast [11] and
returns a single reply to the mobile
node, rather than the corresponding Mobile IPv4 mechanism that
uses IPv4 node. The directed
broadcast and approach used in IPv4 returns a separate reply replies 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 has to be sent back to the mobile node.
- Mobile IPv6 defines an Advertisement Interval option for
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.
- The return routability procedure (see section 5.5) provides a
way to verify the that a mobile node is reachable at its claimed
home address and at its claimed care-of address. This allows
correspondent nodes to verify the authority of the Binding
Updates sent to it. Given that the return routability procedure
is light-weight and does not require participation in a security
infrastructure, it is expected that Route Optimization can
be deployed on a global scale between all mobile nodes and
correspondent nodes. agent.
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].
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 4]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 [2].
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.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 3]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
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.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 5]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
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).
security policy database
A database of rules that describe what security
associations should be applied for different kinds
of packets.
destination option Destination options are carried by the IPv6
Destination Options extension header. Mobile IPv6
defines one new destination option, the Home Address
destination option.
3.2. Mobile IPv6 Terms
home address An IP address assigned to a mobile node, used as the
permanent address of the mobile node. This address
is within the mobile node's home link. Standard IP
routing mechanisms will deliver packets destined for
a mobile node's home address to 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.
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
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 4]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
node is not currently attached to its home link, the
mobile node is said to be "away from home".
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 6]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
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.
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 any given time (e.g., with different subnet
prefixes), the one registered with the mobile node's
home agent is called its "primary" care-of address.
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.
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 procedure
A binding procedure is initiated by the mobile node
to inform either a correspondent node or the mobile
node's home agent of the current binding of the
mobile node.
binding authorization
Binding procedure needs to be authorized to allow
the recipient to believe that the sender has the
right to specify a new binding.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 7]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
return routability procedure
The return routability procedure authorizes binding
procedures by the use of a cryptographic cookie
exchange.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 5]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
correspondent binding procedure
A return routability procedure followed by a
binding procedure, run between the mobile node and a
correspondent node.
home binding procedure
A binding procedure between the mobile node and its
home agent, authorized by the use of IPsec.
nonce Nonces are random numbers used internally by the
correspondent node in the creation of cookies
related to the return routability procedure. The
nonces are not specific to a mobile node, and are
kept secret within the correspondent node, only used
as one input in the creation of the cookies.
cookie Cookies are numbers that are used by mobile nodes
and correspondent nodes in the return routability
procedure.
care-of cookie
A cookie sent directly to the mobile node's claimed
care-of address from the correspondent node.
home cookie A cookie sent to the mobile node's claimed home
address from the correspondent node.
mobile cookie
A cookie sent to the correspondent node from the
mobile node, and later returned to the mobile node.
Mobile cookies are produced randomly.
nonce index
The There are two
kinds of mobile cookies: the HoT cookie and the CoT
cookie.
CoT cookie
A cookie sent by the mobile node uses a particular set of cookies to the the
correspondent node in the return
routability procedure. The cookies have been produced using a
particular CoTI message, to be
returned to the mobile node in the CoT message.
HoT cookie
A cookie sent by the mobile node to the the
correspondent node in the HoTI message, to be
returned to the mobile node in the HoT message.
nonce index
The mobile node uses a particular set of cookies in
the return routability procedure. The cookies have
been produced using a particular set of nonces. A
nonce index is used to indicate which nonces have
been used, without revealing the nonces themselves.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 8] 6]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
binding key
a key used for authenticating binding cache
management messages.
binding security association
a security association established specifically
for the purpose of producing and verifying
authentication data passed with a Binding
Authorization Data option.
4. Overview of Mobile IPv6
4.1. Basic Operation
A mobile node is always addressable at its home address, whether it
is currently attached to its home link or is away from home. While
a mobile node is at home, packets addressed to its home address
are routed to it using conventional Internet routing mechanisms in
the same way as if the node were stationary. Since the The subnet prefix of
a mobile node's home address is one of the subnet prefixes of the
mobile node's home link, packets link. Packets addressed to the mobile node will
therefore be routed to its home link.
While a mobile node is attached to some foreign link away from home,
it is also addressable at one or more care-of addresses, in addition
to its home address. addresses. A care-of
address is an IP address associated with a mobile node while visiting
a particular foreign link. The subnet prefix of a mobile node's
care-of address is one of the subnet prefixes on the foreign link being visited by the mobile node; if link.
As long as the mobile node is connected to stays in this foreign link while using that
care-of address, location, packets addressed
to this care-of address will be routed to the mobile node in its location away from home. node.
The association between a mobile node's home address and care-of
address is known as a "binding" for the mobile node. A mobile node
typically acquires its care-of address through stateless [33] [13] or
stateful (e.g., DHCPv6 [2]) [25]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [20]. [12]. 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. The operation of the mobile node is
specified in Section 11.
While away from home, a mobile node registers one of its care-of
addresses with a router on its home link, requesting this router to
function as the "home agent" for the mobile node. The mobile node
performs this binding registration by sending a "Binding Update"
message to the home agent; the agent. The home agent then replies to the mobile
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 9]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
node by returning a "Binding Acknowledgement" message. The care-of
address associated with this binding registration is known as 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 to the mobile node's home address (or home
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 7]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
addresses) on the home link, and tunnels each link. Each intercepted packet is tunneled
to the mobile node's primary care-of address. To tunnel each
intercepted packet, the home agent encapsulates the packet This tunneling
is performed using IPv6 encapsulation [4], [15], with the outer IPv6
header addressed to the mobile node's primary care-of address. The
operation of the home agent is specified in Section 10.
The Binding Update and Binding Acknowledgement messages, together
with a "Binding Refresh Request" message, are also used to allow IPv6
nodes
Any node communicating with a mobile node are capable is referred to in this
document as a "correspondent node" of dynamically
learning the mobile node, and caching may itself
be either a stationary node or a mobile node. The operation of the
correspondent node is specified in Section 9. Mobile nodes can
inform the correspondent nodes of the current location of the mobile node's binding.
node. This happens through the correspondent binding procedure which involves procedure. As
a part of this procedure, a return routability test is performed
in order to authorize the establishment of the
binding, as binding. This is
specified in Sections 5.5.5 5.2.5 and 5.5.6. 5.2.6. When sending a packet to
any IPv6 destination, a node checks its cached bindings for an
entry for the packet's destination address. If a cached binding
for this destination address is found, the node uses a new type of
IPv6 Routing header [6] [11] (see section 6.4) to route the packet to
the mobile node by way of the care-of address indicated in this
binding. If, instead, the sending node has no cached binding for
this destination address, the node sends the packet normally (with
no Routing header), and the packet is subsequently intercepted and
tunneled by the mobile node's home agent as described above. Any
node communicating with When a
mobile node is referred receives a packet tunneled to it in this document manner, it can
use this as a "correspondent node" of an indication that the correspondent node has no binding
for the mobile node, and may itself be
either a stationary node. The mobile node or can then establish a binding
with the correspondent node.
It is expected that correspondent nodes usually will route packets
directly to the mobile node's care-of address, so that the home agent
is rarely involved with packet transmission to the mobile node. The operation This
is important for scalability and reliability, and for minimizing
overall network load. 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, the impact of any possible failure
of the
correspondent node home agent, the home link, or intervening networks leading to
or from the home link is specified reduced, since these nodes and links are not
involved in Section 9. the delivery of most packets to the mobile node.
Mobile IPv6 also defines one additional a new IPv6 destination option. When a mobile
node sends a packet while away from home, it could generally use
a tunnel via the home agent to send this packet. However, if the
correspondent node in question has a binding for this mobile node,
the mobile node it can use deliver packets more directly. In this case directly to the correspondent
node. The mobile node can sets the Source Address in the packet's IPv6
header to one of its current care-of addresses, and include a "Home
Address" destination option in the packet, giving the mobile node's
home address. Many routers implement security policies such as "ingress
filtering" [7] that do not allow forwarding of packets having a
Source Address that appears topologically incorrect. By using the
care-of address as the IPv6 header Source Address, the packet will
be able to pass normally through such routers, and ingress filtering
rules will still be able to locate the true topological source of
the packet in the same way as packets from non-mobile nodes. By
also including also including the Home Address destination 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 packet. This makes
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 10] 8]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
the use of the care-of address to be transparent above the Mobile IPv6
support level (e.g., at the transport layer). The inclusion of a Home Address
destination option in a packet affects only the 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
destination option in a packet.
It is possible that while a mobile node is away from home, some nodes
on its home link may be reconfigured, such that the reconfigured. The router that was operating
as the mobile node's home agent is can be replaced by a different
router serving this the same role. In this case, the mobile node may not
know the IP address of its own home agent. Mobile IPv6 provides a
mechanism, known as "dynamic home agent address discovery", that
allows a mobile node to dynamically discover the IP address of a
home agent on its home link with which it may register its (primary)
care-of address while away from home. The mobile node sends an ICMP
"Home Agent Address Discovery Request" message to the "Mobile IPv6
Home-Agents" anycast address for its own home subnet prefix [11] [16] and
thus reaches one of the 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, including a list
of home agents on the home link. This procedure is specified in
Sections 10.9 and 11.3.2.
When a mobile node moves from one care-of address arrives to a new care-of
address on link and allocates a new link, care-of
address, it is desirable for packets arriving at the previous care-of
address to be tunneled to still reach the mobile node's
new care-of address. Since the purpose of a Binding Update is
to establish exactly this kind of tunneling, it can be used (at
least temporarily) for tunnels originating node. The mobile node may still
accept packets at the mobile node's previous care-of address, in exactly the same way that if it is used
for establishing tunnels from the mobile node's home address still attached to
the
mobile node's current care-of address. Section 11.6.6 describes the
use of previous link as well as the Binding Update for this purpose. new one. This is discussed in
Section 11.4.3 discusses 11.4.3. If the reasons why it may be desirable for a mobile node is no longer attached to use more than one care-of address at the same time.
However, a mobile node's primary care-of address is distinct among
these
previous link, procedures described in that the home agent maintains only a single care-of address
registered for each home address belonging to a mobile node, and
always tunnels packets sent Section 11.6.6 may be used to a mobile node's home address and
intercepted
establish temporary tunneling from its home link to this mobile node's registered
primary care-of address. The home agent thus need not implement any
policy to 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.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 11]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 previous link.
4.2. New IPv6 Protocols
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
(see Section 6.1). This Header is used to carry the following
messages:
Home Test Init
The
Home Test
Care-of Test Init message is
Care-of Test
These four messages are used to initiate the return routability
procedure from the mobile node to a correspondent node. This procedure
ensures that authorization of subsequent Binding Updates Updates, as
described in Section 5.2.5. The format of the messages are properly authorized
defined in Sections 6.1.3 through 6.1.6.
Binding Update
A Binding Update message is used by a mobile node to redirect notify
a correspondent node or the traffic mobile node's home agent of a particular its
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 9]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
current binding. The Binding Update sent to the mobile node's
home address. agent to register its primary care-of address is marked as
a "home registration". The Home Test Init Binding Update message is described
in detail in Section 6.1.3.
Care-of Test Init
The Care-of Test Init 6.1.7.
Binding Acknowledgement
A Binding Acknowledgement message is used to initiate the
correspondent routability procedure, for acknowledge
receipt of a particular care-of
address. Binding Update, if an acknowledgement was
requested in the Binding Update. The Care-of Test Init Binding Acknowledgement
message is described in detail in Section 6.1.4.
Home Test
The Home Test message carries a cookie which the mobile node
needs before it can properly authorize itself for sending a
Binding Update. This message is sent in reply to the Home Test
Init message, and is described in detail in Section 6.1.5.
Care-of Test
The Care-of Test message carries another cookie which the
mobile node needs before it can properly authorize itself for
sending a Binding Update. This message is sent in reply to
the Care-of Test Init message, and is described in detail in
Section 6.1.6.
Binding Update
A Binding Update message is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked
as a "home registration". The Binding Update message and its
specific authentication requirements are described in detail in
Section 6.1.7.
Binding Acknowledgement
A Binding Acknowledgement message is used to acknowledge
receipt of a Binding Update, if an acknowledgement was
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 12]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
requested in the Binding Update. The Binding Acknowledgement
message and its specific authentication requirements are
described in detail in Section 6.1.8.
Binding Refresh Request
A Binding Refresh Request message is used to request that a mobile
node send to re-establish its binding with the requesting node a Binding Update
containing the mobile node's current binding. correspondent node.
This message is typically used by a correspondent node to refresh a cached
binding for a mobile node, when the cached binding is in
active use but the binding's lifetime is close to expiration.
The correspondent node may use, for instance, recent traffic
and open transport layer connections as an indication of active
use. The Binding Refresh Request message is described in
detail in Section 6.1.2.
No authentication is required for the Binding Refresh Request
message.
Binding Error
The Binding Error message is used by the correspondent node to
signal an error related to mobility, such as an inappropriate
attempt to use the Home Address destination option without
an existing binding. This message is described in detail in
Section 6.1.9.
4.3. New IPv6 Destination Options
Mobile IPv6 defines a new IPv6 destination option, the Home
Address destination option. This 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 above the
Mobile IPv6 support level. 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 6.3 and 11.2.2 for additional details about requirements
for the calculation and verification of the authentication data.
The Home Address destination option is described in detail in
Section 6.3.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 13]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
4.4. 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 Request, described in Section 6.5.
- Home Agent Address Discovery Request Reply, described in Section 6.6.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 10]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The next two message is types are used
by a mobile node to initiate the dynamic home agent for network renumbering
and address
discovery mechanism. When attempting a home registration, the
mobile node may use this mechanism to discover the address of
one or more routers currently operating as home agents on its
home link, with which it may register while away from home.
The Home Agent Address Discovery Request message is described
in detail in Section 6.5.
Home Agent Address Discovery Reply
The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is
described in detail in Section 6.6.
The next two message types are used for network renumbering
and address configuration on configuration on the mobile node, as described in
Section 10.9.1:
- Mobile Prefix Solicitation
The ICMP Mobile Prefix Solicitation message is used by a mobile
node to request prefix information about the home subnet, in
order to retrieve prefixes that are served by home agents and
can be used to configure one or more home addresses, or to
refresh home addresses before the expiration of their validity.
This message is specified Solicitation, described in Section 6.7.
- Mobile Prefix Advertisement
The ICMP Mobile Prefix Advertisement is used by a home agent
to distribute information to a mobile node about prefixes on
the home link which are available for use by the mobile node
while away from home. This message may be sent as a response
to a Mobile Prefix Solicitation, or due to network renumbering
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 14]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
or other prefix changes. This message is specified Advertisement, described in Section Section 10.9.3.
4.5. Conceptual Data Structures
This document describes the Mobile IPv6 protocol in terms of the
following three conceptual data structures:
Binding Cache
A cache, maintained by each IPv6 node, of bindings for other
nodes. A separate Binding Cache is maintained by each IPv6
node for each of its IPv6 addresses. When sending a packet,
the Binding Cache is searched before the Neighbor Discovery
conceptual Destination Cache [20]. [12].
The Binding Cache for any one of a node's IPv6 addresses may
contain at most one entry for each mobile node home address.
The contents of all of a node's Binding Cache entries are
cleared when it reboots.
Binding Cache entries are marked either as "home registration"
entries or "correspondent registration" entries. Home
registration entries are deleted when its binding lifetime
expires, while other entries may be replaced at any time
through a local cache replacement policy.
Binding Update List
A list, maintained by each mobile node, recording information
for each Binding Update sent by 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: those to correspondent nodes, those to the mobile node's
home agent, and those to a home agent on the link on which the
mobile node's previous care-of address is located.
Home Agents List
A list, maintained by each home agent and each mobile node,
recording information about each home agent from which this
node has recently received recent a Router Advertisement in which the
Home Agent (H) bit is set. The home agents This list is thus similar to the Default
Router List conceptual data structure maintained by each host
for Neighbor Discovery [20]. [12].
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 11]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Each home agent maintains a separate Home Agents List for each
link on which it is serving as a home agent; this list is used
by a home agent in the dynamic home agent address discovery
mechanism. Each mobile node, while away from home, also
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 15]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
maintains a Home Agents List, to enable it to notify a home
agent on its previous link when it moves to a new link.
4.6. Binding Management
When a mobile node configures
5. Overview of Mobile IPv6 Security
This specification provides a new care-of number of security features. These
include the protection of Binding Updates both to home agents and
correspondent nodes, and the protection of tunnels, home address
information, and decides routing instructions in data packets.
5.1. Binding Updates to
use this new address as its primary care-of address, Home Agents
Signaling between the mobile node registers this new binding with its home agent by sending and the home agent a Binding Update. requires message
integrity, correct ordering and replay protection.
The mobile node indicates
that an acknowledgement is needed for this Binding Update and
continues to periodically retransmit it until acknowledged. The the home agent acknowledges must have an security association
to protect this signaling. Authentication Header (AH) or
Encapsulating Security Payload (ESP) can be used for integrity
protection. For ESP we require that a non-null authentication
algorithm is applied.
Mobile IPv6 provides its own ordering mechanism inside the Binding
Update by returning a Binding and Acknowledgement messages. A sequence number field is
used, as described in Section 6.1.7.
In order to protect messages exchanged between the mobile node.
When node and
the home agent with IPsec, appropriate security policy database
entries must be created. We need to avoid the possibility that a
mobile node receives a packet tunneled to it from could use its home
agent, the mobile node uses that as an indication that the original
sending correspondent node has no Binding Cache entry for the mobile
node, since the correspondent node would otherwise have sent the
packet directly security association to the mobile node using send a Routing header. The Binding
Update on behalf of another mobile node SHOULD then start a correspondent binding procedure in
order to establish a binding. This would allow using the correspondent
node same home agent.
In order to cache do this, the mobile node's binding for routing future packets to
it.
A correspondent node with security policy database entries MUST
unequivocally identify a Binding Cache entry single SA for a mobile node may
refresh this binding, any given home address and
home agent. In order for example if the binding's lifetime is near
expiration, by sending a Binding Refresh Request to the mobile node.
Normally, a correspondent node will only refresh a Binding Cache
entry in this way if it is actively communicating with home address of the mobile node and has indications, such as an open TCP connection to be
visible when the
mobile node, that it will continue this communication in policy check is made, the future.
When a mobile node receives a Binding Refresh Request, it MAY reply
by initiating a correspondent binding procedure.
A mobile node may MUST use more than one care-of address at the same
time. Use of more than one care-of address by a mobile node may be
useful, for example,
Home Address destination option in Binding Updates sent to improve smooth handover when the mobile node
moves from one wireless link home
agent.
5.2. Binding Updates to another. If each of these wireless
links is connected Correspondent Nodes
Binding Updates to the Internet through a separate base station,
such that the wireless transmission range from the two base stations
overlap, the mobile node may correspondent nodes can be able to remain connected to both
links while in the area of overlap. In this case, protected by using data
exchanged during the mobile node
could acquire return routability procedure. We will first
discuss a new care-of address on the new link before moving
out number of transmission range and disconnecting from the old link. The
mobile preliminary concepts such as node may thus still accept packets at its old care-of address
while it works to update its home agent keys, nonces,
and cookies and correspondent nodes,
notifying them of its new care-of address on the new link.
Since correspondent nodes cache bindings, it is expected that
correspondent nodes usually will route packets directly to cryptographic functions used. Section 5.2.5
outlines the mobile basic return routability procedure. Section 5.2.6 shows
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 16] 12]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
node's care-of address, so that
how the home agent is rarely involved
with packet transmission results of this procedure are used to the mobile authorize a Binding
Update to a correspondent node. This is important for
scalability and reliability, Finally, Sections 5.2.7 and for minimizing overall network load.
By caching the care-of address of 5.2.8
discuss some additional issues.
5.2.1. Node Keys
Each correspondent node has a mobile node, direct delivery of
packets can be achieved from the secret key, Kcn. The correspondent
node uses this key to verify that the mobile
node. Routing packets directly cookies it receives in messages
are those which it has created itself. This key does not need to the mobile node's care-of address
also eliminates congestion at the mobile node's home agent and home
link. In addition, the impact of be
shared with any possible failure of the home
agent, the home link, or intervening networks leading other entity.
A correspondent node can generate a fresh Kcn each time that it boots
to or from avoid the
home link is reduced, since these nodes and links need for secure persistent storage for Kcn. Kcn can be
either a fixed value or regularly updated. Procedures for updating
Kcn are not involved discussed later in
the delivery of most packets to the mobile node.
5. Overview of Mobile IPv6 Security
5.1. Threats
Any mobility solution must protect itself against misuses of the
mobility features. In Mobile IPv6, most of the potential threats
are concerned with denial of service. Some Section 5.2.7.
Kcn consists of the threats 20 octets.
5.2.2. Nonces
Each correspondent node also
include potential generates nonces at regular intervals,
for man-in-the-middle, hijacking, and impersonation
attacks. example every few minutes. The main threats this protocol protects against are as
follows:
1. Threats against Binding Updates sent nonces should be generated by
using a random number generator that is known to home agents and have good randomness
properties [1]. A correspondent nodes. For instance, an attacker might claim that
a certain mobile node is currently at a different location than
it really is. If may use the home agent accepts same Kcn and nonce
with all the information sent to mobiles it as is, the mobile node might is in communication with, so that it does not get traffic destined
need to it, generate and other nodes might get traffic they did not want.
Similarly, store a malicious new nonce when a new mobile node might use the home address of contacts it.
Each nonce is identified by a victim node in nonce index. Nonce indices are
16-bit values that are e.g. incremented each time a forged Binding Update to new nonce is
created. The index value is communicated in the protocol, so that if
a correspondent node.
If such Binding Updates were accepted, nonce is replaced by new nonce during the communications between run of a protocol, the
correspondent node and the victim would be then be disrupted,
because packets can distinguish messages that the correspondent node intended to send to
the victim would should be sent to checked
against the wrong care-of address. This is
a threat to confidentiality as well as availability, because an
attacker might redirect packets meant for another node to itself
in order to learn old nonce from messages that should be checked against
the content of those packets.
A malicious mobile node might also send Binding Updates new nonce. Strictly speaking, indices are not necessary in
which the care-of address is set to the address of a victim
node or an address within a victim network. If such Binding
Updates were accepted, the malicious mobile node could force
authentication, but allow the correspondent node into sending data to efficiently find
the victim node or the
victim network; nonce value that it used in creating a cookie.
Correspondent nodes keep both the correspondent node's replies to current nonce and a small set of
old nonces. Older values can be discarded, and messages sent
by the malicious mobile node using them
will be sent to the victim host
or network. This could rejected as replays.
The specific nonce index values can not be used by mobile nodes to cause a distributed denial
of service attack. Variations
determine the validity of this threat the nonce. Expected validity times for
the nonces values and the procedures for updating them are described
elsewhere [1][31]. discussed
later in Section 5.2.7.
Nonce is an octet string of any length. The recommended length is
64-bit.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 17] 13]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
A malicious node might also send a large number of invalid
Binding Updates to a victim node. If each Binding Update takes a
significant amount of resources (such as CPU) to process before
it can be recognized either as valid or as invalid, then a denial
5.2.3. Cookies
Three different types of service attack can be caused by sending cookies are used in the correspondent node
so many invalid Binding Updates that it has no resources left for
other tasks.
An attacker might also attempt to disrupt a protocol:
- Two mobile node's
communications by replaying a Binding Update that the node had cookies are sent earlier. If to the old Binding Update was accepted, packets
destined for correspondent node from the
mobile node would be sent to its old location node, and not its current location.
2. Reflection attack threats against third partied with later returned to the help
of Mobile IPv6 correspondent nodes that do not use appropriate
security precautions. mobile node. The Home Address destination option can be mobile
cookies are produced randomly, and used to direct response traffic toward a node whose IP address
appears in the option, without allowing ingress filtering to
catch verify that the forged "return address" [32] [23].
3. Threats where an attacker forges tunneled packets between
response matches the
mobile node request, and the home agent, making it appear to ensure that parties who have
not seen the traffic
is coming from request can not spoof responses. One of the mobile node when it
cookies is not.
4. Threats against IPv6 functionality used by Mobile IPv6, such as
the Routing header. The generality of sent in the regular Routing Header
would allow circumvention of IP-address based rules HoTI message, and returned in firewalls
or reflection of traffic to other nodes, even if the usage that
Mobile IPv6 requires HoT
message. This is safe.
5. called the HoT cookie. The security mechanisms of Mobile IPv6 may also be attacked
themselves, e.g. other mobile cookie
is sent in order to force the participants to execute
expensive cryptographic operations or allocate memory for CoTI message, and returned in the
purpose of keeping state.
5.2. Features CoT message.
This specification provides a number of security features. The main
features are: is called the CoT cookie.
- Protection of Binding Updates to A home agents.
- Protection of Binding Updates cookie sent to correspondent nodes.
- Protection against reflection attacks through the Home Address
destination option.
- Protection of tunnels between the mobile node and from the correspondent node
via the home agent.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 18]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
- Preventing Routing Header vulnerabilities. Home cookies are produced cryptographically
from nonces.
- Preventing Denial-of-Service attacks to the Mobile IPv6 security
mechanisms themselves.
Protecting the Binding Updates A care-of cookie is similar to a home agents and to arbitrary
correspondent nodes require very different security solutions due cookie, but sent directly
to the different situations. Mobile nodes mobile node from the correspondent node.
A newly generated random number is typically used for each request
that carries a mobile cookie.
Home and home agents care-of cookies are
expected to be naturally subject to the network administration of produced by the home domain, correspondent node, and thus to have a strong security association to
reliably authenticate the exchanged messages. With such a security
arrangement, IPsec Encapsulating Security Payload (ESP) can be used
to implement the necessary security features. See Section 5.4.
It is expected that Mobile IPv6 will be used
they are based on a global basis
between nodes belonging to different administrative domains.
Building an authentication infrastructure to authenticate mobile
nodes the currently active secret keys and correspondent nodes would be a very demanding task in this
scale. Furthermore, traditional authentication infrastructure keep
track nonces of correct IP addresses for all hosts is either impossible or
at least very hard. That is, it isn't sufficient to authenticate
mobile nodes, authorization to claim right to use an address is
needed. Thus, an "infrastructureless" approach is necessary.
The chosen infrastructureless method verifies that the mobile
correspondent node is "live" (that is, it responds to probes) at its as well as the home and or care-of addresses by performing address. Such a
cookie exchange with the nodes
in question, and by requiring that the eventual Binding Update is
cryptographically bound to the exchanged cookies. Some additional
protection is provided by requiring the cookies be protected by
ESP when exchanged between valid as long as both the mobile node secret key and the correspondent
node via the home agent. This method limits the vulnerabilities nonce used to
those attackers who
create it are valid.
5.2.4. Cryptographic Functions
MAC_K(m) denotes a Message Authentication Code computed on the path between the home agent and the
correspondent node. As adversaries on this path would be able to
cause also other types of attacks, message
m with key K. In this specification, HMAC SHA1 function [26, 19] is seen as sufficient base
security between mobile and correspondent nodes.
Vulnerabilities relating to the use of correspondent nodes as
reflectors via the Home Address destination option can be solved as
follows: We ensure that the mobile node is authorized
used to use compute these codes.
Hash(m) denotes a given
home address before this option can be used. Such authorization is
already performed in the context hash of Route Optimization, and therefore message m. In this specification limits the use of specification, the Home Address option
function used to compute the
situation where the correspondent hash is SHA1 [19].
5.2.5. Return Routability Procedure
The return routability signaling happens as follows:
Mobile node already has a binding cache
entry for the given home address.
Tunnels between the mobile Home agent Correspondent node and the
| |
| 1a. |
| Home Test Init(HoTI) |
| Src = home agent can be
protected by ensuring proper use of source addresses, and optional
cryptographic protection. These procedures are discussed in
Section 5.3. address, |
| Dst = correspondent | |
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 19] 14]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Potential abuses of the Routing Header can be prevented by using a
Mobile IPv6 specific type of a Routing Header. This type provides
the necessary functionality but does not open vulnerabilities.
Denial-of-Service threats against Mobile IPv6 security mechanisms
themselves concern mainly the Binding Update procedures with
correspondent nodes. The protocol has been designed to limit the
effects of such attacks, as will be described in Section 5.5.9.
5.3. Tunnels to and from the Home Agents
Mobile IPv6 tunneling -- as tunneling in general -- needs protection
so that it isn't possible, e.g., for anyone to pose as the home agent
and send traffic to the mobile node. To protect the tunnels to the
mobile node, the mobile node verifies that the outer IP
| Parameters: | |
| - HoT cookie | |
|------------------------->|------------------------->|
| | |
| |
| 1b. |
| Care-of Test Init(CoTI) |
| Src = care-of address
corresponds to its |
| Dst = correspondent |
| Parameters: |
| - CoT cookie |
|---------------------------------------------------->|
| |
| 2a. |
| Home Test (HoT) |
| Src = correspondent, |
| Dst = home agent, to prevent attacks against the tunnel
from other IP addresses.
Tunnels from the mobile node to the address |
| Parameters: |
| - HoT cookie |
| | - home agent need protection
so that it isn't possible for anyone to send traffic through the cookie |
| | - home agent, pose as the mobile node, nonce index |
|<-------------------------|<-------------------------|
| | |
| |
| 2b. |
| Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - CoT cookie |
| - care-of cookie |
| - care-of nonce index |
|<----------------------------------------------------|
| |
The Home and escape detection through
traditional tracing mechanisms.
Binding Updates Care-of Test Init messages are sent to at the home agents are secure. same
time. The home
agent verifies that the outer IP address corresponds to the current
location of the mobile node, to prevent attacks against correspondent node returns the tunnel
from other IP addresses.
For tunneled traffic to Home and from the mobile node, encapsulating Care-of Test
messages as quickly as possible, and perhaps nearly simultaneously,
requiring very little processing. Those four messages form the
traffic inside IPsec ESP offers an optional mechanism
return routability procedure. Due to protect the confidentiality and integrity of nearly simultaneous
message delivery, the traffic against on-path
attackers.
5.4. Binding Updates to Home Agents
Signaling return routability procedure completes in about
roundtrip between the mobile node and the home agent requires correspondent.
1a. Home Test Init
A mobile node sends a Home Test Init message
integrity, correct ordering and replay protection.
In order to have this protection, the mobile
correspondent node and to acquire the home agent
must have a security association. IPsec Encapsulating Security
Payload (ESP) can be used for integrity protection when a non-null
authentication algorithm is applied.
However, IPsec can easily provide replay protection only if dynamic
security association establishment is used. This may not always be
possible, and manual keying would be preferred in some cases. IPsec
also does not guarantee correct ordering of packets, only that they
have not been replayed. Because cookie. The contents of this, Mobile IPv6 provides its
own mechanism inside
the Binding Update and Acknowledgement messages. message can be summarized as follows:
Src = home address
Dst = correspondent
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 20] 15]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
A sequence number field is used to ensure correct ordering. If
Parameters:
- HoT cookie
This message conveys the mobile node reboots and forgets its current sequence number, the node's home
agent uses the status value 141 (Sequence number out of window, see
Section 6.1.8) address to inform the
correspondent node. The mobile node of the use of an improper
sequence number.
Note that the the sequence number mechanism provides also sends along a weak form
of replay protection. However, if a home agent reboots and loses its
state regarding 64 bit
HoT cookie that the sequence numbers, replay attacks become possible.
If correspondent node must return later. The
Home Test Init message is reverse tunneled through the home agent is vulnerable
agent.
1b. Care-of Test Init
The mobile node sends a Care-of Test Init message to this, the use
correspondent node to acquire the care-of cookie. The contents
of a key management
mechanism together with IPsec this message can be used to prevent replay attacks.
A sliding window scheme is used for the sequence numbers. summarized as follows:
Src = care-of address
Dst = correspondent
Parameters:
- CoT cookie
The
protection against replays and reordering attacks without a key
management mechanism works when second message conveys the attacker remembers up to a
maximum of 2**15 Binding Updates.
In order mobile node's care-of address
to protect messages exchanged between the correspondent node. The mobile node and also sends along
a 64 bit CoT cookie that the home agent with IPsec, appropriate security policy database
entries correspondent node must be created. We need return
later. The Care-of Test Init message is sent directly to avoid the possibility that a
mobile node could use its security association
correspondent node.
2a. Home Test
This message is sent in response to send a Binding
Update on behalf Home Test Init message.
The contents of another mobile node using the same home agent.
In order to do this, the security policy database entries MUST
unequivocally identify a single SA for any given message are:
Src = correspondent
Dst = home address and
Parameters:
- HoT cookie
- home agent. In order for the cookie
- home address of the mobile node to be
visible when the policy check is made, nonce index
When the mobile correspondent node MUST use receives the Home Address destination option in Binding Updates sent to the Test Init
message, it generates a 64-bit home
agent. The cookie as follows:
home cookie = First64(MAC_Kcn(home address in | nonce))
The home cookie is formed from the Home Address destination option and first 64 bits of the Binding Update MAC
result. The message MUST be equal and MUST be checked by is sent to the mobile node via the home agent.
5.5. Binding Updates to Correspondent Nodes
Binding Updates to correspondent nodes are protected using
agent; the return
routability procedure. The motivation for designing protocol relies on the return
routability procedure was to have sufficient support for Mobile IP,
without creating major new security problems. It was not our goal
to protect against attacks assumption that were already possible before the
introduction of Mobile IP. This protocol does not defend against
an attacker who can monitor route
between the home agent to correspondent node
path, as such attackers would in any case be able to mount an active
attack against and the mobile node when it is at its home location. secure. The
possibility of such attacks is not an impediment home
cookie also acts as a challenge to test that the deployment of
Mobile IP, because these attacks are possible regardless of whether
Mobile IP mobile can
receive messages sent to its home address. Kcn is used in use.
This protocol also protects against denial the
production of service attacks home cookie in
which the attacker pretends order to be a mobile, but uses the victim's
address as the care of address, and so causes allow the correspondent
node to send the victim traffic verify that it does not expect. For example, generated the home and care-of cookies,
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 21] 16]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
suppose that
without forcing the correspondent node is a news site that will send a
high-bandwidth stream of video to anyone who asks for it. Note that
the use of flow-control protocols such as TCP does not necessarily
defend against this type remember a list of attack, because
all cookies it has handed out.
The HoT cookie from the attacker can fake mobile node is returned in the
acknowledgements. Even keeping TCP initial sequence numbers secret
doesn't help, because Home
Test message, to ensure that the attacker can receive message comes from a node on
the first few segments
(including route between the ISN) at its own address, home agent and then redirect the stream correspondent node.
The home nonce index is delivered to the victim's address. This protocol defends against these attacks
by only completing if packets sent by mobile node to later
allow the correspondent node to efficiently find the
care of address are received and processed by an entity nonce
value that it used in creating the home cookie.
2b. Care-of Test
This message is
willing to participate sent in response to a Care-of Test Init
message. The contents of the protocol. Normally, this will be message are:
Src = correspondent
Dst = care-of address
Parameters:
- CoT cookie
- care-of cookie
- care-of nonce index
The correspondent node also sends a challenge to the
mobile node.
For further information about mobile's
care-of address. When the design rationale of correspondent node receives the return
routability procedure, see [1] [31] [22] [23].
Care-of Test Init message, it generates a 64-bit care-of cookie
as follows:
care-of cookie = First64(MAC_Kcn(care-of address | nonce))
The return routability procedure method uses cookie is formed from the following
principles:
- A first 64 bits of the MAC result.
The cookie exchange verifies that is sent directly to the mobile node is reachable at
its addresses i.e. is at least able to transmit and receive
traffic at its addresses.
- care-of
address. The eventual Binding Update is protected cryptographically using CoT cookie from the cookies.
- Requiring from CoTI message is returne
to ensure that the cookies be protected by ESP when forwarded by message comes from a node on the home agent route to
the mobile correspondent node.
-
The use of symmetric exchanges where responses are sent care-of nonce index is provided to identify the
same address as the request was sent from, to avoid nonce used
for the use of
this protocol in reflection attacks.
- Correspondent nodes operate in a stateless manner until they
receive a Binding Update that can be authorized. care-of cookie. The return routability procedure can be broken by an attacker on the
route between the home agent and care-of nonce indices are
often the correspondent node, but not by
attackers on same in the network Home and Care-of Test messages.
When the mobile node is currently at has received both the Home and not from
elsewhere on Care-of Test
messages, the Internet.
5.5.1. Node Keys
Each correspondent return routability procedure is complete. As a result,
the mobile node has the means to prove its authority to send a secret key, Kcn. This key is used by
Binding Update to the correspondent node. The mobile node to accept only hashes
together the use of cookies which it has
created itself. This key does not need challenges to be shared with any other
entity, so no form a 16 octet session key distribution mechanism is needed for it.
A Kbu:
Kbu = Hash(home cookie | care-of cookie)
Note that the correspondent node can generate a fresh Kcn each time that it boots does not create any state specific
to avoid the need for secure persistent storage for Kcn. Kcn can be mobile node, until it receives the Binding Update from that
mobile node. The correspondent node is unaware of the session
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 22] 17]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
either a fixed value or regularly updated. Procedures for updating
Kcn are discussed later in Section 5.5.7.
Kcn consists of 20 octets.
5.5.2. Nonces
Each correspondent node also generates a
key Kbu, though it can recreate Kbu if it is presented the right
addresses and nonce at regular intervals, indices.
5.2.6. Applying Return Routability for example every few minutes. A correspondent Correspondent Bindings
After the above procedure has completed, the mobile node uses can supply a
Binding Update to the same
Kcn and nonce with all correspondent node. An overview of the mobiles it binding
procedure is in communication with, so
that it does not need to generate and store shown below.
Mobile Node Correspondent node
| |
| 1. Binding Update |
| Src = care-of address, Dst = correspondent |
| Parameters: |
| - home address |
| - a new MAC |
| - home nonce when a new
mobile contacts it. Each index |
| - care-of nonce is identified by index |
| - sequence number |
| - ... |
|---------------------------------------------------->|
| |
| 2. Binding Acknowledgement |
| (if requested) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - sequence number |
| - a nonce index.
Nonce indices are 16-bit values that are e.g. incremented each time MAC |
| - ... |
|<----------------------------------------------------|
| |
Message 1 actually creates a new nonce binding, and message 2 is created. optional. The index value is communicated in
correspondent binding procedure consists of the
protocol, so that if a nonce is replaced return routability
procedure followed by new nonce during the run messages 1 and 2.
1. Binding Update
The mobile node uses the created session key Kbu to authorize
the Binding Update. The contents of a protocol, the message are as
follows:
Src = care-of address
Dst = correspondent
Parameters:
- home address
- MAC_Kbu(care-of address | correspondent node can distinguish messages that
should be checked against the old address | BU)
- home nonce from messages index
- care-of nonce index
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 18]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- sequence number
- ...
The Binding Update message contains Nonce Index option, so that should be
checked against the new nonce. Correspondent nodes keep both
the
current nonce and a small set of old nonces. Older values can be
discarded, correspondent node knows which home and messages using them will be rejected as replays.
The specific nonce index values can not be used by mobile nodes care-of nonces to
determine
use to recompute the validity session key. "BU" is the content of the nonce. Expected validity times for
Binding Update message, excluding (1) the nonces values and IP header, (2) any
extension headers between the procedures for updating them are discussed
later in Section 5.5.7.
Nonce is an octet string of any length. IP header the Mobility Header,
and (3) the Authenticator field inside the Binding Update. The recommended length is 16
octets.
5.5.3. Cookies
Three different types of cookies
first 96 bits from the MAC result are used in as the protocol:
- Mobile cookie is sent Authenticator
field. A sequence number will be used to match an eventual
acknowledgement with this message. The sequence numbers
start from a random value. The three dots represent all the
remaining (not security related) information in the message.
Once the correspondent node from has verified the mobile
node, and later returned to MAC, it can create
a binding cache entry for the mobile mobile.
2. Binding Acknowledgement
The Binding Update is optionally acknowledged by the
correspondent node. Mobile cookies The contents of the message are
produced randomly, and used to verify that as
follows:
Src = correspondent
Dst = care-of address
Parameters:
- sequence number
- MAC_Kbu(care-of address | correspondent node address | BA)
- ...
The Binding Acknowledgement contains the response matches same sequence number
as the request, Binding Update did. "BA" is the content of the Binding
Acknowledgement message, excluding (1) the IP header, (2)
any extension headers between the IP header the Mobility
Header, and to ensure that parties who have not seen (3) the
request can not spoof responses.
- A home cookie sent to Authenticator field inside the mobile node Binding
Acknowledgement. The first 96 bits from the MAC result are
used as the Authenticator field. The three dots represent
all the remaining (not security related) information in the
message.
Bindings established with correspondent node
via nodes using the return
routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE seconds.
The value in the Source Address field in the IPv6 header carrying
the Binding Update message is normally also the home agent. Home cookies are produced cryptographically
from nonces.
- A care-of cookie address
which is used in the binding. However, a different care-of address
MAY be specified by including an Alternate Care-of Address mobility
option in the Binding Update message (see Section 6.2.5). When such
message is sent directly to the mobile correspondent node from and the
correspondent node. Home cookies are produced cryptographically
from nonces.
Mobile cookies are typically newly generated random values for each
new request that needs them. They could also be changed periodically return routability
procedure is used as the authorization method, the Care-of Test Init
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 23] 19]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
only. The policy to use new or old mobile cookies is purely a local
matter
and Care-of Test messages MUST have been performed for the mobile node.
Home and care-of cookies are produced by address in
the correspondent node, and
they are Alternate Care-of Address option (not the Source Address). The
nonce indices MAC value MUST be based on the currently active secret keys information gained in this
test.
5.2.7. Updating Node Keys and nonces Nonces
An update of Kcn can be done at the
correspondent node as well same time as the home or care-of address. Such an update of a
cookie is valid as long as
nonce, so that the nonce index identifies both the secret key nonce and the nonce used key.
Old Kcn values have to
create it are valid.
5.5.4. Cryptographic Functions
MAC_K(m) denotes a Message Authentication Code computed on message
m with key K. In this specification, HMAC SHA1 function [15][21] is
used to compute these codes.
H(m) denotes be therefore remembered as long as old nonce
values.
Before sending a hash of message m. In this specification, SHA1
function [21] is used to compute Binding Update, the hash.
5.5.5. Return Routability Procedure
The return routability signaling happens as follows:
Mobile node Home agent Correspondent node
| |
| Home Test Init(HoTI) |
| Src = home address, |
| Dst = correspondent | |
| Parameters: | |
| - mobile cookie 1 | |
|------------------------->|------------------------->|
| | |
| |
| Care-of Test Init(CoTI) |
| Src = care-of address |
| Dst = correspondent |
| Parameters: |
| - mobile cookie 2 |
|---------------------------------------------------->|
| |
| node has to wait for both
the Home Test (HoT) |
| Src = correspondent, |
| Dst = home address |
| Parameters: |
| - mobile cookie 1 |
| | - home cookie |
| | - home nonce index |
|<-------------------------|<-------------------------|
| | |
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 24]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
| |
| Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - mobile cookie 2 |
| - care-of cookie |
| - care-of nonce index |
|<----------------------------------------------------|
| |
The HoTI and CoTI messages Care-of Cookies to arrive. Due to resource limitations,
rapid deletion of bindings, or reboots it can not be guaranteed that
the cookies are sent at still fresh and acceptable when the same time. The correspondent
node returns uses them in the HoT and CoT messages as quickly as
possible, and perhaps nearly simultaneously, requiring very little
processing. The four messages form processing of the return routability procedure.
(After Binding Update. If the return routability procedure, a binding will be created
with a single request
cookies have become too old, the correspondent node replies with
an optional response.) Due to the
simultaneous sending of messages, the return routability procedure
completes in 1 roundtrip (and the whole process completes an error code in 1.5
roundtrips excluding the acknowledgement message). Binding Acknowledgement. The four messages (HoTI, CoTI, HoT, and CoT) belonging to mobile node
can then retry the return routability procedure procedure. However, it is
recommended that correspondent nodes try to keep these cookies
acceptable as long as possible and SHOULD NOT accept them beyond
MAX_COOKIE_LIFE seconds.
Given that the cookies are described in more detail below. The use of normally expected to be usable for
some time, the results mobile node MAY use them beyond a single run of the
return routability procedure for authenticating procedure. A fast moving mobile node may reuse
a
correspondent binding procedure is described in Section 5.5.6.
HoTI recent Home Test Init Message:
When Cookie from a mobile nodes wants correspondent node when moving to perform route optimization it
sends a HoTI message new
location, and just acquire a new Care-of Cookie to the correspondent node show routability
in order the new location. While this does not save roundtrips due to
initiate the
parallel nature of the home and care-of return routability verification for tests, the Home
Address.
Src = home address
Dst = correspondent
Parameters:
- mobile cookie 1
This message conveys
roundtrip through the mobile node's home address to the
correspondent node. The agent may be longer, and consequently this
optimization is often useful. A mobile node also sends along mobile
cookie C0 that has multiple home
addresses, may also use the same Care-of Cookie for Binding Updates
concerning all of these addresses.
5.2.8. Preventing Replay Attacks
The return routability procedure also protects the participants
against replayed Binding Updates through the use of the sequence
number and a MAC. Care must be taken when removing bindings at
the correspondent node node, however. Correspondent nodes must return later,
along with its own cookie that it generates based on retain
bindings and the home
address. associated sequence number information at least as
long as the nonces used in the authorization of the binding are still
valid. The HoTI message is reverse tunneled through correspondent node can, for instance, change the home
agent.
CoTI
Care-of Test Init Message: nonce
often enough to ensure that the nonces used when removed entries
were created are no longer valid. If many such deletions occur
the correspondent node can batch them together to avoid having to
increment the nonce index too often.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 25] 20]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
When a
5.3. Payload Packets
Payload packets exchanged with mobile nodes wants to perform route optimization it
sends a CoTI message to can be protected in the correspondent node
usual manner, in order to
initiate the return routability verification for same way as stationary hosts can protect them.
However, Mobile IPv6 introduces the care-of
Address.
Src = care-of address
Dst = correspondent
Parameters:
- mobile cookie 2
The second message is sent Home Address destination option,
a Routing Header, and tunneling headers in parallel with the first one. It
conveys payload packets. In
the mobile node's care-of address following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties.
This specification limits the correspondent
node. The mobile node also sends along mobile cookie C1 that use of the Home Address destination
option to the situation where the correspondent node must return later, along with its own
cookie that it generates based on already has a
binding cache entry for the care-of given home address. The
CoTI message is sent directly to This avoids the use
of the correspondent node.
HoT Home Test Message:
This message is sent Address option in response to a HoTI message.
Src = correspondent
Dst = home address
Parameters:
- mobile cookie 1
- home cookie
- home nonce index
When attacks described in Section 14.1. We
also allow the correspondent node receives option to be used when the HoTI message, packet containing it
generates has
been protected by IPsec.
Mobile IPv6 uses a 16 octet home cookie as follows:
home cookie = MAC_Kcn(home address | nonce)
The cookie is sent in Mobile IPv6 specific type of a Routing Header.
This type provides the message to necessary functionality but does not open
vulnerabilities discussed in Section 14.1.
Tunnels between the mobile node via the
Home Agent; it is an assumption of the protocol that and the home agent - are protected by
ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node route is secure. Home cookie also acts as
a challenge to test verifies that the mobile can receive messages sent outer IP address
corresponds to its home address. Kcn is used in the production of agent. The home
cookie in order to allow agent verifies that the correspondent node
outer IP address corresponds to verify that
the cookies used later really came from itself, without forcing the correspondent node to remember a list current location of all cookies it has
handed out.
Mobile cookie 1 from the mobile
node is returned as well in the
HoT message, to ensure that the message comes from someone on
the path (Binding Updates sent to the correspondent node.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 26]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
The home nonce index is carried along in the protocol to allow
the correspondent node to later efficiently find agents are secure). These
measures protect the nonce
value Ni that it used in creating this cookie.
CoT
Care-of Test Message:
This message is sent tunnels against vulnerabilities discussed in response to a CoTI message.
Src = correspondent
Dst = care-of address
Parameters:
- mobile cookie 2
- care-of cookie
- care-of nonce index
The correspondent node also sends a challenge to the mobile's
care-of address. When the correspondent node receives the CoTI
message, it generates a 16 octet care-of cookie as follows:
care-of cookie = MAC_Kcn(care-of address | nonce)
The cookie is sent directly
Section 14.1.
For tunneled traffic to the mobile node at its care-of
address. Mobile cookie 2 and from the mobile node is returned as
well, to ensure that the message comes from someone on the path
to node, encapsulating
the correspondent node.
Again, traffic inside IPsec AH or ESP offers an index is sent along the cookie in order to identify
the used nonce. Note that home and care-of nonce indices are
likely optional mechanism to be
protect the same in HoT integrity and CoT messages, except when
the correspondent node changed its nonce value between the
reception confidentiality of HoTI and the CoTI messages.
When the mobile node has received both the HoT traffic against
on-path attackers.
6. New IPv6 Protocols, Message Types, and CoT messages, the
return routability procedure Destination Option
6.1. Mobility Header
The Mobility Header is complete. As a result, the used by mobile
node has the means to prove its authority to send a Binding Update
to the nodes, correspondent node. The mobile node hashes together the
challenges nodes, and
home agents in all messaging related to form a 20 octet session key (Kbu):
Kbu = H(home cookie | care-of cookie)
Note that the correspondent node has not created any state at this
point. It is unaware creation and management
of bindings. Sections 6.1.2 through 6.1.9 describe the session key Kbu, though it can recreate
Kbu if it is presented the right message types
used in this protocol. These sections also define which addresses and nonce indices. to
use in the IPv6 header in these messages.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 27] 21]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
5.5.6. Applying Return Routability for Correspondent Bindings
After the return routability procedure, the mobile node can proceed
to perform
6.1.1. Format
The Mobility Header is identified by a binding procedure with the correspondent node. An
overview Next Header value of TBD in
the binding procedure is shown below.
Mobile Node Correspondent node
| |
| 1. Binding Update immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Src = care-of address, Dst = correspondent Header Len | MH Type | Parameters:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | - home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - a MAC
| | - home nonce index
. .
. Message Data .
. .
| | - care-of nonce index |
| - sequence number |
| - ... |
|---------------------------------------------------->|
| |
| 2. Binding Acknowledgement |
| (if requested) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - sequence number |
| - ... |
|<----------------------------------------------------|
| |
Message 1 actually creates a binding, and message 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto
8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the
IPv6 Next Header field [11].
This field is optional. The
correspondent intended to be used by a future specification
of piggybacking binding procedure consists messages on payload packets (see
Section C.1).
Implementations conforming to this specification SHOULD set the
payload protocol type to NO_NXTHDR (59 decimal).
Header Len
8-bit unsigned integer. Length of the return routability
procedure followed by Mobility Header in units
of 8 octets, including the messages 1 the Payload Proto, MH Type, Header
Len, Checksum, and 2.
1.
Binding Update (BU) Message:
The mobile node uses Message Data fields.
We require that the created session key Kbu Mobility Header length is a multiple of 8
octets.
MH Type
16-bit selector. Identifies the particular mobility message
in question. Current values are specified in Sections 6.1.2
to 6.1.9. An unrecognized MH Type field causes an error to be
sent to authorize the Binding Update.
Src = care-of address
Dst = correspondent
Parameters:
- home address
- MAC_Kbu(care-of address | correspondent node address | BU)
- home nonce index
- care-of nonce index
- sequence number
- ... source.
Checksum
16-bit unsigned integer. This field contains the checksum of
the Mobility Header. The checksum is calculated from the octet
string consisting of a "pseudo-header" followed by the entire
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 28] 22]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
The message contains home and care-of nonce indices, so that
the correspondent node knows which nonces to use to recompute
Mobility Header starting with the session key. "BU" Payload Proto field. The
checksum is the content 16-bit one's complement of the Binding Update
message, excluding (1) one's complement
sum of this string.
The pseudo-header contains IPv6 header fields, as specified
in Section 8.1 of [11]. The Next Header value used in the IP header, (2) any extension
headers between
pseudo-header is TBD. The addresses used in the IP header pseudo-header
are the Mobility Header, addresses that appear in the Source and (3) Destination
Address fields in the
Authenticator field inside IPv6 packet carrying the Binding Update. The result of Mobility Header.
For computing the MAC_Kbu function is used as checksum, the Authenticator checksum field in
the Binding Update. is set to zero.
Message Data
A sequence number will be used variable length field containing the data specific to match
an eventual acknowledgement with this message. The sequence
numbers start from a random value, which offers the
indicated Mobility Header type.
Mobile IPv6 also defines a weak form number of authentication also to "mobility options" for use
within these messages; if included, any options MUST appear after
the acknowledgement messages. The
three dots represent all fixed portion of the remaining (not security related)
information message data specified in this document.
The presence of such options will be indicated by the Header Len
field within the message.
Once When the correspondent node has verified Header Len is greater than the MAC, it can create
a binding cache entry
length required for the mobile.
2.
Binding Acknowledgement (BA) Message:
The Binding Update is optionally acknowledged by message specified here, the
correspondent node.
Src = correspondent
Dst = care-of address
Parameters:
- sequence number
- ...
The Binding Acknowledgement is not authenticated in remaining octets
are interpreted as mobility options. These options include padding
options that can be used to ensure that other ways
than including options are aligned
properly, and that the right sequence number in total length of the reply. message is divisible by
8. The
three dots represent all the remaining (not security related)
information in the message.
5.5.7. Updating Node Keys encoding and Nonces
An update format of Kcn can be done at defined options are described in
Section 6.2.
Alignment requirements for the Mobility Header are the same time as for
any IPv6 protocol Header. That is, they MUST be aligned on an update of Ni, so
that i identifies both the nonce and the key. Old Kcn values have
8-octet boundary.
6.1.2. Binding Refresh Request (BRR) Message
The Binding Refresh Request (BRR) message is used to
be therefore remembered as long as old nonce values.
Before sending request a Binding Update in Step 3, the
mobile node has
to wait for both node's binding from the Home and Care-of Cookies to arrive. Due mobile node. It is sent according
to resource limitations, rapid deletion of bindings, or reboots
it can not be guaranteed that the cookies are still fresh and
acceptable when the correspondent node uses them rules in Section 9.4.5. When a mobile node receives a
packet containing a Binding Refresh Request message and there
already exists a Binding Update List entry for the processing source of the
Binding Update. If Refresh Request, it MAY start a return routability procedure
(see Section 5.2) if it believes the cookies have become too old, amount of traffic with the
correspondent node replies with an an error code in justifies the use of route optimization. Note that
the Binding
Acknowledgement. The mobile node can then retry the return
routability procedure. However, it is recommended that SHOULD NOT respond to Binding Refresh Requests from
previously unknown correspondent nodes due to Denial-of-Service
concerns.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 29] 23]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
nodes try to keep these cookies acceptable as long as possible and
SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds.
Given that
The Binding Refresh Request message uses the cookies are normally expected to be usable for
some time, MH Type value 0. When
this value is indicated in the mobile node MAY use them beyond a single run MH Type field, the format of the
return routability procedure. A fast moving mobile node may reuse
a recent Home Cookie from a correspondent node when moving to a new
location, and just acquire a new Care-of Cookie to show routability
Message Data field in the new location. While this does not save roundtrips due Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the
parallel nature of the home sender, and care-of return routability tests, MUST be ignored by the
roundtrip through
receiver.
Mobility options
Variable-length field of such length that the home agent may be longer, and consequently this
optimization complete Mobility
Header is often useful. A mobile node that has an integer multiple home
addresses, may also use the same Care-of Cookie for of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this
Binding Updates
concerning Refresh Request message, that need not be present in
all Binding Requests sent. This use of these addresses.
5.5.8. Preventing Replay Attacks
The return routability procedure mobility options also protects
allows for future extensions to the participants
against replayed Binding Updates. The attacker can't replay format of the
same Binding
Refresh Request message due to the sequence number which is be defined. The following options
are valid in a part of the Binding Update, and the attacker can't modify the Refresh Request message:
- Unique Identifier Option
- Binding Update
since the MAC would not verify after that. Care must be taken when
removing bindings at the correspondent node, however. Authorization option
If a binding
is removed either due to garbage collection, request, or expiration
and the nonce used no actual options are present in its creation this message, no padding is still valid, an attacker can
replay
necessary and the old Binding Update. This can Header Length field will be prevented by having the
correspondent node change the nonce often enough set to ensure that the
nonces used when removed entries were created are no longer valid.
If many such deletions occur the correspondent 1.
6.1.3. Home Test Init (HoTI) Message
A mobile node can batch them
together to avoid having uses the Home Test Init (HoTI) message to increment initiate
the nonce index too often.
5.5.9. Preventing Denial-of-Service Attacks
The return routability procedure has been designed with protection
against resource exhaustion Denial-of-Service attacks. In these
attacks the victim has only a limited amount of some resource (such
as network bandwidth or CPU cycles), and the attack consumes some of
this resource. This leaves the victim without enough resources to
carry out other work.
The request a home cookie from a
correspondent nodes do not have to retain any state about
individual mobile nodes until an authentic Binding Update arrives.
This is achieved through the use of the nonces and Kcn that are not
specific to individual mobile nodes. node (see Section 11.5.1). The cookies are specific, but
they can be reconstructed based on the home and care-of address
information that arrives with the Binding Update. This means that Home Test Init message
uses the correspondent nodes are safe against memory exhaustion attacks
except where on-path attackers are concerned. Due to MH Type value 1. When this value is indicated in the use of MH
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 30] 24]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
symmetric cryptography,
Type field, the correspondent nodes are relatively safe
against CPU resource exhaustion attacks as well.
Nevertheless, as [1] describes, there are situations format of the Message Data field in which it the Mobility
Header is
impossible as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ HoT cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero by the mobile sender, and correspondent nodes to determine if
they actually need a binding or whether they just have been fooled
into believing so MUST be ignored by the
receiver.
HoT cookie
64-bit field which contains a random value, the HoT cookie.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an attacker. Therefore, integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST
ignore and skip any options which it does not understand. This
specification does not define any options valid for the Home
Test Init message.
If no actual options are present in this message, no padding is
necessary and the Header Length field will be set to
consider situations where such attacks are being made.
The binding updates that are used in Mobile IPv6 are only an
optimization, albeit a very important optimization. A mobile node
can communicate 2.
This message is sent with a correspondent node even if the correspondent
refuses Source Address set to accept any the home
address of its binding updates. However, performance
will suffer because packets from the correspondent node mobile node, and the Destination Address set to the mobile
node will be routed via
correspondent node's address. The message is tunneled through the mobile's
home agent rather than a more
direct route. A correspondent node can protect itself against some
of the resource exhaustion attacks by not processing binding updates when it is flooded with a large number of binding updates that fail the cryptographic integrity checks. If a correspondent mobile node finds
that it is spending more resources on checking bogus binding updates
than it away from home. Such tunneling
SHOULD employ IPsec ESP in tunnel mode between the home agent and
the mobile node. This protection is likely to save indicated by accepting genuine binding updates, then
it MAY reject some or all Binding Updates without performing any
cryptographic operations.
Additional information needed to make this decision about responding
to requests will usually originate in layers above IP. For example,
TCP knows if the node has a queue of IPsec policy
data that it is trying to send
to a peer. A conformant implementation base. The protection of the protocols in this
specification Home Test Init messages is not required to make use of information from higher
protocol layers, but implementations are likely to be able unrelated
to manage
resources more effectively by making use of such information.
5.5.10. Correspondent Binding Procedure Extensibility
As discussed in Appendix D.3, in the future there may be other
mechanisms beyond the return routability procedure for authorizing
mobile nodes requirement to correspondent nodes. The nodes can protect regular payload traffic, which MAY
use other methods
based on future definition of flag values in the Reserved fields of
HoTI, HoT, CoTI, CoT, and BU messages. Nodes need assurance against
bidding down attacks in this selection by following such tunnels as well. A packet that includes a Home Test Init
message MUST NOT include a Home Address destination option between
the procedure
described in Section 14.3.
6. New IPv6 Protocols, Message Types, and Destination Option
6.1. Mobility Header
The Mobility Header is used by mobile nodes, correspondent nodes, and
home agents in all messaging related to the creation and management
of bindings. The Mobility Header is an preceding IPv6 protocol. Rules header.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 31] 25]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
regarding how it is sent and what addresses are used in
6.1.4. Care-of Test Init (CoTI) Message
A mobile node uses the IPv6
header are given separately in Sections 6.1.2 through 6.1.9, which
describe Care-of Test Init (CoTI) message to initiate
the return routability procedure and request a care-of cookie from
a correspondent node (see Section 11.5.1). The Care-of Test Init
message types used in uses the MH Type value 2. When this protocol.
6.1.1. Format
The Mobility Header is identified by a Next Header value of 62 (XXX) is indicated
in the immediately preceding header, and has MH Type field, the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Proto | format of the Message Data field in the
Mobility Header Len is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MH Type Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+ CoT cookie +
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Message Data Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Reserved
16-bit field is intended reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be used ignored by the
receiver.
CoT cookie
64-bit field which contains a future specification
of piggybacking binding messages on payload packets (see
Section D.1).
Implementations conforming to this specification SHOULD set random value, the
payload protocol type to NO_NXTHDR (59 decimal).
Header Len
8-bit unsigned integer. Length CoT cookie.
Mobility options
Variable-length field of such length that the complete Mobility
Header in units is an integer multiple of 8 octets, including the the Payload Proto, MH Type, Header
Len, Checksum, octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST
ignore and Message Data fields.
MH Type
16-bit selector. Identifies skip any options which it does not understand. This
specification does not define any options valid for the particular mobility message
in question. Current values Care-of
Test Init message.
If no actual options are specified present in Sections 6.1.2
to 6.1.9. An unrecognized MH Type this message, no padding is
necessary and the Header Length field causes an error to will be set to 2.
This message is always sent with the Source Address set to the source.
care-of address of the mobile node, and is sent directly to the
correspondent node. A packet that includes a Care-of Test Init
message MUST NOT include a Home Address destination option between
the Mobility Header and the preceding IPv6 header.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 32] 26]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Checksum
16-bit unsigned integer. This field contains the checksum
of the Mobility Header.
6.1.5. Home Test (HoT) Message
The checksum Home Test (HoT) message is the 16-bit one's
complement of the one's complement sum of an octet string
consisting of a "pseudo-header" followed by response to the entire
Mobility Header starting with HoTI message,
and is sent from the Payload Proto field. The
pseudo-header contains IPv6 header fields, as specified
in correspondent node to the mobile node (see
Section 8.1 of [6]. 5.2.5). The Next Header Home Test message uses the MH Type value used 3.
When this value is indicated in the
pseudo-header is 62 (XXX). For computing MH Type field, the checksum, format of the
checksum field is set to zero.
Message Data
A variable length field containing the data specific to in the
indicated Mobility Header type.
Mobile IPv6 also defines a number of "mobility options" for use
within these messages; if included, any options MUST appear after the
fixed portion of the message data specified in this document. The
presence of such is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ HoT cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Nonce Index
This field will be indicated echoed back by the Header Len mobile node to the
correspondent node in a subsequent binding update.
HoT cookie
64-bit field
within which contains the message. When HoT cookie.
Home Cookie
This field contains the Header Len 64 bit home cookie in the return
routability procedure; it is greater than the first of two cookies which
are to be processed to form a key which is then used to
authenticate a binding update.
Mobility options
Variable-length field of such length
required for the message specified here, that the remaining complete Mobility
Header is an integer multiple of 8 octets are
interpreted as long. Contains
one or more TLV-encoded mobility options options. The encoding receiver MUST
ignore and format of
defined skip any options are described in Section 6.2.
Alignment requirements which it does not understand. This
specification does not define any options valid for the Home
Test message.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 27]
INTERNET-DRAFT Mobility Header are same as for any Support in IPv6 protocol Header. That is, they MUST be aligned on an 8-octet
boundary. We also require that 1 June 2002
If no actual options are present in this message, no padding is
necessary and the Mobility Header length is a
multiple of 8 octets.
6.1.2. Binding Refresh Request (BRR) Message
The Binding Refresh Request (BRR) message is used Length field will be set to request a
mobile node's binding from the mobile node. A packet containing
a Binding Refresh Request 3. This
message is always sent in with the same way as any
packet Destination Address set to a mobile node (Section 9.6). When a mobile node receives
a packet containing a Binding Refresh Request message and there
already exists a Binding Update List entry for the source home
address of the
Binding Refresh Request, it MAY start a return routability procedure
(see Section 5.5) if it believes mobile node, Source Address set to the amount address of traffic with the
correspondent justifies node, and is tunneled through the use of Route Optimization. home agent when the
mobile node is away from home. Note that the Home Test message is
always sent to the home address of the mobile node, even when there
is an existing binding for the mobile node. The tunneling between
the home agent and the mobile node SHOULD NOT respond employ IPsec ESP in tunnel
mode. This protection is indicated by the IPsec policy data base.
6.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is a response to Binding Refresh Requests the CoTI message,
and is sent from
previously unknown the correspondent nodes due node to Denial-of-Service
concerns.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 33]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 the mobile node (see
Section 11.5.2). The Binding Refresh Request Care-of Test message uses the MH Type value 0. 4.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CoT cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
The two 16-bit field fields are reserved for future use. The value These
values MUST be initialized to zero by the sender, and MUST be
ignored by the receiver.
Mobility options
Variable-length
Care-of Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 28]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
CoT cookie
64-bit field which contains the CoT cookie.
Care-of Cookie
This field contains the 64 bit care-of cookie in the return
routability procedure; it is the second of two cookies which
are to be processed to form a key which is then used to
authenticate a binding update.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver MUST
ignore and skip any options which it does not understand.
There MAY be additional information, associated with this
Binding Refresh Request message, that need not be present in
all Binding Requests sent. This use of mobility
specification does not define any options also
allows valid for future extensions the Care-of
Test message.
The CoT message is always sent with the Source Address set to the format
address of the Binding
Refresh Request message to be defined. The following options
are valid in a Binding Refresh Request message:
- Unique Identifier Option
- Binding Authorization option
The Header Length field in correspondent node, and the Mobility Header for this message
MUST be Destination Address set to 1 (since unit is 8 octets) plus
the total length care-of address of
all mobility options present (also in 8 octet units). the mobile node; it is sent directly to the
mobile node. If no actual options are present in this message, no
padding is necessary.
6.1.3. Home Test Init (HoTI) necessary and the Header Len field will be set to 3.
6.1.7. Binding Update (BU) Message
The Home Test Init (HoTI) Binding Update (BU) message is used to initiate the return
routability procedure from the mobile node to by a correspondent mobile node
(see Section 11.6.2). The purpose of this message is to test the
reachability notify
other nodes of the home address. This a new care-of address for itself. A packet containing
a Binding Update message is always sent with
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 34]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 the Source Address set to the home
care-of address of the mobile node, node and the Destination Address set to
the correspondent node's address, and is
tunneled through the home agent when the mobile node is away from
home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between
the home agent and the mobile node. This protection is guided by the
IPsec Policy Data Base. (Note the protection of HoTI messages is
different from the requirement to protect regular payload traffic,
which MAY use such tunnels as well.) address.
The HoTI Binding Update message uses the MH Type value 1. 5. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|L| Reserved | Mobile cookie Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 29]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Acknowledge (A)
The Acknowledge (A) bit is set by the sender, and MUST sending mobile node to
request a Binding Acknowledgement (Section 6.1.8) be ignored by returned
upon receipt of the
receiver.
Mobile cookie
32-bit field which contains a random value, mobile cookie 1,
selected Binding Update.
Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node.
Mobility options
Variable-length field of such length
node to request that the complete Mobility
Header is an integer multiple receiving node should act as this
node's home agent. The destination of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
There MAY be additional information, associated with the packet carrying this
message that need not MUST be present in all HoTI messages. This
use that of mobility options also allows for future extensions to a router sharing the format of same subnet prefix
as the HoTI message to be defined. The encoding and
format home address of defined options are described in Section 6.2. The
following options are valid in a HoTI message:
- Unique Identifier Option
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 35]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
The Header Length field the mobile node in the Mobility Header for this message
MUST be set to 2 (since unit binding.
Single Address Only (S)
If the `S' bit is 8 octets) plus set, the total length of
all mobility options present (also in 8 octet units). If mobile node requests that the home
agent make no actual
options are present changes to any other Binding Cache entry except
for the particular one containing the home address specified
in this message, 4 bytes of padding is necessary.
A packet that includes a HoTI message MUST NOT include a the Home Address destination option.
6.1.4. Care-of Test Init (CoTI) Message This disables home
agent processing for other related addresses, as is described
in Section 10.2.
Duplicate Address Detection (D)
The Care-of Test Init (CoTI) message Duplicate Address Detection (D) bit is used to initiate the return
routability procedure from set by the sending
mobile node to a correspondent request that the receiving node
(see Section 11.6.2). The purpose of this message is to test (the mobile
node's home agent) perform Duplicate Address Detection [13]
on the
reachability of mobile node's home link for the care-of address. home address in this
binding. This message bit is always sent
with only valid when the Source Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise.
Link-Local Address Compatibility (L)
The Link-Local Address Compatibility (L) bit is set to when the care-of
home address of reported by the mobile
node, and is sent directly to the correspondent node.
The CoTI message uses the MH Type value 2. When this value is
indicated in the MH Type field, the format of the Message Data field
in node has the Mobility Header is same interface
identifier (IID) as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the mobile node's link-local address.
Reserved
16-bit field reserved for future use. The value
These fields are unused. They MUST be initialized to zero by
the sender, sender and MUST be ignored by the receiver.
Mobile cookie
32-bit field which contains a random value, mobile cookie 2,
selected
Sequence #
A 16-bit number used by the receiving node to sequence Binding
Updates and by the sending node to match a returned Binding
Acknowledgement with this Binding Update.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 30]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Lifetime
16-bit unsigned integer. The number of time units remaining
before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node. node MUST
be deleted. One time unit is 16 seconds.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 36]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
There MAY be additional information, associated with this
message that need not be present in all CoTI messages. This
use of mobility options also allows for future extensions to
the format of the CoTI message to be defined. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
The following options are valid in a CoTI Binding Update message:
- Unique Identifier Option
The Header Length field in the Mobility Header for this message
MUST be set to 2 (since unit is 8 octets) plus the total length of
all mobility options present (also in 8 octet units). option
- Binding Authorization Data option
- Nonce Indices option.
- Alternate Care-of Address option
If no actual options are present in this message, 4 bytes of no padding is necessary.
necessary and the Header Len field will be set to 4.
A packet that includes a CoTI message Binding Update to the home agent MUST NOT include a the Home Address
destination option.
6.1.5. Home Test (HoT) Message
The Home Test (HoT) message is a response to option if the HoTI message, and Source Address field in the IPv6 header is sent from
not the correspondent node to home address of the mobile node (see Section
8.2). This message node.
The care-of address MUST NOT be any IPv6 address which is always sent with the Destination Address set
to prohibited
for use within a Routing Header; thus multicast addresses, the home
unspecified address, loop-back address, and link-local addresses
are excluded. Binding Updates indicating any such excluded care-of
address MUST be silently discarded.
The deletion of a binding can be indicated by setting the mobile node, Source Address set Lifetime
field to 0 or by setting the care-of address of equal to the home
address. Correspondent nodes SHOULD NOT expire the binding cache
entry before the lifetime expires, if any application hosted by the
correspondent node, and node is tunneled through the home
agent when still likely to require communication with the
mobile node node. A binding cache entry that is away deallocated prematurely
might cause subsequent packets to be dropped from home. Such tunneling SHOULD
employ IPsec ESP in tunnel mode between the home agent and the mobile
node. node,
if they contain the Home Address destination option. This protection situation
is guided by recoverable, since an error message is sent to the IPsec Policy Data Base. mobile node;
however, it causes unnecessary delay in the communications.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 37] 31]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
6.1.8. Binding Acknowledgement (BA) Message
The HoT Binding Acknowledgement message uses is used to acknowledge receipt
of a Binding Update message (Section 6.1.7). When a node receives
a packet containing a Binding Update message, with this node being
the destination of the packet, this node MUST return a Binding
Acknowledgement to the mobile node, if the Acknowledge (A) bit is
set in the the Binding Update. The Binding Acknowledgement message
is sent to the Source Address of the Binding Update message which
is being acknowledged. The packet includes a Routing header if
the Source Address was not the home address of the mobile node, as
described in Sections 10.2 and 9.4.4. The Source Address of the
Binding Acknowledgement is the Destination Address from the Binding
Update.
The Binding Acknowledgement message has the MH Type value 3. 6. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Cookie (128 bits) |
+ +
| |
+ + Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
The two 16-bit
These fields are reserved for future use. These
values unused. They MUST be initialized to zero by
the sender, sender and MUST be ignored by the receiver.
Home Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update. Strictly
speaking, this value is not necessary in
Status
8-bit unsigned integer indicating the authentication,
but allows disposition of the correspondent node to efficiently find
Binding Update. Values of the nonce
value Ni Status field less than 128
indicate that it used in creating the Home Cookie. Without
this field, Binding Update was accepted by the correspondent node would have receiving
node. Values greater than or equal to search through
all currently acceptable nonce values when testing for the
correctness of 128 indicate that
the authenticator sent in a Binding Update.
Mobile cookie
32-bit field which contains mobile cookie 1, returned Update was rejected by the
correspondent receiving node. The
following Status values are currently defined:
0 Binding Update accepted
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Home registration not supported
132 Not home subnet
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 38] 32]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
133 Not home agent for this mobile node
134 Duplicate Address Detection failed
135 Sequence number out of window
136 Route optimization unnecessary due to low traffic
137 Invalid authenticator
138 Expired Home Cookie
This Nonce Index
139 Expired Care-of Nonce Index
Up-to-date values of the Status field contains are to be specified in
the home cookie IANA registry of assigned numbers [18].
Sequence #
The Sequence Number in the return routability
procedure; it Binding Acknowledgement is copied
from the first Sequence Number field in the Binding Update. It used
by the mobile node in matching this Acknowledgement with an
outstanding Binding Update.
Lifetime
The granted lifetime, in time units of two cookies which are to be
processed to form a key 4 seconds, for which
this node SHOULD retain the entry for this mobile node in its
Binding Cache. A value of all one bits (0xffffffff) indicates
infinity.
The value of this field is then used to authenticate a
binding update. undefined if the Status field
indicates that the Binding Update was rejected.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this
message
Binding Acknowledgement message, that need not be present
in all HoT messages. Mobility
options are used to carry that information. The encoding and
format of defined options are described in Section 6.2. Binding Acknowledgements sent. This use of mobility
options also allows for future extensions to the format of the HoT
Binding Acknowledgement message to be defined. This
specification does not define any The following
options are valid for the HoT
message.
The Header Length field in the Mobility Header for this message
MUST be set to 4 (since unit is 8 octets) plus the total length of
all mobility options present (also in 8 octet units). Binding Acknowledgement message:
- Binding Authorization Data option
- Binding Refresh Advice option
If no actual options are present in this message, no 4 bytes of padding is necessary.
6.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is a response to the CoTI message,
necessary and
is sent from the correspondent node Header Len field will be set to the mobile node (see Section
8.2). This message 2.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 33]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The Binding Acknowledgement is always sent with the Source Address set to to the source address of the
Binding Update message, regardless of whether the Binding Update
succeeded or failed. No Routing Headers are added to the message.
6.1.9. Binding Error (BE) Message
The Binding Error (BE) message is used by the correspondent node, node to
signal an error related to mobility, such as an inappropriate attempt
to use the Destination Home Address set destination option without an existing
binding. A packet containing a Binding Error message is sent to the care-of
source address of the mobile node, offending packet. For instance, in the case
of the Home Address destination option error, the packet is the one
that contained the Home Address destination option and therefore
the Binding Error message is sent directly to the care-of address of the
mobile node.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 39]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002 The CoT source address of the Binding Error message is the
correspondent node's address.
The Binding Error message uses the MH Type value 4. 7. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Care-of Cookie (128 bits) |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Status
8-bit unsigned integer indicating the reason for this message.
The two 16-bit fields and following such Status values are currently defined:
1 Home Address destination option used without a binding
2 Received message had an unknown value for the one 32-bit MH Type
field
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 34]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Reserved
A 8-bit field are reserved for future use. These values The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Care-of Nonce Index
This field will be echoed back by the mobile node to the
correspondent node
Home Address
The home address that was contained in a subsequent binding update. It
will allow the correspondent node to select the appropriate
challenge values to authenticate the binding update.
Mobile cookie
32-bit field which contains the Home Address
destination option. The mobile cookie 2, returned by
the correspondent node.
Care-of Cookie
This field contains the care-of cookie in the return
routability procedure; it is the second of two cookies which
are to be processed node uses this information to form a key
determine which is then used to
authenticate a binding update.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 40]
INTERNET-DRAFT Mobility Support does not exist, in IPv6 1 May 2002 cases where the
mobile node has several home addresses.
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
There MAY be additional information, associated with this
message
Binding Error message, that need not be present in all CoT messages. Mobility
options are used to carry that information. The encoding and
format of defined options are described in Section 6.2. Binding
Error messages sent. This use of mobility options also allows
for future extensions to the format of the CoT Binding Error
message to be defined. The encoding and format of defined
options are described in Section 6.2. This specification does
not define any options valid for the CoT Binding Error message.
The Header Length field in the Mobility Header for this message
MUST be set to 4 (since unit is 8 octets) plus the total length of
all mobility options present (also in 8 octet units).
If no actual options are present in this message, no padding is necessary.
6.1.7. Binding Update (BU) Message
The Binding Update (BU) message is used by a mobile node to notify
other nodes of a new care-of address for itself. A packet containing
a Binding Update message is sent with the Source Address set to the
care-of address of the mobile node
necessary and the Destination Address Header Len field will be set to
the correspondent node's address.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 41]
INTERNET-DRAFT 3.
6.2. Mobility Support Options
6.2.1. Format
In order to allow optional fields that may not be needed in IPv6 1 May 2002
The Binding Update message uses every use
of any given Mobility Header, and to allow future extensions to the MH Type value 5. When
format of these messages to be defined, the Mobility Header messages
defined in this value
is indicated document can include one or more mobility options.
Such options are included in the MH Type field, data portion of the format message itself,
after the fixed portion of the Message Data
field message data specified in the Mobility message
subsections of section 6.1.
The presence of such options will be indicated by the Header is Len of
the Mobility Header.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 35]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
These options are encoded within the remaining space of the message
data for that message, using a type-length-value (TLV) format as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
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 |
. .
. Mobility options .
. .
| Option Len | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledge (A)
The Acknowledge (A) bit is set by
Option Type
8-bit identifier of the sending mobile node to
request a Binding Acknowledgement (Section 6.1.8) be returned
upon receipt type of mobility option. When
processing a Mobility Header containing an option for which
the Binding Update.
Home Registration (H)
The Home Registration (H) bit Option Type value is set not recognized by the sending mobile
node to request that the receiving node should act as this
node's home agent. The destination of receiver,
the packet carrying this
message receiver MUST be that of a router sharing quietly ignore and skip over the same subnet prefix
as option,
correctly handling any remaining options in the home address message.
Option Len
8-bit unsigned integer. Length of the mobile node this mobility option, in
octets. The Option Len does not include the binding.
Single Address Only (S)
If the `S' bit is set, length of the mobile node requests
Option Type and Option Len fields.
Option Data
A variable length field that the home
agent make no changes contains data specific to any other Binding Cache entry except
for the particular one containing
option.
The following subsections specify the home address specified Option types which are
currently defined for use in the Home Address destination option. This disables home
agent processing for other related addresses, Mobility Header.
Implementations MUST silently ignore any mobility options that they
do not understand.
6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format
is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is described
in Section 10.2. a special case -- it has
neither Option Len nor Option Data fields.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 42] 36]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit is set by the sending
mobile node to request that the receiving node (the mobile
node's home agent) perform Duplicate Address Detection [33]
on the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection
failed).
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Sequence #
A 16-bit number used by the 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.5). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each
new Binding Update sent or received, as long as the value stays
within the window. A Binding Acknowledgement with Status field
set to 141 (Sequence number out of window) will be returned
if the value is outside the window. Both home agents and
correspondent nodes use the sequence number also to prevent
replay attacks.
Lifetime
32-bit unsigned integer. The number of seconds remaining
before the binding MUST be considered expired. A value of all
one bits (0xffffffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST
be deleted.
Bindings established with correspondent nodes using the return
routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE
seconds.
Home Address
The home address of the mobile node associated with this
Binding Update.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 43]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
A Binding Update sent to a correspondent node MUST include the
following options when the return routability procedure is used
as the authorization method:
- Nonce Indices option. This option contains information the
correspondent node needs in order to find the challenge
values Ni and Nj.
- Binding Authorization Data option. This option contains
a cryptographic hash value which is used to ensure that
it has been sent by the same party who received the HoT
and CoT messages. The authenticator covering a Binding
Update MUST be 96 bits and computed over a string of octets
containing the following fields of the IPv6 header and the
Mobility Header, in order:
* Care-of Address, in the Source Address field of the
IPv6 header
* The address of the correspondent node, in the
Destination Address field of the IPv6 header.
* The contents of the Mobility Header, excluding the
Authenticator field (within the Binding Authorization
Data mobility option) which is not included for the
purposes of calculating the Authenticator. Options of
the Mobility Header are included in the calculation.
The actual authenticator calculation over a sequence of
bits is described in Section 5.5.
There MAY be additional information, associated with this
Binding Update message, that need not be present in all Binding
Updates sent. This use of mobility options also allows for
future extensions to the format of the Binding Update message
to be defined. The following options are valid in a Binding
Update message:
- Unique Identifier option
- Binding Authorization Data option
- Alternate Care-of Address option
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 44]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
The Header Length field in the Mobility Header for this message
MUST be set to 4 (since unit is 8 octets) plus the total length of
all mobility options present (also in 8 octet units). If no actual
options are present in this message, no padding is necessary.
A Binding Update to the home agent MUST include the Home Address
destination option in order to allow for the use of manually keyed
IPsec in the protection of these messages. Note also that as
described in Section 6.3, the Home Address destination option is not
accepted by correspondent nodes that do not have an existing binding
with the sender.
When a packet contains both a Home Address destination Pad1 option and a
Binding Update message, the sender MUST use the same address in both.
The receiver MUST check for equal values and MUST silently discard a
packet that does not pass this test.
The care-of address for the binding given in the Binding Update
message is normally that which was received as the value in the
Source Address field used to insert one octet of padding in the IPv6 header
Mobility Options area of the packet carrying the
Binding Update message. However, a care-of address different from Mobility Header. If more than one octet
of padding is required, the Source Address MAY PadN option, described next, should be specified by including an Alternate Care-of
Address mobility
used rather than multiple Pad1 options.
6.2.3. PadN
The PadN option in the Binding Update message. When such
message is sent to the correspondent node and the return routability
procedure does not have any alignment requirements. Its format
is used as the authorization method, the Care-of Test Init
and Care-of Test messages MUST have been performed for the address in
the Alternate Care-of Address option (not the Source Address). follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Option Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The
contents PadN option is used to insert two or more octets of the Nonce Indices and the Authenticator mobility options
MUST be based on information gained padding in this test.
In any case,
the care-of address MUST NOT be any IPv6 address
which is prohibited for use within Mobility Options area of a Routing Header; thus multicast
addresses, Mobility Header message. For N octets
of padding, the unspecified address, loop-back address, Option Len field contains the value N-2, and link-local
addresses are excluded. Binding Updates indicating any such excluded
care-of address MUST be silently discarded.
The deletion the
Option Data consists of a binding can N-2 zero-valued octets. Option data MUST be indicated
ignored by setting the Lifetime
field to 0 or by setting receiver.
6.2.4. Unique Identifier
The Unique Identifier option has the care-of address alignment requirement of 2n.
Its format is as equal to the home
address (the care-of address can be specified either in an Alternate
Care-of Address mobility 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 = 2 | Length = 2 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier option is valid only in the Binding Update message, if
present, or in the Source Address field in the packet's IPv6 header).
6.1.8. Binding Acknowledgement (BA) Message
The Binding Acknowledgement message is used to acknowledge receipt
of a Refresh
Request, and Binding Update message (Section 6.1.7). When a node receives
a packet containing messages. The Unique Identifier field
contains a Binding Update message, with this node being
the destination of the packet, this node MUST return 16-bit value that serves to uniquely identify a Binding
Acknowledgement
Request among those sent by this Source Address, and to the mobile node, if the Acknowledge (A) bit
is set in the allow the
Binding Update. The Update to identify the specific Binding Acknowledgement Refresh Request to
which it responds.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 45] 37]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
message is sent to the Source
6.2.5. Alternate Care-of Address of the Binding Update message
which is being acknowledged.
The Source Address of the Binding
Acknowledgement is the Destination Alternate Care-of Address from the Binding Update.
The Binding Acknowledgement message option has the MH Type value 6. When
this value is indicated in the MH Type field, the format an alignment requirement of the
Message Data field in the Mobility Header
8n+6. Its format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # Type = 3 | Reserved Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Alternate Care-of Address +
| |
. .
. Mobility options .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
These fields are unused. They MUST be initialized
The Alternate Care-of Address option is valid only in Binding Update
message. The Alternate Care-of Address field contains an address to zero by
the sender and MUST be ignored by the receiver.
Status
8-bit unsigned integer indicating the disposition of
use as the
Binding Update. Values of care-of address for the Status field less binding, rather than 128
indicate that the Binding Update was accepted by using the receiving
node. The following such Status values are currently defined:
0
Binding Update accepted
Values
Source Address of the Status field greater than or equal to 128
indicate that the Binding Update was rejected by packet as the receiving
node. care-of address.
6.2.6. Nonce Indices
The following such Status values are currently defined:
128
Reason unspecified
130
Administratively prohibited
Johnson, Perkins, Arkko Expires Nonce Indices option has an alignment requirement of 2n. Its
format is as follows:
0 1 November 2002 [Page 46]
INTERNET-DRAFT Mobility Support in IPv6 2 3
0 1 May 2002
131
Insufficient resources
132
Home registration not supported
133
Not home subnet
137
Not home agent for this mobile node
138
Duplicate Address Detection failed
141
Sequence number out of window
142
Route optimization unnecessary due to low traffic
143
Invalid authenticator
144
Expired 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 = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index
145
Expired | Care-of Nonce Index
Up-to-date values of |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices option is valid only in the Status Binding Update message,
and only when present together with an Binding Authorization Data
option.
The Home Nonce Index field tells the correspondent node that receives
the message which of the challenge values (Ni) are to be specified in used to
authenticate the most recent "Assigned Numbers" [30].
Sequence # Binding Update.
The Sequence Number in Care-of Nonce Index field tells the Binding Acknowledgement is copied
from correspondent node that
receives the Sequence Number field in message which of the Binding Update being
acknowledged, for use by challenge values (Nj) are to be
used to authenticate the mobile node in matching this
Acknowledgement with an outstanding Binding Update.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 47] 38]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Lifetime
6.2.7. Binding Authorization Data
The granted lifetime, in seconds, for which this node SHOULD
retain the entry for this mobile node in its Binding Cache.
Correspondent nodes should make an effort to honor the
lifetimes, since Authorization Data option has an entry that was garbage collected too early
might cause subsequent packets from the mobile node to be
dropped, if they contained the Home Address destination option.
While this situation alignment requirement of
4n+2. Its format is recoverable since an error message 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 = 5 | Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is
sent to the mobile node, it causes an unnecessary break valid only in the
communications.
Mobile nodes SHOULD send a new Binding Update well before
Refresh Request, Binding Update, and Binding Acknowledgment messages.
The Option Len field contains the
expiration length of this period the authenticator in order
octets.
The Authenticator field contains a cryptographic value which can be
used to extend determine that the lifetime and
not cause a disruption in communications. This is particularly
necessary message in order to prevent packets question comes from being dropped due
to the use of the Home Address destination option without an
existing Binding Cache Entry, and the possibility of clock
drift.
If the node sending the Binding Acknowledgement is serving
as the mobile node's home agent, the Lifetime period also
indicates the period right
authority. Rules for which this node will continue calculating this
service; if value depend on the mobile node requires home agent service from
this node beyond this period, used
authorization procedure. This specification gives the mobile node MUST send a new
Binding Update to it before rules only for
the expiration of return routability procedure. For this period (even
if it is not changing its primary care-of address), in order
to extend the lifetime. The value of procedure, this field is undefined
if the Status field indicates that the Binding Update was
rejected.
Refresh
The recommended interval, option
can only appear in seconds, at which the mobile
node SHOULD send a new Binding Update to this node in order
to "refresh" message and rules for calculating
the mobile node's binding Authenticator value are described in this node's Section 6.1.7.
6.2.8. Binding
Cache. This refreshing of the binding is useful in case the
node fails and loses its cache state. The Refresh period is
determined by the node sending the Advice
The Binding Acknowledgement (the
node caching the binding). If this node Refresh Advice option has an alignment requirement of 2n.
Its format is serving as the
mobile node's home agent, the Refresh value may be set, for
example, based on whether the node stores its 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 = 7 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Cache in
volatile storage or Refresh Advice option is only valid in nonvolatile storage.
If the node sending the Binding
Acknowledgement is not
serving as message, and only on Acknowledgements sent from
the mobile node's 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 reply to a failure of the node, packets from it can still reach home registration. The
Refresh Interval is measured in seconds, and indicates how long
before the mobile node through the mobile node's home agent, causing SHOULD send a new
Binding Update to this node to allow it home registration to recreate this cache the
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 48] 39]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
entry.
home agent. The Refresh Interval MUST be set to indicate a smaller
time interval than the Lifetime value of this field is undefined if the Status
field indicates that the Binding Update was rejected.
Mobility options
Variable-length field of such length that the complete Mobility
Header Acknowledgement.
6.3. Home Address Destination Option
The Home Address destination option is an integer multiple used in a packet sent by a
mobile node while away from home, to inform the recipient of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding the
mobile node's home address.
Multicast addresses, link-local addresses, loopback addresses, IPv4
mapped addresses, and format
of defined options are described in Section 6.2. The receiver the unspecified address, MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this
Binding Acknowledgement message, that need not NOT be present used
within a Home Address option. The Home Address Option MUST NOT
appear more than once in all Binding Acknowledgements sent. This use of mobility
options also allows for future extensions to any given packet, except inside the format payload
part of the
Binding Acknowledgement message to be defined. packet if tunneling is involved.
The following
options are valid for the Binding Acknowledgement message:
- Binding Authorization Data Home Address option
The Header 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 field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
201 = 0xC9
Option Length
8-bit unsigned integer. Length of the option, in octets,
excluding the Mobility Header for this message Option Type and Option Length fields. This field
MUST be set to 3 (since unit is 8 octets) plus the total length 16.
Home Address
The home address of
all mobility options present (also in 8 octet units). If no actual the mobile node sending the packet.
IPv6 requires that options are present appearing in this message, 4 bytes of Pad1 a Hop-by-Hop Options
header or PadN mobility
options are needed to make Destination Options header be aligned in a packet so that
multi-octet values within the length Option Data field of the message a each option fall
on natural boundaries (i.e., fields of width n octets are placed at
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 40]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
an integer multiple of 8.
The Header Length field does include this padding.
The Binding Acknowledgement is sent to n octets from the source address start of the
Binding Update message, regardless header, for
n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home
Address option is 8n+6.
The three highest-order bits of whether the Binding Update
succeeded or failed. No Routing Headers Option Type are added encoded to
indicate specific processing of the message.
If option [11]. For the mobile Home
Address option, these three bits are set to 110, indicating that any
IPv6 node sends a sequence number which is processing this option that does not within recognize the
window of acceptable sequence numbers, then Option
Type must discard the home agent MUST send
back a Binding Acknowledgement with status code 141, and packet and, only if the last
accepted sequence number in packet's Destination
Address was not a multicast address, return an ICMP Parameter
Problem, Code 2, message to the Sequence Number field of packet's Source Address; and that the Binding
Acknowledgement message.
6.1.9. Binding Error (BE) Message
The Binding Error (BE) message is used by
data within the correspondent node to
signal an error related to mobility, such as an inappropriate attempt option cannot change en-route to use the packet's final
destination.
A packet MUST NOT contain more than one Home Address destination option without option, except
that an existing
binding. A encapsulated packet containing [15] MAY contain a Binding Error message is sent to the
source address of the offending packet. For instance, in the case
of the separate Home Address destination
option error, associated with each encapsulating IP header.
The Home Address option MUST be placed as follows:
- After the packet Routing Header, if that header is present
- Before the one Fragment Header, if that contained header is present
- Before the AH Header or ESP Header, if either one of those
headers is present
The inclusion of a Home Address destination option and therefore in a packet
affects the Binding Error message receiving node's processing of only this single packet;
no state is sent to created or modified in the care-of address receiving node as a result
of receiving a Home Address option in a packet. In particular, the
mobile node. The source address
presence of a Home Address option in a received packet MUST NOT alter
the contents of the receiver's Binding Error message is Cache and MUST NOT cause any
changes in the
correspondent node's address. routing of subsequent packets sent by this receiving
node.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 49] 41]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
The Binding Error message
6.4. Routing Header type 2
Mobile IPv6 uses a Routing header to carry the MH Type value 7. When this value Home Address for
packets sent from a correspondent node to a mobile node. The Care of
Address of the mobile node is indicated carried in the MH Type field, IPv6 destination field.
The new Routing header uses a different type than defined for
"regular" IPv6 source routing, enabling firewalls to apply different
rules to source routed packets than to MIPv6. This Routing header
type (Type 2) is restricted to carry only one IPv6 address. All IPv6
nodes which process this Routing header MUST verify that the address
contained within is the node's own home address in order to prevent
packets from being forwarded outside the node.
6.4.1. Routing Header Packet format of the Message Data
field in
The Type 2 Routing header has the Mobility following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
Next Header
8-bit unsigned integer indicating selector. Identifies the reason for this message.
The type of header immediately
following such Status the Routing header. Uses the same values are currently defined:
1
Home Address destination option used without a binding
2
Received message had an unknown value for as the MH Type IPv6
Next Header field
Reserved
A [11].
Hdr Ext Len
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by unsigned integer. Length of the
receiver.
Home Address
The home address that was contained Routing header in the Home Address
destination option. The mobile node uses this information to
determine which binding does
8-octet units, not exist, in cases where including the
mobile node has several home addresses.
Mobility options
Variable-length field of such length that first 8 octets. For the complete Mobility
Header Type
2 Routing header, Hdr Ext Len is an always 2.
Routing Type
8-bit unsigned integer multiple of 8 octets long. Contains one that contains the value 2.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 50] 42]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
There MAY be additional information, associated with this
Binding Error message, that need not be present in all Binding
Error messages sent. This use
Segments Left
8-bit unsigned integer. Number of mobility options also allows
for future extensions route segments remaining;
i.e., number of explicitly listed intermediate nodes still to
be visited before reaching the format final destination. Packets
transmitted through an interface have Segments left is always 1
in this type of the Binding Error
message Routing header.
Reserved
32-bit reserved field. Initialized to be defined. The encoding zero for transmission,
and format ignored on reception.
Home Address
The Home Address of defined
options the destination Mobile Node.
The ordering rules for extension headers in an IPv6 packet are
described in Section 6.2. This specification does
not define any options valid for the Binding Error message. 4.1 of [11]. The Header Length field in the Mobility Header new Routing header (Type 2)
defined for this message
MUST be set to 3 (since unit is 8 octets) plus Mobile IPv6 follows the total length of
all mobility options present (also in 8 octet units). same ordering as other routing
headers. If no actual
options are present in this message, no padding is necessary.
6.2. Mobility Options
6.2.1. Format
In order to allow optional fields that may not be needed in every use
of any given Mobility Header, more than one Routing header (e.g., both a Type 0 and to allow future extensions to a
Type 2 Routing header are present), the
format Type 2 Routing header should
follow all other Routing headers. Otherwise the order of these messages to be defined, any routing
headers is independent of their type and follows [11].
In addition, the Mobility Header
messages general procedures defined in this document by IPv6 for Routing
headers suggest that a received Routing header MAY include one or more mobility
options.
Such options are included be automatically
"reversed" to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the data portion of the received packet is
authenticated [6]. This MUST NOT be done automatically for Type 2
Routing headers.
6.5. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message itself,
after the fixed portion of is used by a
mobile node to initiate the message data specified dynamic home agent address discovery
mechanism, as described in section 6.1. Section 11.3.2. The presence of such options will be indicated by the Header Len of
the Mobility Header.
These options are encoded within the remaining space of the mobile node sends
a Home Agent Address Discovery Request message
data to the "Mobile IPv6
Home-Agents" anycast address for that message, using a type-length-value (TLV) format as
follows: its own home subnet prefix [16].
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 Len Code | Option Data... Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
8-bit identifier of the type of mobility option. When
processing a Mobility Header containing an option for which
the Option Type value is not recognized by the receiver,
the receiver MUST quietly ignore and skip over the option,
correctly handling any remaining options in the message.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 51] 43]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Option Length
8-bit unsigned integer. Length of this mobility option, in
octets. The Option Len does not include the length of the
Option
Type and Option Len fields.
Option Data
A variable length field that contains data specific to the
option.
150 <To Be Assigned by IANA>
Code
0
Checksum
The following subsections specify the Option types which are
currently defined for use ICMP checksum [14].
Identifier
An identifier to aid in the Mobility Header.
Implementations MUST silently ignore any mobility options that they
do not understand.
6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request
message.
Reserved
This field is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! unused. It MUST be initialized to zero by the format of
sender and MUST be ignored by the Pad1 option is a special case -- it has
neither Option Len nor Option Data fields. receiver.
The Pad1 option is used to insert one octet Source Address of padding in the
Mobility Options area of a Mobility Header. If more than Home Agent Address Discovery Request
message packet MUST be one octet of padding is required, the PadN option, described next, should be
used rather than multiple Pad1 options.
6.2.3. PadN
The PadN option does not have any alignment requirements. Its format
is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Option Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - mobile node's current care-of
addresses. The PadN option is used to insert two or more octets of padding in home agent MUST then return the Home Agent Address
Discovery Reply message directly to the Mobility Options area Source Address chosen by the
mobile node. Note that, at the time of a Mobility Header message. For N octets performing this dynamic home
agent address discovery, it is likely that the mobile node is not
registered with any home agent within the specified anycast group.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 52] 44]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
6.6. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a home
agent to respond to a mobile node that uses the dynamic home agent
address discovery mechanism, as described in Section 10.9. One of padding,
the Option Len field contains home agents on the value N, and home link responds to the Option
Data consists mobile node with a
Home Agent Address Discovery Reply message, providing a list of N-2 zero-valued octets. Option data MUST be ignored
by the receiver.
6.2.4. Unique Identifier
The Unique Identifier option has
routers on the alignment requirement of 2n.
Its format is mobile node's home link serving as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 Type | 4 Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
151 <To Be Assigned by IANA>
Code
0
Checksum
The Unique ICMP checksum [14].
Identifier option is valid only in Binding Refresh
Request, HoTI, CoTI, and Binding Update messages.
The Unique
Identifier identifier from the invoking Home Agent Address Discovery
Request message.
Reserved
This field contains a 16-bit value that serves is unused. It MUST be initialized to uniquely
identify a Binding Request among those sent zero by this Source Address,
and to allow the HoTI, CoTI,
sender and Binding Update to identify MUST be ignored by the
specific Binding Refresh Request to which it responds. This matching
of Binding Updates to Binding Refresh Requests is required receiver.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 45]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Home Agent Addresses
A list of addresses of home agents on the
procedure home link for renumbering the home subnet while
mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 46]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.7. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node
to its home agent while it is away from home (Section 10.9.1).
6.2.5. Alternate Care-of Address home. The Alternate Care-of Address option has an alignment requirement purpose of
8n+6. Its format the
message is as follows: to solicit a Mobile Prefix Advertisement from the home
agent, which will allow the mobile node to gather prefix information
about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [13],
or update address(es) according to changes in prefix information
supplied by the home agent.
The Mobile Prefix Solicitation is similar to the Router Solicitation
used in Neighbor Discovery [12], except it is routed from the mobile
node on the visited network to the home agent on the home network by
usual unicast routing rules.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+ +
| Code |
+ Alternate Care-of Address + Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+ + Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of
IP Fields:
Source Address option is valid only in Binding Update
message.
The Alternate Care-of mobile node's care-of address.
Destination Address field contains an
The address of the mobile node's home agent. This home agent
must be on the link which the mobile node wishes to
use as learn
prefix information about.
Hop Limit
Set to an initial hop limit value, similarly to any other
unicast packet sent by the care-of address mobile node.
Authentication Header
If a Security Association for the binding, rather than using IP Authentication Header
exists between the
Source Address of sender and the packet as destination address, then the care-of address.
sender SHOULD include this header. [subject to change]
ICMP Fields:
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 53] 47]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
6.2.6. Nonce Indices
The Nonce Indices option has an alignment requirement of 2n. Its
format 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
Type
152 <To Be Assigned by IANA>
Code
0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum
The Nonce Indices option is valid only ICMP checksum [14].
Identifier
An identifier to aid in the Binding Update message,
and only when present together with an Binding Authorization Data
option.
The Home Nonce Index field tells the correspondent node that receives
the matching a future Mobile Prefix
Advertisement message which of the challenge values (Ni) are to this Mobile Prefix Solicitation
message.
Reserved
This field is unused. It MUST be used initialized to
authenticate zero by the Binding Update.
The Care-of Nonce Index field tells
sender and MUST be ignored by the correspondent receiver.
If the mobile node that receives a Mobile Prefix Advertisement Message
from its home agent (see section 6.8), and the advertisement does not
contain any authentication data, the mobile node MAY nevertheless
send a Binding Update message to its home agent using its new home
address which of has been formed from the challenge values (Nj) newly advertised prefix
information. If there are security concerns that would inhibit
responding to be
used to authenticate the Binding Update.
6.2.7. Binding Authorization Data
The Binding Authorization Data option has an alignment requirement of
4n+2. Its format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 2 + Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is valid only in the Binding
Refresh Request, Binding Update, and Binding Acknowledgment messages.
The Option Len field contains the value 2 + Len, where Len is the
length of unauthenticated advertisements, then the authenticator in octets.
The Authenticator field contains mobile node
SHOULD send a cryptographic Mobile Prefix Solicitation message to its home agent,
with a nonzero Identifier value which that can be used to determine that match a future
advertisement with the solicitation.
The mobile node SHOULD include authentication data along with any
Mobile Prefix Solicitation message in question comes from that it sends to the right home agent.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 54] 48]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
authority. Rules for calculating this value depend on the used
authorization procedure. This specification gives the rules only for
the return routability procedure. For this procedure, this option
can only appear in
6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Binding Update Mobile Prefix Advertisement message and rules for calculating
the Authenticator value are described in Section 6.1.7.
6.3. Home Address Destination Option
The Home Address destination option is used in a packet sent by to a
mobile node while away from home, to inform the recipient of that
packet of distribute prefix information about the mobile node's home address. For packets sent by a
mobile node link
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 IPv6 Destination
Options header of the packet, the correspondent node receiving the
packet is able to substitute traveling away from the mobile node's home address for
this care-of address when processing the packet. network. This makes the
use of the care-of address transparent
will occur in response to the correspondent node
above the Mobile IPv6 support level. Note that multicast addresses,
link-local addresses, loopback addresses, IPv4 mapped addresses,
and the unspecified address, MUST NOT be used within a Home Address
option. The Home Address Option MUST not appear more than once in
any given packet, except inside the payload part of Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited Advertisement sent according to
the packet if
tunneling is involved.
The Home Address option is encoded rules in type-length-value (TLV) format
as follows: Section 10.9.1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+ +
| |
+ Home Address + Code | Checksum |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
201 = 0xC9
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 55]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
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 16.
Home
IP Fields:
Source Address
The home agent's address of as the mobile node sending the packet.
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 would
expect to see it (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]. The alignment requirement [6] for the Home same network prefix)
Destination Address option
If this message is 8n+6.
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 a response to 110, indicating that any IPv6
node processing a Mobile Prefix
Solicitation, this option that does not recognize field contains the Option Type
must discard Source Address
field from that packet. For unsolicited messages,
the packet and, mobile node's care-of address SHOULD be used.
Note that unsolicited messages can only be sent if
the packet's Destination Address
was not mobile node is currently registered with the
home agent.
Authentication Header
An AH header MUST be included unless the mobile node
has yet to configure a multicast address, return an home address.
ICMP Parameter Problem, Fields:
Type
153 <To Be Assigned by IANA>
Code 2,
0
Checksum
The ICMP checksum [14].
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 49]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Identifier
An identifier to aid in matching this Mobile Prefix
Advertisement message to a previous Mobile Prefix Solicitation
message.
Options:
Prefix Information
Each message contains one or more Prefix Information options.
Each option carries the packet's Source Address; and prefix(es) that the data
within the option cannot change en-route mobile node
should use to configure its home address(es). Section 10.9.1
describes which prefixes should be advertised to the packet's final
destination.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] MAY contain a separate Home Address mobile
node.
The Prefix Information option associated is defined in Section 4.6.2
of [12], with each encapsulating IP header. modifications defined in Section 7.2 of this
specification. The Home Address option home agent MUST be placed as follows:
- After use this modified Prefix
Information option to send the Routing Header, if that header is present
- Before aggregate list of home network
prefixes as defined in Section 10.9.1.
The Mobile Prefix Advertisement sent by the Fragment Header, if that header is present
- Before home agent MAY include
the AH Header Source Link-layer Address option defined in RFC 2461 [12], or ESP Header, if either one of those
headers is present
Due to the threat of reflection attacks through the use
Advertisement Interval option specified in Section 7.3.
Future versions of this
option, this specification requires that packets containing Home
Address protocol may define new option types. Mobile
nodes MUST be dropped if there is no corresponding Binding
Cache Entry for that home address with the currently registered
care-of address matching the source address of silently ignore any options they do not recognize and
continue processing the packet. message.
If the
packet Advertisement is dropped, sent in response to a Mobile Prefix
Solicitation, the correspondent nodes SHOULD send home agent MUST copy the Binding
Error Identifier value from that
message to into the source address Identifier field of the packet that contained the
Home Address option (see Section 6.1.9). Advertisement.
The Status field in this home agent MUST NOT send more than one Mobile Prefix
Advertisement message should be set per second to 1. These messages SHOULD be rate-limited. any mobile node.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 56] 50]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
No additional authentication of the Home Address option is
required, except that if the IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the
Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en-route
to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication
of the
7. Modifications to IPv6 header also cover the Home Address option, Neighbor Discovery
7.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the security format of the Source Address field in the IPv6 header is not compromised Router Advertisement
message [12] by the presence addition of a Home Address option. Security issues related to
the Home Address option are discussed further in Section 5. When
attempting single flag bit to verify authentication data in a packet indicate that contains
a Home Address option,
the receiving node MUST make router sending the calculation Advertisement message is serving as if the care-of address were present in the Home Address option,
and the a home address were present in the source IPv6 address field
agent on this link. The format of the IPv6 header. 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 conforms with format represents the calculation following changes over that originally
specified in
section 11.2.2. for Neighbor Discovery [12]:
Home Agent (H)
The inclusion of a Home Address destination option Agent (H) bit is set in a packet
affects Router Advertisement to
indicate that the receiving node's processing of only router sending this single packet;
no state Router Advertisement is created or modified in the receiving node
also functioning as a result
of receiving a Home Address option in a packet. In particular, the
presence of Mobile IP home agent on this link.
Reserved
Reduced from a Home Address option in 6-bit field to a received packet MUST NOT alter 5-bit field to account for the contents
addition of the receiver's Binding Cache and MUST NOT cause any
changes in the routing of subsequent packets sent by this receiving
node. Home Agent (H) bit.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 57] 51]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
6.4. Routing Header type 2
7.2. Modified Prefix Information Option Format
Mobile IPv6 uses requires knowledge of a Routing header to carry the Home Address router's global address for
packets sent from two
reasons:
- To allow a correspondent node home agent (a router) to a mobile node. The Care of
Address learn the address of all
other home agents on the mobile node link for which it is carried providing home
agent service, for use in building its Home Agents List as
part of the IPv6 destination field.
This uses dynamic home agent address discovery mechanism
(Sections 10.9 and 11.3.2).
- To allow a different Routing header type than defined for "regular"
IPv6 source routing, enabling firewalls to apply different rules mobile node to source routed packets than send a Binding Update to MIPv6. This Routing header type
(Type 2) a router on
the link on which its previous care-of address is restricted located, for
purposes of establishing forwarding from this previous care-of
address to carry its new care-of address (Section 11.6.6).
However, Neighbor Discovery [12] only one IPv6 address. All IPv6
nodes which process advertises a router's
link-local address, by requiring this Routing header MUST verify that the address
contained within is to be used as the IP
Source Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to easily
and efficiently advertise its global address, by the node's own home address addition of a
single flag bit in order to prevent
packets from being forwarded outside the node.
6.4.1. Routing Header Packet format of a Prefix Information option for
use in Router Advertisement messages. The Type 2 Routing header has format of the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header Type | Hdr Ext Len=2 Length | Routing Type=2|Segments Left=1| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8-bit selector. Identifies
This format represents the type of header immediately following the Routing header. Uses the same values as the IPv4
Protocol field [10].
Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in
8-octet units, not including the first 8 octets. For the Type
2 Routing header, Hdr Ext Len is always 2.
Routing Type
8-bit unsigned integer changes over that contains the value 2. originally
specified for Neighbor Discovery [12]:
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 58] 52]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 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
Router Address (R)
1-bit router address flag. When set, indicates that the final destination. Packets
transmitted through an interface have Segments left is always 1
Prefix field, in this type of Routing header.
Reserved
32-bit reserved field. Initialized addition to zero for transmission, advertising the indicated prefix,
contains a complete IP address assigned to the sending router.
This router IP address has the same scope and ignored on reception.
Home Address
The Home Address conforms to the
same lifetime values as the advertised prefix. This use of
the destination Mobile Node.
The ordering rules for extension headers in an IPv6 packet are
described Prefix field is compatible with its use in Section 4.1 of [6]. The new Routing header (Type 2)
defined for Mobile IPv6 follows advertising
the same ordering as other routing
headers. If more than one Routing header (e.g., both a Type 0 and a
Type 2 Routing header are present), prefix itself, since prefix advertisement uses only the Type 2 Routing header should
follow all other Routing headers. Otherwise
leading number Prefix bits specified by the order Prefix Length
field. Interpretation of routing
headers this flag bit is thus independent
of their type and follows [6].
In addition, the general procedures defined by IPv6 processing required for Routing
headers suggest that the On-Link (L) and Autonomous
Address-Configuration (A) flag bits.
Reserved1
Reduced from a received Routing header MAY be automatically
"reversed" 6-bit field to construct a Routing header for use in any response
packets sent by upper-layer protocols, if the received packet is
authenticated [6]. This MUST NOT be done automatically for Type 2
Routing headers.
6.5. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a
mobile node 5-bit field to initiate account for the dynamic
addition of the Router Address (R) bit.
In a solicited Router Advertisement, a home agent address discovery
mechanism, as described in Sections 10.9 MUST, and 11.3.2. The mobile
node sends a Home Agent all other
routers SHOULD, include at least one Prefix Information option with
the Router Address (R) bit set. Neighbor Discovery Request message to specifies that,
if including all options in a Router Advertisement causes the
"Mobile IPv6 Home-Agents" anycast address for its own home subnet
prefix [11], and one size of
the home agents responds Advertisement to exceed the mobile node
with link MTU, multiple Advertisements can
be sent, each containing a Home Agent subset of the options [12]. 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 the Router Address Discovery Reply message, providing (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 list single larger unsolicited multicast
Advertisement, at least one of these multiple Advertisements SHOULD
include a Prefix Information option with the routers on Router Address (R) bit
set.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 53]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
7.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the mobile node's home link serving interval at which the
sending router sends unsolicited multicast Router Advertisements.
The format of the Advertisement Interval option is as home agents. 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 Length | Checksum Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 59]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
Type
150 <To Be Assigned by IANA>
Code
0
Checksum
7
Length
8-bit unsigned integer. The ICMP checksum [5].
Identifier
An identifier to aid length of the option (including
the type and length fields) in matching Home Agent Address Discovery
Reply messages to units of 8 octets. The value of
this Home Agent Address Discovery Request
message. field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Advertisement Interval
32-bit unsigned integer. The Source Address of maximum time, in milliseconds,
between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using
the Home Agent Address conceptual router configuration variables defined by
Neighbor Discovery Request
message packet [12], this field MUST be one of the mobile node's current care-of
addresses. The home agent MUST then return the Home Agent Address
Discovery Reply message directly equal to the Source Address chosen by the
mobile node. Note that, at the time of performing value
MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this dynamic home
agent address discovery, it is likely that the option in their Router Advertisements. A
mobile node is not
registered with any home agent within receiving a Router Advertisement containing this option
SHOULD utilize the specified anycast group. Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.4.1.
This option MUST be silently ignored for other Neighbor Discovery
messages.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 60] 54]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
6.6. ICMP
7.4. New Home Agent Address Discovery Reply Message
The ICMP Information Option Format
Mobile IPv6 defines a new Home Agent Address Discovery Reply message is Information option, used in
Router Advertisement messages sent by a home agent to respond advertise
information specific to a mobile node using the dynamic home
agent address discovery mechanism, this router's functionality as described in Sections 10.9
and 11.3.2. The mobile node sends a Home Agent Address Discovery
Request message to the "Mobile IPv6 Home-Agents" anycast address
for its own home subnet prefix [11], and one agent.
The format of the home agents
responds to the mobile node with a Home Agent Address Discovery Reply
message, providing a list of the routers on the mobile node's home
link serving Information option is as home agents. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Length |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ + Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
151 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Identifier
8
Length
8-bit unsigned integer. The identifier from length of the invoking Home Agent Address Discovery
Request message.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 61]
INTERNET-DRAFT Mobility Support option (including
the type and length fields) in IPv6 1 May 2002 units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Addresses
A list of addresses of home agents on Preference
16-bit signed, twos-complement integer. The preference for
the home link agent sending this Router Advertisement, for use in
ordering the
mobile node. The number of addresses present returned to a mobile node in the list is
indicated by the remaining length Home
Agent Addresses field of the IPv6 packet carrying
the a Home Agent Address Discovery Reply
message.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 62]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
6.7. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node
to its home agent while it is away from home. The purpose of the
message Higher values mean more preferable. If this option
is to solicit not included in a Mobile Prefix Router Advertisement from the home
agent, which will allow the mobile node to gather prefix information
about its home network. This information can be used to configure
home address(es) by stateless address autoconfiguration [33],
or update address(es) according to changes in prefix information
supplied by the home agent.
The Mobile Prefix Solicitation is similar to which the Router Solicitation
used in Neighbor Discovery [20], except it Home
Agent (H) bit is routed from the mobile
node on the visited network to set, the preference value for this home agent on the home network by
usual unicast routing rules.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
SHOULD be considered to be 0. Values greater than 0 1 2 3 4 5 6 7 8 9 indicate a
home agent more preferable than this default value, and values
less than 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The mobile node's care-of address.
Destination Address indicate a less preferable home agent.
The address manual configuration of the mobile node's home agent. This home agent
must be on Home Agent Preference value
is described in Section 8.4. In addition, the link which sending home
agent MAY dynamically set the mobile node wishes to learn
prefix information about.
Hop Limit
Set to an initial hop limit Home Agent Preference value, and this message is routed
according to for
example basing it on the rules of a typical unicast packet. A hop
limit number of 64 mobile nodes it is currently suggested [30].
Authentication Header
If a Security Association
serving or on its remaining resources for serving additional
mobile nodes; such dynamic settings are beyond the IP Authentication Header
exists between the sender and scope of
this document. Any such dynamic setting of the destination address, then Home Agent
Preference, however, MUST set the
sender SHOULD include this header. [subject to change]
ICMP Fields: preference appropriately,
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 63] 55]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Type
152 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [5].
Reserved
This field is unused. It MUST be initialized
relative to zero by the
sender and MUST default Home Agent Preference value of 0 that
may be ignored by the receiver.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 64]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
6.8. ICMP Mobile Prefix Advertisement Message Format
A use by some home agents on this link (i.e., a home
agent will send not including a Mobile Prefix Advertisement message Home Agent Information option in its
Router Advertisements will be considered to have a
mobile node to distribute prefix information about Home Agent
Preference value of 0).
Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the
home link
while the mobile node agent in units of seconds. The default value is traveling away from the home network. This
will occur same
as the Router Lifetime, as specified in response to a Mobile Prefix Solicitation with an
Advertisement, or by an unsolicited the main body of the
Router Advertisement sent according message. The maximum value corresponds
to
the rules in Section 10.9.1.
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 18.2 hours. A value of 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address MUST NOT be used. The home agent's address as the mobile node would expect Home Agent
Lifetime applies only to see this router's usefulness as a home
agent; it (i.e., same network prefix)
Destination Address does not apply to information contained in other
message fields or options.
Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which
the Home Agent (H) bit (see Section 7.1) is not set. If this message option
is not included in a response Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to a Mobile Prefix Solicitation,
be the Source Address field from that packet. For same as the Router Lifetime in the Router Advertisement.
If multiple Advertisements are being sent instead of a single
larger unsolicited
messages, multicast Advertisement, all of the mobile node's care-of address SHOULD be used, if
it is currently registered multiple
Advertisements with the home agent. Otherwise, Router Address (R) bit set MUST include this
option with the
mobile node's home address SHOULD same contents, otherwise this option MUST be used.
Authentication Header
An AH header omitted
from all Advertisements.
This option MUST be included unless silently ignored for other Neighbor Discovery
messages.
If both the mobile node has yet Home Agent Preference and Home Agent Lifetime are set
to
configure a home address.
ICMP Fields:
Type
153 <To Be Assigned their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by IANA>
Code
0 this home
agent.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 65] 56]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Checksum
7.5. Changes to Sending Router Advertisements
The ICMP checksum [5].
Options:
Prefix Information
Each message contains one or more Prefix Information options.
Each option carries the prefix(es) Neighbor Discovery protocol specification [12] limits routers to
a minimum interval of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface
(limited 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 to rely on an absence
of advertisements to detect router failure; a separate
Neighbor Unreachability Detection algorithm provides failure
detection."
This limitation, however, is not suitable to providing timely
movement detection for mobile nodes. Mobile nodes detect their
own movement by learning the presence of new routers as the mobile
node
should use moves into wireless transmission range of them (or physically
connects to configure its home address(es). Section 10.9.1
describes which prefixes should a new wired network), and by learning that previous
routers are no longer reachable. Mobile nodes MUST be advertised able to the mobile
node.
The Prefix Information option is defined in Section 4.6.2
of [20], with modifications defined in Section 7.2 of
quickly detect when they move to a link served by a new router, so
that they can acquire a new care-of address and send Binding Updates
to register this
specification. The care-of address with their home agent MUST use this modified Prefix
Information option and to notify
correspondent nodes as needed.
Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes
this limit such that routers MAY send unsolicited multicast Router
Advertisements more frequently. In particular, on network interfaces
where the aggregate list of home router is expecting to provide service to visiting mobile
nodes (e.g., wireless network
prefixes interfaces), or on which it is serving
as defined in Section 10.9.1.
The Mobile Prefix Advertisement sent by the a home agent MAY include to one or more mobile nodes (who may return home and
need to hear its Advertisements), the Source Link-layer Address option defined router SHOULD be configured
with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value,
to allow sending of unsolicited multicast Router Advertisements more
often. Recommended values for these limits are:
- MinRtrAdvInterval 0.05 seconds
- MaxRtrAdvInterval 1.5 seconds
Use of these modified limits MUST be configurable, and specific
knowledge of the type of network interface in RFC 2461 [20], or use SHOULD be taken
into account in configuring these limits for each network interface.
When sending unsolicited multicast Router Advertisements more
frequently than the standard limit on unsolicited multicast
Advertisement Interval option specified in Section 7.3.
Future versions frequency, the sending router need not include all
options in each of this protocol may define new these Advertisements, but it SHOULD include at
least one Prefix Information option types. Mobile
nodes MUST silently ignore any options they do not recognize and
continue processing with the message. Router Address (R) bit
set (Section 7.2) in each.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 66] 57]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7. Modifications
7.6. Changes to IPv6 Sending Router Solicitations
In addition to the limit on routers sending unsolicited multicast
Router Advertisement messages (Section 7.5), Neighbor Discovery
7.1. Modified
defines limits on nodes sending Router Advertisement Message Format 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 modifies relaxes 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 is not configured with any current care-of
address (e.g., the format of mobile node has moved since its previous
care-of address was configured), MAY send more than the defined
Neighbor Discovery limit of MAX_RTR_SOLICITATIONS Router Advertisement
message [20] by
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 addition defined Neighbor Discovery limit of
RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST
be configurable, and specific knowledge of a single flag bit to indicate that the router type of network
interface in use SHOULD be taken into account in configuring this
limit for each network interface. A recommended minimum interval
is 1 second.
- After sending at most MAX_RTR_SOLICITATIONS Router Solicitations,
a mobile node MUST reduce the Advertisement message is serving as rate at which it sends subsequent
Router Solicitations. Subsequent Router Solicitations SHOULD
be sent using a home
agent on this link. binary exponential backoff mechanism, doubling
the interval between consecutive Router Solicitations, up to a
maximum interval. The format maximum interval MUST be configurable and
SHOULD be chosen appropriately based on the characteristics of
the type of network interface in use.
- While still searching for a new default router and care-of
address, a mobile node MUST NOT increase the rate at which it
sends Router Advertisement message
is Solicitations unless it has received a positive
indication (such 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 following changes over from lower network layers) that originally
specified it has moved
to a new link. After successfully acquiring a new care-of
address, the mobile node SHOULD also increase the rate at which
it will send Router Solicitations when it next begins searching
for Neighbor Discovery [20]:
Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to
indicate that the new default router sending this Router Advertisement and care-of address.
- A mobile node that is
also functioning as a Mobile IP home agent on this link.
Reserved
Reduced from a 6-bit field to currently configured with a 5-bit field care-of address
SHOULD NOT send Router Solicitations to account for the
addition of the Home Agent (H) bit. default router
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 67] 58]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global
on its current link, until its movement detection algorithm
(Section 11.4.1) determines that it has moved and that its
current care-of address might no longer be valid.
8. Requirements for two
reasons:
- To allow a home agent (a router) to learn the address Types of all
other home agents IPv6 Nodes
Mobile IPv6 places some special requirements on the link for which it functions
provided by different types of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement is providing home
agent service,
intended to support.
The requirements are set for use in building its Home Agents List as
part of the dynamic following groups of nodes:
- All IPv6 nodes.
- All IPv6 nodes with support for route optimization.
- All IPv6 routers.
- All Mobile IPv6 home agent address discovery mechanism
(Sections 10.9 and 11.3.2). agents.
- To allow a All Mobile IPv6 mobile node to send a Binding Update to a router on
the link on which its previous care-of address nodes.
It is located, for
purposes outside the scope of establishing forwarding from this previous care-of
address specification to its new care-of address (Section 11.6.6).
However, Neighbor Discovery [20] specify which
of these groups are mandatory in IPv6. We only advertises describe what is
mandatory for a router's
link-local address, by requiring this address node that supports, for instance, route optimization.
Other specifications are expected to be used as define the IP
Source Address extent of each Router Advertisement.
Mobile IPv6.
8.1. General Requirements for All IPv6 extends Neighbor Discovery to allow Nodes
Any IPv6 node may at any time be a router to easily
and efficiently advertise its global address, by the addition correspondent node of a
single flag bit in the format of mobile
node, either sending a Prefix Information option packet to a mobile node or receiving a
packet from a mobile node. The following requirements are necessary
for
use in Router Advertisement messages. every IPv6 node (whether host or router, whether mobile or
stationary), since otherwise communications may be impossible:
- The format of the Prefix
Information node MUST be able to validate a Home Address option is received
in any IPv6 packet 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents described in Section 9.2.2.
- The node MUST be able to send a Binding Error message as
described in Section 9.4.6.
8.2. Route Optimization Requirements for All IPv6 Nodes
The ability of a correspondent node to participate in route
optimization is essential for the following changes over that originally
specified efficient operation of the IPv6
Internet, beneficial for Neighbor Discovery [20]: robustness and reduction of jitter and
latency, and necessary to avoid congestion in the home network.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 68] 59]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
Router Address (R)
1-bit router address flag. When set, indicates
The following requirements apply to all nodes that the
Prefix field, in addition support route
optimization:
- The node MUST be able to advertising the indicated prefix,
contains participate in a complete IP address assigned return routability
procedure (Section 9.3).
- The node MUST be able to the sending router.
This router IP address has the same scope and conforms process Binding Update messages
(Section 9.4).
- The node MUST be able to the
same lifetime values as the advertised prefix. This use return a Binding Acknowledgement message
(Section 6.1.8).
- The node MUST be able to maintain a Binding Cache of the Prefix field is compatible with its use
bindings received in advertising
the prefix itself, since prefix advertisement uses only the
leading number Prefix bits specified by the Prefix Length
field. Interpretation of this flag bit is thus independent
of the processing required for the On-Link (L) accepted Binding Updates, as described in
Sections 9.1 and Autonomous
Address-Configuration (A) flag bits.
Reserved1
Reduced from 9.5.
- The node MUST be able to insert a 6-bit field Routing Header type 2 into
packets to be sent to a 5-bit field mobile node, as described in Section 9.6.
- The node SHOULD be able to account interpret ICMP messages as described
in Section 9.7.
8.3. Requirements for the
addition of the Router Address (R) bit.
In a solicited Router Advertisement, All IPv6 Routers
All IPv6 routers, even those not serving as a home agent MUST, and all other
routers SHOULD, include at least one Prefix Information for
Mobile IPv6, have an effect on how well mobile nodes can communicate:
- Every IPv6 router SHOULD be able to send an Advertisement
Interval option with
the Router Address (R) bit set. Neighbor Discovery specifies that,
if including all options (Section 7.3) in a Router Advertisement causes the size each of
the Advertisement to exceed the link MTU, multiple its Router
Advertisements can
be sent, each containing a subset [12], to aid movement detection by mobile nodes
(as in Section 11.4.1). The use of the options [20]. In this case,
at least one of these multiple option in Router
Advertisements being sent instead
of a single larger solicited Advertisement, MUST include a Prefix
Information option with the be configurable.
- Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Address (R) bit set.
All routers Advertisements at the faster rate described in
Section 7.5. The use of this faster rate MUST be configurable.
- Each router SHOULD include at least one Prefix Information option prefix with the Router Address (R) `R' bit set,
set and with its full IP address 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 its router advertisements (as
described in Section 7.2).
- Filtering routers SHOULD
include a Prefix Information option with the Router Address (R) bit
set. support different rules for Type 0 and
Type 2 Routing headers (see Section 6.4) so that filtering of
source routed packets (Type 0) will not necessarily limit MIPv6
traffic which is delivered via Type 2 Routing headers.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 69] 60]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7.3. New Advertisement Interval Option Format
Mobile
8.4. Requirements for IPv6 defines Home Agents
In order for a new Advertisement Interval option, used in
Router Advertisement messages mobile node to advertise the interval operate correctly while away from home,
at which the
sending least one IPv6 router sends unsolicited multicast Router Advertisements.
The format of on the Advertisement Interval option is mobile node's home link must function
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. a home agent for the mobile node. The length following additional
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 the option (including home
agent (Section 10.1). Each such Binding Cache entry records the type
mobile node's binding with its primary care-of address and length fields) is
marked as a "home registration" (Section 10.2).
- Every home agent MUST be able to intercept packets (using
proxy Neighbor Discovery [12]) addressed to a mobile node for
which it is currently serving as the home agent, on that mobile
node's home link, while the mobile node is away from home
(Section 10.4).
- Every home agent MUST be able to encapsulate [15] such
intercepted packets in units of 8 octets. The value order to tunnel them to the primary
care-of address for the mobile node indicated in its binding in
the home agent's Binding Cache (Section 10.5).
- Every home agent MUST support decapsulating [15] reverse tunneled
packets sent to it from a mobile node's home address. Every home
agent MUST also check that the source address in the tunneled
packets corresponds to the currently registered location of
this field the
mobile node (Section 10.6).
- Every home agent MUST be 1.
Reserved
This field able to return a Binding Acknowledgement
message in response to a Binding Update option received with the
Acknowledge (A) bit set (Section 10.2).
- Every home agent MUST maintain a separate Home Agents List for
each link on which it is unused. It serving as a home agent, as described in
Section 4.5.
- Every home agent MUST be initialized able to accept packets addressed to zero by
the
sender "Mobile IPv6 Home-Agents" anycast address for the subnet
on which it is serving as a home agent [16], and MUST be ignored by the receiver.
Advertisement Interval
32-bit unsigned integer. The maximum time,
able to participate in milliseconds,
between successive unsolicited router Router Advertisement
messages dynamic home agent address discovery
(Section 10.9).
- Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to be sent
by this router on this network interface. Using home agent in the conceptual router configuration variables defined by
Neighbor Discovery [20], this Home Agent Preference field MUST be equal to of the value
MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option Home
Agent Information Option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for Advertisements that router
in its movement detection algorithm, as described in Section 11.4.1.
This option MUST be silently ignored for other Neighbor Discovery
messages. it sends
(Section 7.4).
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 70] 61]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used in
Router Advertisement messages sent by a
- Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to advertise
information specific to this router's functionality as a Mobile Prefix
Solicitations (Section 6.7). This behavior MUST be configurable,
so that home agent.
The format of agents can be configured to avoid sending such
Prefix Advertisements according to the Home Agent 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
8-bit unsigned integer. The length needs of the option (including
the type and length fields) network
administration in units of 8 octets. The value the home domain.
8.5. Requirements for IPv6 Mobile Nodes
Finally, the following requirements apply to all IPv6 nodes capable
of
this field functioning as mobile nodes:
- Every IPv6 mobile node MUST be 1.
Reserved
This field is unused. It able to perform IPv6 encapsulation
and decapsulation [15].
- Every IPv6 mobile node MUST support the return routability
procedure (Section 5.2.5).
- Every IPv6 mobile node MUST be initialized able to zero by the
sender send Binding Update
messages, as specified in Sections 11.6.1, 11.6.2, and 11.6.6.
- Every IPv6 mobile node 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 in
ordering the addresses returned able to a receive and process
Binding Acknowledgement messages, as specified in Section 11.6.3.
- Every IPv6 mobile node MUST maintain a Binding Update List in
which it records the Home
Agent Addresses field IP address of each other node to which it
has sent a Home Agent Address Discovery Reply
message. Higher values mean more preferable. If this option
is not included in a Router Advertisement in Binding Update, for which the Home
Agent (H) bit is set, the preference value for this home agent
SHOULD be considered to be 0. Values greater than 0 indicate Lifetime sent in that
binding has not yet expired (Section 11.1).
- Every IPv6 mobile node MUST support receiving a
home agent more preferable than this default value, and values
less than 0 indicate Binding Refresh
Request (Section 6.1.2), by responding with a Binding Update
message.
- Every IPv6 mobile node MUST support sending packets containing a
Home Address option (Section 11.2.1).
- Every IPv6 mobile node MUST maintain a less preferable home agent.
The manual configuration of the Home Agent Preference value
is Agents List, as
described in Section 8.3. In addition, the sending 4.5.
- Every mobile node MUST support receiving Mobile Prefix
Advertisements (Section 11.3.4) and reconfiguring its home
agent MAY dynamically set the Home Agent Preference value, for
example basing it
address based on the number of mobile nodes it is currently
serving or on its remaining resources for serving additional prefix information contained therein.
- Every IPv6 mobile nodes; such dynamic settings are beyond the scope of
this document. Any such dynamic setting node SHOULD support use of the Home Agent
Preference, however, MUST set the preference appropriately, dynamic
home agent address discovery mechanism, as described in
Section 11.3.2.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 71] 62]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
relative
9. Correspondent Node Operation
This section explains the special processing required for the return
routability and binding procedures, as well as to manage the default Home Agent Preference value of 0 that
may be in use by some home agents on this link (i.e., binding
cache, handle ICMP messages and send packets to a home
agent not including mobile node.
9.1. Conceptual Data Structures
Each IPv6 node maintains a Home Agent Information option in its
Router Advertisements will Binding Cache of bindings for other nodes.
A separate Binding Cache SHOULD be considered to have a Home Agent
Preference value maintained by each IPv6 node for
each of 0).
Home Agent Lifetime
16-bit unsigned integer. its IPv6 addresses. The lifetime associated Binding Cache MAY be implemented in
any manner consistent with the
home agent external behavior described in units of seconds. The default value is this
document, for example by being combined with the same node's Destination
Cache as maintained by Neighbor Discovery [12]. When sending a
packet, the Router Lifetime, as specified in Binding Cache is searched before the main body of Neighbor Discovery
conceptual Destination Cache [12] (i.e., any Binding Cache entry for
this destination SHOULD take precedence over any Destination Cache
entry for the
Router Advertisement message. same destination).
Each Binding Cache entry conceptually contains the following fields:
- The maximum value corresponds
to 18.2 hours. A value home address of 0 MUST NOT be used. The Home Agent
Lifetime applies only to the mobile node for which this router's usefulness is the Binding
Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent.
If the destination address of the packet matches the home
agent; it does not apply to information contained address
in other
message fields or options.
Home agents MAY include the Binding Cache entry, this option in their Router Advertisements.
This option MUST NOT entry SHOULD be included in a Router Advertisement used in which routing
that packet.
- The care-of address for the Home Agent (H) bit (see Section 7.1) is not set. If this option
is not included mobile node indicated by the home
address field in this Binding Cache entry. If the destination
address of a Router Advertisement packet being routed by a node matches the home
address in which this entry, the Home Agent (H)
bit packet SHOULD be routed to this
care-of address. This is set, the lifetime described in Section 9.6 for packets
originated by this node, and in Section 10.5 if this node is the
mobile node's home agent MUST be considered to
be and the same as packet was intercepted by it on
the Router Lifetime in home link.
- A lifetime value, indicating the Router Advertisement.
If multiple Advertisements are being sent instead of a single
larger unsolicited multicast Advertisement, all of remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from
the multiple
Advertisements with Lifetime field in the Router Address (R) bit set MUST include Binding Update that created or last
modified this
option with Binding Cache entry. Once the same contents, otherwise lifetime of this option
entry expires, the entry MUST be omitted deleted from all Advertisements.
This option MUST be silently ignored for other Neighbor Discovery
messages.
If both the Home Agent Preference and Home Agent Lifetime are set
to their default values specified above, Binding Cache.
- A flag indicating whether or not this option SHOULD NOT be
included in Binding Cache entry is a
"home registration" entry.
- The maximum value of the Router Advertisement messages sent by Sequence Number field received in
previous Binding Updates for this mobile node home
agent. address.
The Sequence Number field is 16 bits long, and all comparisons
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 72] 63]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7.5. Changes
between Sequence Number values MUST be performed modulo 2**15 as
explained in Section 9.4.1.
- Recent usage information for this Binding Cache entry, as needed
to Sending Router Advertisements
The Neighbor Discovery protocol specification [20] limits routers implement the cache replacement policy in use in the Binding
Cache and to assist in determining whether a minimum interval Binding Refresh
Request should be sent when the lifetime of 3 seconds between sending unsolicited multicast
Router Advertisement messages from this entry nears
expiration.
Binding Cache entries not marked as "home registrations" MAY be
replaced at any given network interface
(limited time by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough
that hosts will learn of their presence within a few
minutes, any reasonable local cache replacement policy
but not frequently enough to rely on an absence SHOULD NOT be unnecessarily deleted. The Binding Cache for any
one of advertisements to detect router failure; a separate
Neighbor Unreachability Detection algorithm provides failure
detection."
This limitation, however, is not suitable to providing timely
movement detection node's IPv6 addresses may contain at most one entry for mobile nodes. Mobile nodes detect their
own movement by learning the presence of new routers as the
each mobile node moves into wireless transmission range home address. The contents of them (or physically
connects to a new wired network), and by learning that previous
routers are no longer reachable. Mobile nodes node's Binding
Cache MUST NOT be able to
quickly detect when they move changed in response to a link served by Home Address option in
a new router, so
that they can acquire received packet. The contents of all of a new care-of address and send node's Binding Updates
to register this care-of address Cache
entries, for each of its IPv6 addresses, MUST be cleared when the
node reboots.
9.2. Receiving Packets from a Mobile Node
Packets sent by a mobile node with their home agent and to notify either a Home Address destination
option or a Mobility Header (or both) require special processing at
the correspondent nodes node as needed.
Thus, to provide good support for mobile nodes, Mobile explained below.
9.2.1. Processing Mobility Header (MH) Messages
All IPv6 relaxes
this limit such that routers MAY send unsolicited multicast Router
Advertisements more frequently. In particular, on network interfaces
where the router is expecting to provide service to visiting mobile correspondent nodes (e.g., wireless network interfaces), or on which it MUST observe the following rules when
processing Mobility Header messages:
1. If an MH message of unknown type is serving
as received (Section 6.1, the
correspondent node SHOULD issue a home agent to one or more mobile nodes (who may return home and
need Binding Error message to hear its Advertisements), the router SHOULD be configured
packet's Source Address with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, Status field set to allow sending of unsolicited multicast Router Advertisements more
often. Recommended values for these limits are:
- MinRtrAdvInterval 0.05 seconds
- MaxRtrAdvInterval 1.5 seconds
Use of these modified limits 2. Finally, the
correspondent node MUST be configurable, and specific
knowledge of discard the type of network interface in use SHOULD be taken
into account in configuring these limits for each network interface.
When sending unsolicited multicast Router Advertisements more
frequently than packet.
2. If the standard limit "Next Header" field is not NO_NXTHDR (59 decimal), the
packet MUST be silently discarded.
3. The checksum must be verified as per Section 6.1.
Subsequent checks depend on unsolicited multicast
Advertisement frequency, the sending router need not include all
options particular Mobility Header message,
as specified in each of these Advertisements, but it SHOULD include at
least one Prefix Information option with Sections 9.3 and 9.4. Subsequent checks depend
on the Router Address (R) bit
set particular Mobility Header message. There are two types
of Mobility Header messages. The return routability procedure
(Section 7.2) in each. 9.3) is used to verify liveness of the mobile node at both
its home address as well as its care-of address. These liveness
probes are used to secure binding updates.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 73] 64]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
7.6. Changes to Sending Router Solicitations
In addition to the limit on routers sending unsolicited multicast
Router Advertisement
The other type of Mobility Header messages are directly concerned
with managing bindings (Section 7.5), Neighbor Discovery
defines limits on nodes sending Router Solicitation messages, such
that a 9.4).
9.2.2. Receiving Packets with Home Address Destination Option
If the correspondent 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 has a Binding Cache Entry for the home
address of a mobile node, packets sent by the mobile node from finding a new
default router (and thus a new care-of address) quickly as it moves
about.
Mobile IPv6 relaxes this limit such that, while MAY include
a mobile Home Address destination option. The correspondent node is away MUST
process the option in a manner consistent with exchanging the Home
Address field from home, the Home Address option into the IPv6 header and
replacing the original value of the Source Address field there.
After all IPv6 options have been processed, it MUST be possible to
process the packet without the knowledge that it MAY send Router Solicitations more frequently. The
following limits for sending Router Solicitations are recommended for
mobile nodes while away came originally from home:
- A mobile node that is not configured with any current care-of
address (e.g., the mobile node has moved since its previous
a care-of address or that a Home Address option was configured), MAY send more than used.
Due to the defined
Neighbor Discovery limit threat of MAX_RTR_SOLICITATIONS Router
Solicitations.
- The rate at which reflection attacks, this specification requires
that packets containing a mobile node sends Router Solicitations Home Address option MUST be limited, although a mobile node MAY send Router Solicitations
more frequently than dropped if
there is no corresponding Binding Cache Entry for the defined Neighbor Discovery limit of
RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST
be configurable, given home
address and specific knowledge of the type packet was not protected by IPsec. A corresponding
Binding Cache Entry MUST have the currently registered care-of
address equal to the source address of network
interface in use SHOULD be taken into account in configuring this
limit for each network interface. the packet. A recommended minimum interval packet that
contains a Binding Update message and a Home Address option is 1 second.
- After sending at most MAX_RTR_SOLICITATIONS Router Solicitations,
considered to pass the above tests if the Binding Update successfully
creates or updates a mobile node MUST reduce Binding Cache Entry.
If the rate at which it sends subsequent
Router Solicitations. Subsequent Router Solicitations packet is dropped due the above tests, the correspondent nodes
SHOULD
be sent using a binary exponential backoff mechanism, doubling send the interval between consecutive Router Solicitations, up Binding Error message to a
maximum interval. the source address of the
packet that contained the Home Address option (see Section 6.1.9).
The maximum interval MUST Status field in this message should be configurable and set to 1. These messages
SHOULD be chosen appropriately based on the characteristics rate-limited.
No additional authentication of the type Home Address option is
required, except that if the IPv6 header of network interface in use.
- While still searching for a new default router and care-of
address, a mobile node packet is covered
by authentication, then that authentication MUST NOT increase also cover the rate at which it
sends Router Solicitations unless
Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since
it has received a positive
indication (such as from lower network layers) indicates that it has moved
to a new link. After successfully acquiring a new care-of
address, the mobile node SHOULD also increase data within the rate at which
it will send Router Solicitations when it next begins searching
for a new default router option cannot change en-route
to the packet's final destination, and care-of address.
- A mobile node thus the option is included in
the authentication computation. By requiring that any authentication
of the IPv6 header also cover the Home Address option, the security
of the Source Address field in the IPv6 header is currently configured with not compromised by
the presence of a Home Address option. Security issues related to
the Home Address option are discussed further in Section 5. When
attempting to verify authentication data in a packet that contains
a Home Address option, the receiving node MUST make the calculation
as if the care-of address
SHOULD NOT send Router Solicitations to were present in the default router Home Address option,
and the home address were present in the source IPv6 address field
of the IPv6 header. This conforms with the calculation specified in
section 11.2.2.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 74] 65]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
on it current link, until its movement detection algorithm
(Section 11.4.1) determines that it has moved and that its
current care-of address might no longer be valid.
8. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions
provided by different types of IPv6 nodes.
9.3. Return Routability Procedure
This section summarizes
those requirements, identifying the functionality each requirement
is intended to support. Further details on this functionality is
provided in the following sections.
8.1. Requirements for All IPv6 Hosts and Routers
Since any IPv6 node may at any time be subsection specifies actions taken by a correspondent node of a
mobile node, either sending a packet to a mobile node or
during the return routability procedure.
9.3.1. Receiving Home Test Init Messages
Upon receiving a
packet from a mobile node, Home Test Init message, the following requirements apply to ALL
IPv6 nodes (whether host or router, whether mobile or stationary):
- Every IPv6 correspondent node
verifies the following:
- MH Type field for this message is 1.
- The Header Extension Length field MUST be able greater than or equal
to process the length specified in Section 6.1.3.
- The packet MUST NOT include a Home Address option
received in any IPv6 packet.
- Every IPv6 destination option.
In preparation for sending the corresponding Home Test Message,
the correspondent node SHOULD be able checks that it has the necessary material
to participate engage in a return routability procedure, process Binding Update messages, and to
return a Binding Acknowledgement option if the Acknowledge (A)
bit is set as specified in
Section 5.2. For that procedure, the received Binding Update.
- Every IPv6 correspondent node SHOULD be able to maintain MUST have a Binding Cache of the
bindings received in accepted Binding Updates.
8.2. Requirements for All IPv6 Routers
The following requirements apply to all IPv6 routers, even those
secret Kcn and a nonce Nj. If it does not
serving as have this material yet,
it MUST produce it before continuing with the return routability
procedure.
Section 9.3.3 specifies further processing.
9.3.2. Receiving Care-of Test Init Messages
Upon receiving a home agent Care-of Test Init message, the correspondent node
verifies the following:
- MH Type field for Mobile IPv6: this message is 2.
- Every IPv6 router SHOULD The Header Extension Length field MUST be able greater than or equal
to send an Advertisement
Interval option the length specified in each of its Router Advertisements, to aid
movement detection by mobile nodes. Section 6.1.4.
- The use of this option in
Router Advertisements packet MUST be configurable.
- Every IPv6 router SHOULD be able to support NOT include a Home Address destination option.
In preparation for sending unsolicited
multicast Router Advertisements at the faster rate described corresponding Care-of Test Message,
the correspondent node checks that it has the necessary material
to engage in a return routability procedure, as specified in
Section 7.5. The use of 5.2. For that procedure, the correspondent node MUST have a
secret Kcn and a nonce Nl. If it does not have this faster rate material yet,
it MUST be configurable.
- Each router SHOULD include at least one prefix produce it before continuing with the 'R' bit
set and with its full IP address in its router advertisements. return routability
procedure.
Section 9.3.4 specifies further processing.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 75] 66]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
- Filtering routers SHOULD support different rules for Type 0 and
Type 2 Routing headers so that filtering of source routed packets
(Type 0) will not necessarily limit MIPv6 traffic via Type 2
Routing headers.
8.3. Requirements for IPv6
9.3.3. Sending Home Agents
In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on Test Messages
Unless already created, the mobile node's home link must function
as correspondent node creates a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers capable of serving as "Home
Cookie" and an associated "Home Nonce Index". It then creates a home
agent:
- Every home agent MUST be able Home
Test message (Section 6.1.5) and sends it to maintain an entry in its Binding
Cache for each the mobile node for which it is serving as at the
latter's home
agent. Each such Binding Cache entry records address.
9.3.4. Sending Care-of Test Messages
Unless already created, the mobile node's
binding with its primary care-of address and is marked as correspondent node creates a "home
registration".
- Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery) addressed to "Care-of
Cookie" and an associated "Care-of Nonce Index". It then creates a mobile node for which
Care-of Test message (Section 6.1.6) and sends it is
currently serving as the home agent, on that mobile node's home
link, while to the mobile node is away from home.
- Every home agent MUST be able to encapsulate such intercepted
packets in order to tunnel them to
at the primary latter's care-of address
for address.
9.4. Processing Bindings
This section explains how the mobile correspondent node indicated in its binding in processes the home agent's
binding cache messages. These messages are:
- Binding Cache. Update
- Every home agent MUST support decapsulating reverse tunneled
packets sent to it from Binding Refresh Request
- Binding Acknowledgement
- Binding Error
9.4.1. Receiving Binding Updates
Before accepting a mobile node's home address. Every home
agent MUST also check that Binding Update message, the source address in receiving node MUST
validate the tunneled
packets corresponds Binding Update according to the currently registered location of the
mobile node. following tests:
- Every home agent The packet MUST be able to return contain a Binding Acknowledgement
message Home Address option.
- The Header Len field in response to a the Binding Update option received with the
Acknowledge (A) bit set.
- Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described greater than
or equal to the length specified in Section 4.5. 6.1.7.
- Every The Sequence Number field in the Binding Update message is
greater than the Sequence Number received in the previous Binding
Update for this home agent address, if any.
This Sequence Number comparison MUST be able to accept packets addressed to
the "Mobile IPv6 Home-Agents" anycast address for performed modulo 2**16,
i.e., the subnet
on which it number is serving as a home agent [11], and MUST be
able free running counter represented modulo
65536. A Sequence Number in a received Binding Update is
considered less than or equal to participate the last received number if
its value lies in dynamic home agent address discovery
(Section 10.9). the range of the last received number and the
preceding 32767 values, inclusive. For example, if the last
received sequence number was 15, then messages with sequence
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 76] 67]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
- Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to
numbers 0 through 15, as well as 32784 through 65535, would be sent
by this home agent in
considered less than or equal.
When the Home Agent Preference field of return routability procedure is used as an authorization
method, the Home
Agent Information Option in Router Advertisements that it sends. following are also required:
- Every home agent SHOULD support sending ICMP Mobile
Prefix Advertisements, The Home and SHOULD respond to Mobile Prefix
Solicitations.
8.4. Requirements for IPv6 Mobile Nodes
Finally, Care-of Nonce Index values in the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes:
- Every IPv6 mobile Nonce Indices
mobility option are recognized by the correspondent node. As
described in Section 5.2, the correspondent node MUST be able to perform IPv6 encapsulation
and decapsulation [4]. discards Nonce
values that are too old.
- Every IPv6 mobile The correspondent node MUST support re-generate the return routability
procedure Home Cookie and sending Binding Update messages, as specified the
Care-of Cookie from the information contained in
Sections 11.6.1, 11.6.2, and 11.6.6; the packet.
It then generates the session key Kbu and MUST be able uses it to receive
and process verify
the authenticator field in the Binding Acknowledgement messages, Update as specified in
Section 11.6.3.
- Every IPv6 mobile 6.1.7. Note that a care-of address different from the
Source Address MAY have been specified by including an Alternate
Care-of Address mobility option in the Binding Update message.
When such message is received and the return routability
procedure is used as an authorization method, the correspondent
node MUST support use of verify the authenticator by using the dynamic home agent address discovery mechanism, as described within
the Alternate Care-of Address in Section 11.3.2. the calculations.
- Every IPv6 The Binding Authorization Data option MUST be present, and its
contents MUST be satisfy rules presented in Section 5.2.6.
If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the
receiving node MUST maintain send back a Binding Update List Acknowledgement with status
code 141, and the last accepted sequence number in
which it records the IP address Sequence
Number field of each other the Binding Acknowledgement.
If the mobile node to which it
has sent sends a Binding Update, for Home or Care-of Nonce Index value which is
no longer recognized by the Lifetime sent in that
binding has not yet expired.
- Every IPv6 mobile correspondent node, then the receiving
node MUST support receiving send back a Binding Refresh
Request, by responding Acknowledgement with a status code 144 or
145, respectively.
Any Binding Update which fails to satisfy all of these tests for
any reason other than insufficiency of the Sequence Number or Nonce
Indices MUST be silently ignored, and the packet carrying the Binding
Update message.
- Every IPv6 mobile node MUST support sending packets containing a
Home Address option. This option MUST be included in all packets
sent discarded.
In this section, the care-of address refers to a correspondent node the IPv6 address,
which was originally located in the IPv6 header when the following three conditions
apply: The correspondent node has a binding with this packet was
transmitted by the mobile node. The mobile node
If the Binding Update is away from home. The packet would
otherwise have been sent with valid according to the mobile node's home address as tests above, then the IP Source Address.
- Every IPv6 mobile node MUST maintain a Home Agents List,
Binding Update is processed further as
described in Section 4.5. follows:
- Every mobile node MUST support receiving Mobile Prefix
Advertisements If the Lifetime specified in the Binding Update is nonzero and reconfiguring its
the specified Care-of Address is not equal to the home address based on the
prefix information contained therein.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 77] 68]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
9. Correspondent Node Operation
This section explains the special processing required
for the return
routability and binding procedures, as well as to manage the binding
cache, handle ICMP messages and send packets binding, then this is a request to cache a binding for
the mobile node.
9.1. Conceptual Data Structures
Each IPv6 node maintains a Binding Cache 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 If the external behavior described Home Registration (H) bit is set in this
document, for example by being combined with the node's Destination
Cache as maintained by Neighbor Discovery [20]. When sending a
packet, the
Binding Cache is searched before Update, the Neighbor Discovery
conceptual Destination Cache [20] (i.e., any Binding Cache entry for
this destination SHOULD take precedence over any Destination Cache
entry for Update is processed according to the same destination).
Each Binding Cache entry conceptually contains
procedure specified in Section 10.2; otherwise, it is processed
according to the following fields: procedure specified in Section 9.4.2.
- The home address of If the mobile node for which this is Lifetime specified in the Binding
Cache entry. This field Update is used as zero or the key for searching
specified Care-of Address matches the
Binding Cache home address for the destination address of
binding, then this is a packet being sent.
If the destination address of request to delete the packet matches mobile node's
cached binding. If the home address Home Registration (H) bit is set in the
Binding Cache entry, this entry SHOULD be used in routing
that packet.
- The care-of address for Update, the mobile node indicated by Binding Update is processed according to the home
address field
procedure specified in this Binding Section 10.3; otherwise, it is processed
according to the procedure specified in Section 9.4.3.
9.4.2. Requests to Cache entry. If a Binding
This section describes the destination
address processing of a packet being routed by valid Binding Update that
requests a node matches to cache a mobile node's binding, for which the home
address Home
Registration (H) bit is not set in the Binding Update.
In this entry, case, the packet receiving node SHOULD be routed to this
care-of address, as described create a new entry in Section 9.6, its
Binding Cache for packets
originated by this mobile node, or in Section 10.5, if update its existing Binding
Cache entry for this node is the mobile node's home agent and the packet was intercepted by it on
the home link.
- A lifetime value, indicating the remaining node, if such an entry already exists.
The lifetime for this the Binding Cache entry. The lifetime value entry is initialized from the
Lifetime field specified in the Binding Update that created or last
modified Update, although this Binding Cache entry. Once
lifetime MAY be reduced by the node caching the binding; the lifetime of this
entry expires,
for the Binding Cache entry MUST NOT be deleted from greater than the Lifetime
value specified in the Binding Cache.
- A flag indicating whether or not this Binding Cache entry is a
"home registration" entry.
- A flag indicating whether or not this Update. Any Binding Cache entry
represents MUST
be deleted after the expiration of its lifetime.
The Sequence Number value received from a mobile node that should be advertised as a router in
proxy Neighbor Advertisements sent a Binding
Update is stored by this a correspondent node on its behalf.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 78]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
This flag is only valid if the its Binding Cache entry indicates that
this is a "home registration" entry.
- The length of the routing prefix
for that mobile node. If the home address. This
field is only valid if the "home registration" flag is set on
this receiving correspondent node has no
Binding Cache entry.
- The maximum value of the Sequence Number field received in
previous Binding Updates entry for this the sending mobile node home address.
The Sequence Number field is 16 bits long, and all comparisons
between Sequence Number values node, it MUST be performed modulo 2**16.
For example, using an implementation in the C programming
language, a Sequence Number value A is greater than another accept any
Sequence Number value B if ((short)((a) - (b)) > 0), if the
"short" data type is a 16-bit signed integer.
- Recent usage information for this Binding Cache entry, as needed
to implement the cache replacement policy in use in the a received Binding
Cache and Update from this mobile
node.
9.4.3. Requests to assist in determining whether Delete a Binding Refresh
Request should be sent when
This section describes the lifetime processing of this entry nears
expiration.
Binding Cache entries not marked as "home registrations" MAY be
replaced at any time by any reasonable local cache replacement policy
but SHOULD NOT be unnecessarily deleted. The a valid Binding Cache for any
one of Update that
requests a node's IPv6 addresses may contain at most one entry for
each mobile node home address. The contents of a node's Binding
Cache MUST NOT be changed in response to delete a Home Address option in
a received packet. The contents of all of a mobile node's binding from its Binding Cache
entries,
Cache, for each of its IPv6 addresses, MUST be cleared when which the
node reboots.
9.2. Receiving Packets from a Mobile Node
Packets sent by a mobile node with either a Home Address destination
option or a Mobility Header (or both) require special processing at
the correspondent node as explained below.
9.2.1. Processing Mobility Header (MH) Messages
All IPv6 correspondent nodes MUST observe the following rules when
processing Mobility Header messages:
1. If an MH message of unknown type Registration (H) bit is received (Section 6.1, not set in the
Binding Update.
Any existing binding for the
correspondent mobile node SHOULD issue a MUST be deleted. A Binding Error message to the
packet's Source Address with Status field set to 2. Finally,
Cache entry for the
correspondent mobile node MUST discard NOT be created in response to
receiving the packet. Binding Update.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 79] 69]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
2.
If the "Next Header" field is not NO_NXTHDR (59 decimal), binding cache entry was created by use of return routability
nonces, the
packet correspondent node MUST be silently discarded.
3. The checksum must be verified as per Section 6.1.
Subsequent checks depend on ensure that the particular Mobility Header message.
There same nonces are two types of Mobility Header messages. The return
routability procedure (Section 9.3) is
not used to verify liveness of again with the
mobile node at both its particular home address as well as its and care-of address.
These liveness probes If
both nonces are used still valid, the correspondent node has to secure binding updates.
The other type remember
the particular combination of Mobility Header messages are directly concerned
with managing bindings (Section 9.4).
9.2.2. Receiving Packets with Home Address Destination Option
Packets sent by a mobile nonce indexes, addresses, and sequence
number as illegal, until at least one of the nonces has become too
old.
9.4.4. Sending Binding Acknowledgements
When any node while away from home MAY include receives a Home
Address destination option, if packet containing a Binding Update message
in which the correspondent node has Acknowledge (A) bit is set, it MUST return a Binding
Acknowledgement message acknowledging receipt of the Binding Update.
If the node accepts the Binding Update and creates or updates an
entry in its Binding Cache Entry for that home address. It MUST process this binding, the option Status field in the
Binding Acknowledgement MUST be set to a
manner consistent with exchanging value less than 128; if, on
the Home Address field from other hand the
Home Address option into Binding Update is accepted and the IPv6 header, replacing `A' bit is not
set, the original
value of node SHOULD NOT send a Binding Acknowledgement. If the Source Address field there. However, any actual
modifications to node
rejects the Source Address Binding Update and does not create or update an entry for
this binding, a Binding Acknowledgement MUST be sent even if the `A'
bit was not set, and the Status field in the packet's IPv6 header Binding Acknowledgement
MUST be carried out in such set to a fashion that further processing value greater than or equal to 128. Specific values
for the Status field are described in Section 6.1.8 and in the IANA
registry of such
a assigned numbers [18].
The packet after all IPv6 options processing (e.g., at the transport
layer) does not depend on that information to know that in which the original
Source Address was a care-of address, or that Binding Acknowledgement is returned
MUST meet the Home Address option
was used specific authentication requirements for Binding
Acknowledgements, defined in Section 5.2. Furthermore, if the packet.
Since packet
is to be sent to the sending mobile node uses its home address at any address other than the transport
layer when sending such mobile
node's home address, it MUST be sent using a Routing header (even if
the binding was rejected). The intermediate IP address, to which
the packet will be delivered immediately before the home address, is
determined as follows:
- Whenever the Binding Update is accepted with a packet, nonzero lifetime,
the use of routing header will be constructed using the care-of address
and Home Address option is transparent to both the mobile node and
the correspondent node above
as described in Section 9.6.
- Otherwise, if the level Source IP Address of the Home Address option
generation and processing.
Packets packet containing Home Address Option MUST be dropped if there is
no corresponding
the Binding Cache Entry Update, is legal for inclusion in a Routing Header,
the routing header will be constructed using that home IP address. In this
case,
Note that multicast addresses, link-local addresses, loopback
addresses, IPv4 mapped addresses, and the correspondent nodes SHOULD send unspecified address,
MUST NOT be used within a Routing Header for the Binding Error message
to
Acknowledgement.
Otherwise, if the source address of Binding Update has a zero lifetime but the packet that contained Source
IP address is not allowable for use within the Home Address
Option (see Section 6.1.9).
9.3. Return Routability Procedure
A correspondent node engages in Routing Header,
the return routability procedure in
order to secure a subsequent Binding Update. This is a requirement
in order to authorize the creation of new bindings as well as to
refresh existing ones. In particular, these messages are used Acknowledgment MUST be sent to
establish the mobile node's liveness (responsiveness to packets) at
both its care-of address as well as its home
address.
Johnson, Perkins, Arkko Expires 1 November December 2002 [Page 80] 70]
INTERNET-DRAFT Mobility Support in IPv6 1 May June 2002
9.3.1. Receiving HoTI Messages
The HoTI message initiates
Entries in a node's Binding Cache MUST be deleted when their lifetime
expires.
9.4.5. Sending Binding Refresh Requests
If a Binding Cache entry being deleted is still in active use
in sending packets to a mobile node, the return routability procedure from next packet sent to the
mobile node will be routed normally to the mobile node's home address to link.
Communication with the correspondent node.
The correspondent mobile node verifies continues, but the following:
- MH Type field for this message is 1.
- The Header Extension Length field MUST be greater than or equal
to tunneling
from the length specified home network creates additional overhead and latency in Section 6.1.3.
- The packet MUST NOT include a Home Address destination option.
In preparation for sending
delivering packets to the corresponding HoT Message, mobile node.
If the
correspondent node checks sender knows that it has the necessary material
to engage in a return routability procedure, as specified Binding Cache entry is still in
Section 5.5. For that procedure, the correspondent node MUST have a
secret Kcn and a nonce Nj. If it does not have this material yet,
it MUST produce active
use, it before continuing with the return routability
procedure.
Section 9.3.3 specifies further processing.
9.3.2. Receiving CoTI Messages
The CoTI MAY send a Binding Refresh Request message initiates the return routability procedure from to the mobile node's care-of address location node
in an attempt to avoid this overhead and latency due to deleting and
recreating the correspondent node. Binding Cache entry. The correspondent node verifies the following:
- MH Type field for this Binding Refresh Request
message is 2.
- The Header Extension Length field MUST be greater than or equal
to the length specified sent in Section 6.1.4.
- The packet MUST NOT include a Home Address destination option.
In preparation for sending the corresponding CoT Message, same way as any packet addressed to the mobile
node (Section 9.6).
The correspondent node checks MAY retransmit Binding Refresh Request
messages provided that rate limitation is applied. The correspondent
node SHOULD stop retransmitting when it has the necessary material
to engage in receive a return routability procedure, Home Test Init
message, as specified in
Section 5.5. For that procedure, the correspondent mobile node MUST have a
secret Kcn and a nonce Nl. If it does not have this material yet,
it MUST produce it before continuing with is responsible for retransmissions during
the return routability procedure.
Section 9.3.4 specifies further processing.
Johnson, Perkins, Arkko Expires 1 November 2002 [Page 81]
INTERNET-DRAFT Mobility Support in IPv6 1 May 2002
9.3.3.
9.4.6. Sending HoT Binding Error Messages
Unless already created,
If the correspondent node creates receives a "Home
Cookie" and an associated "Home Nonce Index". It then creates packet with a
HoT message (Section 6.1.5) and sends Home Address
destination option it to MUST verify that it has a binding for that
mobile node. Specifically, it MUST have a binding entry for the
mobile node node's home address (as obtained from the Home Address option)
at the
latter's home address.
9.3.4. Sending CoT Messages
Unless already created, mobile node's care-of address (from the IP source address of
the packet). If the correspondent node creates does not find such a "Care-of
Cookie" and an associated "Care-of Nonce Index". binding
entry, it MUST discard the packet. It then creates MUST also return a
CoT Binding
Error message (Section 6.1.6) and sends it 6.1.9), subject to rate limiting in the mobile node at the
latter's care-of address.
9.4. Processing Bindings
This section explains how the correspondent node processes the
binding cache messages. These same
manner as is done for ICMPv6 messages are:
- Binding Update
- Binding Refresh Request
- Binding Acknowledgement
- Binding Error
9.4.1. Receiving Binding Updates
Before accepting [14].
9.5. Cache Replacement Policy
Conceptually, a Binding Update message, the receiving node MUST
validate the Binding Update according to the following tests:
- The packet MUST NOT contain maintains a Home Address option.
- The Header Len field separate timer for each entry