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 June
29 Oct 2002
Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-18.txt>
<draft-ietf-mobileip-ipv6-19.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. 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 stationary can communicate with mobile nodes.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page i]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Comparison with Mobile IP for IPv4 2
3. Terminology 3
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 4 5
4. Overview of Mobile IPv6 7
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
4.2. New IPv6 Protocols Protocol . . . . . . . . . . . . . . . . . . . . 9
4.3. New IPv6 Destination Options Option . . . . . . . . . . . . . . . 10
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10
4.5. Conceptual Data Structures Structure Terminology . . . . . . . . . . 11
4.6. Site-Local Addressability . . . . . . . . . . . . . . . . 11
5. Overview of Mobile IPv6 Security 12
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 12
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 12 13
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13
5.2.3. Cookies . . . . . . and Tokens . . . . . . . . . . . . . . . 14
5.2.4. Cryptographic Functions . . . . . . . . . . . . . 14 15
5.2.5. Return Routability Procedure . . . . . . . . . . 14 15
5.2.6. Applying Return Routability for Correspondent
Bindings . . . . . . . . . . . . Authorizing Binding Management Messages . . . . . 18 19
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 20 22
5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 22
5.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . 22
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 21 22
6. New IPv6 Protocols, Protocol, Message Types, and Destination Option 21 23
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 21 23
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 22 23
6.1.2. Binding Refresh Request (BRR) Message . . . . . . 23 . . . 25
6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 24 . . . 26
6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 26 . . . . 27
6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 27 . . . 28
6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 28 . . . 29
6.1.7. Binding Update (BU) Message . . . . . . . . . . . 29 . . 31
6.1.8. Binding Acknowledgement (BA) Message . . . . . . 32 . . . 33
6.1.9. Binding Error (BE) Message . . . . . . . . . . . 34 . . . 35
Johnson, Perkins, Arkko Expires 29 April 2003 [Page ii]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 35 36
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 35
Johnson, Perkins, Arkko Expires 1 December 2002 [Page ii]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 37
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36 37
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 37 38
6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 37
6.2.5. Alternate Care-of Address . . . . . . . . . . . . 38
6.2.6.
6.2.5. Nonce Indices . . . . . . . . . . . . . . . . . . 38
6.2.7. 39
6.2.6. Binding Authorization Data . . . . . . . . . . . 39
6.2.8.
6.2.7. Binding Refresh Advice . . . . . . . . . . . . . 39 40
6.3. Home Address Destination Option . . . . . . . . . . . . . 40 . . . . . . 41
6.4. Type 2 Routing Header type 2 . . . . . . . . . . . . . . . . . . 42 43
6.4.1. Routing Header Packet format Format . . . . . . . . . . . . . . . . . . . . . 42 43
6.5. ICMP Home Agent Address Discovery Request Message . . . . 43 44
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 45 46
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49
7. Modifications to IPv6 Neighbor Discovery 51
7.1. Modified Router Advertisement Message Format . . . . . . 51
7.2. Modified Prefix Information Option Format . . . . . . . . 52
7.3. New Advertisement Interval Option Format . . . . . . . . 54
7.4. New Home Agent Information Option Format . . . . . . . . 55
7.5. Changes to Sending Router Advertisements . . . . . . . . 57
7.6. Changes to Sending Router Solicitations . . . . . . . . . 58 59
7.7. Changes to Duplicate Address Detection . . . . . . . . . 60
8. Requirements for Types of IPv6 Nodes 59 60
8.1. General Requirements for All IPv6 Nodes . . . . . . . . . 59 . . . . . . . . . . . . 61
8.2. Route Optimization Requirements for All IPv6 Nodes with Support for Route Optimization . . . 59 . . 61
8.3. Requirements for All IPv6 Routers . . . . . . . . . . . . 60 . . . . . . . . 62
8.4. Requirements for IPv6 Home Agents . . . . . . . . . . . . 61 . . . . . . . . 62
8.5. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 62 . . . . . . . . . 63
9. Correspondent Node Operation 63 65
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 63 65
9.2. Receiving Packets from a Mobile Node Processing Mobility Headers . . . . . . . . . . 64
9.2.1. . . . . . 66
9.3. Packet Processing Mobility Header (MH) Messages . . . . 64
9.2.2. . . . . . . . . . . . . . . . . 66
9.3.1. Receiving Packets with Home Address Destination
Option . . . . . . . . . . . . . . . . . . 65
9.3. 66
9.3.2. Sending Packets to a Mobile Node . . . . . . . . 67
9.3.3. Sending Binding Error Messages . . . . . . . . . 68
9.3.4. Receiving ICMP Error Messages . . . . . . . . . . 69
9.4. Return Routability Procedure . . . . . . . . . . . . . . 66
9.3.1. 69
9.4.1. Receiving Home Test Init Messages . . . . . . . . 66
9.3.2. 69
9.4.2. Receiving Care-of Test Init Messages . . . . . . 66
9.3.3. 70
9.4.3. Sending Home Test Messages . . . . . . . . . . . 67
9.3.4. 70
9.4.4. Sending Care-of Test Messages . . . . . . . . . . 67
9.4. 70
9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 67
9.4.1. 70
9.5.1. Receiving Binding Updates . . . . . . . . . . . . 67
9.4.2. 71
9.5.2. Requests to Cache a Binding . . . . . . . . . . . 69
9.4.3. 73
9.5.3. Requests to Delete a Binding . . . . . . . . . . 69
9.4.4. 74
9.5.4. Sending Binding Acknowledgements . . . . . . . . 70
9.4.5. 74
Johnson, Perkins, Arkko Expires 29 April 2003 [Page iii]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
9.5.5. Sending Binding Refresh Requests . . . . . . . . 71
9.4.6. Sending Binding Error Messages 75
9.6. Cache Replacement Policy . . . . . . . . . 71
9.5. Cache Replacement Policy . . . . . . . 75
10. Home Agent Operation 76
10.1. Conceptual Data Structures . . . . . . . . . 71
9.6. Sending Packets to a Mobile Node . . . . . . . 76
10.2. Processing Mobility Headers . . . . . 72
9.7. Receiving ICMP Error Messages . . . . . . . . . . 77
10.3. Processing Bindings . . . . 73
Johnson, Perkins, Arkko Expires 1 December 2002 [Page iii]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
10. Home Agent Operation 74
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 74
10.2. 77
10.3.1. Primary Care-of Address Registration . . . . . . . . . . 75
10.3. 77
10.3.2. Primary Care-of Address De-Registration . . . . . 81
10.4. Packet Processing . . . . . . . 79
10.4. . . . . . . . . . . . . . 82
10.4.1. Intercepting Packets for a Mobile Node . . . . . . . . . 80
10.5. 82
10.4.2. Tunneling Intercepted Packets to a Mobile Node . . . . . 81
10.6. 83
10.4.3. Handling Reverse Tunneled Packets from a Mobile
Node . . 83
10.7. Protecting Return Routability Packets . . . . . . . . . . 83
10.8. Receiving Router Advertisement Messages . . . . . . . 85
10.4.4. Protecting Return Routability Packets . . . . . 84
10.9. . 85
10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 85
10.9.1. 86
10.5.1. Receiving Router Advertisement Messages . . . . . 86
10.6. Sending Prefix Information to the Mobile Node . . . . . . 89
10.6.1. Aggregate List of Home Network Prefixes . . . . . 87
10.9.2. 89
10.6.2. Scheduling Prefix Deliveries to the Mobile Node . 89
10.9.3. 90
10.6.3. Sending Advertisements to the Mobile Node . . . . 90
10.9.4. 92
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . 91 92
11. Mobile Node Operation 91 93
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 91 93
11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 94
11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 93
11.2.1. 95
11.3.1. Sending Packets While Away from Home . . . . . . 93
11.2.2. 95
11.3.2. Interaction with Outbound IPsec Processing . . . 96
11.2.3. 97
11.3.3. Receiving Packets While Away from Home . . . . . 97
11.2.4. 99
11.3.4. Receiving ICMP Error Messages . . . . . . . . . . 100
11.3.5. Routing Multicast Packets . . . . . . . . . . . . 99
11.3. 101
11.4. Home Agent and Prefix Management . . . . . . . . . . . . 100
11.3.1. Receiving Local Router Advertisement Messages . . 100
11.3.2. 102
11.4.1. Dynamic Home Agent Address Discovery . . . . . . 101
11.3.3. 102
11.4.2. Sending Mobile Prefix Solicitations . . . . . . . 102
11.3.4. 103
11.4.3. Receiving Mobile Prefix Advertisements . . . . . 103
11.4. 104
11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 104
11.4.1. 105
11.5.1. Movement Detection . . . . . . . . . . . . . . . 104
11.4.2. 105
11.5.2. Forming New Care-of Addresses . . . . . . . . . . 107
11.4.3.
11.5.3. Using Multiple Care-of Addresses . . . . . . . . 108
11.5. 109
11.5.4. Returning Home . . . . . . . . . . . . . . . . . 109
11.6. Return Routability Procedure . . . . . . . . . . . . . . 109
11.5.1. 111
11.6.1. Sending Home and Care-of Test Init Messages . . . 109
11.5.2. 111
11.6.2. Receiving Return Routability Messages . . . . . . 109
11.5.3. Retransmitting in the Return Routability Procedure 111
11.5.4. Rate Limiting for 112
11.6.3. Protecting Return Routability Procedure Packets . 111
11.6. . . . . . 113
11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 111
11.6.1. 114
11.7.1. Sending Binding Updates to the Home Agent . . . . 111
11.6.2. 114
11.7.2. Correspondent Binding Procedure . . . . . . . . . 114
11.6.3. 116
11.7.3. Receiving Binding Acknowledgements . . . . . . . 117
11.6.4. 119
11.7.4. Receiving Binding Refresh Requests . . . . . . . 118
11.6.5. 121
11.7.5. Receiving Binding Error Messages . . . . . . . . 119
11.6.6. Forwarding from a Previous Care-of Address . . . 120
11.6.7. Returning Home . . . . . . . . . . . . . . . . . 121
11.6.8. Retransmitting Binding Updates . . . . . . . . . 123
11.6.9.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page iv]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
11.8. Retransmissions and Rate Limiting Binding Updates . . . . . . . . . . 124
11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 124 122
12. Protocol Constants 125 123
13. IANA Considerations 126
Johnson, Perkins, Arkko Expires 1 December 2002 [Page iv]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 124
14. Security Considerations 127 125
14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 127 125
14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 129 127
14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 130 128
14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 132 130
14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 132 130
14.4.2. Offered Protection . . . . . . . . . . . . . . . 132 131
14.4.3. Comparison to Regular IPv6 Communications . . . . 133 131
14.4.4. Return Routability Replays . . . . . . . . . . . 135 133
14.4.5. Return Routability Denial-of-Service . . . . . . 135 133
14.5. Tunneling via the Dynamic Home Agent Address Discovery . . . . . . . . . . 134
14.6. Prefix Discovery . . . . 136
14.6. Home Address Destination Option . . . . . . . . . . . . . 137 . . . 135
14.7. Type 2 Routing Header Tunneling via the Home Agent . . . . . . . . . . . . . . 135
14.8. Home Address Option . . . . 138
Acknowledgements 138
References 140
A. State Machine for the Correspondent Binding Procedure 142
A.1. Main State Machine . . . . . . . . . . . . . . . 135
14.9. Type 2 Routing Header . . . . 143
A.2. Return Routability Procedure . . . . . . . . . . . . . . 149
B. 136
Contributors 137
Acknowledgements 137
References 139
A. Changes from Previous Version of the Draft 153
C. 142
A.1. Changes from Draft Version 18 . . . . . . . . . . . . . . 142
B. Future Extensions 154
C.1. 146
B.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 154
C.2. 146
B.2. Triangular Routing and Unverified Home Addresses . . . . 154
C.3. 146
B.3. New Authorization Methods beyond Return Routability . . . 155
C.4. 146
B.4. Security and Dynamically Generated Home Addresses . . . . 155
C.5. 147
B.5. Remote Home Address Configuration . . . . . . . . . . . . 155 147
Chairs' Addresses 157 149
Authors' Addresses 157 149
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page v]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
1. Introduction
This document specifies how the IPv6 Internet operates with mobile
computers. Without specific support for mobility in IPv6 [11],
packets destined to a mobile node would not be able to reach it while
the mobile node is away from its home 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. address". Packets may be routed to the mobile
node using this address regardless of the mobile node's current point
of attachment to 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 re-establishing
link-layer connectivity to the node in each new location.
Mobile IP IPv6 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). 11.5.1).
- Access control on a link being visited by a mobile node.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 1]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 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 benefits both
from the experiences gained from the development of Mobile IP support
in IPv4 (Mobile IPv4) [20, 21, 22], together with and from the opportunities
provided by IPv6. Mobile IPv6 thus shares many features with
Mobile IPv4, but is integrated into IP IPv6 and provides offers many other
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" agents",
as are used in Mobile IPv4. In Mobile IPv6,
mobile nodes make use of IPv6 features, to operate operates in any location without
any special support required from the local router.
- Support for what is known in Mobile IPv4 as "route
optimization" [23] route optimization is now built in as a fundamental part of the
protocol, rather than being added on as an optional a nonstandard set of extensions that may not be supported by all nodes as in
Mobile IPv4. extensions.
- Mobile IPv6 route optimization can operate securely even without
pre-arranged security associations. It is expected that route
optimization can be deployed on a global scale between all mobile
nodes and correspondent nodes.
- Support is also integrated into Mobile IPv6 for allowing route
optimization to coexist efficiently with routers that perform
"ingress filtering" [24]. Both the current care-of address and
the home address can be carried in packets, allowing packets to
pass normally through ingress filtering routers. [23].
- In Mobile IPv6, the mobile node does not have to tunnel multicast
packets to its home agent. The inclusion of the home address in
packets is compatible with multicast routing that is based in
part on the packet's Source Address.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 2]
INTERNET-DRAFT Mobility Support in IPv6 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.
- Most packets sent to a mobile node while away from home in
Mobile IPv6 are sent using an IPv6 Routing routing header rather than IP
encapsulation, reducing the amount of resulting overhead compared
to Mobile IPv4.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 2]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- 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 IPv6 encapsulation (and the Routing routing header) removes
the need in Mobile IPv6 to manage "tunnel soft state".
- The dynamic home agent address discovery mechanism in Mobile IPv6
returns a single reply to the mobile node. The directed
broadcast approach used in IPv4 returns separate replies from
each home 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 [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.
unicast routable address
An identifier for a single interface such that
a packet sent to it from another IPv6 subnet is
delivered to the interface identified by that
address. Accordingly, a unicast routable address must
have either a global or site-local scope (but not
link-local).
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 29 April 2003 [Page 3]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 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.
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. Destination
options include optional information that need
be examined only by the IPv6 node given as the
destination address in the IPv6 header, not by other
intermediate routing nodes. Mobile IPv6 defines one
new destination option, the Home Address destination option.
option (see Section 6.3).
routing header
A routing header may be present as an IPv6 header
extension, and indicates that the payload has to be
delivered to a destination IPv6 address in some way
that is different from what would be carried out by
standard Internet routing. In this document, use of
the term "routing header" typically refers to use of a
type 2 routing header, as specified in Section 6.4.
'|' (concatenation)
Some formulas in this specification use the symbol '|'
indicate bytewise concatenation, as in A | B. This
concatenation requires that all of the bytes of the
datum A appear first in the result, followed by all of
the bytes of the datum B.
First (size, input)
Some formulas in this specification use a functional
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 4]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
form "First (size, input)" to indicate truncation of
the "input" data so that only the first "size" bits
remain to be used.
3.2. Mobile IPv6 Terms
home address An IP
A unicast routable 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".
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
A unicast routable 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
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 5]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
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.
registration
The process during which a mobile node sends a Binding
Update to its home agent or a correspondent node,
causing a binding for the mobile node to be registered.
mobility message
A message containing a Mobility Header (see
Section 6.1).
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.
return routability procedure
The return routability procedure authorizes binding
procedures by the use of a cryptographic cookie token 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 keygen tokens
related to the return routability procedure. The nonces
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 6]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
are not specific to a mobile node, and are kept secret
within the correspondent node, only used
as one input in the creation of node.
nonce index
A nonce index is used to indicate which nonces have
been used when creating keygen token values, without
revealing the cookies. nonces themselves.
cookie Cookies are numbers that are A cookie is a random number used by a mobile nodes
and to
prevent spoofing by a bogus correspondent nodes node 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 init cookie
A cookie sent to the correspondent node from in the
mobile node, and later returned Care-of
Test Init message, to be returned in the mobile node.
Mobile cookies are produced randomly. There are two
kinds of mobile cookies: the HoT cookie and the CoT
cookie.
CoT Care-of Test
message.
home init cookie
A cookie sent by the mobile node to the the correspondent node in the CoTI Home Test
Init message, to be returned to the mobile node in the CoT Home Test message.
HoT cookie
keygen token
A cookie sent keygen token is a number supplied by a correspondent
node in the return routability procedure to enable the
mobile node to compute the necessary binding management
key for authorizing a Binding Update.
care-of keygen token
A keygen token sent by the correspondent node in the HoTI message, to be
returned to
Care-of Test message.
home keygen token
A keygen token sent by the mobile correspondent node in the HoT
Home Test 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.
binding management key (Kbm)
A
nonce index is used to indicate which nonces have
been used, without revealing the nonces themselves.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 6]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 binding management key (Kbm) is a key used for authenticating
authorizing a binding cache management messages.
binding security association message (e.g.,
Binding Update or Binding Acknowledgement). Return
routability provides a security association established specifically
for the purpose of producing and verifying
authentication data passed with way to create a Binding
Authorization Data option. binding
management key.
4. Overview of Mobile IPv6
4.1. Basic Operation
A mobile node is always expected to be addressable at its home
address, whether it is currently attached to its home link or is
away from home. The "home address" is an IP address assigned to the
mobile node within its home subnet prefix on its home link. While
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 7]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
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. The subnet prefix of
a mobile node's home address is one of the subnet prefixes of the mobile node's home link. Packets addressed to the mobile node will
therefore be routed to its home link. link, using conventional Internet
routing mechanisms.
While a mobile node is attached to some foreign link away from home,
it is also addressable at one or more care-of addresses. A care-of
address is an IP address associated with a mobile node while visiting that has the
subnet prefix of a particular foreign link. The subnet prefix of a mobile node's node can
acquire its care-of address is one of the subnet prefixes on the foreign link. through conventional IPv6 stateless or
stateful auto-configuration mechanisms. As long as the mobile node
stays in this location, packets addressed to this care-of address
will be routed to the mobile node. The mobile node may also accept
packets from several care-of addresses, such as when it is moving but
still reachable at the previous link.
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 [13] or
stateful (e.g., DHCPv6 [25]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [12]. Other methods
of acquiring a care-of address are also possible, but 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 primary care-of
addresses address 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 home agent replies to the mobile node by returning a
"Binding Acknowledgement" message. The care-of
address associated with this binding registration is known as operation of 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. Each intercepted packet is tunneled
to the mobile node's primary care-of address. This tunneling
is performed using IPv6 encapsulation [15], with the outer IPv6
header addressed to the mobile node's primary care-of address. The
operation of the node
and the home agent is specified in Section 10. Sections 11 and 10, respectively.
Any node communicating with a mobile node is referred to in this
document as a "correspondent node" of the mobile node, and 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
provide information about their current location of the mobile
node. to correspondent
nodes. This happens through the correspondent binding procedure. As
a part of this procedure, a return routability test is performed in
order to authorize the establishment of the binding. This The operation
of the correspondent node is specified in Sections 5.2.5 Section 9.
There are two possible modes for communications between the mobile
node and 5.2.6. a correspondent node. The first mode, bidirectional
tunneling, does not require Mobile IPv6 support from the
correspondent node and is available even if the mobile node has not
registered its current binding with the correspondent node. Packets
from the correspondent node are routed to the home agent and then
tunneled to the mobile node. Packets to the correspondent node are
tunneled from the mobile node to the home agent ("reverse tunneled")
and then routed normally from the home network to the correspondent
node. In this mode, the home agent uses proxy Neighbor Discovery
to intercept any IPv6 packets addressed to the mobile node's home
address (or home addresses) on the home link. Each intercepted
packet is tunneled to the mobile node's primary care-of address.
This tunneling is performed using IPv6 encapsulation [15].
The second mode, "route optimization", requires the mobile node to
register its current binding at the correspondent node. Packets
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 8]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
from the correspondent node can be routed directly to the care-of
address of the mobile node. When sending a packet to any IPv6
destination, a the correspondent 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 routing header [11] (see section 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. When a
mobile node receives a packet tunneled to it in this manner, it can
use this as an indication that the correspondent node has no binding
for the mobile node. The mobile node 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 address allows
the mobile node. This
is important for scalability and reliability, and for minimizing
overall network load. Routing packets directly shortest communications path to the mobile node's
care-of address be used. It also eliminates
congestion at the mobile node's home agent and home link. In
addition, the impact of any possible failure of the home agent, the home link, agent or intervening
networks leading on the path to or from the home link it is reduced, since these nodes and links are not
involved reduced.
When routing packets directly to the mobile node, the correspondent
node sets the Destination Address in the delivery of most packets IPv6 header to the care-of
address of the mobile node.
Mobile IPv6 defines a A new type of IPv6 destination option. When a mobile
node sends a routing header (see
Section 6.4) is also added to the 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, carry the mobile node can deliver packets directly to desired home
address. Similarly, the correspondent
node. The mobile node sets the Source Address in
the packet's IPv6 header to one of its current care-of addresses, and include addresses. The
mobile node adds a new IPv6 "Home Address" destination option in the packet, giving the mobile node's (see
Section 6.3) to carry its home address. By also including the Home Address destination option
in each packet, the sending mobile node can communicate its The inclusion of home
address to the correspondent node receiving this packet. This makes
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 8]
INTERNET-DRAFT Mobility Support
addresses in IPv6 1 June 2002 these packets makes the use of the care-of address
transparent above the Mobile IPv6
support level network layer (e.g., at the transport layer).
It is possible that while a mobile node is away from home, some nodes
on its
Mobile IPv6 also provides support for multiple home link may be reconfigured. The router that was operating
as agents, and the mobile node's home agent can be replaced by a different
router serving
reconfiguration of the same role. home network. In this case, these cases, the mobile
node may not know the IP address of its own home agent. Mobile IPv6 provides a agent, and even
the home subnet prefixes may change over time. A mechanism, known
as "dynamic home agent address discovery", that discovery" 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 [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 arrives to a new link and allocates a new care-of
address, it is desirable for packets arriving at the previous care-of
address to still reach link,
even when the mobile node. The mobile node may still
accept packets at the previous address, if it is still attached to
the previous link as well as the away from home. Mobile nodes can also
learn new one. This is discussed in
Section 11.4.3. If the mobile node is no longer attached to information about home subnet prefixes through the
previous link, procedures "prefix
discovery" mechanism. These mechanisms are described in Section 11.6.6 may be used to
establish temporary tunneling from the previous link. Sections 6.5
through 6.8.
4.2. New IPv6 Protocols Protocol
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
Home Test
Care-of Test Init
Care-of Test
These four messages are used to initiate the return
routability procedure from the mobile node to a
correspondent node. This ensures authorization of
subsequent Binding Updates, as described in Section 5.2.5.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 9]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The format of the messages are defined in Sections 6.1.3
through 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
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 agent to register its primary care-of address is
marked as a "home registration". The Binding Update message
is 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 requested in the
Binding Update. The Binding Acknowledgement
message is described in
detail in Section 6.1.8.
Binding Refresh Request
A Binding Refresh Request message is used to request a mobile node
to re-establish its binding with the correspondent node.
This message is typically used 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.
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 Option
Mobile IPv6 defines a new IPv6 destination option, the Home
Address destination option. This option is described in detail in
Section 6.3.
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 described in Section 4.1,
Sections 10.5 and 11.4.1, the following two new ICMP message types
are used for home agent address discovery:
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 10]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- Home Agent Address Discovery Request, described in Section 6.5.
- Home Agent Address Discovery 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 types are used for network renumbering
and address configuration on the mobile node, as described in
Section 10.9.1: 10.6:
- Mobile Prefix Solicitation, described in Section 6.7.
- Mobile Prefix Advertisement, described in Section Section 10.9.3. 6.8.
4.5. Conceptual Data Structures Structure Terminology
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, cache of bindings for other nodes. A separate This cache is maintained
by home agents and correspondent nodes. The cache contains
both "correspondent registration" entries (see Section 9.1) and
"home registration" entries (see Section 10.1).
Binding Cache Update List
This list 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 [12]. mobile node. The Binding Cache for any one of a node's IPv6 addresses may
contain at most one entry list has an
item for each every binding that the mobile node home address.
The contents of all of has or is trying
to establish with a node's Binding Cache entries are
cleared when it reboots.
Binding Cache entries specific other node. Both correspondent
and home registrations are marked either as "home registration"
entries or "correspondent registration" entries. Home
registration entries included in this list. Entries from
the list 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 as the Lifetime sent in that Binding Update has not yet expired. The the Binding Update
expires. See Section 11.1.
Home Agents List includes all bindings sent by the mobile
node: those to correspondent nodes, those to the mobile node's
home agent, and those
Home agents need to a know which other home agent on the link agents are on which the
mobile node's previous care-of address
same link. This information is located. stored in the Home Agents List
A list, maintained by each List,
as described in more detail in Section 10.1. The list is used
for informing mobile nodes during dynamic home agent and each address
discovery.
4.6. Site-Local Addressability
Mobile nodes are free to move from site to site, but the use of
site-local addresses must be carefully managed. When a mobile node,
recording information about each node
or home agent from which this address is site-local, then packets that use those
address need to stay within the site. The mobile node SHOULD use
such addresses only when it somehow has recently received a Router Advertisement in which the
Home Agent (H) bit is set. This list guarantee - for instance,
by configuration - that it is similar safe to the Default
Router List conceptual data structure maintained by each host
for Neighbor Discovery [12]. do so. Thus, a mobile node MAY
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 11]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Each
use a site-local home agent maintains address for roaming within a separate Home Agents List site, but not for each
link on which it
roaming to another site. This is serving as true even though the mobile node
may be able to obtain a home agent; this list is used
by globally addressable care-of address at the
new site.
If a mobile node or home agent has a global IPv6 address available,
it SHOULD be selected for use with Mobile IP signaling, in order to
make the greatest chance for success in case the dynamic home agent address discovery
mechanism. Each mobile node, while away from home, also
maintains a Home Agents List, to enable it node might
move to notify a home
agent on its previous link different site.
Operations affecting multi-sited IPv6 nodes are not completely
understood, especially when it moves to mobility management is involved. For
this reason, home agents SHOULD NOT be multi-sited. Similarly,
a new link. mobile node that uses site-local home, care-of, or home agent
addresses SHOULD NOT be multi-sited.
5. Overview of Mobile IPv6 Security
This specification provides a 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 routing instructions in data packets.
5.1.
Binding Updates to Home Agents
Signaling between are protected by the mobile node and use of IPsec extension headers,
or by the home agent requires message
integrity, correct ordering and replay protection. use of the Binding Authorization Data option. This option
employs a binding management key, Kbm, which can be established
through the return routability procedure.
5.1. Binding Updates to Home Agents
The mobile node and the home agent must have an a security association
to protect this signaling. Authentication Header (AH) or
Encapsulating Security Payload (ESP) can MUST be used for integrity
protection. used. For ESP we require that ESP, a
non-null authentication algorithm is MUST be applied.
Mobile IPv6 provides its own ordering mechanism inside the Binding
Update 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 and
the home agent with IPsec, appropriate security policy database
entries must be created. We need to avoid the possibility that a A mobile node could use must be prevented from
using its security association to send a Binding Update on behalf
of another mobile node using the same home agent.
In order to do this, This MUST be
achieved by checking that the given home address has been used with
the right security association. Such a check can be provided in
IPsec processing, by having the security policy database entries MUST
unequivocally identify a single SA security association for any given
home address and home agent. The check may also be provided as
a part of Mobile IPv6 processing, if information about the used
security association is available in there. In order for any case, it is
necessary that the home address of the mobile node to be is visible when in
the policy check Binding Updates and Acknowledgements. The home address is made, the mobile node MUST use used
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 12]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
in these packets as a source or destination, or in the Home Address destination
Destination option or the type 2 routing header.
As with all IPsec security associations in Binding Updates sent this specification, manual
configuration of security associations MUST be supported. Automatic
key management with IKE [9] MAY be supported. When dynamic keying
is used, either the security policy database entries or the MIPv6
processing MUST unequivocally identify the IKE phase 1 credentials
which can be used to create security associations for a particular
home address.
Reference [24] is an informative description and example of using
IPsec to protect the communications between the mobile node and the
home agent.
5.2. Binding Updates to Correspondent Nodes
Binding Updates to correspondent nodes can be protected by using
a binding management key, Kbm. Kbm may be established using data
exchanged during the return routability procedure. We will first
discuss a number The data exchange
is accomplished by use of preliminary concepts such as node keys, nonces, cookies, tokens, and cookies and the
certain cryptographic functions used. functions. Section 5.2.5 outlines the basic
return routability procedure. Section 5.2.6 shows
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 12]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 how the results
of this procedure are used to authorize a Binding Update to a
correspondent node. Finally, Sections 5.2.7 and 5.2.8 discuss some
additional issues.
5.2.1. Node Keys
Each correspondent node has a secret key, Kcn. Kcn, called the "node key",
which it uses to produce the keygen tokens sent to the mobile nodes.
The node key MUST be a random number, 20 octets in length. The correspondent node uses this
key allows the correspondent node to verify that the cookies it receives keygen tokens
used by the mobile node in messages authorizing a Binding Update are those which it has created itself. indeed
its own. This key does not need to MUST NOT be shared with any other entity.
A correspondent node can MAY generate a fresh Kcn each time that it boots
to node key at any time;
this avoid the need for secure persistent storage for Kcn. Kcn can be
either a fixed value or regularly updated. key storage. Procedures
for optionally updating
Kcn the node key are discussed later in
Section 5.2.7.
Kcn consists of 20 octets.
5.2.2. Nonces
Each correspondent node also generates nonces at regular intervals,
for example every few minutes.
intervals. The nonces should be generated by using a random number
generator that is known to have good randomness properties [1].
A correspondent node may use the same Kcn and nonce with all the
mobiles it is in communication with, so that it does not
need to generate and store a new nonce when a new mobile contacts it. with.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 13]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Each nonce is identified by a nonce index. Nonce indices are
16-bit values that are e.g. incremented each time When a new nonce is
created. The index value is communicated in the protocol, so that if
generated, it must be associated with a nonce is replaced by new nonce during index; this may be
done, for example, by incrementing the run value of a protocol, the
correspondent node can distinguish messages previous nonce
index, if the nonce index is used as an array pointer into a linear
array of nonces. However, there is no requirement that nonces be
stored that way, or that the values of subsequent nonce indices
have any particular relationship to each other. The index value
is communicated in the protocol, so that if a nonce is replaced by
new nonce during the run of a protocol, the correspondent node can
distinguish messages that should be checked against the old nonce
from messages that should be checked against the new nonce. Strictly
speaking, indices are not necessary in the authentication, but allow
the correspondent node to efficiently find the nonce value that it
used in creating a cookie. keygen token.
Correspondent nodes keep both the current nonce and a small set of
old nonces. Older
valid previous nonces whose lifetime has not yet expired. Expired
values can MUST be discarded, and messages using them stale or unknown indices
will be rejected as replays. rejected.
The specific nonce index values can not cannot be used by mobile nodes to
determine the validity of the nonce. Expected validity times for
the nonces values and the procedures for updating them are discussed
later in Section 5.2.7.
Nonce
A nonce is an octet string of any length. The recommended length is
64-bit.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 13]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
64 bits.
5.2.3. Cookies
Three different types of and Tokens
The return routability address test procedure uses cookies are used in and keygen
tokens as opaque values within the protocol: test init and test messages,
respectively.
- Two mobile cookies The "home init cookie" and "care-of init cookie" are 64 bit
values sent to the correspondent node from the mobile node, and
later returned to the mobile node. The mobile
cookies are produced randomly, and used to verify that the
response matches the request, and to ensure that parties who have
not seen the request can not spoof responses. One of the mobile
cookies home init cookie is sent
in the HoTI Home Test Init message, and returned in the HoT Home Test
message. This is called the HoT cookie. The other mobile care-of init cookie is sent in the CoTI Care-of Test
Init message, and returned in the CoT Care-of Test message.
This is called the CoT cookie.
- A home cookie The "home keygen token" and "care-of keygen token" are 64-bit
values sent to by the mobile correspondent node from to the correspondent mobile node via the
home agent. agent (via the Home cookies are produced cryptographically
from nonces.
- A Test message) and the care-of cookie is similar to a home cookie, but sent directly
to address
(by the Care-of Test message), respectively.
The mobile node from the correspondent node.
A should use a newly generated random number is typically used for each
request that carries a mobile home init or care-of init cookie. The cookies
are used to verify that the Home Test or Care-of Test message matches
the Home Test Init or Care-of Test Init message, respectively. These
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 14]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
cookies also serve to ensure that parties who have not seen the
request cannot spoof responses.
Home and care-of cookies keygen tokens are produced by the correspondent node, and
they are node
based on the its currently active secret keys key (Kcn) and nonces of the
correspondent node nonces, as well as
the home or care-of address. Such a
cookie address (respectively). A keygen token is valid
as long as both the secret key (Kcn) and the nonce used to create it
are valid.
5.2.4. Cryptographic Functions
MAC_K(m) denotes a Message Authentication Code computed on message
m with key K. In this specification, HMAC SHA1 function [26, 19] is
used to compute these codes.
Hash(m) denotes a hash of message m.
In this specification, the function used to compute the hash values is
SHA1 [19]. Message Authentication Codes (MACs) are computed using
HMAC_SHA1 [25, 19]. HMAC_SHA1(K,m) denotes such a MAC computed on
message m with key K.
5.2.5. Return Routability Procedure
The return routability signaling happens as follows:
Mobile Return Routability Procedure enables the correspondent node Home agent Correspondent to
obtain some reasonable assurance that the mobile node
| |
| 1a. |
| Home Test Init(HoTI) |
| Src = home address, |
| Dst = correspondent | |
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 14]
INTERNET-DRAFT Mobility Support is in IPv6 1 June 2002
| Parameters: | |
| - HoT cookie | |
|------------------------->|------------------------->|
| | |
| |
| 1b. |
| Care-of Test Init(CoTI) |
| Src = fact
addressable at its claimed care-of address |
| Dst = correspondent |
| Parameters: |
| - CoT cookie |
|---------------------------------------------------->|
| |
| 2a. |
| Home Test (HoT) |
| Src = correspondent, |
| Dst = as well as at its home address |
| Parameters: |
| - HoT cookie |
| | - home cookie |
| | - home nonce index |
|<-------------------------|<-------------------------|
| | |
| |
| 2b. |
| Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - CoT cookie |
| - care-of cookie |
| -
address. Only with this assurance is the correspondent node able to
accept Binding Updates from the mobile node which would then instruct
the correspondent node to direct that mobile node's data traffic to
its claimed care-of nonce index |
|<----------------------------------------------------|
| | address.
This is done by testing whether packets addressed to the two claimed
addresses are routed to the mobile node. The mobile node can pass
the test only if it is able to supply proof that it received certain
data (the "keygen tokens") which the correspondent node sends to
those addresses. These data are combined by the mobile node into a
binding management key, denoted Kbm.
Figure 1 shows the message flow for the return routability
procedures.
The Home and Care-of Test Init messages are sent at the same time.
The procedure requires very little processing at the correspondent node returns
node, and the Home and Care-of Test messages as quickly as possible, and can be returned quickly,
perhaps nearly simultaneously,
requiring very little processing. Those simultaneously. These four messages form the return
routability procedure. Due to the nearly simultaneous
message delivery, the return routability procedure completes in about
roundtrip between the mobile node and the correspondent.
1a.
Home Test Init
A mobile node sends a Home Test Init message to the
correspondent node to acquire the home cookie. keygen token. The
contents of the message can be summarized as follows:
Src
Source Address = home address
Dst = correspondent
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 15]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
Figure 1: Message Flow for Return Routability Address Testing
Destination Address = correspondent
Parameters:
- HoT home init cookie
This
The Home Test Init message conveys the mobile node's home
address to the correspondent node. The mobile node also sends
along a 64 bit
HoT home init cookie that the correspondent node must
return later. The Home Test Init message is reverse tunneled
through the home agent.
1b. The mobile node remembers these cookie
values to obtain some assurance that its protocol messages are
being processed by the desired correspondent node.
Care-of Test Init
The mobile node sends a Care-of Test Init message to the
correspondent node to acquire the care-of cookie. keygen token. The
contents of this message can be summarized as follows:
Src
Source Address = care-of address
Dst
Destination Address = correspondent
Parameters:
- CoT care-of init cookie
The second Care-of Test Init message conveys the mobile node's care-of
address to the correspondent node. The mobile node also sends
along a 64 bit CoT care-of init cookie that the correspondent node must
return later. The Care-of Test Init message is sent directly
to the correspondent node.
2a.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 16]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Home Test
The Home Test
This message is sent in response to a Home Test Init
message. The contents of the message are:
Src
Source Address = correspondent
Dst
Destination Address = home address
Parameters:
- HoT home init cookie
- home cookie keygen token
- home nonce index
When the correspondent node receives the Home Test Init
message, it generates a 64-bit home cookie keygen token as follows:
home cookie = First64(MAC_Kcn(home keygen token :=
First (64, HMAC_SHA1 (Kcn, (home address | nonce)) nonce | 0)))
where | denotes concatenation. The final "0" inside the
HMAC_SHA1 function is a single zero octet, used to distinguish
home and care-of cookies from each other.
The home cookie keygen token is formed from the first 64 bits of
the MAC
result. The message is sent to the mobile node via the home
agent; the protocol relies on the assumption that the route
between the home agent and the mobile node is secure. MAC. The home
cookie also acts as a challenge to test keygen token tests that the mobile can
receive messages sent to its home address. Kcn is used in
the production of home cookie keygen token in order to allow the
correspondent node to verify that it generated the home and
care-of cookies,
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 16]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 nonces, without forcing the correspondent node to
remember a list of all cookies tokens it has handed out.
The HoT cookie from the mobile node is returned in the Home Test message, message is sent to ensure that the message comes from a mobile node on via the route between home
network, where it is presumed that the home agent and will tunnel
the correspondent node.
The home nonce index is delivered message to the mobile node to later
allow node. This means that the correspondent mobile
node needs to already have sent a Binding Update to efficiently find the nonce
value home
agent, so that it used in creating the home cookie.
2b. Care-of Test
This message is sent in response to a Care-of Test Init agent will have received and authorized
the new care-of address for the mobile node before the return
routability procedure. For improved security, it is important
that the data passed between the home agent and the mobile node
be immune from inspection and passive attack. Such protection
can be gained by encrypting the home keygen token as it is
tunneled from the home agent to the mobile node.
The home init cookie from the mobile node is returned in the
Home Test message, to ensure that the message comes from a node
on the route between the home agent and the correspondent node.
The home nonce index is delivered to the mobile node to later
allow the correspondent node to efficiently find the nonce
value that it used in creating the home keygen token.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 17]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Care-of Test
This message is sent in response to a Care-of Test Init
message. The contents of the message are:
Src
Source Address = correspondent
Dst
Destination Address = care-of address
Parameters:
- CoT care-of init cookie
- care-of cookie keygen token
- care-of nonce index
The correspondent node also sends a challenge also to the mobile's
care-of address. When the correspondent node receives the
Care-of Test Init message, it generates a 64-bit care-of cookie keygen token
as follows:
care-of cookie = First64(MAC_Kcn(care-of keygen token :=
First (64, HMAC_SHA1 (Kcn, (care-of address | nonce)) nonce | 1)))
Here, the final "1" inside the HMAC_SHA1 function is a single
octet containing the hex value 0x01, and is used to distinguish
home and care-of cookies from each other. The cookie keygen token is
formed from the first 64 bits of the MAC result.
The cookie is MAC, and sent directly
to the mobile node at its care-of address. The CoT care-of init
cookie from the from CoTI Care-of Test Init message is returne returned to
ensure that the message comes from a node on the route to the
correspondent node.
The care-of nonce index is provided to identify the nonce used
for the care-of cookie. keygen token. The home and care-of nonce
indices are
often MAY be the same same, or different, in the Home and Care-of
Test messages.
When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a result, result
of the procedure, the mobile node has the means to prove its authority data it needs to send a
Binding Update to the correspondent node. The mobile node hashes
together the challenges
tokens together to form a 16 20 octet session binding key Kbu:
Kbu Kbm:
Kbm = Hash(home cookie SHA1 (home keygen token | care-of cookie) keygen token)
A Binding Update may also be used to delete a previously established
binding by setting the care-of address equal to the home address
(Section 6.1.7). In this case, the care-of keygen token is not used.
Instead, the binding management key is generated as follows:
Kbm = SHA1(home keygen token)
Note that the correspondent node does not create any state specific
to the 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 December 2002 29 April 2003 [Page 17] 18]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
mobile node. The correspondent node does not maintain the value for
the binding management key Kbu, though it can recreate Kbu if Kbm; it is presented creates Kbm when given the right
addresses and nonce indices.
indices and the mobile node's addresses.
5.2.6. Applying Return Routability for Correspondent Bindings Authorizing Binding Management Messages
After the above procedure has completed, the mobile node has created the binding management key (Kbm),
it can supply a verifiable Binding Update to the correspondent
node. An This section provides an overview of the this binding
procedure procedure.
Figure 2 shows the message flow. The Binding Update creates a
binding, and the Binding Acknowledgement is shown below. optional.
Mobile Node node Correspondent node
| |
| 1. Binding Update (BU) |
|---------------------------------------------->|
| Src = care-of address, Dst = correspondent |
| Parameters: |
| - home address |
| - a MAC |
| - home (MAC, seq#, nonce index |
| - indices, care-of nonce index |
| - sequence number address) |
| - ... |
|---------------------------------------------------->|
| |
| 2. Binding Acknowledgement |
| (BA) (if requested) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - sequence number |
| - a MAC sent) |
|<----------------------------------------------|
| - ... |
|<----------------------------------------------------|
| (MAC, seq#, status) |
Figure 2: Message 1 actually creates a binding, and message 2 is optional. The
correspondent binding procedure consists of the return routability
procedure followed by Flow for Establishing Binding at
the messages 1 and 2.
1. Correspondent Node
Binding Update
The
To authorize a Binding Update, the mobile node uses the created session creates a
binding management key Kbu to authorize Kbm from the Binding Update. keygen tokens as described
in the previous section. The contents of the message are as
follows:
Src Binding Update
include the following:
Source Address = care-of address
Dst
Destination Address = correspondent
Parameters:
- home address
- MAC_Kbu(care-of address | correspondent node address | BU) (within the Home Address destination
option or in the Source Address)
- sequence number (within the Binding Update message
header)
- home nonce index (within the Nonce Indices option)
- care-of nonce index
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 18]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- sequence number (within the Nonce Indices option)
- ... HMAC_SHA1 (Kbm, (care-of address | CN address | BU))
The Binding Update message contains may contain a Nonce Index Indices option, so that
indicating to the correspondent node knows which home and care-of
nonces to use to recompute Kbm, the session binding management key. "BU"
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 19]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The MAC is computed as described in Section 6.2.6, using the content of the
Binding Update message, excluding (1) the IP header, (2) any
extension headers between the IP header
correspondent node's address as the Mobility Header, destination address and (3) the Authenticator field inside the
Binding Update. The
first 96 bits from the MAC result are used Update message itself as the 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. Mobility Header Data.
Once the correspondent node has verified the MAC, it can create
a binding cache Binding Cache entry for the mobile.
2.
Binding Acknowledgement
The Binding Update is optionally acknowledged by the
correspondent node. The contents of the message are as
follows:
Src
Source Address = correspondent
Dst
Destination Address = care-of address
Parameters:
- sequence number (within the Binding Update message
header)
- MAC_Kbu(care-of HMAC_SHA1 (Kbm, (care-of address | correspondent node CN address | BA)
- ... BA))
The Binding Acknowledgement contains the same sequence number
as the Binding Update did. "BA" Update. The MAC is computed as described in
Section 6.2.6, using the content of the Binding
Acknowledgement message, excluding (1) the IP header, (2)
any extension headers between the IP header correspondent node's address as the Mobility
Header,
destination address and (3) the Authenticator field inside the Binding
Acknowledgement. The first 96 bits from the MAC result are
used message itself as the Authenticator field. The three dots represent
all the remaining (not security related) information in the
message. Mobility
Header Data.
Bindings established with correspondent nodes using keys created
by way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFE seconds. seconds (see Section 12).
The value in the Source Address field in the IPv6 header carrying the
Binding Update message is normally also the care-of 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). 6.2.4). When such a message is sent to
the correspondent node and the return routability procedure is used
as the authorization method, the Care-of Test Init
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 19]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 and Care-of Test
messages MUST have been performed for the address in the Alternate
Care-of Address option (not the Source Address). The nonce indices
and MAC value MUST be based on information gained in this test.
The care-of address may be set equal to the home address in order to
delete a previously established binding In this case, generation of
the binding management key depends exclusively on the home keygen
token (Section 5.2.5).
5.2.7. Updating Node Keys and Nonces
An update of Kcn can be done
Correspondent nodes generate nonces at the same time as an update of a
nonce, so that the nonce index identifies both the nonce and the key.
Old Kcn values have regular intervals. It
is recommended to be therefore remembered as long as old keep each nonce
values.
Before sending (identified by a Binding Update, the mobile node has to wait nonce index)
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 20]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
acceptable for both
the Home and Care-of Cookies to arrive. Due to resource limitations,
rapid deletion of bindings, or reboots at least MAX_TOKEN_LIFE seconds (see Section 12)
after it can not be guaranteed that
the cookies are still fresh and acceptable when has been first used in constructing a return routability
message response. However, the correspondent node uses them in the processing of the Binding Update. If MUST NOT accept
nonces beyond MAX_NONCE_LIFE seconds (see Section 12) after the
cookies have become too old, first
use. As the correspondent node replies with
an an error code in difference between these two constants is 30 seconds,
a convenient way to enforce the Binding Acknowledgement. above lifetimes is to generate a
new nonce every 30 seconds. The mobile node can then retry the return routability procedure. However, it is
recommended continue to accept
tokens that have been based on the last 8 (MAX_NONCE_LIFE / 30)
nonces. This results in tokens being acceptable MAX_TOKEN_LIFE
to MAX_NONCE_LIFE seconds after they have been sent to the mobile
node, depending on whether the token was sent at the beginning or
end of the first 30 second period. Note that the correspondent nodes try
node may also attempt to keep these cookies
acceptable generate new nonces on demand, or only if
the old nonces have been used. This is possible, as long as possible the
correspondent node keeps track of how long time ago the nonces were
used for the first time, and does not generate new nonces on every
return routability request.
Due to resource limitations, rapid deletion of bindings, or reboots
the correspondent node may not in all cases recognize the nonces
that the tokens were based on. If a nonce index is unrecognized,
the correspondent node replies with an an error code in the
Binding Acknowledgement (either 136, 137, or 138 as discussed
in Section 6.1.8). The mobile node can then retry the return
routability procedure.
An update of Kcn SHOULD NOT accept them beyond
MAX_COOKIE_LIFE seconds. be done at the same time as an update of a
nonce, so that nonce indices can identify both the nonce and the key.
Old Kcn values have to be therefore remembered as long as old nonce
values.
Given that the cookies tokens are normally expected to be usable for
some time,
MAX_TOKEN_LIFE seconds, the mobile node MAY use them beyond a single
run of the return routability procedure. procedure until MAX_TOKEN_LIFE expires.
After this the mobile node SHOULD NOT use the tokens. A fast moving
mobile node may reuse a recent Home Cookie home keygen token from a correspondent
node when moving to a new location, and just acquire a new Care-of Cookie care-of
keygen token to show routability in the new location.
While this does not save roundtrips the number of round-trips due to the
parallel nature
simultaneous processing of the home and care-of return routability tests, the
roundtrip
there are fewer messages being exchanged, and a potentially long
round-trip through the home agent may be longer, and consequently is avoided. Consequently, this
optimization is often useful. A mobile node that has multiple home
addresses, may also use the same Care-of Cookie care-of keygen token for Binding
Updates concerning all of these addresses.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 21]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
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, however. Correspondent nodes must retain
bindings and the associated sequence number information at least as
long as the nonces used in the authorization of the binding are still
valid. The correspondent node can, for instance, change the nonce
often enough to ensure that the nonces used when removed entries
were created are no longer valid. If many such deletions occur
the correspondent node can batch them together to avoid having to
increment the nonce index too often.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 20]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
5.3. Dynamic Home Agent Address Discovery
No security is required for dynamic home agent address discovery.
5.4. Prefix Discovery
The mobile node and the home agent must have a security association
to protect prefix discovery. IPsec AH or ESP SHOULD be supported and
used for integrity protection. For ESP, a non-null authentication
algorithm MUST be applied.
5.5. Payload Packets
Payload packets exchanged with mobile nodes can be protected in the
usual manner, in the same way as stationary hosts can protect them.
However, Mobile IPv6 introduces the Home Address destination option,
a Routing Header, routing header, and tunneling headers in the payload packets. In
the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties.
This specification limits the use of the Home Address destination
option to the situation where the correspondent node already has a
binding cache
Binding Cache entry for the given home address. This avoids the use
of the Home Address option in attacks described in Section 14.1. We
also allow the option to be used when the packet containing it has
been protected by IPsec.
Mobile IPv6 uses a Mobile IPv6 specific type of a Routing Header. routing header.
This type provides the necessary functionality but does not open
vulnerabilities discussed in Section 14.1.
Tunnels between the mobile node and the home agent are protected by
ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node verifies that the outer IP address
corresponds to its home agent. The home agent verifies that the
outer IP address corresponds to the current location of the mobile
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 22]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
node (Binding Updates sent to the home agents are secure). These
measures protect the tunnels against vulnerabilities discussed in
Section 14.1.
For tunneled traffic to and from the mobile node, encapsulating tunneled via the traffic inside home agent, additional IPsec AH or ESP offers an optional mechanism to
protect the integrity
encapsulation MAY be supported and confidentiality of the traffic against
on-path attackers. used.
6. New IPv6 Protocols, Protocol, Message Types, and Destination Option
6.1. Mobility Header
The Mobility Header is an extension header used by mobile nodes,
correspondent nodes, and home agents in all messaging related to
the creation and management of bindings. Sections 6.1.2 through 6.1.9 The subsections within
this section describe the message types
used in this protocol. These sections also define which addresses to
use in that may be sent using the IPv6 header in these messages.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 21]
INTERNET-DRAFT
Mobility Support in IPv6 1 June 2002 Header.
6.1.1. Format
The Mobility Header is identified by a Next Header value of TBD <To
be assigned by IANA> in the immediately preceding header, and has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 intended to be used by a future specification
of piggybacking binding messages on payload packets (see
Section C.1). B.1).
Implementations conforming to this specification SHOULD set the
payload protocol type to NO_NXTHDR IPPROTO_NONE (59 decimal).
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 23]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Header Len
8-bit unsigned integer. Length integer, representing the length of the Mobility
Header in units of 8 octets, including excluding the first 8 octets.
The length of the Payload Proto, MH Type, Mobility Header
Len, Checksum, and Message Data fields.
We require that the Mobility Header length is MUST be a multiple of 8
octets.
MH Type
16-bit
8-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
indication to be
sent sent.
Reserved
8-bit field reserved for future use. The value MUST be
initialized to zero by the source. sender, and MUST be ignored by the
receiver.
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 December 2002 [Page 22]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Mobility Header starting with the Payload Proto field. The
checksum is the 16-bit one's complement of the 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
pseudo-header is TBD. TBD <To be assigned by IANA>. The addresses
used in the pseudo-header are the addresses that appear in
the Source and Destination Address fields in the IPv6 packet
carrying the Mobility Header.
Note that the procedures described in Section 11.3.1 apply
even for the Mobility Header. If a mobility message has a
Home Address destination option, then the checksum calculation
uses the home address in this option as the value of the IPv6
Source Address field. The type 2 routing header is treated as
explained in [26].
The Mobility Header is considered as the upper layer protocol
for the purposes of calculating the pseudo-header. The
Upper-Layer Packet Length field in the pseudo-header MUST be
set to the total length of the Mobility Header.
For computing the checksum, the checksum field is set to zero.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 24]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Message Data
A variable length field containing the data specific to 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 options will be indicated by the Header Len field
within the message. When the Header Len value is greater than the
length required for the message specified here, the remaining octets
are interpreted as mobility options. These options include padding
options that can be used to ensure that other options are aligned
properly, and that the total length of the message is divisible
by 8. The encoding and format of defined options are described in
Section 6.2.
Alignment requirements for the Mobility Header are the same as for
any IPv6 protocol Header. That is, they MUST be aligned on an
8-octet boundary.
6.1.2. Binding Refresh Request (BRR) Message
The Binding Refresh Request (BRR) message is used to request a
mobile node's binding from the mobile node. It is sent according to
the rules in Section 9.4.5. 9.5.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 source of the
Binding Refresh Request, it MAY start a return routability procedure
(see Section 5.2) if it believes the amount of traffic with the
correspondent justifies the use of route optimization. Note that processes the mobile node SHOULD NOT respond to Binding Refresh Requests from
previously unknown correspondent nodes due message
according to Denial-of-Service
concerns.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 23]
INTERNET-DRAFT Mobility Support the rules in IPv6 1 June 2002 Section 11.7.4.
The Binding Refresh Request message uses the MH Type value 0. When
this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 25]
INTERNET-DRAFT Mobility options Support in IPv6 29 Oct 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.
There MAY be additional information, associated with this
Binding Refresh Request message, that need not be present in
all Binding Requests Refresh Request messages sent. This use of mobility Mobility options also
allows for
allow future extensions to the format of the Binding Refresh
Request message to be defined. The following This specification does not
define any options
are valid in a for the Binding Refresh Request message:
- Unique Identifier Option
- Binding Authorization option
message.
If no actual options are present in this message, no padding is
necessary and the Header Length Len field will be set to 1. 0.
6.1.3. Home Test Init (HoTI) Message
A mobile node uses the Home Test Init (HoTI) message to initiate the
return routability procedure and request a home cookie keygen token from a
correspondent node (see Section 11.5.1). 11.6.1). The Home Test Init message
uses the MH Type value 1. When this value is indicated in the MH
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 24]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Type field, the format of the Message Data field in the Mobility
Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ HoT cookie Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
HoT cookie
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 26]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Home Init Cookie
64-bit field which contains a random value, the HoT home init
cookie.
Mobility options 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. 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 Len field will be set to 2. 1.
This message is sent with the Source Address set to the home
address of the mobile node, and the Destination Address set to the
correspondent node's address. The message 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 indicated by the IPsec policy data base. The protection of Home
Test Init messages is unrelated to the requirement to protect regular
payload traffic, which MAY use such tunnels as well. A packet that includes a Home 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 December 2002 [Page 25]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.1.4. Care-of Test Init (CoTI) Message
A mobile node uses the Care-of Test Init (CoTI) message to initiate
the return routability procedure and request a care-of cookie keygen token
from a correspondent node (see Section 11.5.1). 11.6.1). The Care-of Test
Init message uses the MH Type value 2. When this value is indicated
in the MH Type field, the format of the Message Data field in the
Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CoT cookie Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 27]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
CoT cookie
Care-of Init Cookie
64-bit field which contains a random value, the CoT care-of init
cookie.
Mobility options 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. This
specification does not define any options valid for the Care-of
Test Init message.
If no actual options are present in this message, no padding is
necessary and the Header Length Len field will be set to 2.
This 1.
6.1.5. Home Test Message
The Home Test (HoT) message is always sent with the Source Address set a response to the
care-of address of the mobile node, Home Test Init
message, and is sent directly to from the correspondent node. A packet that includes a Care-of node to the mobile node
(see Section 5.2.5). The Home 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 December 2002 [Page 26]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.1.5. Home Test (HoT) Message
The Home Test (HoT) message is a response to the HoTI message,
and is sent from the correspondent node to the mobile node (see
Section 5.2.5). The Home Test message uses uses the MH Type value 3.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ HoT cookie Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Cookie Keygen Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 28]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Home Nonce Index
This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update.
HoT cookie Binding Update.
Home Init Cookie
64-bit field which contains the HoT home init cookie.
Home Cookie Keygen Nonce
This field contains the 64 bit home cookie keygen token used in the
return routability procedure; it is the first of two cookies which
are to be processed to form a key which is then used to
authenticate a binding update. procedure.
Mobility options 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. 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 Support in IPv6 1 June 2002
If no actual options are present in this message, no padding is
necessary and the Header Length Len field will be set to 3. This
message is always sent with the Destination Address set to the home
address of the mobile node, Source Address set to the address of the
correspondent node, and is tunneled through the home agent when the
mobile node is away from home. 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 employ IPsec ESP in tunnel
mode. This protection is indicated by the IPsec policy data base. 2.
6.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is a response to the CoTI Care-of Test
Init message, and is sent from the correspondent node to the mobile
node (see Section 11.5.2). 11.6.2). The Care-of Test message uses the MH
Type value 4. When this value is indicated in the MH Type field,
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 29]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
the format of the Message Data field in the Mobility Header is as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ CoT cookie Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Cookie Keygen Nonce +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
The two 16-bit fields are reserved for future use. These
values MUST be initialized to zero by the sender, and MUST be
ignored by the receiver.
Care-of Nonce Index
This field value 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 Binding Update.
Care-of Init Cookie
64-bit field which contains the CoT care-of init cookie.
Care-of Cookie Keygen Nonce
This field contains the 64 bit care-of cookie keygen token used 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. procedure.
Mobility options 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. This
specification does not define any options valid for the Care-of
Test message.
The CoT message is always sent with the Source Address set to the
address of the correspondent node, and the Destination Address set to
the care-of address of the mobile node; it is sent directly to the
mobile node.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 3. 2.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 30]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
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 Updates are
sent with the Source Address set to the
care-of address of the mobile node as described in Section 11.7.1 and the Destination Address set to
the correspondent node's address. 11.7.2.
The Binding Update message uses the MH Type value 5. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|L| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 sending mobile node to
request a Binding Acknowledgement (Section 6.1.8) be returned
upon receipt of the Binding Update.
Home Registration (H)
The Home Registration (H) bit is set by the sending mobile
node to request that the receiving node should act as this
node's home agent. The destination of the packet carrying this
message MUST be that of a router sharing the same subnet prefix
as the home address of the mobile node in the binding.
Single Address Only (S)
If the `S' this bit is set, the mobile node requests that the home
agent make no changes to any other Binding Cache entry except
for the particular one containing the home address specified
in the Home Address destination option. This disables home
agent processing for other related addresses, as is described
in Section 10.2. 10.3.1.
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 [13]
on the mobile node's home link for the home address in this
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 31]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
binding. This bit is only valid when the 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 when the
home address reported by the mobile node has the same interface
identifier (IID) as the mobile node's link-local address.
Reserved
These fields are unused. They 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.
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) (0xffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST
be deleted. One time unit is 16 4 seconds.
Mobility options 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.
The following options are valid in a Binding Update message:
- Unique Identifier option Update:
- Binding Authorization Data option
- Nonce Indices option.
- Alternate Care-of Address option
If no actual options are present in this message, no 4 bytes of padding is
necessary and the Header Len field will be set to 4.
A Binding Update to the home agent 1.
The care-of address MUST include the Home Address
destination option if the Source Address field in the IPv6 header is
not the home address of the mobile node.
The care-of address MUST NOT be any IPv6 address which is prohibited
for use within a Routing Header; thus multicast addresses, the
unspecified address, loop-back address, and link-local addresses
are excluded. unicast routable address. Binding
Updates indicating any such excluded for a care-of address which is not a unicast routable address
MUST be silently discarded.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 32]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The deletion of a binding can be indicated by setting the Lifetime
field to 0 or by setting the care-of address equal to the home
address. In either case, generation of the binding management
key depends exclusively on the home keygen token (Section 5.2.5).
Correspondent nodes SHOULD NOT expire the binding cache Binding Cache entry before
the lifetime expires, if any application hosted by the correspondent
node is still likely to require communication with the mobile node.
A binding cache Binding Cache entry that is deallocated prematurely might cause
subsequent packets to be dropped from the mobile node, if they
contain the Home Address destination option. This situation is
recoverable, since an error Binding Error message is sent to the mobile node;
node (see Section 6.1.9); however, it causes unnecessary delay in the
communications.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 31]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.1.8. Binding Acknowledgement (BA) Message
The Binding Acknowledgement message is used to acknowledge receipt of a
Binding Update message (Section 6.1.7). When a node receives
a This 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 9.5.4 and 9.4.4. The Source Address of the
Binding Acknowledgement is the Destination Address from the Binding
Update. 10.3.1.
The Binding Acknowledgement message has the MH Type value 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
These fields are unused. They MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Status
8-bit unsigned integer indicating the disposition of the
Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving
node. Values greater than or equal to 128 indicate that
the Binding Update was rejected by the receiving node. The
following Status values are currently defined:
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 33]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
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 December 2002 [Page 32]
INTERNET-DRAFT Mobility Support in IPv6 1 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 Expired home nonce index
137 Invalid authenticator
138 Expired Home Nonce Index
139 care-of nonce index
138 Expired Care-of Nonce Index nonces
Up-to-date values of the Status field are to be specified in
the IANA registry of assigned numbers [18].
Sequence #
The Sequence Number in the Binding Acknowledgement is
copied from the Sequence Number field in the Binding Update.
It is used by the mobile node in matching this Binding
Acknowledgement with an outstanding Binding Update.
Lifetime
The granted lifetime, in time units of 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) (0xffff) indicates
infinity.
The value of this field is undefined if the Status field
indicates that the Binding Update was rejected.
Mobility options 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.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 34]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
There MAY be additional information, associated with this
Binding Acknowledgement message, Acknowledgement, that need not be present in all
Binding Acknowledgements sent. This use of mobility Mobility options also allows for allow future
extensions to the format of the Binding Acknowledgement message to
be defined. The following options are valid for the Binding Acknowledgement message:
Acknowledgement:
- Binding Authorization Data option
- Binding Refresh Advice option
If no options are present in this message, 4 bytes of padding is
necessary and the Header Len field will be set to 2.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 33]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The Binding Acknowledgement is sent to the source address of the
Binding Update message, regardless of whether the Binding Update
succeeded or failed. No Routing Headers are added to the message. 1.
6.1.9. Binding Error (BE) Message
The Binding Error (BE) 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. A packet containing a Binding Error message is sent to the
source address of the 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 to the care-of address of the
mobile node. The source address of the Binding Error message is the
correspondent node's address.
binding; see Section 9.3.3 for details.
The Binding Error message uses the MH Type value 7. When this value
is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
8-bit unsigned integer indicating the reason for this message.
The following such Status values are currently defined:
1 Unknown binding for Home Address destination option used without a binding
2 Received message had an unknown value for the Unrecognized MH Type
field value
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 34] 35]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Reserved
A 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Home Address
The home address that was contained in the Home Address
destination option. The mobile node uses this information to
determine which binding does not exist, in cases where the
mobile node has several home addresses.
Mobility options 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
Binding Error message, that need not be present in all Binding
Error messages sent. This use of mobility Mobility options also allows
for allow future extensions
to the format of the format of the 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 Binding Error message.
If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 3. 2.
6.2. Mobility Options
6.2.1. Format
In order to allow
Mobility messages can include one or more mobility options. This
allows optional fields that may not be needed in every use of any given a
particular Mobility Header, and to allow as well as future extensions to the
format of these messages to be defined, the Mobility Header messages
defined in this document can include one or more mobility options. messages. Such options are included in the data portion Message
Data field of the message itself, after the fixed portion of the
message data specified in the message subsections of section Section 6.1.
The presence of such options will be indicated by the Header Len of
the Mobility Header. If included, the Binding Authorization Data
option (Section 6.2.6) MUST be the last option and MUST NOT have
trailing padding. Otherwise, options can be placed in any order.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 35] 36]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
These
6.2.1. Format
Mobility options are encoded within the remaining space of the message
data for that
Message Data field of a mobility message, using a type-length-value
(TLV) format as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Option Len Length
8-bit unsigned integer. Length integer, representing the length in octets of this
the mobility option, in
octets. The Option Len does not include the length of including the Option Type and Option Len
Length fields.
Option Data
A variable length field that contains data specific to the
option.
The following subsections specify the Option types which are
currently defined for use 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
is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case -- - it has
neither Option Len Length nor Option Data fields.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 36] 37]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
The Pad1 option is used to insert one octet of padding in the
Mobility Options area of a Mobility Header. If more than 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Len Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding in
the Mobility Options area of a Mobility Header mobility message. For N octets of
padding, the Option Len Length field contains the value N-2, and the
Option Data consists of N-2 zero-valued octets. Option data MUST be
ignored by the receiver.
6.2.4. Unique Identifier
The Unique Identifier option has the 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 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 2 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier option is valid only in Binding Refresh
Request, and Binding Update messages. The Unique Identifier field
contains a 16-bit value that serves to uniquely identify a Binding
Request among those sent by this Source Address, and to allow the
Binding Update to identify the specific Binding Refresh Request to
which it responds.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 37]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.2.5. Alternate Care-of Address
The Alternate Care-of Address option has an alignment requirement of
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address option is valid only in Binding Update
message. Update.
The Alternate Care-of Address field contains an address to use as the
care-of address for the binding, rather than using the Source Address
of the packet as the care-of address.
6.2.6.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 38]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
6.2.5. 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 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices option is valid only 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 message which of the challenge its stored random nonce values (Ni) are is to be used to
authenticate
produce the home keygen token to authorize the Binding Update.
The Care-of Nonce Index field tells the correspondent node that
receives the message which of the challenge its stored random nonce values (Nj) are is to
be used to authenticate produce the care-of keygen token to authorize the Binding
Update.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 38]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
6.2.7.
6.2.6. Binding Authorization Data
The Binding Authorization Data option has an alignment requirement of
4n+2.
8n+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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Len Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is valid only in the Binding
Refresh Request, Binding Update, Update
and Binding Acknowledgment messages. Acknowledgment.
The Option Len Length field contains the length of the authenticator in
octets.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 39]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The Authenticator field contains a cryptographic value which can be
used to determine that the message in question comes from the right
authority. Rules for calculating this value depend on the used
authorization procedure. This specification gives the rules only for
For the return routability procedure. For this procedure, this option can only appear in a the
Binding Update message and rules Binding Acknowledgements. Rules for calculating
the Authenticator value are described in Section 6.1.7.
6.2.8. Binding Refresh Advice
The Binding Refresh Advice 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 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length the following:
Mobility Data = 2 care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ final dest | Refresh Interval Mobility Header Data
Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
Where |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option denotes concatenation and "final dest" is only valid in the Binding
Acknowledgement message, and only on Acknowledgements sent from IPv6 address
of the mobile node's home agent in reply to a home registration. The
Refresh Interval final destination of the packet. "Mobility Header Data" is measured in seconds, and indicates how long
before
the mobile node SHOULD send a new home registration to content of the
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 39]
INTERNET-DRAFT Mobility Support Header, excluding the Authenticator
field itself. The Authenticator value is calculated as if the
Checksum field in the Mobility Header was zero. The Checksum in the
transmitted packet is still calculated in the usual manner, with
the calculated Authenticator being a part of the packet protected
by the Checksum. Kbm is the binding management key, which is
typically created using nonces provided by the correspondent node
(see Section 9.4).
The first 96 bits from the MAC result are used as the Authenticator
field. Note that, if the message is sent to a destination which is
itself mobile, the "final dest" address may not be the address found
in the Destination Address field of the IPv6 header; instead the
address of the true destination (e.g., its home address) should be
used.
6.2.7. Binding Refresh Advice
The Binding Refresh Advice option has an alignment requirement of 2n.
Its format is as follows:
0 1 June 2002 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 = 6 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option is only valid in the Binding
Acknowledgement, and only on Binding Acknowledgements sent from
the mobile node's home agent in reply to a home registration. The
Refresh Interval is measured in units of four seconds, and indicates
how long before the mobile node SHOULD send a new home registration
to the home agent. The Refresh Interval MUST be set to indicate
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 40]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
a smaller time interval than the Lifetime value of the Binding
Acknowledgement.
6.3. Home Address Destination Option
The Home Address destination option is carried by the Destination Option
extension header (Next Header value = 60). It is used in a packet
sent by a mobile node while away from home, to inform the recipient
of the mobile node's home address.
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 the packet if tunneling is involved.
The Home Address option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
201 = 0xC9
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 Address
The home address of the mobile node sending the packet. This
address MUST be a unicast routable address.
IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 40]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
an integer multiple of n octets from the start of the header, for
n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home
Address option is 8n+6.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 41]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The three highest-order bits of the Option Type field are encoded
to indicate specific processing of the option [11]. For [11]; for the Home
Address option, these three bits are set to 110, indicating that any 110. This indicates the
following processing requirements:
- Any IPv6 node processing this option that does not recognize the Option Type must
discard the packet and, only if packet.
- If the packet's Destination Address was not a multicast address,
return an ICMP Parameter Problem, Code 2, message to the packet's
Source Address; and that otherwise, for multicast addresses, the ICMP
message MUST NOT be sent.
- The data within the option cannot change en-route to the packet's
final destination.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [15] MAY contain a separate Home Address
option associated with each encapsulating IP header.
The Home Address option MUST be placed as follows:
- After the Routing Header, routing header, if that header is present
- Before the Fragment Header, if that header is present
- Before the AH Header or ESP Header, if either one of those
headers is present
For each IPv6 packet header, the Home Address Option MUST NOT appear
more than once. However, an encapsulated packet [15] MAY contain a
separate Home Address option associated with each encapsulating IP
header.
The inclusion of a Home Address destination option in a packet
affects the receiving node's processing of only this single packet;
no packet.
No state is created or modified in the receiving node as a result
of receiving a Home Address option in a packet. In particular, the
presence of a Home Address option in a received packet MUST NOT alter
the contents of the receiver's Binding Cache and MUST NOT cause any
changes in the routing of subsequent packets sent by this receiving
node.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 41] 42]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
6.4. Type 2 Routing Header type 2
Mobile IPv6 uses defines a Routing new routing header variant, the type 2
routing header, to carry allow the Home Address for
packets sent packet to be routed directly from a
correspondent node to a the mobile node. node's care-of address. The Care of mobile
node's care-of address is inserted into the IPv6 Destination Address of
field. Once the packet arrives at the care-of address, the mobile
node retrieves its home address from the routing header, and this is carried in
used as the IPv6 final destination field. address for the packet.
The new Routing 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. Mobile IPv6. This Routing routing
header type (Type (type 2) is restricted to carry only one IPv6 address.
All IPv6 nodes which process this Routing 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.
The IP address contained in the routing header, since it is the
mobile node's home address, MUST be a unicast routable address.
Furthermore, if the scope of the home address is smaller than the
scope of the care-of address, the mobile node MUST discard the packet
(see Section 4.6).
6.4.1. Routing Header Packet format Format
The Type type 2 Routing routing header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
8-bit selector. Identifies the type of header immediately
following the Routing routing header. Uses the same values as the IPv6
Next Header field [11].
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 43]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Hdr Ext Len
8-bit
2 (8-bit unsigned integer. Length integer); length of the Routing routing header in
8-octet units, not including the first 8 octets. For the octets
Routing Type
2 Routing (8-bit unsigned integer).
Segments Left
1 (8-bit unsigned integer).
Reserved
32-bit reserved field. Initialized to zero for transmission,
and ignored on reception.
Home Address
The Home Address of the destination Mobile Node.
For a type 2 routing header, the Hdr Ext Len is always 2.
Routing Type
8-bit unsigned integer that contains the value MUST be 2.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 42]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 The Segments
Left
8-bit unsigned integer. Number value describes the number of route segments remaining; i.e.,
number of explicitly listed intermediate nodes still to be visited
before reaching the final destination. Packets
transmitted through an interface have Segments left is always 1
in this type of Routing header.
Reserved
32-bit reserved field. Initialized to zero for transmission,
and ignored on reception.
Home Address
The Home Address of the destination Mobile Node. Left MUST be 1. The
ordering rules for extension headers in an IPv6 packet are described
in Section 4.1 of [11]. The new Routing type 2 routing header (Type 2) defined for Mobile
IPv6 follows the same ordering as other routing headers. If more than one Routing header (e.g., both a
Type 0 and a
Type type 2 Routing routing header are present), present, the Type type 2 Routing routing
header should follow all other Routing headers. Otherwise the order of other routing
headers is independent of their type and follows [11]. header.
In addition, the general procedures defined by IPv6 for Routing routing
headers suggest that a received Routing routing header MAY be automatically
"reversed" to construct a Routing 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 type 2
Routing
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 to initiate the dynamic home agent address discovery
mechanism, as described in Section 11.3.2. 11.4.1. The mobile node sends
a
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 44]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
the Home Agent Address Discovery Request message to the "Mobile Mobile IPv6
Home-Agents"
Home-Agents anycast address for 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 43]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Type
150 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [14].
Identifier
An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request
message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
The Source Address of the Home Agent Address Discovery Request
message packet 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 to the Source Address chosen by the
mobile node. Note that, at the time of performing this dynamic home
agent address discovery, discovery procedure, it is likely that the mobile node
is not registered with any home agent within the specified anycast
group.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 44] 45]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 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
the home agents on the home link 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 as home agents. 10.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
151 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [14].
Identifier
The identifier from the invoking Home Agent Address Discovery
Request message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
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 home link for the
mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 46]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 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 is to solicit a Mobile Prefix Advertisement from
the home agent, which will allow the mobile node to gather prefix
information about its home network. This information can be used to
configure
home address(es) by stateless address autoconfiguration [13],
or and update home 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The mobile node's care-of address.
Destination Address
The address of the mobile node's home agent. This home agent
must be on the link which the mobile node wishes to learn
prefix information about.
Hop Limit
Set to an initial hop limit value, similarly to any other
unicast packet sent by the mobile node.
Authentication Header
If a Security Association for the IP Authentication Header
exists between the sender and the
Destination Option:
A Home Address destination address, then the
sender SHOULD include this header. [subject to change] option MUST be included.
AH or ESP header:
IPsec headers SHOULD be supported and used as described in
Section 5.4.
ICMP Fields:
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 47]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Type
152 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [14].
Identifier
An identifier to aid in matching a future Mobile Prefix
Advertisement message to this Mobile Prefix Solicitation
message. Solicitation.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
If the mobile node 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 has been formed from the newly advertised prefix
information. If there are security concerns that would inhibit
responding to unauthenticated advertisements, then the mobile node
SHOULD send a Mobile Prefix Solicitation message to its home agent,
with a nonzero Identifier value that can be used to match a future
advertisement with the solicitation.
The mobile node SHOULD include authentication data along with any
Mobile Prefix Solicitation message that it sends to the home agent.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 48]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message to a mobile
node to distribute prefix information about the home link while the
mobile node is traveling away from the home network. This will occur
in response to a Mobile Prefix Solicitation with an Advertisement,
or by an unsolicited Advertisement sent according to the rules in
Section 10.9.1. 10.6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The home agent's address as the mobile node would
expect to see it (i.e., same network prefix)
Destination Address
If this message is a response to a Mobile Prefix
Solicitation, this field contains the Source Address
field from that packet. For unsolicited messages,
the mobile node's care-of address SHOULD be used.
Note that unsolicited messages can only be sent if
the mobile node is currently registered with the
home agent.
Authentication Header
An AH
Routing header:
A type 2 routing header MUST be included unless the mobile node
has yet to configure a home address. included.
AH or ESP header:
IPsec headers SHOULD be supported and used as described in
Section 5.4.
ICMP Fields:
Type
153 <To Be Assigned by IANA>
Code
0
Checksum
The ICMP checksum [14].
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 49]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Code
0
Checksum
The ICMP checksum [14].
Identifier
An identifier to aid in matching this Mobile Prefix
Advertisement message to a previous Mobile Prefix Solicitation
message. Solicitation.
Options:
Prefix Information
Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should
use to configure its home address(es). Section 10.9.1 10.6 describes
which prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2
of [12], with modifications defined in Section 7.2 of this
specification. The home agent MUST use this modified Prefix
Information option to send the aggregate list of home network
prefixes as defined in Section 10.9.1. 10.6.1.
The Mobile Prefix Advertisement sent by the home agent MAY include
the Source Link-layer Address option defined in RFC 2461 [12], or the
Advertisement Interval option specified in Section 7.3.
Future versions of this protocol may define new option types. Mobile
nodes MUST silently ignore any options they do not recognize and
continue processing the message.
If the Advertisement is sent in response to a Mobile Prefix
Solicitation, the home agent MUST copy the Identifier value from that
message into the Identifier field of the Advertisement.
The home agent MUST NOT send more than one Mobile Prefix
Advertisement message per second to any mobile node.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 50]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7. Modifications to IPv6 Neighbor Discovery
7.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement
message [12] by the addition of a single flag bit to indicate that
the router sending the Advertisement message is serving as a home
agent on this link. The format of the Router Advertisement message
is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally
specified for Neighbor Discovery [12]:
Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is
also functioning as a Mobile IP IPv6 home agent on this link.
Reserved
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Home Agent (H) above bit.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 51]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address for two
reasons:
- To allow a home agent (a router) to learn the address of all
other home agents on the link for which it is providing home
agent service, for use in
building its a Home Agents List as part of the dynamic home agent address
discovery mechanism (Sections 10.9 10.5 and 11.3.2).
- To allow a mobile node to send a Binding Update to a router on
the link on which its previous care-of address is located, for
purposes of establishing forwarding from this previous care-of
address to its new care-of address (Section 11.6.6). 11.4.1).
However, Neighbor Discovery [12] only advertises a router's
link-local address, by requiring this address 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 addition of a single flag bit in the
format of a Prefix Information option for use in Router Advertisement
messages. The format of the Prefix Information option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally
specified for Neighbor Discovery [12]:
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 52]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Router Address (R)
1-bit router address flag. When set, indicates that the
Prefix field, in addition to advertising the indicated prefix,
contains a complete IP address assigned to the sending router.
This router IP address has the same scope and conforms to the
same lifetime values as the advertised prefix. This use of
the Prefix field is compatible with its use in advertising
the prefix itself, since prefix advertisement 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) and Autonomous
Address-Configuration (A) flag bits.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 52]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Router Address (R) above bit.
In a solicited Router Advertisement, a home agent MUST, and all other routers SHOULD,
MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery specifies that, if including
all options in a Router Advertisement causes the size of the
Advertisement to exceed the link MTU, multiple Advertisements can be
sent, each containing a subset of the options [12]. In this case, at
least one (not all) of these multiple Advertisements being sent instead
of a single larger solicited Advertisement, MUST include a Prefix
Information option with the Router Address (R) bit set.
All routers SHOULD include at least one Prefix Information option
with the Router Address (R) bit set, in each unsolicited multicast
Router Advertisement that they send. If multiple Advertisements
are being sent instead of a single larger unsolicited multicast
Advertisement, at least one of these multiple Advertisements SHOULD
include a Prefix Information option with needs
to satisfy the Router Address (R) bit
set. above requirement.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 53]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the interval at which the
sending router sends unsolicited multicast Router Advertisements.
The format of the Advertisement Interval option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using
the conceptual router configuration variables defined by
Neighbor Discovery [12], this field MUST be equal to the value
MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.4.1. 11.5.1.
This option MUST be silently ignored for other Neighbor Discovery
messages.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 54]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used in
Router Advertisement messages Advertisements sent by a home agent to advertise information
specific to this router's functionality as a home agent. The format
of 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 of the option (including
the type and length fields) in units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Preference
16-bit signed, twos-complement two's complement integer. The preference for
the home agent sending this Router Advertisement, for use in
ordering the addresses returned to a mobile node in the Home
Agent Addresses field of a Home Agent Address Discovery Reply
message. Higher values mean more preferable. If this option
is not included in a Router Advertisement in 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 a
home agent more preferable than this default value, and values
less than 0 indicate a less preferable home agent.
The manual configuration of the Home Agent Preference value
is described in Section 8.4. In addition, the sending home
agent MAY dynamically set the Home Agent Preference value, for
example basing it on the number of mobile nodes it is currently
serving or on its remaining resources for serving additional
mobile nodes; such dynamic settings are beyond the scope of
this document. Any such dynamic setting of the Home Agent
Preference, however, MUST set the preference appropriately,
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 55]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
relative to the default Home Agent Preference value of 0 that
may be in use by some home agents on this link (i.e., a home
agent not including a Home Agent Information option in its
Router Advertisements will be considered to have a Home Agent
Preference value of 0).
Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the
home agent in units of seconds. The default value is the same
as the Router Lifetime, as specified in the main body of the
Router Advertisement message. Advertisement. The maximum value corresponds to 18.2
hours. A value of 0 MUST NOT be used. The Home Agent Lifetime
applies only to this router's usefulness as a home agent; it
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 option
is not included in a Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to
be the same as the Router Lifetime in the Router Advertisement.
If multiple Advertisements are being sent instead of a single
larger unsolicited multicast Advertisement, all of the multiple
Advertisements with the Router Address (R) bit set MUST include this
option with the same contents, otherwise this option MUST be omitted
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, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home
agent.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 56]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7.5. Changes to Sending Router Advertisements
The 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 moves into wireless transmission range of them (or physically
connects to a new wired network), and by learning that previous
routers are no longer reachable. Mobile nodes MUST be able to
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 care-of address with their home agent 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, This is important
on network interfaces where the router is expecting to provide
service to visiting mobile nodes (e.g., wireless network interfaces),
or on which it is serving as a home agent to one or more mobile
nodes (who may return home and need to hear its Advertisements), the router Advertisements).
Such routers 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 use SHOULD be taken
into account in configuring these limits for each network interface.
When sending unsolicited
Note that multicast Router Advertisements more
frequently than the standard limit on unsolicited multicast
Advertisement frequency, the sending router need are not include all
options always required
in certain wireless networks that have limited bandwidth. Mobility
detection or link changes in such networks may be done at lower
layers. Router advertisements in such networks SHOULD be sent only
when solicited. In such networks it SHOULD be possible to disable
unsolicited multicast Router Advertisements on specific interfaces.
The MaxRtrAdvInterval in such a case can be set to some high value.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 57]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
When sending unsolicited multicast Router Advertisements more
frequently than the standard limit on unsolicited multicast
Advertisement frequency, the sending router need not include all
options in each of these Advertisements, but it SHOULD include at
least one Prefix Information option with the Router Address (R) bit
set (Section 7.2) in each.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 57] 58]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
7.6. Changes to Sending Router Solicitations
In addition to the limit on routers sending unsolicited multicast
Router Advertisement messages (Section 7.5), Neighbor Discovery
defines limits on nodes sending Router Solicitation messages, such
that a node SHOULD send no more than 3 Router Solicitations, and that
these 3 transmissions SHOULD be spaced at least 4 seconds apart.
However, these limits prevent a mobile node from finding a new
default router (and thus a new care-of address) quickly as it moves
about.
Mobile IPv6 relaxes 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 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
Solicitations.
- The rate at which a mobile node sends Router Solicitations MUST
be limited, although a mobile node MAY send Router Solicitations
more frequently than the defined Neighbor Discovery limit of
RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST
be configurable, and specific knowledge of the 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 rate at which it sends subsequent
Router Solicitations. Subsequent Router Solicitations SHOULD
be sent using a binary exponential backoff back-off mechanism, doubling
the interval between consecutive Router Solicitations, up to a
maximum interval. The 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 Solicitations unless it has received a positive
indication (such as from lower network layers) that 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 a new default router and care-of address.
- A mobile node that is currently configured with a care-of address
SHOULD NOT send Router Solicitations to the default router
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 58] 59]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
on its current link, until its movement detection algorithm
(Section 11.4.1) 11.5.1) determines that it has moved and that its
current care-of address might no longer be valid.
7.7. Changes to Duplicate Address Detection
Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to
stop using the address and wait for reconfiguration. In addition, if
the failed address was a link-local address formed from an interface
identifier, the interface should be disabled.
Mobile IPv6 extends this behavior as follows. Upon failing Duplicate
Address Detection while away from home, the mobile node SHOULD stop
using the address on this interface until the mobile node moves to
another link. The mobile node SHOULD NOT wait for reconfiguration or
disable the interface.
The mobile node MUST NOT discard the home address based on a failure
of a link-local address with the same interface identifier. Instead,
the mobile node SHOULD generate a new random interface identifier and
use it for assigning itself a new link-local address. In order to do
this, the mobile node applies to the link-local address the procedure
described in [17] for global addresses. At most 5 consecutive
attempts SHOULD be performed to generate such addresses and test
them through Duplicate Address Detection. If after these attempts
no unique address was found, the mobile node SHOULD log a system
error and give up attempting to find a link-local address on that
interface, until the node moves to a new link.
8. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions
provided by different types of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement is
intended to support.
The requirements are set for the following groups of nodes:
- All IPv6 nodes.
- All IPv6 nodes with support for route optimization.
- All IPv6 routers.
- All Mobile IPv6 home agents.
- All Mobile IPv6 mobile nodes.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 60]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
It is outside the scope of this specification to specify which
of these groups are mandatory in IPv6. We only describe what is
mandatory for a node that supports, for instance, route optimization.
Other specifications are expected to define the extent of IPv6.
8.1. General Requirements for All IPv6 Nodes
Any IPv6 node may at any time be a correspondent node of a mobile
node, either sending a packet to a mobile node or receiving a packet
from a mobile node. The following requirements There are necessary
for every no Mobile IPv6 node (whether host or router, whether mobile or
stationary), since otherwise communications may be impossible:
- The node MUST be able to validate a Home Address option received
in any specific requirements
for such nodes, and standard IPv6 packet as described in Section 9.2.2.
- The node MUST be able to send a Binding Error message as
described in Section 9.4.6. techniques are sufficient.
8.2. IPv6 Nodes with Support for Route Optimization Requirements for All IPv6
Nodes that implement route optimization are a subset of all IPv6
nodes on the Internet. The ability of a correspondent node to
participate in route optimization is essential for the efficient
operation of the IPv6 Internet, beneficial for robustness and
reduction of jitter and latency, and necessary to avoid congestion
in the home network.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 59]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 The following requirements apply to all
correspondent nodes that support route optimization:
- The node MUST be able to participate in validate a return routability
procedure (Section 9.3).
- The node MUST be able to process Home Address option using an
existing Binding Update messages
(Section 9.4). Cache entry, as described in Section 9.3.1.
- The node MUST be able to return insert a Binding Acknowledgement message
(Section 6.1.8).
- The node MUST type 2 routing header
into packets to be able sent to maintain a Binding Cache of the
bindings received in accepted Binding Updates, mobile node, as described in
Sections 9.1
Section 9.3.2.
- Unless the correspondent node is also acting as a mobile node, it
MUST ignore type 2 routing headers and 9.5. drop all packets that it
has received with such headers.
- The node MUST SHOULD be able to insert a Routing Header type 2 into
packets interpret ICMP messages as described
in Section 9.3.4.
- The node MUST be able to send Binding Error messages as described
in Section 9.3.3.
- The node MUST be sent able to a mobile node, process Mobility Headers as described in
Section 9.6. 9.2.
- The node SHOULD MUST be able to interpret ICMP participate in a return routability
procedure (Section 9.4).
- The node MUST be able to process Binding Update messages
(Section 9.5).
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 61]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- The node MUST be able to return a Binding Acknowledgement
(Section 9.5.4).
- The node MUST be able to maintain a Binding Cache of the
bindings received in accepted Binding Updates, as described in Section 9.7.
Sections 9.1 and 9.6.
8.3. Requirements for All IPv6 Routers
All IPv6 routers, even those not serving as a home agent 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 (Section 7.3) in each of its Router
Advertisements [12], to aid movement detection by mobile nodes
(as in Section 11.4.1). 11.5.1). The use of this option in Router
Advertisements MUST be configurable.
- Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router 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 with the `R' Router
Address (R) bit set and with its full IP address in its router advertisements Router
Advertisements (as described in Section 7.2).
- Filtering routers SHOULD support different rules for Type type 0
and
Type type 2 Routing routing headers (see Section 6.4) so that filtering
of source routed packets (Type (type 0) will not necessarily limit MIPv6
Mobile IPv6 traffic which is delivered via Type type 2 Routing routing
headers.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 60]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
8.4. Requirements for IPv6 Home Agents
In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function
as a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers capable of serving that serve 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 home
agent (Section 10.1). Each such Binding Cache entry records the
mobile node's binding with its primary care-of address (Sections 10.1 and is
marked as a "home registration" (Section 10.2). 10.3.1).
- 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). 10.4.1).
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 62]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- Every home agent MUST be able to encapsulate [15] such
intercepted packets in order to tunnel them to the primary
care-of address for the mobile node indicated in its binding in
the home agent's Binding Cache (Section 10.5). 10.4.2).
- 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 the
mobile node (Section 10.6). 10.4.3).
- The node MUST be able to process Mobility Headers as described in
Section 10.2.
- Every home agent MUST be able to return a Binding Acknowledgement
message
in response to a Binding Update option received with the
Acknowledge (A) bit set (Section 10.2). 10.3.1).
- Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in
Section 4.5.
Sections 10.1 and 10.5.1.
- Every home agent MUST be able to accept packets addressed to
the "Mobile Mobile IPv6 Home-Agents" Home-Agents anycast address for the subnet
on which it is serving as a home agent [16], and MUST be
able to participate in dynamic home agent address discovery
(Section 10.9). 10.5).
- Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to be sent
by this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends
(Section 7.4).
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 61]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
Solicitations (Section 6.7). This behavior MUST be configurable,
so that home agents can be configured to avoid sending such
Prefix Advertisements according to the needs of the network
administration in the home domain.
8.5. Requirements
- Every home agent MUST support IPsec ESP for protection of packets
belonging to the return routability procedure (Section 10.4.4).
8.5. IPv6 Mobile Nodes
Finally, the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes:
- Every The node MUST maintain a Binding Update List (Section 11.1).
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 63]
INTERNET-DRAFT Mobility Support in IPv6 mobile 29 Oct 2002
- The node MUST support sending packets containing a Home
Address option (Section 11.3.1), and follow the required IPsec
interaction (Section 11.3.2).
- The node MUST be able to perform IPv6 encapsulation and
decapsulation [15].
- Every IPv6 mobile The node MUST be able to process type 2 routing header as defined
in Sections 6.4 and 11.3.3.
- The node MUST support receiving a Binding Error message
(Section 11.7.5).
- The node SHOULD support receiving ICMP errors (Section 11.3.4).
- The node MUST support movement detection, care-of address
formation, and returning home (Section 11.5).
- The node MUST be able to process Mobility Headers as described in
Section 11.2.
- The node MUST support the return routability procedure
(Section 5.2.5). 11.6).
- Every IPv6 mobile The node MUST be able to send Binding Update
messages, Updates, as specified in
Sections 11.6.1, 11.6.2, 11.7.1 and 11.6.6. 11.7.2.
- Every IPv6 mobile The node MUST be able to receive and process Binding Acknowledgement messages,
Acknowledgements, as specified in Section 11.6.3.
- Every IPv6 mobile node MUST maintain a Binding Update List in
which it records the IP address of each other node to which it
has sent a Binding Update, for which the Lifetime sent in that
binding has not yet expired (Section 11.1). 11.7.3.
- Every IPv6 mobile The node MUST support receiving a Binding Refresh Request
(Section 6.1.2), by responding with a Binding Update
message. Update.
- Every IPv6 mobile The node MUST support sending packets containing a
Home Address option receiving Mobile Prefix Advertisements
(Section 11.2.1).
- Every IPv6 mobile node MUST maintain a Home Agents List, as
described in Section 4.5.
- Every mobile node MUST support receiving Mobile Prefix
Advertisements (Section 11.3.4) 11.4.3) and reconfiguring its home address based on the
prefix information contained therein.
- Every IPv6 mobile The node SHOULD support use of the dynamic home agent address
discovery mechanism, as described in Section 11.3.2. 11.4.1.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 62] 64]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 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 to a mobile node.
9.1. Conceptual Data Structures
Each
IPv6 node maintains nodes with route optimization support maintain 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 the
external behavior described in this document, for example by being
combined with the node's Destination Cache as maintained by Neighbor
Discovery [12]. When sending a packet, the Binding Cache is searched
before the Neighbor Discovery conceptual Destination Cache [12] (i.e., [12].
That is, any Binding Cache entry for this destination SHOULD take
precedence over any Destination Cache entry for the same destination). destination.
Each Binding Cache entry conceptually contains the following fields:
- The home address of the mobile node for which this 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 address
in the Binding Cache entry, this entry SHOULD be used in routing
that packet.
- The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry. If the destination
address of a packet being routed by a node matches the home
address in this entry, the packet SHOULD be routed to this
care-of address. This is described in Section 9.6 9.3.2 for packets
originated by this node, and in Section 10.5 if this node is the
mobile node's home agent and the packet was intercepted by it on
the home link. node.
- A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from
the Lifetime field in the Binding Update that created or last
modified this Binding Cache entry. Once the lifetime of this
entry expires, the entry MUST be deleted from the Binding Cache.
- A flag indicating whether or not this Binding Cache entry is a
"home registration"
home registration entry.
- The maximum value of the Sequence Number field received in
previous Binding Updates for this mobile node home address. The
Sequence Number field is 16 bits long, and all comparisons
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 63]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
between long. Sequence Number values
MUST be performed compared modulo 2**15 2**16 as explained in Section 9.4.1. 9.5.1.
- Recent usage Usage information for this Binding Cache entry, as entry. This is needed
to implement the cache replacement policy in use in the Binding
Cache and to assist in determining whether
Cache. Recent use of a cache entry also serves as an indication
that a Binding Refresh Request should be sent when the lifetime
of this entry nears expiration.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 65]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Binding Cache entries not marked as "home registrations" home registrations MAY be
replaced at any time by any reasonable local cache replacement policy
but SHOULD NOT be unnecessarily deleted. 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 a node's Binding
Cache MUST NOT be changed in response to a Home Address option in a
received packet. The contents of all of a node's Binding 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 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 Headers
Mobility Header (MH) Messages
All IPv6 correspondent nodes processing MUST observe the following rules when
processing Mobility Header messages: rules:
1. If an The MH message of unknown type is received Type field MUST have a known value (Section 6.1, 6.1.1).
Otherwise, the
correspondent node MUST discard the message and SHOULD issue a
Binding Error message to the
packet's Source Address as described in Section 9.3.3, with Status
field set to 2 (unrecognized MH Type value).
2. Finally, the
correspondent node MUST discard the packet.
2. If the "Next Header" The Payload Proto field is not NO_NXTHDR MUST be IPPROTO_NONE (59 decimal), decimal).
Otherwise, the
packet node MUST be silently discarded. discard the message.
3. The checksum must be verified as per Section 6.1. Otherwise, the
node MUST silently discard the message.
Subsequent checks depend on the particular Mobility Header message, Header, as
specified in Sections 9.3 9.4 and 9.4. Subsequent checks depend
on 9.5.
9.3. Packet Processing
This section describes how the particular Mobility Header message. There are two types
of Mobility Header messages. The return routability procedure
(Section 9.3) is used correspondent node sends packets 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 December 2002 [Page 64]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The other type of Mobility Header messages are directly concerned
with managing bindings (Section 9.4).
9.2.2. node, and receives packets from it.
9.3.1. Receiving Packets with Home Address Destination Option
If the correspondent node has a Binding Cache Entry entry for the home
address of a mobile node, packets sent by the mobile node MAY include
a Home Address destination option. The correspondent node MUST
process the option in
Packets containing a manner consistent with exchanging the Home
Address field from 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 dropped if the knowledge that it came originally from
a care-of given
home address or that is not a Home Address option was used.
Due to the threat of reflection attacks, this specification requires
that packets unicast routable address.
Packets containing a Home Address option MUST also be dropped if
there is no corresponding Binding Cache Entry entry for the given home
address and the packet was not protected by IPsec.
address. A corresponding Binding Cache Entry entry MUST have the currently
registered care-of address equal to the source address of the packet. A packet
These tests MUST NOT be done for packets that
contains contain a Binding
Update message and a Home Address option is
considered to pass the above tests if the Binding Update successfully
creates or updates a Binding Cache Entry. option.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 66]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
If the packet is dropped due the above tests, the correspondent nodes node
SHOULD send the Binding Error message to the source address of the
packet that contained the Home Address option (see as described in Section 6.1.9). 9.3.3.
The Status field in this message should be set to 1. These messages
SHOULD 1 (unknown binding
for Home Address destination option).
The correspondent node MUST process the option in a manner consistent
with exchanging the Home Address field from 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 rate-limited. possible to process the packet without the knowledge that it
came originally from a care-of address or that a Home Address option
was used.
No additional authentication of the Home Address option is
required, except that if the IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the
Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en-route
to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication
of the IPv6 header also cover the Home Address option, the security
of the Source Address field in the IPv6 header is not compromised by
the presence of a Home Address option. Security issues related to
the 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 were present in the 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 December 2002 [Page 65]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
9.3. Return Routability Procedure
This subsection specifies actions taken by a correspondent node
during the return routability procedure.
9.3.1. Receiving Home Test Init Messages
Upon receiving Section 11.3.2.
9.3.2. Sending Packets to a Home Test Init message, Mobile Node
Before sending any packet, the correspondent sending node
verifies the following:
- MH Type field SHOULD examine its
Binding Cache for an entry for this message is 1.
- The Header Extension Length field MUST be greater than or equal
to the length specified in Section 6.1.3.
- The packet MUST NOT include a Home Address destination option.
In preparation for sending address to which the corresponding Home Test Message,
packet is being sent. If the correspondent sending node checks that it has the necessary material
to engage in a return routability procedure, as specified in
Section 5.2. For that procedure, the correspondent node MUST have a
secret Kcn and a nonce Nj. If it does not have Binding Cache entry
for this material yet,
it MUST produce it before continuing with address, the return routability
procedure.
Section 9.3.3 specifies further processing.
9.3.2. Receiving Care-of Test Init Messages
Upon receiving sending node SHOULD use a Care-of Test Init message, type 2 routing header
to route the correspondent packet to this mobile node
verifies the following:
- MH Type field for (the destination node) by way
of its care-of address. Assuming there are no additional routing
headers in this message is 2.
- The Header Extension Length field MUST be greater than or equal
to packet beyond those needed by Mobile IPv6, the length specified mobile
node sets the fields in Section 6.1.4. the packet's IPv6 header and routing header
as follows:
- The packet MUST NOT include a Home Destination Address destination option.
In preparation for sending in the corresponding Care-of Test Message, packet's IPv6 header is set to the correspondent node checks that it has
mobile node's home address (the original destination address to
which the necessary material packet was being sent).
- The routing header is initialized to engage in contain a return routability procedure, as specified in
Section 5.2. For that procedure, single route
segment, containing the correspondent 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 mobile node's care-of address copied from
the return routability
procedure.
Section 9.3.4 specifies further processing. Binding Cache entry. The Segments Left field is, however,
temporarily set to zero.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 66] 67]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
9.3.3. Sending Home Test Messages
Unless already created,
The IP layer will insert the correspondent node creates a "Home
Cookie" routing header before performing IPsec
processing. The IPsec Security Policy Database will be consulted
based on the IP source address and an associated "Home Nonce Index". It then creates a the destination address (which
will be the mobile node's home address). Once all IPsec processing
has been performed, the node swaps the IPv6 destination field with
the Home
Test message (Section 6.1.5) Address field in the routing header, sets the Segments Left
field to one, and sends the packet. This ensures the AH calculation
is done on the packet in the form it will have on the receiver after
advancing the routing header.
Following the definition of a type 2 routing header in Section 6.4,
this packet will be routed to the mobile node's care-of address,
where it will be delivered to the mobile node at (the mobile node has
associated the
latter's home address.
9.3.4. Sending Care-of Test Messages
Unless already created, care-of address with its network interface).
Note that following the correspondent node creates a "Care-of
Cookie" and above conceptual model in an associated "Care-of Nonce Index". It then implementation
creates a
Care-of Test message (Section 6.1.6) some additional requirements for path MTU discovery since the
layer that decides the packet size (e.g., TCP and sends it applications using
UDP) needs to be aware of the size of the headers added by the IP
layer on the sending node.
If, instead, the sending node has no Binding Cache entry for the
destination address to which the packet is being sent, the sending
node simply sends the packet normally, with no routing header. If
the destination node is not a mobile node (or is a mobile node that
is currently at home), the latter's care-of address.
9.4. Processing Bindings
This section explains how packet will be delivered directly to this
node and processed normally by it. If, however, the correspondent destination node processes
is a mobile node that is currently away from home, the
binding cache messages. These messages are:
- Binding Update
- Binding Refresh Request
- Binding Acknowledgement
- packet will
be intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address.
9.3.3. Sending Binding Error
9.4.1. Receiving Binding Updates
Before accepting Messages
Sections 9.2 and 9.3.1 describe error conditions that lead to a need
to send a Binding Update message, the receiving node MUST
validate the Error message.
A Binding Update according Error message is sent to the following tests:
- The packet MUST address that appeared in the
IPv6 Source Address field of the offending packet. If the Source
Address field does not contain a unicast address, the Binding Error
message MUST NOT be sent.
The Home Address option.
- The Header Len field in the Binding Update option is greater than
or equal to Error message MUST be copied
from the length specified in Section 6.1.7.
- The Sequence Number field in the Binding Update message is
greater than the Sequence Number received Home Address field in the previous Binding
Update for this home address, if any.
This Sequence Number comparison MUST be performed modulo 2**16,
i.e., Home Address destination option of
the number is a free running counter represented modulo
65536. A Sequence Number in a received Binding Update is
considered less than offending packet, or equal set to the last received number unspecified address if
its value lies no such
option appeared in the range of the last received number and the
preceding 32767 values, inclusive. For example, if packet.
Binding Error messages are subject to rate limiting in the last
received sequence number was 15, then same
manner as is done for ICMPv6 messages with sequence [14].
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 67] 68]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
numbers 0 through 15, as well as 32784 through 65535, would be
considered less than or equal.
9.3.4. Receiving ICMP Error Messages
When the return routability procedure is used as an authorization
method, correspondent node has a Binding Cache entry for a mobile
node, all traffic destined to the following are also required:
- The Home and Care-of Nonce Index values in mobile node goes directly to the Nonce Indices
mobility option are recognized
current care-of address of the mobile node using a routing header.
Any ICMP error message caused by packets on their way to the correspondent node. As
described care-of
address will be returned in Section 5.2, the normal manner to the correspondent node discards Nonce
values that are too old.
- The
node.
On the other hand, if the correspondent node MUST re-generate has no Binding Cache
entry for the Home Cookie and mobile node, the
Care-of Cookie from packet will be routed through the information contained
mobile node's home link. Any ICMP error message caused by the
packet on its way to the mobile node while in the packet.
It then generates tunnel, will be
transmitted to the session key Kbu and uses it mobile node's home agent. By the definition of
IPv6 encapsulation [15], the home agent MUST relay certain ICMP error
messages back to verify the authenticator field original sender of the packet, which in this
case is the Binding Update as specified correspondent node.
Thus, in
Section 6.1.7. Note that a care-of address different all cases, any meaningful ICMP error messages caused by
packets from a correspondent node to a mobile node will be returned
to the
Source Address MAY have been specified by including correspondent node. If the correspondent node receives
persistent ICMP Destination Unreachable messages after sending
packets to a mobile node based on an Alternate
Care-of Address mobility option entry in its Binding Cache, the
correspondent node SHOULD delete this Binding Update message.
When such message is received and Cache entry.
9.4. Return Routability Procedure
This subsection specifies actions taken by a correspondent node
during the return routability
procedure is used as an authorization method, procedure.
9.4.1. Receiving Home Test Init Messages
Upon receiving a Home Test Init message, the correspondent node MUST verify the authenticator by using the address within
the Alternate Care-of Address in
verifies the calculations. following:
- The Binding Authorization Data option MUST be present, and its
contents Header Len field in the Mobility Header MUST NOT be satisfy rules presented less than
the length specified in Section 5.2.6.
If the mobile node sends 6.1.3.
- The packet MUST NOT include a sequence number Home Address destination option.
Any packet carrying a Home Test Init message which is not greater than fails to satisfy
all of these tests MUST be silently ignored.
Otherwise, in preparation for sending the sequence number from corresponding Home Test
Message, the last successful Binding Update, then correspondent node checks that it has the
receiving necessary
material to engage in a return routability procedure, as specified
in Section 5.2. The correspondent node MUST send back have a Binding Acknowledgement with status
code 141, secret Kcn and the last accepted sequence number in the Sequence
Number field of the Binding Acknowledgement.
a nonce. If it does not have this material yet, it MUST produce it
before continuing with the mobile node sends return routability procedure.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 69]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
Section 9.4.3 specifies further processing.
9.4.2. Receiving Care-of Test Init Messages
Upon receiving a Home or Care-of Nonce Index value which is
no longer recognized by Test Init message, the correspondent node, then the receiving node
verifies the following:
- The Header Len field in the Mobility Header MUST send back NOT be less than
the length specified in Section 6.1.4.
- The packet MUST NOT include a Binding Acknowledgement with status code 144 or
145, respectively. Home Address destination option.
Any Binding Update packet carrying a Care-of Test Init message 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 ignored.
Otherwise, in preparation for sending the packet carrying corresponding Care-of Test
Message, the Binding
Update MUST be discarded.
In this section, correspondent node checks that it has the care-of address refers necessary
material to engage in a return routability procedure in the IPv6 address,
which was originally located manner
described in Section 9.4.1.
Section 9.4.4 specifies further processing.
9.4.3. Sending Home Test Messages
The correspondent node creates a home keygen token and uses the IPv6 header when
current nonce index as the packet was
transmitted by Home Nonce Index. It then creates a Home
Test message (Section 6.1.5) and sends it to the mobile node.
If node at the Binding Update
latter's home address. Note that the Home Test message is valid according always
sent to the tests above, then home address of the
Binding Update mobile node, even when there is processed further as follows:
- If the Lifetime specified in an
existing binding for the Binding Update is nonzero mobile node.
9.4.4. Sending Care-of Test Messages
The correspondent node creates a care-of nonce and uses the current
nonce index as the specified Care-of Address is not equal Nonce Index. It then creates a Care-of
Test message (Section 6.1.6) and sends it to the home address mobile node at the
latter's care-of address.
9.5. Processing Bindings
This section explains how the correspondent node processes messages
related to bindings. These messages are:
- Binding Update
- Binding Refresh Request
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 68] 70]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
for the binding, then this is a request to cache
- Binding Acknowledgement
- Binding Error
9.5.1. Receiving Binding Updates
Before accepting a binding for
the mobile node. If the Home Registration (H) bit is set in the Binding Update, the receiving node MUST validate
the Binding Update is processed according to the
procedure specified in Section 10.2; otherwise, it is processed according to the procedure specified in Section 9.4.2. following tests:
- If the Lifetime specified in the Binding Update is zero or The packet MUST contain a Home Address option with a unicast
routable home address, unless the
specified Care-of Source Address matches is the home
address for the
binding, then this is a request to delete of the mobile node's
cached binding. If the Home Registration (H) bit is set node
- The Header Len field in the
Binding Update, the Binding Update is processed according to the
procedure specified in Section 10.3; otherwise, it Mobility Header is processed
according to no less than the procedure
length specified in Section 9.4.3.
9.4.2. Requests to Cache a Binding
This section describes the processing of a valid Binding Update that
requests a node to cache a mobile node's binding, for which the Home
Registration (H) bit is not set in the Binding Update.
In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this mobile node, or update its existing Binding
Cache entry for this mobile node, if such an entry already exists. 6.1.7.
- The lifetime for the Binding Cache entry is initialized from the
Lifetime Sequence Number field specified in the Binding Update, although this
lifetime MAY be reduced by the node caching the binding; the lifetime
for the Binding Cache entry MUST NOT be Update is greater than
the Lifetime
value specified Sequence Number received in the previous Binding Update. Any Binding Cache entry Update for
this home address, if any.
This Sequence Number comparison MUST be deleted after performed modulo 2**16,
i.e., the expiration of its lifetime.
The number is a free running counter represented modulo
65536. A Sequence Number value received from a mobile node in a received Binding Update is stored by a correspondent node in its Binding Cache entry
for that mobile node. If the receiving correspondent node has no
Binding Cache entry for
considered less than or equal to the sending mobile node, it MUST accept any
Sequence Number last received number if
its value lies in a the range of the last received Binding Update from this mobile
node.
9.4.3. Requests number and the
preceding 32767 values, inclusive. For example, if the last
received sequence number was 15, then messages with sequence
numbers 0 through 15, as well as 32784 through 65535, would be
considered less than or equal.
When the return routability procedure is used to Delete a Binding
This section describes enable the processing
establishment of a valid Binding Update that
requests a node nonce indices as inputs to delete a mobile node's binding from its Binding
Cache, for which the Home Registration (H) bit is not set in creation of the
Binding Update.
Any existing
binding for key Kbm, the mobile node following are also required:
- A Nonce Indices mobility option MUST be deleted. A Binding
Cache entry for present, and the mobile node Home and
Care-of Nonce Index values in this option MUST NOT be created in response recent enough
to
receiving the Binding Update.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 69]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
If the binding cache entry was created be recognized by use of return routability
nonces, the correspondent node.
- The correspondent node MUST ensure that the same nonces are
not used again with re-generate the particular home keygen token and care-of address. If
both nonces are still valid,
the correspondent node has to remember care-of keygen token from the particular combination of 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 receives a packet containing a Binding Update message information contained in which the Acknowledge (A) bit is set, it MUST return a Binding
Acknowledgement message acknowledging receipt of
packet. It then generates the Binding Update.
If binding management key Kbm and
uses it to verify the node accepts authenticator field in the Binding Update and creates or updates an
entry
as specified in its Binding Cache Section 6.1.7.
When using Kbm for this binding, validating the Status field in Binding Update, the following are
required:
- The Binding Acknowledgement Authorization Data mobility option MUST be set to present,
and its contents MUST satisfy rules presented in Section 5.2.6.
Note that a value less than 128; if, on care-of address different from the other hand Source Address MAY
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 71]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
have been specified by including an Alternate Care-of Address
mobility option in the Binding Update Update. When such message is accepted
received and the `A' bit return routability procedure is not
set, used as an
authorization method, the correspondent node SHOULD NOT send a Binding Acknowledgement. If MUST verify the node
rejects
authenticator by using the address within the Alternate Care-of
Address in the calculations.
- The Binding Update and does not create or update an entry for
this binding, a Binding Acknowledgement Authorization Data mobility option MUST be sent even if the `A'
bit was not set, last
option and the Status field in the Binding Acknowledgement MUST NOT have trailing padding.
- The Home Registration (H) bit MUST NOT be set to set.
If the mobile node sends a value sequence number which is not greater than or equal to 128. Specific values
for
the Status field are described in Section 6.1.8 sequence number from the last successful Binding Update, then the
receiving node MUST send back a Binding Acknowledgement with status
code 135, and the last accepted sequence number in the IANA
registry Sequence
Number field of assigned numbers [18].
The packet in which the Binding Acknowledgement is returned
MUST meet Acknowledgement.
If the specific authentication requirements for Binding
Acknowledgements, defined in Section 5.2. Furthermore, if receiving node no longer recognizes the packet
is to be sent to Home Nonce
Index value, Care-of Nonce Index value, or both values from the mobile
Binding Update, then the receiving node at MUST send back a Binding
Acknowledgement with status code 136, 137, or 138, respectively.
Packets carrying Binding Updates that fail to satisfy all of these
tests for any address reason other than insufficiency of the mobile
node's home address, it Sequence Number
or expired nonce index values MUST be sent using a Routing header (even if silently discarded.
If the binding was rejected). The intermediate IP address, Binding Update is valid according to which the packet will be delivered immediately before tests above, then the home address,
Binding Update is
determined processed further as follows:
- Whenever If the Lifetime specified in the Binding Update is accepted with a nonzero lifetime,
the routing header will be constructed using and
the specified care-of address
as described in Section 9.6.
- Otherwise, if the Source IP Address of is not equal to the packet containing home address
for the Binding Update, binding, then this is legal a request to cache a binding for inclusion
the mobile node. If the Home Registration (H) bit is set in a Routing Header, the routing header will be constructed using that IP address.
Note that multicast addresses, link-local addresses, loopback
addresses, IPv4 mapped addresses, and the unspecified address,
MUST NOT be used within a Routing Header for
Binding Update, the Binding
Acknowledgement.
Otherwise, if Update is processed according to the
procedure specified in Section 10.3.1; otherwise, it is processed
according to the procedure specified in Section 9.5.2.
- If the Lifetime specified in the Binding Update has a is zero lifetime but or the Source
IP
specified care-of address is not allowable for use within matches the Routing Header, home address for the Binding Acknowledgment MUST be sent
binding, then this is a request to delete the mobile node's
cached binding. The update MUST include a valid home
address. nonce index
(the care-of nonce index MUST be ignored by the correspondent
node). In this case, generation of the binding management key
depends exclusively on the home keygen token (Section 5.2.5). If
the Home Registration (H) bit is set in the Binding Update, the
Binding Update is processed according to the procedure specified
in Section 10.3.2; otherwise, it is processed according to the
procedure specified in Section 9.5.3.
The specified care-of address MUST be determined as follows:
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 70] 72]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
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 the Alternate Care-of Address option is still in active use present, the care-of
address is the address in sending packets to a mobile node, that option.
- Otherwise, the next packet sent to care-of address is the
mobile node will be routed normally to Source Address field in the mobile node's
packet's IPv6 header.
The home link.
Communication with address for the mobile node continues, but binding MUST be determined as follows:
- If the tunneling
from Home Address destination option is present, the home network creates additional overhead and latency in
delivering packets to the mobile node.
If
address is the sender knows address in that option.
- Otherwise, the Binding Cache entry home address is still the Source Address field in active
use, it MAY send a Binding Refresh Request message to the
packet's IPv6 header. This implies that the mobile node
in an attempt to avoid this overhead is at
home and latency due is about to perform de-registration.
9.5.2. Requests to deleting and
recreating the Binding Cache entry. The a Binding Refresh Request
message is sent in the same way as any packet addressed to
This section describes the mobile
node (Section 9.6).
The correspondent node MAY retransmit processing of a valid Binding Refresh Request
messages provided Update that rate limitation is applied. The correspondent
requests a node SHOULD stop retransmitting when it receive to cache a Home Test Init
message, as the mobile node is responsible node's binding, for retransmissions during which the Home
Registration (H) bit is not set in the return routability procedure.
9.4.6. Sending Binding Error Messages
If Update.
In this case, the correspondent receiving node receives a packet with a Home Address
destination option it MUST verify that it has SHOULD create a binding new entry in its
Binding Cache for that this mobile node. Specifically, it MUST have a binding node, or update its existing Binding
Cache entry for the this mobile node's home address (as obtained from node, if such an entry already exists.
The lifetime for the Home Address option)
at Binding Cache entry is initialized from the mobile node's care-of address (from the IP source address of
Lifetime field specified in the packet). If Binding Update, although this
lifetime MAY be reduced by the correspondent node does not find such a binding
entry, it MUST discard caching the binding; the lifetime
for the packet. It MUST also return a Binding
Error message (Section 6.1.9), subject to rate limiting Cache entry MUST NOT be greater than the Lifetime
value specified in the same
manner as is done for ICMPv6 messages [14].
9.5. Binding Update. Any Binding Cache Replacement Policy
Conceptually, entry MUST
be deleted after the expiration of its lifetime.
The Sequence Number value received from a mobile node maintains in a separate timer for each entry Binding
Update is stored by a correspondent node in its Binding Cache. When creating or updating a Cache entry
for that mobile node. If the receiving correspondent node has no
Binding Cache entry for the sending mobile node, it MUST accept any
Sequence Number value in
response to a received and accepted Binding Update, the node sets the
timer for Update from this entry mobile
node.
The correspondent node MAY refuse to the specified Lifetime period. Any entry in accept a node's new Binding Cache MUST
entry, if it does not have sufficient resources. A new entry MAY
also be deleted after the expiration of refused if the
Lifetime specified correspondent node believes its resources are
utilized more efficiently in some other purpose, such as serving
another mobile node with higher amount of traffic. In both cases
the correspondent node SHOULD return a Binding Update from which the entry was
created or last updated. Acknowledgement with
status value 130.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 71] 73]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Each node's
9.5.3. Requests to Delete a Binding Cache will, by necessity, have
This section describes the processing of a valid Binding Update that
requests a finite size.
A node MAY use any reasonable local policy for managing the space
within to delete a mobile node's binding from its Binding
Cache, except that any for which the Home Registration (H) bit is not set in the
Binding Update.
Any existing binding for the mobile node MUST be deleted. A Binding
Cache entry marked as a "home
registration" (Section 10.2) for the mobile node MUST NOT be deleted from created in response to
receiving the cache until Binding Update.
If the expiration Binding Cache entry was created by use of its lifetime period. When such "home registration"
entries are deleted, return routability
nonces, the home agent correspondent node MUST also cease intercepting
packets on ensure that the mobile node's same nonces are
not used again with the particular home link addressed to and care-of address. If
both nonces are still valid, the mobile correspondent node
(Section 10.4), just has to remember
the particular combination of nonce indexes, addresses, and sequence
number as if illegal, until at least one of the mobile node had de-registered its
primary care-of address (see Section 10.3).
When attempting to add a new "home registration" entry in response nonces has become too
old.
9.5.4. Sending Binding Acknowledgements
A Binding Acknowledgement may be sent to indicate receipt of a
Binding Update with the Home Registration (H) bit set, if no
sufficient space can be found, the node MUST reject as follows:
- If the Binding Update and MUST return was silently discarded as described in
Section 9.5.1, a Binding Acknowledgement to MUST NOT be sent.
- Otherwise, if the sending
mobile node, Acknowledge (A) bit set is set in which the Status field is set to 131 (insufficient
resources). When otherwise attempting to add a new entry to its Binding Cache,
Update, a node MAY, if needed, choose to drop any entry
already in its Binding Cache, other than "home registration"
entries, in order to make space for the new entry. For example, a
"least-recently used" (LRU) strategy for cache entry replacement
among entries not marked as "home registrations" is likely to
work well unless Acknowledgement MUST be sent.
- Otherwise, if the size of node rejects the Binding Cache is substantially
insufficient.
If the node sends a packet to Update, a destination for which it has dropped
the entry from its Binding Cache, the packet will
Acknowledgement MUST be routed through
the mobile node's home link. The mobile node can detect this, and
establish a new binding sent.
- Otherwise, if necessary.
9.6. Sending Packets to a Mobile Node
Before sending any packet, the sending node SHOULD examine its
Binding Cache for an entry for the destination address to which accepts the
packet is being Binding Update, a Binding
Acknowledgement SHOULD NOT be sent.
If the sending node has a accepts the Binding Cache Update and creates or updates
an entry for this address, binding, the sending node SHOULD use a Routing header to
route Status field in the packet Binding
Acknowledgement MUST be set to this mobile node (the destination node) by way
of a value less than 128. Otherwise, the care-of address in
Status field MUST be set to a value greater than or equal to 128.
Values for the binding recorded Status field are described in that Binding Cache
entry. For example, assuming use of a Type 2 Routing header (see Section 6.4), if no other use of a Routing header is involved 6.1.8 and in the routing
IANA registry of this packet, the mobile node sets the fields in assigned numbers [18].
If the
packet's IPv6 header and Routing header as follows:
- The Destination Address Status field in the packet's IPv6 header is set to Binding Acknowledgement contains the mobile node's value
136 (expired home nonce index), 137 (expired care-of address copied from nonce index),
or 138 (expired nonces), then the message MUST NOT include the
Binding Cache
entry.
- The Routing header is initialized to contain a single route
segment, with an Address of Authorization Data mobility option. Otherwise, the mobile node's home address (the
original destination address to which Binding
Authorization Data mobility option MUST be included, and MUST meet
the packet was being sent). specific authentication requirements for Binding Acknowledgements
as defined in Section 5.2.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 72] 74]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Following
If the definition Source Address field of a Type 2 Routing the IPv6 header in Section 6.4,
this that carried the
Binding Update does not contain a unicast address, the Binding
Acknowledgement MUST NOT be sent, and the Binding Update packet will MUST
be routed to silently discarded. Otherwise, the mobile node's care-of address,
where it will acknowledgement MUST be delivered sent
to the mobile node (the mobile node has
associated Source Address. Unlike the care-of address with its network interface).
Note that following treatment of regular packets, this
addressing procedure does not use information from the above conceptual model in an implementation
creates some additional requirements for path MTU discovery since Binding Cache.
If the
layer that decides Source Address is the packet size (e.g., TCP and applications using
UDP) needs to be aware home address of the size of the headers added by mobile node, i.e.,
the IP
layer on Binding Update did not contain a Home Address destination option,
then the sending node.
The IP layer will insert Binding Acknowledgement MUST be sent to that address,
and the routing header before performing IPsec
processing. The IPsec Security Policy Database will MUST NOT be consulted
based on the IP source address and used. Otherwise, the final IP destination (which
will Binding
Acknowledgement MUST be in the sent using a type 2 routing header). The definition of AH ensures that
the AH calculation is done on header which
contains the packet mobile node's home address.
Entries in the form it will have on
the receiver after advancing the routing header.
If, instead, the sending node has no a node's Binding Cache entry for the
destination address to which the packet is being sent, the sending
node simply sends the packet normally, with no Routing header. MUST be deleted when their lifetime
expires.
9.5.5. Sending Binding Refresh Requests
If
the destination node is not a mobile node (or Binding Cache entry being deleted is still in active use
in sending packets to a mobile node that
is currently at home), node, the next packet will be delivered directly sent to this
node and processed normally by it. If, however, the destination node
is a
mobile node that is currently away from home, the packet will be intercepted by routed normally to the mobile node's home agent and tunneled (using
IPv6 encapsulation [15]) to link.
Communication with the mobile node's current primary care-of
address, as described in Section 10.5. The mobile node MAY then send
a Binding Update to continues, but the sending node, as described in Section 11.6.2,
allowing tunneling
from the sending node to create a Binding Cache entry for its use home network creates additional overhead and latency in sending subsequent
delivering packets to this the mobile node.
9.7. Receiving ICMP Error Messages
When
If the sender knows that the correspondent node has a Binding Cache entry for is still in active
use, it MAY send a mobile
node, all traffic destined Binding Refresh Request message to the mobile node goes directly
in an attempt to the
current care-of address of the mobile node using a Routing header.
Any ICMP error message caused by packets on their way avoid this overhead and latency due to deleting and
recreating the care-of
address will be returned Binding Cache entry. The Binding Refresh Request
message is sent in the normal manner same way as any packet addressed to the mobile
node (Section 9.3.2).
The correspondent
node.
On the other hand, if the node MAY retransmit Binding Refresh Request
messages provided that rate limitation is applied. The correspondent
node has no SHOULD stop retransmitting when it receives a Binding Update.
9.6. Cache
entry Replacement Policy
Conceptually, a node maintains a separate timer for the mobile node, the packet will be routed through the
MN's home link. Any ICMP error message caused by the packet on each entry in its
way
Binding Cache. When creating or updating a Binding Cache entry in
response to a received and accepted Binding Update, the mobile node while in sets the tunnel, will be transmitted
timer for this entry to the mobile specified Lifetime period. Any entry in
a node's home agent. By the definition of IPv6
encapsulation [15], the home agent Binding Cache MUST relay certain ICMP error
messages back to be deleted after the original sender expiration of the packet, which
Lifetime specified in this
case is the correspondent node. Binding Update from which the entry was
created or last updated.
Each node's Binding Cache will, by necessity, have a finite size.
A node MAY use any reasonable local policy for managing the space
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 73] 75]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
Likewise, if a packet for
within its Binding Cache, except that any entry marked as a mobile node arrives at home
registration (Section 10.3.1) MUST NOT be deleted from the cache
until the expiration of its lifetime period. When such home
registration entries are deleted, the mobile node's
previous link and is intercepted there by a home agent for MUST also cease
intercepting packets on the mobile node's previous home link addressed to
the mobile node (Section 10.4.1), just as if the mobile node had
de-registered its primary care-of address (see Section 11.6.6), the packet will
be tunneled 10.3.2).
When attempting to the mobile node's add a new care-of address. As above, any
ICMP error message caused by the packet while home registration entry in this tunnel will
be returned response
to that a Binding Update with the Home Registration (H) bit set, if
no sufficient space can be found, the home agent, which agent MUST relay certain ICMP error
messages back to reject the correspondent node [15]. The relayed packet
Binding Update. Furthermore, the home agent MUST NOT contain return a routing header entry with the care-of address of Binding
Acknowledgement to the sending mobile node.
Thus, node, in all cases, any meaningful ICMP error messages caused by
packets from a correspondent which the Status field
is set to 130 (insufficient resources).
A node MAY choose to drop any entry already in its Binding Cache,
other than home registration entries, in order to make space for
a mobile node will be returned new entry. For example, a "least-recently used" (LRU) strategy
for cache entry replacement among entries not marked as home
registrations is likely to work well unless the correspondent node. size of the Binding
Cache is substantially insufficient.
If the correspondent node receives
persistent ICMP Destination Unreachable messages after sending
packets sends a packet to a mobile node based on an destination for which it has dropped
the entry in from its Binding Cache, the
correspondent packet will be routed through
the mobile node's home link. The mobile node SHOULD delete this Binding Cache entry. can detect this, and
establish a new binding if necessary.
10. Home Agent Operation
10.1. Conceptual Data Structures
Each home agent MUST maintain a Binding Cache and Home Agents List.
The rules for maintaining a Binding Cache are same for home
agents and correspondent nodes, and have already been described in
Section 9.1. In addition, if an entry in a node's Binding Cache
for which the node is serving as a home agent is marked as a "home
registration" entry, it MUST NOT be deleted by the home agent until
the expiration of its binding lifetime.
The Home Agents List is maintained by each home agent (as well as
each mobile node), agent, recording
information about each home agent from router on the same link which is acting as
a home agent; this node has received list is used by the dynamic home agent address
discovery mechanism. A router is known to be acting as a home agent,
if it sends a Router Advertisement in which the Home Agent (H) bit
is set, for which set. When the remaining lifetime for this a list entry (defined below) has not yet expired. expires,
that entry is removed from the Home Agents List. The home agents list Home Agents
List is thus similar to the Default Router List conceptual data
structure maintained by each host for Neighbor Discovery [12], although the [12]. The
Home Agents List MAY be implemented in any manner consistent with the
external behavior described in this document.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 76]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 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 maintains a Home Agents
List, to enable it to notify a home agent on its previous link when
it moves to a new link; a mobile node MAY maintain a separate Home
Agents List for each link on which it has a home agent, or it MAY
maintain a single list for all links. Each Home Agents List entry
conceptually contains the following fields:
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 74]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- The link-local IP address of a router on the link, that this
node currently believes is operating as a home agent for that
link. A new entry agent. A new entry is created or an
existing entry is updated in the Home Agents List in response to receipt of a valid Router
Advertisement in which the Home Agent (H) bit is set. Each Home
Agents List entry conceptually contains the following fields:
- The link-local IP address of the a home agent on the link. This
address is learned through the Source Address of the Router
Advertisements received from
it the router [12].
- One or more global IP addresses for this home agent, agent. Global
addresses are learned through Prefix Information options with the
Router Address (R) bit set, received in Router Advertisements
from this link-local address. Global addresses for the router
in a Home Agents List entry MUST be deleted once the prefix
associated with that address is no longer valid [12].
Are there interactions with the new Router Advertisement
stuff?
- The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement
received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home
Agent Lifetime field in the option; otherwise, the lifetime is
initialized from the Router Lifetime field in the received Router
Advertisement. The If Home Agents List entry lifetime is
decremented until it reaches zero, at which time this
the entry MUST be deleted from the Home Agents List.
- The preference for this home agent; higher values indicate a more
preferable home agent. The preference value is taken from the
Home Agent Preference field (a signed, twos-complement integer) in the received Router Advertisement,
if the Router Advertisement contains a Home Agent Information
Option, and is otherwise set to the default value of 0. A home
agent uses this preference in ordering the Home Agents List returned in when
it sends an ICMP Home Agent Address Discovery message message.
10.2. Processing Mobility Headers
All IPv6 home agents MUST observe the rules described in response to Section 9.2
when processing Mobility Headers.
10.3. Processing Bindings
10.3.1. Primary Care-of Address Registration
When a mobile node's
initiation of dynamic home agent address discovery. A mobile node uses this preference in determining which of receives a Binding Update, it MUST validate it and
determine the home agents
on its previous link type of Binding Update according to notify when the steps described
in Section 9.5.1. Furthermore, it moves MUST authenticate the Binding
Update as described in Section 5.1. This includes authorization of
the particular node to control a new link.
10.2. Primary Care-of Address Registration particular home address, as the home
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 77]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
address unequivocally identifies the security association that must
be used.
This section describes the processing of a valid and authorized
Binding Update that Update, when it requests the receiving node to serve as its home agent, registering
its registration of the mobile
node's primary care-of address.
To begin processing the Binding Update, the home agent MUST perform
the following sequence of tests:
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 75]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- If the node is not a router that implements home agent
functionality, then the node MUST reject the Binding Update
and MUST return a Binding Acknowledgement to the mobile node,
in which the Status field is set to 132 131 (home registration not
supported).
- Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List,
then the home agent MUST reject the Binding Update and SHOULD
return a Binding Acknowledgement to the mobile node, in which the
Status field is set to 133 132 (not home subnet).
- Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for
the rejection.
- A Home Address destination option MUST be present in the message.
- Finally, if the Duplicate Address Detection (D) bit is set in the
Binding Update, this home agent MUST perform Duplicate Address
Detection [13] on the mobile node's home link for the link-local
address associated with the home address in this binding, before
returning the Binding Acknowledgement. This ensures that no
other node on the home link was using the mobile node's home
address when the Binding Update arrived arrived.
If home agent accepts the Binding Update, it MUST then create a
new entry in its Binding Cache for this mobile node, or update its
existing Binding Cache entry, if such an entry already exists. The
Home Address field as received in the Home Address option provides
the home address of the mobile node.
The care-of address for this
Binding Cache entry is determined as follows:
- If the Alternate Care-of Address option is present, the care-of
address is the address in that option.
- Otherwise, the care-of address is the the Source Address field in
the packet's IPv6 header.
The home agent MUST mark this Binding Cache entry as a "home
registration" home
registration to indicate that the node is serving as a home agent for
this binding. Binding Cache entries marked as a "home
registration" home registration
MUST be excluded from the normal cache replacement policy used for
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 78]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
the Binding Cache (Section 9.5) 9.6) and MUST NOT be removed from the
Binding Cache until the expiration of the Lifetime period.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 76]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
When the 'D' bit is set, the address used for Duplicate Address
Detection SHOULD be the mobile node's link-local address.
Normal processing for Duplicate Address Detection specifies that, in
certain cases, the node SHOULD delay sending the initial Neighbor
Solicitation message of Duplicate Address Detection by a random delay
between 0 and MAX_RTR_SOLICITATION_DELAY [12, 13]; however, in
this case, 13]. However, when
the Duplicate Address Detection (D) bit instructs the home agent
to perform Duplicate Address Detection, the home agent SHOULD NOT
perform such a delay. If this Duplicate Address Detection fails,
then the home agent MUST reject the Binding Update and MUST return a
Binding Acknowledgement to the mobile node, in which the Status field
is set to 138 134 (Duplicate Address Detection failed). When the home
agent sends a successful Binding Acknowledgement to the mobile node, in response to a Binding
Update with the `D' bit set,
the home agent assures to the mobile node that its home address will
continue to be kept unique by the home agent at least as long as the
lifetime granted for that home address binding is not over.
If the `S' Single Address Only (S) bit field in the Binding Update is zero, The
the home agent creates or updates Binding Cache entries for each of possibly
several home addresses. The set of such home addresses is formed
by replacing the routing prefix for the given home address with
all other routing prefixes on the mobile node's home link that are
supported by the home agent processing the Binding Update. The home
agent creates such a separate primary care-of address registration
for each such home address. Note that the same considerations for
Duplicate Address Detection apply for each affected home address.
The specific addresses which are to be tested before accepting value of the Single Address Only (S) bit field is examined only
for new registrations. Its value is ignored on de-registrations and
re-registrations of the same addresses.
The specific addresses which are to be tested before accepting the
Binding Update, and later to be defended by performing Duplicate
Address Detection, depend on the settings of the `S' Single Address Only
(S) and `L' Link-Local Address Compatibility (L) bits, as follows:
- S=0 & L=0: Defend all non link-local unicast the given address. The Single Address Only (S) bit
is ignored in this case since we cannot derive other on-link
addresses possible
on link. without knowing the interface identifier.
- S=0 & L=1: L=1 and S=0: Defend all non link-local unicast addresses
possible on link and the derived link-local.
- S=1 & L=0: Defend the given address.
- S=1 & L=1: L=1 and S=1: Defend both the given non link-local unicast (home)
address and the derived link-local.
The lifetime of the Binding Cache entry depends on a number of
factors:
- The lifetime for the Binding Cache entry MUST NOT be greater than
the Lifetime value specified in the Binding Update.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 79]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- The lifetime for the Binding Cache entry MUST NOT be greater
than the remaining valid lifetime for the subnet prefix in the
mobile node's home address specified with the Binding Update,
and MUST NOT be greater than the Lifetime value specified in the
Binding Update.
The remaining valid lifetime for this prefix is
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 77]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 determined by
the home agent based on its own Prefix List entry for this
prefix [12].
- However, if the `S' Single Address Only (S) bit field in the Binding
Update is zero, the lifetime for the each that Binding Cache entry MUST
NOT be greater than the minimum remaining valid lifetime for all
subnet prefixes on the mobile node's home link. If the value of
the Lifetime field specified by the mobile node in its Binding
Update is greater than this prefix lifetime, the home agent MUST
decrease the binding lifetime to less than or equal to the prefix
valid lifetime.
- The home agent MAY further decrease the specified lifetime for
the binding, for example based on a local policy. The resulting
lifetime is stored by the home agent in the Binding Cache entry,
and this Binding Cache entry MUST be deleted by the home agent
after the expiration of this lifetime.
Regardless of the setting of the `A' Acknowledge (A) bit in the Binding
Update, the home agent MUST return a Binding Acknowledgement to the
mobile node, constructed as follows:
- The Status field MUST be set to a value 0, indicating success.
- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.
- The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the home agent in its "home registration" home registration Binding
Cache entry for the mobile node, as described above.
- The Refresh field MUST be set to a value less than or equal to
the Lifetime value being returned in the Binding Update. If the home agent stores the Binding Cache entry in nonvolatile storage
(that survives the crash or other failure of the home agent),
storage, then the Binding Refresh field SHOULD Advice mobility option MUST be set to the same value as the
Lifetime field; otherwise,
omitted. Otherwise, the home agent MAY set include this option to
suggest that the mobile node refreshes its binding sooner than
the actual lifetime of the binding ends.
If the Binding Refresh Advice mobility option is present, the
Refresh Interval field in the option MUST be set to a value less
than the Lifetime field, to indicate value being returned in the Binding Update.
This indicates that the mobile node SHOULD attempt to refresh its
home registration at the indicated shorter interval (although the interval. The home
agent will MUST still retain the registration for the Lifetime period,
even if the mobile node does not refresh its registration within
the Refresh period). period.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 80]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
The rules for selecting the Destination IP address (and possibly
Routing Header
routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in section 9.4.4. Section 9.5.4.
In addition, the home agent MUST follow the procedure defined in
Section 10.4 10.4.1 to intercept packets on the mobile node's home link
addressed to the mobile node, while the home agent is serving as
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 78]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
the home agent for this mobile node. The home agent MUST also be
prepared to accept reverse tunneled packets from the new care-of
address of the mobile node, as described in Section 10.6. 10.4.3. Finally,
the home agent MUST also propagate new home network prefixes, as
described in Section 10.9.1.
10.3. 10.6.
10.3.2. Primary Care-of Address De-Registration
When a node receives a Binding Update, it MUST validate it and
determine the type of
A Binding Update according to is validated and authorized in the steps manner described
in Section 9.4.1. the previous section. This section describes the processing of a
valid Binding Update that requests the receiving node to no longer
serve as its home agent, de-registering its primary care-of address.
To begin processing the Binding Update, the home agent MUST perform
the following test:
- If the receiving node has no entry marked as a "home
registration" home registration
in its Binding Cache for this mobile node, then this node
MUST reject the Binding Update and SHOULD return a Binding
Acknowledgement to the mobile node, in which the Status field is
set to 137 133 (not home agent for this mobile node).
If the home agent does not reject the Binding Update as described
above, then it MUST delete any existing entry in its Binding Cache
for this mobile node, and proceed as follows.
The node. Then, the home agent MUST return a Binding
Acknowledgement to the mobile node, constructed as follows:
- The Status field MUST be set to a value 0, indicating success.
- The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.
- The Lifetime field MUST be set to zero.
- The Binding Refresh field Advice mobility option MUST be set to zero. omitted.
In addition, the home agent MUST stop intercepting packets on
the mobile node's home link that are addressed to the mobile node
(Section 10.4). 10.4.1).
The rules for selecting the Destination IP address (and possibly
Routing Header (and, if required,
routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in section 9.4.4. the previous section. When the Status
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 79] 81]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
field in the Binding Acknowledgement is greater than or equal to 128
and the Source Address of the Binding Update is on the home link, the
home agent MUST send it to the same link-layer address as the Binding
Update came from.
10.4. Packet Processing
10.4.1. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for mobile node it MUST
attempt to intercept packets on the mobile node's home link that are
addressed to the mobile node, and MUST tunnel each intercepted packet
to the mobile node using IPv6 encapsulation [15].
In order to do this, when a node begins serving as the home agent
it MUST multicast onto the home link a Neighbor Advertisement
message [12] on behalf of the mobile node. Specifically, the home
agent performs the following steps:
-
1. The home agent examines the value of the `S' Single Address Only (S)
bit in the received Binding Update message. Update. If this bit is nonzero, the following
next step is carried out only for the individual home address
specified for this binding. If, instead, this bit is zero, then
the following next step is carried out for each one address for the mobile
node formed from the interface identifier in the mobile node's
home address in this binding (the remaining low-order bits in
the address after the configured subnet prefix), together with each one of the
subnet prefixes currently considered by the home agent to be
on-link (including the mobile node. Each address is formed by replacing,
in turn, the configured subnet prefix in the mobile node's home
address. For this purpose, the set of on-link prefixes includes
both the link-local and site-local
prefix).
- prefix.
2. For each specific IP address for the mobile node determined
in the first step above, the home agent sends a Neighbor
Advertisement message [12] to the all-nodes multicast address
on the home link, to advertise the home agent's own link-layer
address for this IP address on behalf of the mobile node.
All fields in each such Neighbor Advertisement message SHOULD be
set in the same way they would be set by the mobile node itself
if sending this Neighbor Advertisement while at home [12], with
the following exceptions:
*
- The Target Address in the Neighbor Advertisement message MUST be set
to the specific IP address for the mobile node.
*
- The Advertisement MUST include a Target Link-layer Address
option specifying the home agent's link-layer address.
*
- The Router (R) bit in the Advertisement MUST be set to zero.
* The
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 82]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- The Solicited Flag (S) in the Advertisement MUST NOT be set,
since it was not solicited by any Neighbor Solicitation
message.
* Solicitation.
- The Override Flag (O) in the Advertisement MUST be set,
indicating that the Advertisement SHOULD override any
existing Neighbor Cache entry at any node receiving it.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 80]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Any node on the home link receiving one of the Neighbor Advertisement
messages described above will thus update its Neighbor Cache to
associate the mobile node's address with the home agent's link
layer address, causing it to transmit any future packets for the
mobile node normally
destined to this address instead the mobile node to the mobile node's home agent. Since
multicasting on the local link (such as Ethernet) is typically
not guaranteed to be reliable, the home agent MAY retransmit
this Neighbor Advertisement message up to MAX_ADVERT_REXMIT (see
Section 12) times to increase its reliability. It is still possible
that some nodes on the home link will not receive any of these
Neighbor Advertisements, but these nodes will eventually be able
to detect the link-layer address change for the mobile node's home
address, through use of Neighbor Unreachability Detection [12].
While a node is serving as a home agent for some mobile node (it
still has a "home registration" entry for this mobile node in its
Binding Cache), node, the
home agent uses IPv6 Neighbor Discovery [12] to intercept unicast
packets on the home link addressed to the mobile node's home address.
In order to intercept packets in this way, the home agent MUST
act as a proxy for this mobile node, and reply to any received
Neighbor Solicitation messages Solicitations for it. When a home agent receives a Neighbor Solicitation message,
Solicitation, it MUST check if the Target Address specified in the
message matches the home address of any mobile node for which it
has a Binding Cache entry marked as a "home
registration". (Note home registration. Note that
Binding Update messages with the `S' Single Address Only (S) bit set to zero will
result in multiple Binding Cache entries, so checks on all these
entries necessarily include all possible home addresses for the
mobile node). node.
If such an entry exists in the home agent's Binding Cache, the
home agent MUST reply to the Neighbor Solicitation message with a Neighbor
Advertisement message,
Advertisement, giving the home agent's own link-layer address as the
link-layer address for the specified Target Address. In addition,
the Router (R) bit in the Advertisement MUST be set to zero. Acting
as a proxy in this way allows other nodes on the mobile node's home
link to resolve the mobile node's IPv6 home address, and allows the
home agent to defend these addresses on the home link for Duplicate
Address Detection [12].
10.5.
10.4.2. Tunneling Intercepted Packets to a Mobile Node
For any packet sent to a mobile node from the mobile node's home
agent (for which the home agent is the original sender of the
packet), the home agent is operating as a correspondent node of
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 83]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
the mobile node for this packet and the procedures described in
Section 9.6 9.3.2 apply. The home agent (as a correspondent node) then uses a
Routing routing header to
route the packet to the mobile node by way of the primary care-of
address in the home agent's Binding Cache (the mobile node's
primary care-of address, in this case).
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 81]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Cache.
While the mobile node is away from home and this node is acting
as the mobile node's home agent, home, the home agent intercepts
any packets on the home link addressed to the mobile node's home
address (including addresses formed from other on-link prefixes, if
the 'S' Single Address Only (S) bit was zero in the Binding Update), as
described in Section 10.4. The home agent cannot use a Routing header to forward
these intercepted packets to the mobile node, since it cannot modify
the packet in flight without invalidating any existing IPv6 AH [5] or
ESP [6] header present in the packet. 10.4.1. In order to forward each intercepted
packet to the mobile node, the home agent MUST tunnel the packet to
the mobile node using IPv6 encapsulation [15]; the tunnel entry point node is the home agent,
and the tunnel exit point node is the primary care-of address as
registered with the home agent. [15]. When a home agent
encapsulates an intercepted packet for forwarding to the mobile
node, the home agent sets the Source Address in the new tunnel IP
header to the home agent's own IP address, and sets the Destination
Address in the tunnel IP header to the mobile node's primary care-of
address. When received by the mobile node (using its primary care-of
address), node, normal processing of the
tunnel header [15] will result in decapsulation and processing of the
original packet by the mobile node.
However, packets addressed to the mobile node's link-local address
MUST NOT be tunneled to the mobile node. Instead, such a packet MUST
be discarded, and the home agent SHOULD return an ICMP Destination
Unreachable, Code 3, message to the packet's Source Address (unless
this Source Address is a multicast address). Packets addressed to
the mobile node's site-local address SHOULD be tunneled to the mobile
node by default, but this behavior MUST be configurable to disable
it; currently, the exact definition and semantics of a "site" and a
site-local address are incompletely defined in IPv6, and this default
behavior might change at some point in the future.
Tunneling of multicast packets to a mobile node follows similar
limitations to those defined above for unicast packets addressed to
the mobile node's link-local and site-local addresses. Multicast
packets addressed to a multicast address with link-local scope [3],
to which the mobile node is subscribed, MUST NOT be tunneled
to the mobile node; such packets SHOULD be silently discarded
(after delivering to other local multicast recipients). Multicast
packets addressed to a multicast address with scope larger
than link-local but smaller than global (e.g., site-local and
organization-local) [3],
organization-local [3]), to which the mobile node is subscribed,
SHOULD be tunneled to the mobile node by default, but this default. This behavior MUST
be configurable to disable it; allow changing or disabling it. Note that this
default behavior might change at some point in the future as the
definition of these scopes become more completely defined in IPv6.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 82]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Before tunneling a packet to the mobile node, the home agent MUST
perform any IPsec processing as indicated by the security policy data
base.
10.6.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 84]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
10.4.3. Handling Reverse Tunneled Packets from a Mobile Node
Unless a binding has been established between the mobile node and a
correspondent node, traffic from the mobile node to the correspondent
node goes through a reverse tunnel. This tunnel extends between the
mobile node and the home agent. Home agents MUST support reverse
tunneling as follows:
- The tunneled traffic arrives to the home agent using IPv6
encapsulation [15].
- The tunnel entry point is the primary care-of address as
registered with the home agent and the tunnel exit point is the
home agent.
- When a home agent decapsulates a tunneled packet from the mobile
node, the home agent verifies MUST verify that the Source Address in the
tunnel IP header is the mobile node's primary care-of address.
Otherwise any node in the Internet could send traffic through the
home agent and escape ingress filtering limitations.
Reverse tunneled packets MAY be discarded unless accompanied by a
valid AH or ESP header, depending on the security policies used by
the home agent. In any case, the home agent MUST check that the
source address in the tunneled packets corresponds to the currently
registered location of the mobile node, as otherwise any node in the
Internet could send traffic through the home agent and escape ingress
filtering limitations. The support for authenticated reverse tunneling
allows the home agent to protect the home network and correspondent
nodes from malicious nodes masquerading as a mobile node, even if
they know the current location of the real mobile node.
10.7.
10.4.4. Protecting Return Routability Packets
The return routability procedure described in Section 5 5.2.5 assumes
that the confidentiality of the Home Test Init and Home Test messages
is protected as it is they are tunneled from between the home agent to the
mobile node. Therefore, the home agent MUST support tunnel mode
IPsec ESP for the protection of packets belonging to the return
routability procedure. Support for a non-null encryption transform
and authentication algorithm MUST be available. In this case
it It isn't necessary
to distinguish between different kinds of packets within the return
routability procedure.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 83]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The security association between the home agent and the mobile node
MUST change its destination address (tunnel gateway address) when the
care-of address for the mobile node changes [24].
The above protection SHOULD be turned on and used with all mobile nodes. The use
is controlled by configuration of the IPsec security policy database
both at the mobile node and at the home agent.
As described earlier, the Binding Update and Binding Acknowledgement
messages require protection between the home agent and the mobile
node. These messages and the return routability messages employ the
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 85]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
same protocol from the point of view of the security policy database,
the Mobility Header. One way to set up the The security policy database is to have one rule entries MUST be
defined as if they were specifically for the Mobility Header traffic tunnel interface between
the mobile node and the home agent addresses, and an optional rule
following it for Mobility Header traffic between agent. That is, the mobile node and
any other address.
10.8. Receiving Router Advertisement Messages
For each link policy entries are
not generally applied on which a router provides service as a home agent,
the router maintains a Home Agents List recording information
about all other home agents traffic on that link. the physical interface(s) of
the nodes, but rather only on traffic that enters the tunnel. This
makes use of per-interface security policy database entries [4],
specific to the tunnel interface (the node's attachment to the
tunnel [11]).
10.5. Dynamic Home Agent Address Discovery
This section describes how a home agent can help mobile nodes to
discover the addresses of the home agents. The home agent keeps
track of the other home agents on the same link, and responds to
queries sent by the mobile node.
10.5.1. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent,
the router maintains a Home Agents List recording information
about all other home agents on that link. This list is used in
the dynamic home agent address discovery mechanism, described in
Section 10.9. 10.5. The information for the list is learned through
receipt of the periodic unsolicited multicast Router Advertisements,
in a manner similar to the Default Router List conceptual data
structure maintained by each host for Neighbor Discovery [12]. In
the construction of the Home Agents List, the Router Advertisements
are from each other home agent on the link, and the Home Agent (H)
bit is set in them.
On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [12], the home
agent performs the following steps, in addition to any steps already
required of it by Neighbor Discovery:
- If the Home Agent (H) bit in the Router Advertisement is not set,
check to see if the sending node has an entry in the current Home
Agents List. If it does, delete the corresponding entry. In any
case all of the following steps are skipped.
- Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [12].
- Determine from the Router Advertisement the preference for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the
preference is taken from the Home Agent Preference field in the
option; otherwise, the default preference of 0 MUST be used.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 86]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- Determine from the Router Advertisement the lifetime for this home agent. If the Router
Advertisement contains a Home
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 84]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 Agent Information Option, then
the lifetime is taken from the Home Agent Lifetime field in the
option; otherwise, the lifetime specified by the Router Lifetime
field in the Router Advertisement SHOULD be used.
- If the link-local address of the home agent sending this
Advertisement is already present in this home agent's Home
Agents List and the received home agent lifetime value is zero,
immediately delete this entry in the Home Agents List.
- Otherwise, if the link-local address of the home agent sending
this Advertisement is already present in the receiving home
agent's Home Agents List, reset its lifetime and preference to
the values determined above.
- If the link-local address of the home agent sending this
Advertisement, as determined above,
Advertisement is not already present in the Home Agents List
maintained by the receiving home agent, and the lifetime for
the sending home agent, as determined above, agent is non-zero, create a new entry in the
list, and initialize its lifetime and preference to the values
determined above.
- If the Home Agents List entry for the link-local address of
the home agent sending this Advertisement was not deleted as
described above, determine any global address(es) of the home
agent based on each Prefix Information option received in
this Advertisement in which the Router Address (R) bit is set
(Section 7.2). For each Add all such global address determined from this
Advertisement, add this global address addresses to the list of
global addresses for this home agent in this Home Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for
each such valid home agent address until that entry's lifetime expires,
after which time the entry MUST be deleted.
10.9. Dynamic Home Agent Address Discovery
A mobile node, while away from home, MAY use the dynamic home agent
address discovery mechanism in section 11.3.2 to attempt to discover
the address of one or more routers serving as home agents on its home
link. This discovery might become necessary, for example, if some
nodes on its home link have been reconfigured while the mobile node
has been away from home, such that the router that was operating as
the mobile node's home agent has been replaced by a different router
serving this role.
As described in Section 11.3.2, 11.4.1, a mobile node attempts dynamic
home agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the "Mobile Mobile IPv6 Home-Agents" Home-Agents anycast
address [16] for its home IP subnet prefix, using its care-of address
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 85]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
as the Source Address of the packet. prefix. A home agent receiving
such a Home Agent Address Discovery Request message that is serving
this subnet (the home agent is configured with this anycast address on one
of its network interfaces) SHOULD return an ICMP Home Agent Address Discovery Reply
message to the mobile node (at its care-of address
that was used as the Source Address of the Request message), node, with the Source Address of the Reply
packet set to one of the global unicast addresses of the home agent.
The Home Agent Addresses field in the Reply message is constructed as
follows:
- The Home Agent Addresses field SHOULD contain one global IP
address for each home agent currently listed in this home agent's
own Home Agents List (Section 4.5). 10.1). However, if this home
agent's own global IP address would be placed in the list
(as described below) as the first entry
in the list, list (as described below), then this home agent SHOULD NOT
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 87]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
include its own address in the Home Agent Addresses field in the
Reply message. Not placing this home agent's own IP address in
the list will cause the receiving mobile node to consider this
home agent as the most preferred home agent; otherwise, this home
agent will be considered to be preferred in its order given by
its place in the list returned.
- The IP addresses in the Home Agent Addresses field SHOULD
be listed in order of decreasing preference value, values, based
either on the respective advertised preference from a Home
Agent Information option or on the default preference of 0 if
no preference is advertised (or on the configured home agent
preference for this home agent itself). The home agent with
the highest preference SHOULD be listed first in the Home Agent
Addresses field, and the home agent with the lowest preference
SHOULD be listed last.
- Among home agents with equal preference, their IP addresses
in the Home Agent Addresses field SHOULD be listed in an
order randomized with respect to other home agents with equal
preference, each time a Home Agent Address Discovery Reply
message is returned by this home agent.
- For each entry in this home agent's Home Agents List, if more
than one global IP address is associated with this list entry,
then one of these global IP addresses SHOULD be selected to
include in the Home Agent Addresses field in the Reply message. As described in Section 4.5, one Home Agents List
entry, identified by the home agent's link-local address,
exists for each home agent on the link; associated with that
list entry is one or more global IP addresses for this home
agent, learned through Prefix Information options with the
Router Address (R) bit is set, received in Router Advertisements
from this link-local address.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 86]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The selected global IP address for each home agent to include in
forming the Home Agent Addresses field in the Reply message MUST
be the global IP address of the respective home agent sharing a
prefix with the Destination IP address of the Request message;
if message.
If no such global IP address is known for some home agent, an
entry for that home agent MUST NOT be included in the Home Agent
Addresses field in the Reply message.
- In order to avoid The home agent SHOULD reduce the possibility number of home agent IP
addresses so that the Reply message packet
being fragmented (or rejected by an intermediate router with an
ICMP Packet Too Big message [14]), if the resulting total packet
size containing the complete list of home agents in the Home
Agent Addresses field would exceed fits within the minimum IPv6
MTU [11], the
home agent SHOULD reduce the number of home agent IP addresses
returned in the packet to the number of addresses that will fit
without exceeding this limit. [11]. The home agent addresses returned selected for inclusion in the
packet SHOULD be those from the complete list with the highest
preference.
10.9.1. Aggregate List This limitation avoids the danger of Home Network Prefixes the Reply
message packet being fragmented (or rejected by an intermediate
router with an ICMP Packet Too Big message [14]).
- If the Reply message packet must be truncated to fit within the
minimum IPv6 provides mechanisms for node configuration when it turns on, MTU, and the home agent sending the message is
not the highest priority, then its address MUST appear in renumbering a subnet, such as when a site switches the
list sent to a new
network service provider. These mechanisms are a part avoid implying that it is the highest priority.
Therefore, if this home agent would not appear in the truncated
list because it is of Neighbor
Discovery [12] and Address Autoconfiguration [13].
In renumbering, new prefixes and addresses can be introduced for lower priority than the
subnet and old ones can last entry, this
home agent's address must be deprecated and removed. These mechanisms
are defined to work while all nodes using the old prefixes are at
home, connected to substituted for the link using these prefixes. Mobile last entry.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 88]
INTERNET-DRAFT Mobility Support in IPv6
extends these mechanisms 29 Oct 2002
10.6. Sending Prefix Information to work also with mobile nodes that are away
from home when the renumbering takes place. Mobile Node
10.6.1. Aggregate List of Home Network Prefixes
Mobile IPv6 arranges to propagate relevant prefix information to the
mobile node when it is away from home, so that it may be used in
mobile node home address configuration, and in network renumbering.
In this mechanism, mobile nodes away from home receive Mobile Prefix
Advertisements messages with Prefix Information Options, which give
the valid lifetime and preferred lifetime for available prefixes on
the home link.
To avoid possible security attacks from forged Mobile Prefix
Advertisements all such Advertisements MUST be authenticated to the
mobile node by its home agent using IPsec [4, 5, 6].
A mobile node on a remote network SHOULD autoconfigure all of the
global IP addresses, which it would autoconfigure if it were attached
to its home network, from network prefixes representing network
addresses that and which are from prefixes served by home
agents. Site-local addresses MAY be autoconfigured if the mobile
node is roaming in a network on the
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 87]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 same site as its home addresses.
Site-local addresses and addresses not served by a home agent MUST
NOT be autoconfigured, since they are unusable in the remote network.
To support this, the home agent monitors prefixes advertised by
itself and other home agents routers on the home link, and passes
this aggregated list of relevant subnet prefixes on to the mobile
node in Mobile Prefix Advertisements.
The home agent SHOULD construct the aggregate list of home subnet
prefixes as follows:
- Copy prefix information defined in the home agent's AdvPrefixList
on the home subnet's interfaces to the aggregate list. Also
apply any changes made to the AdvPrefixList on the home agent to
the aggregate list.
- Check valid prefixes received in Router Advertisements from the
home network for consistency with the home agent's AdvPrefixList,
as specified in section Section 6.2.7 of RFC 2461
(Neighbor Discovery [12]). [12]. Do not update
the aggregate list with any information from received prefixes
that fail this check.
- Check For Router Advertisements which contain an `H' have the Home Agent (H) bit (from other
home agents) for
set, check valid prefixes that are not yet in the aggregate
list, and if they are usable for autoconfiguration (`A' bit set,
list. If a Prefix Information option has the autonomous address
configuration (A) flag set and the prefix length is valid
for address autoconfiguration on the home subnet) subnet, add them these
advertisements and preserve the `L' on-link (L) flag value. Clear
the
`R' Router Address (R) flag and zero the interface-id portion of
the prefix field to prevent mobile nodes from treating another
router's interface address as belonging to the home agent. Treat
the lifetimes of these prefixes as decrementing in real time, as
defined in
section Section 6.2.7 of RFC 2461 [12].
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 89]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- Do not perform consistency checks on valid prefixes received
in Router Advertisements on the home network that do not exist
in the home agent's AdvPrefixList. Instead, if the prefixes
already exist in the aggregate list, update the prefix lifetime
fields in the aggregate list according to the rules specified for
hosts in
section Section 6.3.4 of RFC 2461 (Neighbor Discovery [12]) [12] and section Section 5.5.3 of RFC
2462 (Stateless Address Autoconfiguration [13]). [13].
- If the L flag is set on valid prefixes received in a Router
Advertisement, and that prefix already exists in the aggregate
list, set the flag in the aggregate list. Ignore the flag if it
is clear.
- Delete prefixes from the aggregate list when their valid
lifetimes expire.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 88]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
The home agent uses the information in the aggregate list to
construct Mobile Prefix Advertisements. It may be possible to
construct an aggregate list by combining information contained in the
home agent's AdvPrefixList and its Home Agents List used for Dynamic
Home Agent Address Discovery (Section 11.3.2).
10.9.2. 11.4.1).
10.6.2. Scheduling Prefix Deliveries to the Mobile Node
A home agent serving a mobile node will schedule the delivery of new
prefix information to that mobile node when any of the following
conditions occur:
MUST:
- The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address.
- The mobile node requests the information with a Mobile Prefix
Solicitation (see section 11.3.3). Section 11.4.2).
MAY:
- A new prefix is added to the aggregate list.
- The valid or preferred lifetime or the state of the flags changes
for a prefix which is not used in any binding cache Binding Cache entry for
this mobile node.
The home agent uses the following algorithm to determine when to send
prefix information to the mobile node.
- If the mobile node has not received the prefix information within
the last HomeRtrAdvInterval (see Section 12) seconds, then
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 90]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
transmit the prefix information. This MAY be done according to a
periodically scheduled transmission.
- If a mobile node sends a solicitation, answer right away.
- If a prefix in the aggregate list that matches the mobile node's
home registration is added, or if its information changes in
any way that does not cause the mobile node's address to go
deprecated, ensure that a transmission is scheduled (as described
below), and calculate RAND_ADV_DELAY in order to randomize the
time at which the transmission is scheduled.
- If a home registration expires, cancel any scheduled
advertisements to the mobile node.
The aggregate list is sent in its entirety in all cases.
Suppose that the home agent already has scheduled the transmission
of a Router Mobile Prefix Advertisement to the mobile node. Then add the data
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 89]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
from the existing scheduled transmission to the newly scheduled
transmission, deleting The home agent
deletes the previously scheduled transmission event.
In this case, the home agent does not perform the following algorithm
to schedule an event and schedules
another advertisement to the mobile node.
Otherwise, the home agent uses the following algorithm to compute computes a fresh value for RAND_ADV_DELAY,
the offset from the current time for the scheduled transmission. The computation transmission
as follows. First calculate the maximum delay for the scheduled
Advertisement:
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
where MaxMobPfxAdvInterval is expected to
alleviate bursts of as defined in Section 12. Then compute
the final delay for the advertisement:
RAND_ADV_DELAY = MinMobPfxAdvInterval +
(rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
This computation is expected to alleviate bursts of advertisements
when prefix information changes. In addition, a home agent MAY
further reduce the rate of packet transmission by further delaying
individual advertisements, if needed to avoid overwhelming local
network resources.
Calculate the maximum delay for the scheduled Advertisment as
follows.
MAX_SCHEDULE_DELAY == min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
Then compute RAND_ADV_DELAY ==
MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) The home agent SHOULD periodically continue to
retransmit an unsolicited Advertisement to the mobile node, either until it
is acknowledged by the receipt from the mobile node of a Binding Update
with a home address matching the new home prefix in the packet,
or until the home agent receives a Mobile Prefix Solicitation from
the mobile node.
The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12)
before the first retransmission, and double the retransmission wait
time for every succeeding retransmission, up until a maximum of
PREFIX_ADV_RETRIES attempts. attempts (see Section 12). If the mobile node's
bindings expire before the matching Binding Update has been received,
then the home agent MUST NOT attempt any more retransmissions, even
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 91]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
if not all PREFIX_ADV_RETRIES have been retransmitted. After another Binding
Update is received from the mobile node, and if If the
mobile node has
not returned to the sends another Binding Update without returning home network in
the meantime, the home agent SHOULD begin the process again of begin transmitting the
unsolicited Advertisement.
If while the home agent is still retransmitting a Mobile Prefix
Advertisement to the mobile node, another some condition as described above occurs on the home link causing causes
another Prefix Advertisement to be sent to the mobile node, before
the mobile node acknowledges a previous transmission the home agent
SHOULD combine any Prefix Information options in the unacknowledged
Mobile Prefix Advertisement into the a new Advertisement, discard Advertisement. The home agent
discards the old Advertisement, and then
begin retransmitting the new one. according to the above algorithm.
10.9.3. Advertisement.
10.6.3. Sending Advertisements to the Mobile Node
When sending a Mobile Prefix Advertisement to the mobile node, the
home agent MUST construct the packet as follows:
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 90]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- The Source Address in the packet's IPv6 header MUST be set to
the home agent's IP address to which the mobile node addressed
its current home registration, or its default global home agent
address if no binding exists.
- If a security association exists with the mobile node's address,
the packet MUST be protected by IPsec [4, 5, 6] to guard against
malicious Mobile Prefix Advertisements. The IPsec protection
MUST provide sender authentication and data integrity protection
covering the Mobile Prefix Advertisement, and MAY provide replay
protection.
- If the advertisement was solicited, it MUST be authenticated and destined to the
source address of the solicitation. If it was triggered by
prefix changes or renumbering, the advertisement's destination
will be the mobile node's home address in the binding which
triggered the rule.
- The packet A type 2 routing header MUST be sent as any other unicast IPv6 packet. If a
care-of address is used, included with the packet will mobile node's
home address.
- IPsec headers SHOULD be delivered directly.
If a binding exists, the supported and used.
- The home agent will MUST send the packet with
a routing header containing the care-of address, as it would any other
packet sent to the mobile node originated by the home agent
(rather than using unicast
IPv6 encapsulation, as would be used by the
home agent for intercepted packets).
10.9.4. packet that it originates.
10.6.4. Lifetimes for Changed Prefixes
As described in Section 10.2, 10.3.1, the lifetime returned by the home
agent in a Binding Acknowledgement MUST be no greater than the
remaining valid lifetime for the subnet prefix in the mobile node's
home address. This limit on the binding lifetime serves to prohibit
use of a mobile node's home address after it becomes invalid.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 92]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
11. Mobile Node Operation
11.1. Conceptual Data Structures
Each mobile node MUST maintain a Binding Update List and Home Agents List.
The rules for maintaining a Home Agents List are same for home agents
and correspondent nodes, and have been described in Section 10.1.
The Binding Update List records 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 node either to a its home agent
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 91]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
on the link on which the mobile node's previous care-of address is
located. or
correspondent nodes. It also contains Binding Updates which are
waiting for the completion of the return routability procedure before
they can be sent. However, for multiple Binding Updates sent to
the same destination address, the Binding Update List contains only
the most recent Binding Update (i.e., with the greatest Sequence
Number value) sent to that destination. The Binding Update List MAY
be implemented in any manner consistent with the external behavior
described in this document.
Each Binding Update List entry conceptually contains the following
fields:
- The IP address of the node to which a Binding Update was sent.
If the Binding Update was successfully received by that node
(e.g., not lost by the network), a Binding Cache entry may have
been created or updated based on this Binding Update. The
Binding Cache entry may still exist, if that node has not deleted
the entry before its expiration (e.g., to reclaim space in its
Binding Cache for other entries). some reason.
- The home address for which that Binding Update was sent. This
will be one of the following:
* one the mobile node's home addresses for typical Binding
Updates (Sections 11.6.1 and 11.6.2), or
* the mobile node's previous care-of address for Binding
Updates sent to establish forwarding from the mobile node's
previous location (Section 11.6.6).
- The care-of address sent in that Binding Update. This value
is necessary for the mobile node to determine if it has sent a
Binding Update giving its new care-of address to this destination
after changing its care-of address.
- The initial value of the Lifetime field sent in that Binding
Update.
- The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding Update
and is decremented until it reaches zero, at which time this
entry MUST be deleted from the Binding Update List.
- The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination. The Sequence Number field
is 16 bits long, and all comparisons between Sequence Number
values MUST be performed modulo 2**15 in the manner explained
already in 2**16 (see Section 9.4.1. 9.5.1).
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 92] 93]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
- The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting restriction
for sending Binding Updates.
- The state of any retransmissions needed for this Binding Update,
if the Acknowledge (A) bit was set in this Binding Update. This
state includes the time remaining until the next retransmission
attempt for the Binding Update, and the current state of the
exponential back-off mechanism for retransmissions.
- A flag that, when set, indicates that specifying whether or not future Binding Updates should not
be sent to this destination. The mobile node sets this flag
in the Binding Update List entry when it receives an ICMP
Parameter Problem, Code 1, error message in response to a return
routability message or Binding Update sent to that destination,
as described in Section 11.7. 11.3.4.
The Binding Update list also conceptually contains the following data
related to running the return routability procedure. This data is
relevant only for Binding Updates sent to correspondent nodes.
- The time at which a Home Test Init or Care-of Test Init message
was last sent to this destination, as needed to implement the
rate limiting restriction for the return routability procedure.
- The state of any retransmissions needed for this return
routability procedure. This state includes the time remaining
until the next retransmission attempt and the current state of
the exponential back-off mechanism for retransmissions.
- Mobile cookie Cookie values used the Home Test Init and Care-of Test Init
messages.
- Home and care-of cookies keygen tokens received from the correspondent
node.
- Home and care-of nonce indices received from the correspondent
node.
- The time at which each of the cookies tokens and nonces was received
from this correspondent node, as needed to implement cookie reuse while
moving.
11.2. Packet Processing
11.2.1. Sending Packets While Away from Home
While a Mobility Headers
All IPv6 mobile node is away from home, it continues to nodes MUST observe the rules described in Section 9.2
when processing Mobility Headers.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 94]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
11.3. Packet Processing
11.3.1. Sending Packets While Away from Home
While a mobile node is away from home, it continues to use its home
address, as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node MAY choose among
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 93]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
these in selecting the address that it will use as the source of the
packet, as follows:
- Protocols layered over IP will generally treat the mobile node's
home address as its IP address for most packets. For packets
sent that are part of transport-level connections established
while the mobile node was at home, the mobile node MUST use
its home address. Likewise, for packets sent that are part of
transport-level connections that the mobile node may still be
using after moving to a new location, the mobile node SHOULD use
its home address in this way. When sending such packets,
the delivery method depends on whether a binding exists with
the correspondent node. If a binding exists, the mobile
node SHOULD send the packets directly to the correspondent node.
Otherwise, if a binding does not exist, the mobile node MUST use
reverse tunneling. Detailed operation for both of these cases is
described later in this section.
- For short-term communication, particularly for communication that
may easily be retried if it fails, the The mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, thus not requiring the use
of a Home Address option in the packet. This is particularly
useful for short-term communication that may easily be retried
if it fails. An example of this type of communication might
be DNS queries sent by the mobile node [27, 28]. Using the
mobile node's care-of address as the source for such queries will
generally have a lower overhead than using the mobile node's
home address, since no extra options need be used in either
the query or its reply, and all reply. Such packets can be routed normally,
directly between their source and destination without relying
on Mobile IP. IPv6. If application running on the mobile node has
no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile
node SHOULD NOT use its care-of address as the source of the
packet in this way.
The mobile node may send packets to the correspondent node
that includes the home address destination option directly
to the correspondent node only if the mobile node is aware
that the correspondent node already has a Binding Cache entry
for the mobile node's home address. Section 9.3.1 specifies
the rules for Home Address Destination Option Processing at a
correspondent node. The mobile node needs to ensure that there
exists a Binding Cache entry for its home address so that the
correspondent node can process the packet.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 95]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- While not at its home link, the mobile node MUST NOT use its home
address (or the home address destination option) in Neighbor
Discovery messages on the visited link. The mobile node also
MUST NOT use its home address when communicating with link-local
or site-local peers on the visited link, if the scope of the home
address is larger than the scope of the peer's address.
For packets sent by a mobile node while it is at home, no special
Mobile IP IPv6 processing is required for sending this packet. required. Likewise, if the mobile
node uses any address other than any of its home addresses as the
source of a packet sent while away from home no special Mobile IP IPv6
processing is required for sending that packet. required. In
each either case, the packet is simply
addressed and transmitted in the same way as any normal IPv6 packet.
For packets sent by the mobile node sent while away from home using
the mobile node's home address as the source, special Mobile IP IPv6
processing of the packet is required. This can be done in the
following two ways,
as described above. These ways are: ways:
direct delivery
This is manner of delivering packets does not require going
through the home network, and typically will enable faster and
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 94]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
more reliable transmission. A mobile node SHOULD arrange to
supply the home address in a Home Address option, and allowing
the IPv6 header's Source Address field to be set to one of the
mobile node's care-of addresses; the correspondent node will
then use the address supplied in the Home Address option to
serve the function traditionally done by the Source IP address
in the IPv6 header. the The mobile node's home address is then
supplied to higher protocol layers and applications.
Specifically:
- Construct the packet using the mobile node's home address
as the packet's Source Address, in the same way as if the
mobile node were at home. This includes the calculation of
upper layer checksums using the home address as the value
of the source.
- Insert a Home Address option into the packet, with the Home
Address field copied from the original value of the Source
Address field in the packet.
- Change the Source Address field in the packet's IPv6 header
to one of the mobile node's care-of addresses. This will
typically be the mobile node's current primary care-of
address, but MUST be a care-of address with a subnet prefix
that is on-link on the network interface on which the
mobile node will transmit the packet.
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 96]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through
any router implementing ingress filtering [24]. [23].
reverse tunneling
This is the mechanism which tunnels the packets via the home
agent. It isn't as efficient as the above mechanism, but is
needed if there is no binding yet with the correspondent node.
Specifically:
- The packet is sent to the home agent using IPv6
encapsulation [15].
- The Source Address in the tunnel packet is the primary
care-of address as registered with the home agent.
- The Destination Address in the tunnel packet is the home
agent's address.
Reverse tunneled packets MAY be protected using a AH or ESP
header, depending on the security policies used by the home
agent. The support for encrypted reverse tunneling allows
mobile nodes to defeat certain kinds of traffic analysis, and
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 95]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
provides a mechanism by which routers on the home network can
distinguish authorized traffic from other possibly malicious
traffic.
11.2.2.
11.3.2. Interaction with Outbound IPsec Processing
This section sketches the interaction between outbound Mobile
IP
IPv6 processing and outbound IP Security (IPsec) processing for
packets sent by a mobile node while away from home. Any specific
implementation MAY use algorithms and data structures other than
those suggested here, but its processing MUST be consistent with the
effect of the operation described here and with the relevant IPsec
specifications. In the steps described below, it is assumed that
IPsec is being used in transport mode [4] and that the mobile node is
using its home address as the source for the packet (from the point
of view of higher protocol layers or applications, as described in
Section 11.2.1): 11.3.1):
- The packet is created by higher layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IP IPv6
were not being used.
- As part of outbound packet processing in IP, the packet is
compared against the IPsec security policy database to determine
what processing is required for the packet [4].
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 97]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
- If IPsec processing is required, the packet is either mapped to
an existing Security Association (or SA bundle), or a new SA (or
SA bundle) is created for the packet, according to the procedures
defined for IPsec.
- Since the mobile node is away from home, the mobile is either
using reverse tunneling or route optimization to reach the
correspondent node.
If reverse tunneling is used, the packet is constructed in the
normal manner and then tunneled through the home agent.
If route optimization is in use, the mobile node inserts a Home
Address destination option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in
Section 11.2.1. 11.3.1. The Destination Options header in which the
Home Address destination option is inserted MUST appear in the
packet after the Routing Header, routing header, if present, and before the IPsec
(AH [5] or ESP [6]) header, so that the Home Address destination
option is processed by the destination node before the IPsec
header is processed.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 96]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Finally, once the packet is fully assembled, the necessary IPsec
authentication (and encryption, if required) processing is
performed on the packet, initializing the Authentication Data in
the IPsec header. The AH authentication data MUST be calculated
as if the following were true:
* the IPv6 source address in the IPv6 header contains the
mobile node's home address,
* the Home Address field of the Home Address destination option
(section
(Section 6.3) contains the new care-of address.
- This allows, but does not require, the receiver of the packet
containing a Home Address destination option to exchange the two
fields of the incoming packet, simplifying processing for all
subsequent packet headers. However, such an exchange is not
required, as long as the result of the authentication calculation
remains the same.
In addition, when using any
When an automated key management protocol [4]
(such as IKE [9]) is used to create a new SA (or SA bundle) while away from
home,
security associations towards a mobile node MUST take special care in its processing of the
key management protocol. Otherwise, other nodes with which peer, it is important to ensure that
the
mobile node must communicate as part of peer can send the automated key management protocol processing may be unable to correctly deliver packets to the mobile node
node. This may not be possible if they and/or the mobile node's peer is the home agent do
not then have a current Binding Cache entry for of the
mobile node. node, and the purpose of the security associations would be to
send a Binding Update to the home agent. Packets addressed to the
home address of the mobile node cannot be used before the Binding
Update has been processed. For the default case of using IKE as
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 98]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
the automated key management protocol [9, 4], such problems can be
avoided by the following
requirements on requirements:
- When the use of IKE by a mobile node while is away from home:
- The mobile node home, it MUST use its care-of
address as the Source Address of all packets it sends as part of
the key management protocol (without use of Mobile IP IPv6 for these
packets, as suggested in Section 11.2.1). 11.3.1).
- In addition, for all security associations bound to the mobile
node's home address established by way of IKE, the mobile node MUST
include an ISAKMP Identification Payload [8] in the IKE exchange,
giving the mobile node's home address as the initiator of the
Security Association [7].
11.2.3.
11.3.3. Receiving Packets While Away from Home
While away from home, a mobile node will receive packets addressed to
its home address, by one of three methods:
- Packets sent by a correspondent node that does not have a Binding
Cache entry for the mobile node, will be tunneled to the mobile
node via its home agent.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 97]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
- Packets sent by a correspondent node that has a Binding Cache
entry for the mobile node that contains the mobile node's current
care-of address, will be sent by the correspondent node using
a type 2 Routing routing header. The packet will be addressed to the
mobile node's care-of address, with the final hop in the Routing routing
header directing the packet to the mobile node's home address;
the processing of this last hop of the Routing routing header is entirely
internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node.
- Packets sent by a correspondent node that has a Binding
Cache entry for the mobile node that contains an out-of-date
care-of address for the mobile node, will also be sent by the
correspondent node using a type 2 Routing header, as described
above. If the mobile node sent a Binding Update to a home agent
on the link on which its previous care-of address is located
(Section 11.6.6), and if this home agent is still serving as a
home agent for the mobile node's previous care-of address, then
such a packet will be delivered to the mobile node via this home
agent.
For packets received by the first of these methods, the mobile node
MUST check that the IPv6 source address of the tunnel tunneled packet is the
IP address of its home agent.
For packets received by either the first or last of these three
methods, the mobile node SHOULD send a Binding Update to the original
sender of the packet, as described in Section 11.6.2, 11.7.2, subject to
the rate limiting defined in Section 11.6.9. 11.8. The mobile node MUST
also process the received packet in the manner defined for IPv6
encapsulation [15], which will result in the encapsulated (inner)
packet being processed normally by upper-layer protocols within the
mobile node, as if it had been addressed (only) to the mobile node's
home address.
For packets received by the second method above (using a Type type 2
Routing
routing header), the following rules will result in the packet being
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 99]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
processed normally by upper-layer protocols within the mobile node,
as if it had been addressed to the mobile node's home address.
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 98]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
A node receiving a packet addressed to itself (i.e., one of the
node's addresses is in the IPv6 destination field) follows the next
header chain of headers and processes them. When it encounters
a Type type 2 Routing routing header during this processing it performs the
following checks. If any of these checks fail the node MUST silently
discard the packet.
- The length field in the RH routing header is exactly 2.
- The segments left field in the RH routing header is either 0 or 1.
(Values on the wire are always 1. But implementations may
process RH in a
manner the routing header so that the value may become 0 after RH
the routing header has been processed, but before the rest of the
packet is processed.)
- The Home Address field in the RH routing header is one of the node's
home addresses, if the segments left field was 1. Thus, in
particular the address field is required to be a unicast routable
address.
Once the above checks have been performed, the node swaps the
IPv6 destination field with the Home Address field in the RH, routing
header, decrements segments left, and resubmits the packet to IP
for processing the next header. Conceptually this follows the same
model as in RFC 2460. However, in the case of Type type 2 Routing routing header
this can be simplified since it is known that the packet will not be
forwarded to a different node.
The definition of AH requires the sender to calculate the AH
integrity check value of a routing header in a way as it appears in
the receiver after it has processed the header. Since IPsec headers
follow the Routing Header, routing header, any IPsec processing will operate on
the packet with the home address in the IP destination field and
segments left being zero. Thus, the AH calculations at the sender
and receiver will have an identical view of the packet.
11.2.4.
11.3.4. Receiving ICMP Error Messages
Any node that doesn't recognize the Mobility header will return an
ICMP Parameter Problem, Code 1, message to the sender of the packet.
If the mobile node receives such an ICMP error message in response to
a return routability procedure or Binding Update, it SHOULD record
in its Binding Update List that future Binding Updates SHOULD NOT be
sent to this destination.
Correspondent nodes who have participated in the return routability
procedure MUST implement the ability to correctly process received
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 100]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
packets containing a Home Address destination option. Therefore,
correctly implemented correspondent nodes should always be able to
recognize Home Address options. If a mobile node receives an ICMP
Parameter Problem, Code 2, message from some node indicating that it
does not support the Home Address option, the mobile node SHOULD log
the error and then discard the ICMP message.
11.3.5. Routing Multicast Packets
A mobile node that is connected to its home link functions in the
same way as any other (stationary) node. Thus, when it is at home,
a mobile node functions identically to other multicast senders and
receivers. This section therefore describes the behavior of a mobile
node that is not on its home link.
In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method by which a mobile
node MAY join the group is via a (local) multicast router on the
foreign link being visited. The mobile node SHOULD use one of its
care-of addresses that shares a subnet prefix with the multicast
router, as the source IPv6 address of its multicast group membership
control messages. If the multicast applications depend on the
address of the joining node, the mobile node MAY treat the router as
a correspondent node and establish a binding with it. The mobile
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 99]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 node can then MUST NOT use the Home Address
destination option in the sent
control messages. when sending MLD packets [29]
Alternatively, a mobile node MAY join multicast groups via a
bi-directional tunnel to its home agent. The mobile node tunnels its
multicast group membership control packets to its home agent, and the
home agent forwards multicast packets down the tunnel to the mobile
node.
A mobile node that wishes to send packets to a multicast group also
has two options: (1) send
1. Send directly on the foreign link being
visited; or (2) send via a tunnel to visited.
The application is aware of the care-of address and uses it for
multicast traffic just like any other stationary address. The
mobile node MUST NOT use Home Address destination option in such
traffic.
2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST
use its home address as the IPv6 Source Address of the inner
multicast packet.
11.3. Home Agent and Prefix Management
11.3.1. Receiving Local Router Advertisement Messages
Each mobile node maintains a Home Agents List recording information
about all home agents
Note that direct sending from which it receives a Router Advertisement,
for which the home agent lifetime indicated in that Router
Advertisement has not yet expired. This list foreign link is used by only applicable
while the mobile node is at that foreign link. This is because the
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 101]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
associated multicast tree is specific to that source location and
any change of location and source address will invalidate the source
specific tree or branch and the application context of the other
multicast group members.
This specification does not provide mechanisms to enable it such local
multicast session to send a Binding Update survive hand-off, and to the global unicast
address of seamlessly continue
from a home agent new CCoA on its previous link when it moves to a each new
link, as described in Section 11.6.6. On receipt of a valid Router
Advertisement, foreign link. Any such mechanism,
developed as defined in the processing algorithm specified for
Neighbor Discovery [12], an extension to this specification, needs to take into
account the impact of fast moving mobile node performs nodes on the following
steps, in addition Internet
multicast routing protocols and their ability to any steps already required of it by Neighbor
Discovery.
- If the Home Agent (H) bit in maintain the Router Advertisement is not set,
integrity of source specific multicast trees and branches.
While the sending node currently has an entry in the node's Home
Agents List, delete use of reverse tunnelling can ensure that multicast trees
are independent of the corresponding entry. Subsequently, skip
all mobile nodes movement, in some case such
tunnelling can have adverse affects. The latency of specific types
of multicast applications such as multicast based discovery protocols
will be affected when the following steps.
- Otherwise, extract round-trip time between the Source Address from foreign subnet
and the IP header home agent is significant compared to that of the
Router Advertisement. This is topology to
be discovered. In addition, the link-local IP address on this
link of delivery tree from the home agent sending this Advertisement [12].
- Determine in
such circumstances relies on unicast encapsulation from the Router Advertisement agent to
the preference for this
home agent. If mobile node and is therefore bandwidth inefficient compared to
the Router Advertisement contains a native multicast forwarding in the foreign multicast system.
11.4. Home Agent
Information Option, then the preference is taken from the and Prefix Management
11.4.1. Dynamic Home Agent Preference field Address Discovery
Sometimes, when the mobile node needs to send a Binding Update to its
home agent to register its new primary care-of address, as described
in Section 11.7.1, the option; otherwise, mobile node may not know the default
preference address of 0 MUST be used.
- Determine from the Router Advertisement the lifetime any
router on its home link that can serve as a home agent for
this it. For
example, some nodes on its home agent. If the Router Advertisement contains a Home
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 100]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
Agent Information Option, then the lifetime is taken from
the Home Agent Lifetime field in the option; otherwise, the
lifetime specified by the Router Lifetime field in the Router
Advertisement SHOULD be used.
- If the link-local address of the home agent sending this
Advertisement is already present in this mobile node's Home
Agents List and the received home agent lifetime value is zero,
immediately delete this entry in the Home Agents List.
- Otherwise, if the link-local address of the home agent sending
this Advertisement is already present in the receiving mobile
node's Home Agents List, reset its lifetime and preference to the
values determined above.
- If the link-local address of the home agent sending this
Advertisement, as determined above, is not already present in the
Home Agents List maintained by the receiving mobile node, and
the lifetime for the sending home agent, as determined above,
is non-zero, create a new entry in the list, and initialize its
lifetime and preference to the values determined above.
- If the Home Agents List entry for the link-local address of
the home agent sending this Advertisement was not deleted as
described above, determine any global address(es) of the home
agent based on each Prefix Information option received in
this Advertisement in which the Router Address (R) bit is set
(Section 7.2). For each such global address determined from this
Advertisement, add this global address to the list of global
addresses for this home agent in this Home Agents List entry.
A mobile node SHOULD maintain an entry in its Home Agents List for
each such valid home agent address until that entry's lifetime
expires, after which time the entry MUST be deleted.
11.3.2. Dynamic Home Agent Address Discovery
Sometimes, when the mobile node needs to send a Binding Update to its
home agent to register its new primary care-of address, as described
in Section 11.6.1, the mobile node may not know the address of any
router on its home link that can serve as a home agent for it. For
example, some nodes on its home link may have been reconfigured while link may have been reconfigured while
the mobile node has been away from home, such that the router that
was operating as the mobile node's home agent has been replaced by a
different router serving this role.
In this case, the mobile node MAY attempt to discover the address of
a suitable home agent on its home link. To do so, the mobile node
sends an ICMP Home Agent Address Discovery Request message to the
"Mobile
Mobile IPv6 Home-Agents" Home-Agents anycast address [16] for its home subnet
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 101]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
prefix. As described in Section 10.9, 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message, giving this home agent's own
global unicast IP address along with a list of the global unicast IP
address of each other home agent operating on the home link.
The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to
the home agent address given as the IP Source Address of the packet
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 102]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
carrying the Reply message or to any of the unicast IP addresses
listed in the Home Agent Addresses field in the Reply. For example,
if necessary, the mobile node MAY attempt its home registration
with each of these home agents, in turn, by sending each a Binding
Update and waiting for the matching Binding Acknowledgement, until
its registration is accepted by one of these home agents. The mobile
node MUST, however, wait at least 1.5 times longer than (RetransTimer
* DupAddrDetectTransmits) before sending a Binding Update to the next
home agent. In trying each of the returned home agent addresses, the
mobile node SHOULD try each in the order listed in the Home Agent
Addresses field in the received Home Agent Address Discovery Reply
message. If the home agent identified by the Source Address field in
the IP header of the packet carrying the Home Agent Address Discovery
Reply message is not listed in the Home Agent Addresses field in the
Reply, it SHOULD be tried before the first address given in the list;
otherwise, it SHOULD be tried in its listed order.
If the mobile node has a current registration with some home agent
on its home link (the Lifetime for that registration has not yet
expired), then the mobile node MUST attempt any new registration
first with that home agent. If that registration attempt fails
(e.g., times out or is rejected), the mobile node SHOULD then
reattempt this registration with another home agent on its home link.
If the mobile node knows of no other suitable home agent, then it MAY
attempt the dynamic home agent address discovery mechanism described
above.
If, after a mobile node transmits a Home Agent Address Discovery
Request message to the Home Agents Anycast address, it does not
receive a corresponding Home Agent Address Discovery Reply message
within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
node MAY retransmit the same Request message to the same anycast
address. This retransmission MAY be repeated up to a maximum of
DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be
delayed by twice the time interval of the previous retransmission.
11.3.3.
11.4.2. Sending Mobile Prefix Solicitations
When a mobile node has a home address that is about to become
invalid, it sends a Mobile Prefix Solicitation to its home agent
in an attempt to acquire fresh routing prefix information. The
new information also enables the mobile node to participate in
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 102]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
renumbering operations affecting the home network, as described in
section 10.9.1.
Section 10.6.
The mobile node MUST use the Home Address destination option to carry
its home address and SHOULD use IPsec to protect the solicitation.
The mobile node SHOULD send a Solicitation to the home agent when
its home address will become invalid within MaxRtrAdvInterval
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 103]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
seconds, where this value is acquired in a previous Mobile Prefix
Advertisement from the home agent. If no such value is known, the
value MAX_PFX_ADV_DELAY seconds is used instead (see section Section 12).
This solicitation follows the same retransmission rules specified for
Router Solicitations [12], except that the initial retransmission
interval is specified to be INITIAL_SOLICIT_TIMER (see section Section 12).
As described in Section 11.6.2, 11.7.2, Binding Updates sent by the mobile
node to other nodes MUST use a lifetime no greater than the remaining
lifetime of its home registration of its primary care-of address.
The mobile node SHOULD further limit the lifetimes that it sends on
any Binding Updates to be within the remaining preferred valid lifetime (see
Section 10.9.2) 10.6.2) for the prefix in its home address.
When the lifetime for a changed prefix decreases, and the change
would cause cached bindings at correspondent nodes in the Binding
Update List to be stored past the newly shortened lifetime, the
mobile node MUST issue a Binding Update to all such correspondent
nodes.
These limits on the binding lifetime serve to prohibit use of a
mobile node's home address after it becomes invalid.
11.3.4.
11.4.3. Receiving Mobile Prefix Advertisements
Section 10.9.1 10.6 describes the operation of a home agent to support boot
time configuration and renumbering a mobile node's home subnet while
the mobile node is away from home. The home agent sends Mobile
Prefix Advertisement messages Advertisements to the mobile node while away from home, giving
"important" Prefix Information options that describe changes in the
prefixes in use on the mobile node's home link.
When a mobile node receives a
The Mobile Prefix Advertisement, it MUST
validate it according Solicitation is similar to the following test:
- The Source Address 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.
When a mobile node receives a Mobile Prefix Advertisement, it MUST
validate it according to the following test:
- The Source Address of the IP packet carrying the Mobile Prefix
Advertisement is the same as the home agent address to which
the mobile node last sent an accepted "home registration" home registration Binding
Update to register its primary care-of address. Otherwise, if
no such registrations have been made, it SHOULD be the mobile
node's stored home agent address, if one exists. Otherwise, if
the mobile node has not yet discovered its home agent's address,
it MUST NOT accept Mobile Prefix Advertisements.
Johnson, Perkins, Arkko Expires 1 December 2002 29 April 2003 [Page 103] 104]
INTERNET-DRAFT Mobility Support in IPv6 1 June 29 Oct 2002
- The packet MUST have a type 2 routing header and SHOULD be
protected by an IPsec [4, 5, 6] to guard against
malicious prefix advertisements, if a security association
exists (i.e. unless the mobile node does not yet have a home
address configured). The IPsec protection MUST provide sender
authentication, data integrity protection, header as described in Sections 5.4
and replay protection,
covering the advertisement. 6.8.
Any received Mobile Prefix Advertisement not meeting this test MUST
be silently discarded. For advertisements that do not contain the
same ICMP Identifier value as in a solicitation cookie, recently sent solicitation, the
mobile node MAY MUST send a solitication
containing such solicitation and expect an advertisement with
a cookie matching Identifier before accepting the advertisement for further processing.
For an accepted Mobile Prefix Advertisement, the mobile node MUST
process the Prefix Information Options as if they arrived in a
Router Advertisement on the mobile node's home link [12]. Such
processing may result in the mobile node configuring a new home
address, although due to separation between preferred lifetime and
valid lifetime, such changes should not affect most communication
by the mobile node, in the same way as for nodes that are at home.
In this case,, case, the mobile node MUST return a Binding Update, which
will be viewed by the home agent as an acknowledgement of the
corresponding Mobile Prefix Advertisement, which it can cease
transmitting. In addition, if the method used for this new home
address configuration would require the mobile node to perform
Duplicate Address Detection [13] for the new address if the mobile
node were located at home, then the mobile node MUST set the
Duplicate Address Detection (D) bit in this Binding Update to its
home agent, to request the home agent to perform this Duplicate
Address Detection on behalf of the mobile node.
11.4.
11.5. Movement
11.4.1.
11.5.1. Movement Detection
The primary movement detection mechanism for Mobile IPv6 defined
in this section uses the facilities of IPv6 Neighbor Discovery,
including Router Discovery and Neighbor Unreachability Detection.
The mobile node SHOULD supplement this mechanism with other
information whenever it is available to the mobile node (e.g.,
from lower protocol layers). The description here is based on the
conceptual model of the organization and data structures defined by
Neighbor Discovery [12].
Mobile nodes SHOULD use Router Discovery to discover new routers
and on-link subnet prefixes; a mobile node MAY send Router Solicitation
messages,
Solicitations, or MAY wait for unsolicited (periodic) multicast
Router
Advertisement messages, Advertisements, as specified for Router Discovery [12]. Based
on received Router Advertisement messages, Advertisements, a mobile node maintains an entry
in its Default Router List for each router, and
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 104]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002 an entry in its
Prefix List for each subnet prefix that it currently considers to be
on-link. Each entry in these lists has an associated invalidation
timer value. While away from home, a mobile node typically selects
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 105]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
one default router and one subnet prefix to use as the subnet
prefix in its primary care-of address. A mobile node MAY also have
associated additional care-of addresses, using other subnet prefixes
from its Prefix List. The method by which a mobile node selects
and forms a care-of address from the available subnet prefixes is
described in Section 11.4.2. 11.5.2. The mobile node registers its primary
care-of address with its home agent, as described in Section 11.6.1. 11.7.1.
While a mobile node is away from home, it is important for the mobile
node to quickly detect when its default router becomes unreachable.
When this happens, the mobile node SHOULD switch to a new default
router and potentially to a new primary care-of address. If, on the
other hand, the mobile node becomes unreachable from its default
router, it should attempt to become reachable through some other
router. To detect when its default router becomes unreachable, a
mobile node SHOULD use Neighbor Unreachability Detection.
For a mobile node to detect when it has become unreachable from its
default router, the mobile node cannot efficiently rely on Neighbor
Unreachability Detection alone, since the network overhead would
be prohibitively high in many cases. Instead, when a mobile node
receives any IPv6 packets from its current default router at all,
irrespective of the source IPv6 address, it SHOULD use that as an
indication that it is still reachable from the router.
Since the router SHOULD be sending periodic unsolicited multicast
Router Advertisement messages, Advertisements, the mobile node will have frequent opportunity
to check if it is still reachable from its default router, even
in the absence of other packets to it from the router. If Router
Advertisements that the mobile node receives include an Advertisement
Interval option, the mobile node MAY use its Advertisement Interval
field as an indication of the frequency with which it SHOULD expect
to continue to receive future Advertisements from that router. This
field specifies the minimum rate (the maximum amount of time between
successive Advertisements) that the mobile node SHOULD expect. If
this amount of time elapses without the mobile node receiving any
Advertisement from this router, the mobile node can be sure that at
least one Advertisement sent by the router has been lost. It is
thus possible for the mobile node to implement its own policy for
determining the number of Advertisements from its current default
router it is willing to tolerate losing before deciding to switch to
a different router from which it may currently be correctly receiving
Advertisements.
On some types of network interfaces, the mobile node MAY also
supplement this monitoring of Router Advertisements, by setting its
network interface into "promiscuous" receive mode, so that it is able
Johnson, Perkins, Arkko Expires 1 December 2002 [Page 105]
INTERNET-DRAFT Mobility Support in IPv6 1 June 2002
to receive all packets on the link, including those not addressed to
it at the link layer (i.e., disabling link-level address filtering).
The mobile node will then be able to detect any packets sent by the
router, in order to detect reachability from the router. This use of
Johnson, Perkins, Arkko Expires 29 April 2003 [Page 106]
INTERNET-DRAFT Mobility Support in IPv6 29 Oct 2002
promiscuous mode may be useful on very low bandwidth (e.g., wireless)
links, but its use MUST be configurable on the mobile node since it
is likely to consume additional energy resources.
If the above means do not provide indication that the mobile node
is still reachable from its current default router (for instance,
the mobile node receives no packets from the router for a period of
time), then the mobile node SHOULD attempt to actively probe the
router with Neighbor Solicitation messages,