draft-ietf-mobileip-ipv6-18.txt   draft-ietf-mobileip-ipv6-19.txt 
IETF Mobile IP Working Group David B. Johnson IETF Mobile IP Working Group David B. Johnson
INTERNET-DRAFT Rice University INTERNET-DRAFT Rice University
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
Jari Arkko Jari Arkko
Ericsson Ericsson
1 June 2002 29 Oct 2002
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-18.txt> <draft-ietf-mobileip-ipv6-19.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
months, and may be updated, replaced, or obsoleted by other documents months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document specifies the operation the IPv6 Internet with mobile This document specifies the operation of the IPv6 Internet with
computers. Each mobile node is always identified by its home mobile computers. Each mobile node is always identified by its
address, regardless of its current point of attachment to the home address, regardless of its current point of attachment to the
Internet. While situated away from its home, a mobile node is also Internet. While situated away from its home, a mobile node is also
associated with a care-of address, which provides information about associated with a care-of address, which provides information about
the mobile node's current location. IPv6 packets addressed to a the mobile node's current location. IPv6 packets addressed to a
mobile node's home address are transparently routed to its care-of mobile node's home address are transparently routed to its care-of
address. The protocol enables IPv6 nodes to cache the binding 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 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 send any packets destined for the mobile node directly to it at this
care-of address. To support this operation, Mobile IPv6 defines a care-of address. To support this operation, Mobile IPv6 defines a
new IPv6 protocol and a new destination option. All IPv6 nodes, new IPv6 protocol and a new destination option. All IPv6 nodes,
whether mobile or stationary, MUST support communications with mobile whether mobile or stationary can communicate with mobile nodes.
nodes.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Comparison with Mobile IP for IPv4 2 2. Comparison with Mobile IP for IPv4 2
3. Terminology 3 3. Terminology 3
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 4 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Mobile IPv6 7 4. Overview of Mobile IPv6 7
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 9 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 9
4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 10 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 10
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 10
4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 11 4.5. Conceptual Data Structure Terminology . . . . . . . . . . 11
4.6. Site-Local Addressability . . . . . . . . . . . . . . . . 11
5. Overview of Mobile IPv6 Security 12 5. Overview of Mobile IPv6 Security 12
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 12 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 12
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 12 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 13
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . 13
5.2.3. Cookies . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . 14
5.2.4. Cryptographic Functions . . . . . . . . . . . . . 14 5.2.4. Cryptographic Functions . . . . . . . . . . . . . 15
5.2.5. Return Routability Procedure . . . . . . . . . . 14 5.2.5. Return Routability Procedure . . . . . . . . . . 15
5.2.6. Applying Return Routability for Correspondent 5.2.6. Authorizing Binding Management Messages . . . . . 19
Bindings . . . . . . . . . . . . . . . . . 18
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . 20
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 20 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . 22
5.3. Payload Packets . . . . . . . . . . . . . . . . . . . . . 21 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 22
5.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . 22
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 22
6. New IPv6 Protocols, Message Types, and Destination Option 21 6. New IPv6 Protocol, Message Types, and Destination Option 23
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 21 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 22 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 23
6.1.2. Binding Refresh Request (BRR) Message . . . . . . 23 6.1.2. Binding Refresh Request Message . . . . . . . . . 25
6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 24 6.1.3. Home Test Init Message . . . . . . . . . . . . . 26
6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 26 6.1.4. Care-of Test Init Message . . . . . . . . . . . . 27
6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 27 6.1.5. Home Test Message . . . . . . . . . . . . . . . . 28
6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 28 6.1.6. Care-of Test Message . . . . . . . . . . . . . . 29
6.1.7. Binding Update (BU) Message . . . . . . . . . . . 29 6.1.7. Binding Update Message . . . . . . . . . . . . . 31
6.1.8. Binding Acknowledgement (BA) Message . . . . . . 32 6.1.8. Binding Acknowledgement Message . . . . . . . . . 33
6.1.9. Binding Error (BE) Message . . . . . . . . . . . 34 6.1.9. Binding Error Message . . . . . . . . . . . . . . 35
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 35 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 36
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 35 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 37
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 36 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 37
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 37 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 38
6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 37 6.2.4. Alternate Care-of Address . . . . . . . . . . . . 38
6.2.5. Alternate Care-of Address . . . . . . . . . . . . 38 6.2.5. Nonce Indices . . . . . . . . . . . . . . . . . . 39
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 38 6.2.6. Binding Authorization Data . . . . . . . . . . . 39
6.2.7. Binding Authorization Data . . . . . . . . . . . 39 6.2.7. Binding Refresh Advice . . . . . . . . . . . . . 40
6.2.8. Binding Refresh Advice . . . . . . . . . . . . . 39 6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 41
6.3. Home Address Destination Option . . . . . . . . . . . . . 40 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 43
6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 42 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . 43
6.4.1. Routing Header Packet format . . . . . . . . . . 42 6.5. ICMP Home Agent Address Discovery Request Message . . . . 44
6.5. ICMP Home Agent Address Discovery Request Message . . . . 43 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 46
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 45
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 47
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 49
7. Modifications to IPv6 Neighbor Discovery 51 7. Modifications to IPv6 Neighbor Discovery 51
7.1. Modified Router Advertisement Message Format . . . . . . 51 7.1. Modified Router Advertisement Message Format . . . . . . 51
7.2. Modified Prefix Information Option Format . . . . . . . . 52 7.2. Modified Prefix Information Option Format . . . . . . . . 52
7.3. New Advertisement Interval Option Format . . . . . . . . 54 7.3. New Advertisement Interval Option Format . . . . . . . . 54
7.4. New Home Agent Information Option Format . . . . . . . . 55 7.4. New Home Agent Information Option Format . . . . . . . . 55
7.5. Changes to Sending Router Advertisements . . . . . . . . 57 7.5. Changes to Sending Router Advertisements . . . . . . . . 57
7.6. Changes to Sending Router Solicitations . . . . . . . . . 58 7.6. Changes to Sending Router Solicitations . . . . . . . . . 59
7.7. Changes to Duplicate Address Detection . . . . . . . . . 60
8. Requirements for Types of IPv6 Nodes 59 8. Requirements for Types of IPv6 Nodes 60
8.1. General Requirements for All IPv6 Nodes . . . . . . . . . 59 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 61
8.2. Route Optimization Requirements for All IPv6 Nodes . . . 59 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 61
8.3. Requirements for All IPv6 Routers . . . . . . . . . . . . 60 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 62
8.4. Requirements for IPv6 Home Agents . . . . . . . . . . . . 61 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 62
8.5. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 62 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 63
9. Correspondent Node Operation 63 9. Correspondent Node Operation 65
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 63 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 65
9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 64 9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 66
9.2.1. Processing Mobility Header (MH) Messages . . . . 64 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 66
9.2.2. Receiving Packets with Home Address Destination 9.3.1. Receiving Packets with Home Address Destination
Option . . . . . . . . . . . . . . . . . . 65 Option . . . . . . . . . . . . . . . . . . 66
9.3. Return Routability Procedure . . . . . . . . . . . . . . 66 9.3.2. Sending Packets to a Mobile Node . . . . . . . . 67
9.3.1. Receiving Home Test Init Messages . . . . . . . . 66 9.3.3. Sending Binding Error Messages . . . . . . . . . 68
9.3.2. Receiving Care-of Test Init Messages . . . . . . 66 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . 69
9.3.3. Sending Home Test Messages . . . . . . . . . . . 67 9.4. Return Routability Procedure . . . . . . . . . . . . . . 69
9.3.4. Sending Care-of Test Messages . . . . . . . . . . 67 9.4.1. Receiving Home Test Init Messages . . . . . . . . 69
9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 67 9.4.2. Receiving Care-of Test Init Messages . . . . . . 70
9.4.1. Receiving Binding Updates . . . . . . . . . . . . 67 9.4.3. Sending Home Test Messages . . . . . . . . . . . 70
9.4.2. Requests to Cache a Binding . . . . . . . . . . . 69 9.4.4. Sending Care-of Test Messages . . . . . . . . . . 70
9.4.3. Requests to Delete a Binding . . . . . . . . . . 69 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 70
9.4.4. Sending Binding Acknowledgements . . . . . . . . 70 9.5.1. Receiving Binding Updates . . . . . . . . . . . . 71
9.4.5. Sending Binding Refresh Requests . . . . . . . . 71 9.5.2. Requests to Cache a Binding . . . . . . . . . . . 73
9.4.6. Sending Binding Error Messages . . . . . . . . . 71 9.5.3. Requests to Delete a Binding . . . . . . . . . . 74
9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 71 9.5.4. Sending Binding Acknowledgements . . . . . . . . 74
9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 72 9.5.5. Sending Binding Refresh Requests . . . . . . . . 75
9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 73 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 75
10. Home Agent Operation 74 10. Home Agent Operation 76
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 74 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 76
10.2. Primary Care-of Address Registration . . . . . . . . . . 75 10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 77
10.3. Primary Care-of Address De-Registration . . . . . . . . . 79 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 77
10.4. Intercepting Packets for a Mobile Node . . . . . . . . . 80 10.3.1. Primary Care-of Address Registration . . . . . . 77
10.5. Tunneling Intercepted Packets to a Mobile Node . . . . . 81 10.3.2. Primary Care-of Address De-Registration . . . . . 81
10.6. Handling Reverse Tunneled Packets from a Mobile Node . . 83 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 82
10.7. Protecting Return Routability Packets . . . . . . . . . . 83 10.4.1. Intercepting Packets for a Mobile Node . . . . . 82
10.8. Receiving Router Advertisement Messages . . . . . . . . . 84 10.4.2. Tunneling Intercepted Packets to a Mobile Node . 83
10.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 85 10.4.3. Handling Reverse Tunneled Packets from a Mobile
10.9.1. Aggregate List of Home Network Prefixes . . . . . 87 Node . . . . . . . . . . . . . . . . . . . 85
10.9.2. Scheduling Prefix Deliveries to the Mobile Node . 89 10.4.4. Protecting Return Routability Packets . . . . . . 85
10.9.3. Sending Advertisements to the Mobile Node . . . . 90 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 86
10.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 91 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 . . . . . 89
10.6.2. Scheduling Prefix Deliveries to the Mobile Node . 90
10.6.3. Sending Advertisements to the Mobile Node . . . . 92
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . 92
11. Mobile Node Operation 91 11. Mobile Node Operation 93
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 91 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 93
11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 93 11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 94
11.2.1. Sending Packets While Away from Home . . . . . . 93 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 95
11.2.2. Interaction with Outbound IPsec Processing . . . 96 11.3.1. Sending Packets While Away from Home . . . . . . 95
11.2.3. Receiving Packets While Away from Home . . . . . 97 11.3.2. Interaction with Outbound IPsec Processing . . . 97
11.2.4. Routing Multicast Packets . . . . . . . . . . . . 99 11.3.3. Receiving Packets While Away from Home . . . . . 99
11.3. Home Agent and Prefix Management . . . . . . . . . . . . 100 11.3.4. Receiving ICMP Error Messages . . . . . . . . . . 100
11.3.1. Receiving Local Router Advertisement Messages . . 100 11.3.5. Routing Multicast Packets . . . . . . . . . . . . 101
11.3.2. Dynamic Home Agent Address Discovery . . . . . . 101 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 102
11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 102 11.4.1. Dynamic Home Agent Address Discovery . . . . . . 102
11.3.4. Receiving Mobile Prefix Advertisements . . . . . 103 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . 103
11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 104 11.4.3. Receiving Mobile Prefix Advertisements . . . . . 104
11.4.1. Movement Detection . . . . . . . . . . . . . . . 104 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 105
11.4.2. Forming New Care-of Addresses . . . . . . . . . . 107 11.5.1. Movement Detection . . . . . . . . . . . . . . . 105
11.4.3. Using Multiple Care-of Addresses . . . . . . . . 108 11.5.2. Forming New Care-of Addresses . . . . . . . . . . 107
11.5. Return Routability Procedure . . . . . . . . . . . . . . 109 11.5.3. Using Multiple Care-of Addresses . . . . . . . . 109
11.5.1. Sending Home and Care-of Test Init Messages . . . 109 11.5.4. Returning Home . . . . . . . . . . . . . . . . . 109
11.5.2. Receiving Return Routability Messages . . . . . . 109 11.6. Return Routability Procedure . . . . . . . . . . . . . . 111
11.5.3. Retransmitting in the Return Routability Procedure 111 11.6.1. Sending Home and Care-of Test Init Messages . . . 111
11.5.4. Rate Limiting for Return Routability Procedure . 111 11.6.2. Receiving Return Routability Messages . . . . . . 112
11.6. Processing Bindings . . . . . . . . . . . . . . . . . . . 111 11.6.3. Protecting Return Routability Packets . . . . . . 113
11.6.1. Sending Binding Updates to the Home Agent . . . . 111 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 114
11.6.2. Correspondent Binding Procedure . . . . . . . . . 114 11.7.1. Sending Binding Updates to the Home Agent . . . . 114
11.6.3. Receiving Binding Acknowledgements . . . . . . . 117 11.7.2. Correspondent Binding Procedure . . . . . . . . . 116
11.6.4. Receiving Binding Refresh Requests . . . . . . . 118 11.7.3. Receiving Binding Acknowledgements . . . . . . . 119
11.6.5. Receiving Binding Error Messages . . . . . . . . 119 11.7.4. Receiving Binding Refresh Requests . . . . . . . 121
11.6.6. Forwarding from a Previous Care-of Address . . . 120 11.7.5. Receiving Binding Error Messages . . . . . . . . 121
11.6.7. Returning Home . . . . . . . . . . . . . . . . . 121 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 122
11.6.8. Retransmitting Binding Updates . . . . . . . . . 123
11.6.9. Rate Limiting Binding Updates . . . . . . . . . . 124
11.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 124
12. Protocol Constants 125 12. Protocol Constants 123
13. IANA Considerations 126 13. IANA Considerations 124
14. Security Considerations 127 14. Security Considerations 125
14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 127 14.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 125
14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 129 14.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 127
14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 130 14.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 128
14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 132 14.4. Binding Updates to Correspondent Nodes . . . . . . . . . 130
14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 132 14.4.1. Overview . . . . . . . . . . . . . . . . . . . . 130
14.4.2. Offered Protection . . . . . . . . . . . . . . . 132 14.4.2. Offered Protection . . . . . . . . . . . . . . . 131
14.4.3. Comparison to Regular IPv6 Communications . . . . 133 14.4.3. Comparison to Regular IPv6 Communications . . . . 131
14.4.4. Return Routability Replays . . . . . . . . . . . 135 14.4.4. Return Routability Replays . . . . . . . . . . . 133
14.4.5. Return Routability Denial-of-Service . . . . . . 135 14.4.5. Return Routability Denial-of-Service . . . . . . 133
14.5. Tunneling via the Home Agent . . . . . . . . . . . . . . 136 14.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 134
14.6. Home Address Destination Option . . . . . . . . . . . . . 137 14.6. Prefix Discovery . . . . . . . . . . . . . . . . . . . . 135
14.7. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 138 14.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 135
14.8. Home Address Option . . . . . . . . . . . . . . . . . . . 135
14.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 136
Acknowledgements 138 Contributors 137
References 140 Acknowledgements 137
A. State Machine for the Correspondent Binding Procedure 142 References 139
A.1. Main State Machine . . . . . . . . . . . . . . . . . . . 143
A.2. Return Routability Procedure . . . . . . . . . . . . . . 149
B. Changes from Previous Version of the Draft 153 A. Changes from Previous Version of the Draft 142
A.1. Changes from Draft Version 18 . . . . . . . . . . . . . . 142
C. Future Extensions 154 B. Future Extensions 146
C.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 154 B.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 146
C.2. Triangular Routing and Unverified Home Addresses . . . . 154 B.2. Triangular Routing and Unverified Home Addresses . . . . 146
C.3. New Authorization Methods beyond Return Routability . . . 155 B.3. New Authorization Methods beyond Return Routability . . . 146
C.4. Security and Dynamically Generated Home Addresses . . . . 155 B.4. Security and Dynamically Generated Home Addresses . . . . 147
C.5. Remote Home Address Configuration . . . . . . . . . . . . 155 B.5. Remote Home Address Configuration . . . . . . . . . . . . 147
Chairs' Addresses 157 Chairs' Addresses 149
Authors' Addresses 157 Authors' Addresses 149
1. Introduction 1. Introduction
This document specifies how the IPv6 Internet operates with mobile This document specifies how the IPv6 Internet operates with mobile
computers. Without specific support for mobility in IPv6 [11], computers. Without specific support for mobility in IPv6 [11],
packets destined to a mobile node would not be able to reach it while 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 the mobile node is away from its home link. In order to continue
communication in spite of its movement, a mobile node could change 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 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 node would then not be able to maintain transport and higher-layer
connections when it changes location. Mobility support in IPv6 is connections when it changes location. Mobility support in IPv6 is
particularly important, as mobile computers are likely to account for particularly important, as mobile computers are likely to account for
a majority or at least a substantial fraction of the population of a majority or at least a substantial fraction of the population of
the Internet during the lifetime of IPv6. the Internet during the lifetime of IPv6.
The protocol defined in this document, known as Mobile IPv6, allows The protocol defined in this document, known as Mobile IPv6, allows
a mobile node to move from one link to another without changing the 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 mobile node's "home address". Packets may be routed to the mobile
its "home address", an IP address assigned to the mobile node within node using this address regardless of the mobile node's current point
its home subnet prefix on its home link. Packets may be routed to of attachment to the Internet. The mobile node may also continue
the mobile node using this address regardless of the mobile node's to communicate with other nodes (stationary or mobile) after moving
current point of attachment to the Internet. The mobile node may to a new link. The movement of a mobile node away from its home
also continue to communicate with other nodes (stationary or mobile) link is thus transparent to transport and higher-layer protocols and
after moving to a new link. The movement of a mobile node away from applications.
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 The Mobile IPv6 protocol is just as suitable for mobility across
homogeneous media as for mobility across heterogeneous media. For homogeneous media as for mobility across heterogeneous media. For
example, Mobile IPv6 facilitates node movement from one Ethernet example, Mobile IPv6 facilitates node movement from one Ethernet
segment to another as well as it facilitates node movement from an segment to another as well as it facilitates node movement from an
Ethernet segment to a wireless LAN cell, with the mobile node's IP Ethernet segment to a wireless LAN cell, with the mobile node's IP
address remaining unchanged in spite of such movement. address remaining unchanged in spite of such movement.
One can think of the Mobile IPv6 protocol as solving the One can think of the Mobile IPv6 protocol as solving the
network-layer mobility management problem. Some mobility management network-layer mobility management problem. Some mobility management
applications -- for example, handover among wireless transceivers, applications -- for example, handover among wireless transceivers,
each of which covers only a very small geographic area -- have been each of which covers only a very small geographic area -- have been
solved using link-layer techniques. For example, in many current solved using link-layer techniques. For example, in many current
wireless LAN products, link-layer mobility mechanisms allow a wireless LAN products, link-layer mobility mechanisms allow a
"handover" of a mobile node from one cell to another, reestablishing "handover" of a mobile node from one cell to another, re-establishing
link-layer connectivity to the node in each new location. link-layer connectivity to the node in each new location.
Mobile IP does not attempt to solve all general problems related to Mobile IPv6 does not attempt to solve all general problems related
the use of mobile computers or wireless networks. In particular, to the use of mobile computers or wireless networks. In particular,
this protocol does not attempt to solve: this protocol does not attempt to solve:
- Handling links with partial reachability, or unidirectional - Handling links with partial reachability, or unidirectional
connectivity, such as are often found in wireless networks (but connectivity, such as are often found in wireless networks (but
see Section 11.4.1). see Section 11.5.1).
- Access control on a link being visited by a mobile node. - Access control on a link being visited by a mobile node.
- Local or hierarchical forms of mobility management (similar to - Local or hierarchical forms of mobility management (similar to
many current link-layer mobility management solutions). many current link-layer mobility management solutions).
- Assistance for adaptive applications - Assistance for adaptive applications
- Mobile routers - Mobile routers
- Service Discovery - Service Discovery
- Distinguishing between packets lost due to bit errors vs. - Distinguishing between packets lost due to bit errors vs.
network congestion network congestion
2. Comparison with Mobile IP for IPv4 2. Comparison with Mobile IP for IPv4
The design of Mobile IP support in IPv6 (Mobile IPv6) represents a The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both
natural combination of the experiences gained from the development of from the experiences gained from the development of Mobile IP support
Mobile IP support in IPv4 (Mobile IPv4) [20, 21, 22], together with in IPv4 (Mobile IPv4) [20, 21, 22], and from the opportunities
the opportunities provided by IPv6. Mobile IPv6 thus shares many provided by IPv6. Mobile IPv6 thus shares many features with
features with Mobile IPv4, but is integrated into IP and provides Mobile IPv4, but is integrated into IPv6 and offers many other
many improvements. This section summarizes the major differences improvements. This section summarizes the major differences between
between Mobile IPv4 and Mobile IPv6: Mobile IPv4 and Mobile IPv6:
- There is no longer any need to deploy special routers as - There is no need to deploy special routers as "foreign agents",
"foreign agents" as are used in Mobile IPv4. In Mobile IPv6, as in Mobile IPv4. Mobile IPv6 operates in any location without
mobile nodes make use of IPv6 features, to operate in any any special support required from the local router.
location without any special support required from the local
router.
- Support for what is known in Mobile IPv4 as "route - Support for route optimization is a fundamental part of the
optimization" [23] is now built in as a fundamental part protocol, rather than a nonstandard set of extensions.
of the protocol, rather than being added on as an optional set
of extensions that may not be supported by all nodes as in
Mobile IPv4.
- Mobile IPv6 route optimization can operate securely even without - Mobile IPv6 route optimization can operate securely even without
pre-arranged security associations. It is expected that route pre-arranged security associations. It is expected that route
optimization can be deployed on a global scale between all mobile optimization can be deployed on a global scale between all mobile
nodes and correspondent nodes. nodes and correspondent nodes.
- Support is also integrated into Mobile IPv6 for allowing route - Support is also integrated into Mobile IPv6 for allowing route
optimization to coexist efficiently with routers that perform optimization to coexist efficiently with routers that perform
"ingress filtering" [24]. Both the current care-of address and "ingress filtering" [23].
the home address can be carried in packets, allowing packets to
pass normally through ingress filtering routers.
- In Mobile IPv6, the mobile node does not have to tunnel multicast - 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 to its home agent.
packets is compatible with multicast routing that is based in
part on the packet's Source Address.
- The movement detection mechanism in Mobile IPv6 provides - The movement detection mechanism in Mobile IPv6 provides
bidirectional confirmation of a mobile node's ability to bidirectional confirmation of a mobile node's ability to
communicate with its default router in its current location. communicate with its default router in its current location.
- Most packets sent to a mobile node while away from home in - Most packets sent to a mobile node while away from home in
Mobile IPv6 are sent using an IPv6 Routing header rather than IP Mobile IPv6 are sent using an IPv6 routing header rather than IP
encapsulation, reducing the amount of resulting overhead compared encapsulation, reducing the amount of resulting overhead compared
to Mobile IPv4. to Mobile IPv4.
- Mobile IPv6 is decoupled from any particular link layer, as it - Mobile IPv6 is decoupled from any particular link layer, as it
uses IPv6 Neighbor Discovery [12] instead of ARP. This also uses IPv6 Neighbor Discovery [12] instead of ARP. This also
improves the robustness of the protocol. improves the robustness of the protocol.
- The use of IPv6 encapsulation (and the Routing header) removes - The use of IPv6 encapsulation (and the routing header) removes
the need in Mobile IPv6 to manage "tunnel soft state". the need in Mobile IPv6 to manage "tunnel soft state".
- The dynamic home agent address discovery mechanism in Mobile IPv6 - The dynamic home agent address discovery mechanism in Mobile IPv6
returns a single reply to the mobile node. The directed returns a single reply to the mobile node. The directed
broadcast approach used in IPv4 returns separate replies from broadcast approach used in IPv4 returns separate replies from
each home agent. each home agent.
3. Terminology 3. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 41 skipping to change at page 3, line 32
3.1. General Terms 3.1. General Terms
IP Internet Protocol Version 6 (IPv6). IP Internet Protocol Version 6 (IPv6).
node A device that implements IP. node A device that implements IP.
router A node that forwards IP packets not explicitly router A node that forwards IP packets not explicitly
addressed to itself. 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. host Any node that is not a router.
link A communication facility or medium over which nodes link A communication facility or medium over which nodes
can communicate at the link layer, such as an can communicate at the link layer, such as an Ethernet
Ethernet (simple or bridged). A link is the layer (simple or bridged). A link is the layer immediately
immediately below IP. below IP.
interface A node's attachment to a link. interface A node's attachment to a link.
subnet prefix subnet prefix
A bit string that consists of some number of initial A bit string that consists of some number of initial
bits of an IP address. bits of an IP address.
interface identifier interface identifier
A number used to identify a node's interface on a A number used to identify a node's interface on a
link. The interface identifier is the remaining link. The interface identifier is the remaining
skipping to change at page 4, line 19 skipping to change at page 4, line 19
subnet prefix. subnet prefix.
link-layer address link-layer address
A link-layer identifier for an interface, such as A link-layer identifier for an interface, such as
IEEE 802 addresses on Ethernet links. IEEE 802 addresses on Ethernet links.
packet An IP header plus payload. packet An IP header plus payload.
security association security association
A security object shared between two nodes which A security object shared between two nodes which
includes the data mutually agreed on for operation includes the data mutually agreed on for operation of
of some cryptographic algorithm (typically including some cryptographic algorithm (typically including a
a key). key).
security policy database security policy database
A database of rules that describe what security A database of rules that describe what security
associations should be applied for different kinds associations should be applied for different kinds of
of packets. packets.
destination option Destination options are carried by the IPv6 destination option
Destination Options extension header. Mobile IPv6 Destination options are carried by the IPv6
defines one new destination option, the Home Address Destination Options extension header. Destination
destination option. 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 (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
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 3.2. Mobile IPv6 Terms
home address An IP address assigned to a mobile node, used as the home address
permanent address of the mobile node. This address A unicast routable address assigned to a mobile node,
is within the mobile node's home link. Standard IP used as the permanent address of the mobile node. This
routing mechanisms will deliver packets destined for 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. a mobile node's home address to its home link.
home subnet prefix home subnet prefix
The IP subnet prefix corresponding to a mobile The IP subnet prefix corresponding to a mobile node's
node's home address. home address.
home link The link on which a mobile node's home subnet prefix home link The link on which a mobile node's home subnet prefix is
is defined. defined.
mobile node A node that can change its point of attachment from mobile node
one link to another, while still being reachable via A node that can change its point of attachment from one
its home address. link to another, while still being reachable via its
home address.
movement A change in a mobile node's point of attachment to movement A change in a mobile node's point of attachment to the
the Internet such that it is no longer connected to Internet such that it is no longer connected to the same
the same link as it was previously. If a mobile link as it was previously. If a mobile node is not
node is not currently attached to its home link, the currently attached to its home link, the mobile node is
mobile node is said to be "away from home". said to be "away from home".
correspondent node correspondent node
A peer node with which a mobile node is A peer node with which a mobile node is communicating.
communicating. The correspondent node may be either The correspondent node may be either mobile or
mobile or stationary. stationary.
foreign subnet prefix foreign subnet prefix
Any IP subnet prefix other than the mobile node's Any IP subnet prefix other than the mobile node's home
home subnet prefix. subnet prefix.
foreign link Any link other than the mobile node's home link. foreign link
Any link other than the mobile node's home link.
care-of address care-of address
An IP address associated with a mobile node while A unicast routable address associated with a mobile
visiting a foreign link; the subnet prefix of this node while visiting a foreign link; the subnet prefix
IP address is a foreign subnet prefix. Among the of this IP address is a foreign subnet prefix. Among
multiple care-of addresses that a mobile node may the multiple care-of addresses that a mobile node may
have at any given time (e.g., with different subnet have at any given time (e.g., with different subnet
prefixes), the one registered with the mobile node's prefixes), the one registered with the mobile node's
home agent is called its "primary" care-of address. home agent is called its "primary" care-of address.
home agent A router on a mobile node's home link with which home agent
the mobile node has registered its current care-of A router on a mobile node's home link with which the
address. While the mobile node is away from home, mobile node has registered its current care-of address.
the home agent intercepts packets on the home While the mobile node is away from home, the home agent
link destined to the mobile node's home address, intercepts packets on the home link destined to the
encapsulates them, and tunnels them to the mobile mobile node's home address, encapsulates them, and
node's registered care-of address. tunnels them to the mobile node's registered care-of
address.
binding The association of the home address of a mobile node binding The association of the home address of a mobile node
with a care-of address for that mobile node, along with a care-of address for that mobile node, along with
with the remaining lifetime of that association. 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 binding procedure
A binding procedure is initiated by the mobile node A binding procedure is initiated by the mobile node to
to inform either a correspondent node or the mobile inform either a correspondent node or the mobile node's
node's home agent of the current binding of the home agent of the current binding of the mobile node.
mobile node.
binding authorization binding authorization
Binding procedure needs to be authorized to allow Binding procedure needs to be authorized to allow the
the recipient to believe that the sender has the recipient to believe that the sender has the right to
right to specify a new binding. specify a new binding.
return routability procedure return routability procedure
The return routability procedure authorizes binding The return routability procedure authorizes binding
procedures by the use of a cryptographic cookie procedures by the use of a cryptographic token exchange.
exchange.
correspondent binding procedure correspondent binding procedure
A return routability procedure followed by a A return routability procedure followed by a
binding procedure, run between the mobile node and a binding procedure, run between the mobile node and a
correspondent node. correspondent node.
home binding procedure home binding procedure
A binding procedure between the mobile node and its A binding procedure between the mobile node and its home
home agent, authorized by the use of IPsec. agent, authorized by the use of IPsec.
nonce Nonces are random numbers used internally by the nonce Nonces are random numbers used internally by the
correspondent node in the creation of cookies correspondent node in the creation of keygen tokens
related to the return routability procedure. The related to the return routability procedure. The nonces
nonces are not specific to a mobile node, and are are not specific to a mobile node, and are kept secret
kept secret within the correspondent node, only used within the correspondent node.
as one input in the creation of the cookies.
cookie Cookies are numbers that are used by mobile nodes
and correspondent nodes in the return routability
procedure.
care-of cookie nonce index
A cookie sent directly to the mobile node's claimed A nonce index is used to indicate which nonces have
care-of address from the correspondent node. been used when creating keygen token values, without
revealing the nonces themselves.
home cookie A cookie sent to the mobile node's claimed home cookie A cookie is a random number used by a mobile nodes to
address from the correspondent node. prevent spoofing by a bogus correspondent node in the
return routability procedure.
mobile cookie care-of init cookie
A cookie sent to the correspondent node from the A cookie sent to the correspondent node in the Care-of
mobile node, and later returned to the mobile node. Test Init message, to be returned in the Care-of Test
Mobile cookies are produced randomly. There are two message.
kinds of mobile cookies: the HoT cookie and the CoT
cookie.
CoT cookie home init cookie
A cookie sent by the mobile node to the the A cookie sent to the correspondent node in the Home Test
correspondent node in the CoTI message, to be Init message, to be returned in the Home Test message.
returned to the mobile node in the CoT message.
HoT cookie keygen token
A cookie sent by the mobile node to the the A keygen token is a number supplied by a correspondent
correspondent node in the HoTI message, to be node in the return routability procedure to enable the
returned to the mobile node in the HoT message. mobile node to compute the necessary binding management
key for authorizing a Binding Update.
nonce index care-of keygen token
The mobile node uses a particular set of cookies in A keygen token sent by the correspondent node in the
the return routability procedure. The cookies have Care-of Test message.
been produced using a particular set of nonces. A
nonce index is used to indicate which nonces have
been used, without revealing the nonces themselves.
binding key home keygen token
a key used for authenticating binding cache A keygen token sent by the correspondent node in the
management messages. Home Test message.
binding security association binding management key (Kbm)
a security association established specifically A binding management key (Kbm) is a key used for
for the purpose of producing and verifying authorizing a binding cache management message (e.g.,
authentication data passed with a Binding Binding Update or Binding Acknowledgement). Return
Authorization Data option. routability provides a way to create a binding
management key.
4. Overview of Mobile IPv6 4. Overview of Mobile IPv6
4.1. Basic Operation 4.1. Basic Operation
A mobile node is always addressable at its home address, whether it A mobile node is always expected to be addressable at its home
is currently attached to its home link or is away from home. While address, whether it is currently attached to its home link or is
a mobile node is at home, packets addressed to its home address away from home. The "home address" is an IP address assigned to the
are routed to it using conventional Internet routing mechanisms in mobile node within its home subnet prefix on its home link. While
the same way as if the node were stationary. The subnet prefix of a mobile node is at home, packets addressed to its home address are
a mobile node's home address is one of the subnet prefixes of the routed to the mobile node's home link, using conventional Internet
mobile node's home link. Packets addressed to the mobile node will routing mechanisms.
therefore be routed to its home link.
While a mobile node is attached to some foreign link away from home, 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 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 address is an IP address associated with a mobile node that has the
a particular foreign link. The subnet prefix of a mobile node's subnet prefix of a particular foreign link. The mobile node can
care-of address is one of the subnet prefixes on the foreign link. acquire its care-of address through conventional IPv6 stateless or
As long as the mobile node stays in this location, packets addressed stateful auto-configuration mechanisms. As long as the mobile node
to this care-of address will be routed to 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 The association between a mobile node's home address and care-of
address is known as a "binding" for the mobile node. A mobile node address is known as a "binding" for the mobile node. While away
typically acquires its care-of address through stateless [13] or from home, a mobile node registers its primary care-of address with
stateful (e.g., DHCPv6 [25]) Address Autoconfiguration, according a router on its home link, requesting this router to function as the
to the methods of IPv6 Neighbor Discovery [12]. Other methods "home agent" for the mobile node. The mobile node performs this
of acquiring a care-of address are also possible, but are beyond binding registration by sending a "Binding Update" message to the
the scope of this document. The operation of the mobile node is home agent. The home agent replies to the mobile node by returning a
specified in Section 11. "Binding Acknowledgement" message. The operation of the mobile node
and the home agent is specified in Sections 11 and 10, respectively.
While away from home, a mobile node registers one of its care-of
addresses with a router on its home link, requesting this router to
function as the "home agent" for the mobile node. The mobile node
performs this binding registration by sending a "Binding Update"
message to the home agent. The 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 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
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 home agent is specified in Section 10.
Any node communicating with a mobile node is referred to in this Any node communicating with a mobile node is referred to in this
document as a "correspondent node" of the mobile node, and may itself 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 be either a stationary node or a mobile node. Mobile nodes can
correspondent node is specified in Section 9. Mobile nodes can provide information about their current location to correspondent
inform the correspondent nodes of the current location of the mobile nodes. This happens through the correspondent binding procedure. As
node. This happens through the correspondent binding procedure. As a part of this procedure, a return routability test is performed in
a part of this procedure, a return routability test is performed order to authorize the establishment of the binding. The operation
in order to authorize the establishment of the binding. This is of the correspondent node is specified in Section 9.
specified in Sections 5.2.5 and 5.2.6. When sending a packet to
any IPv6 destination, a node checks its cached bindings for an
entry for the packet's destination address. If a cached binding
for this destination address is found, the node uses a new type of
IPv6 Routing header [11] (see section 6.4) to route the packet to
the mobile node by way of the care-of address indicated in this
binding. If, instead, the sending node has no cached binding for
this destination address, the node sends the packet normally (with
no Routing header), and the packet is subsequently intercepted and
tunneled by the mobile node's home agent as described above. 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 There are two possible modes for communications between the mobile
directly to the mobile node's care-of address, so that the home agent node and a correspondent node. The first mode, bidirectional
is rarely involved with packet transmission to the mobile node. This tunneling, does not require Mobile IPv6 support from the
is important for scalability and reliability, and for minimizing correspondent node and is available even if the mobile node has not
overall network load. Routing packets directly to the mobile node's registered its current binding with the correspondent node. Packets
care-of address also eliminates congestion at the mobile node's home from the correspondent node are routed to the home agent and then
agent and home link. In addition, the impact of any possible failure tunneled to the mobile node. Packets to the correspondent node are
of the home agent, the home link, or intervening networks leading to tunneled from the mobile node to the home agent ("reverse tunneled")
or from the home link is reduced, since these nodes and links are not and then routed normally from the home network to the correspondent
involved in the delivery of most packets to the mobile node. 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].
Mobile IPv6 defines a new IPv6 destination option. When a mobile The second mode, "route optimization", requires the mobile node to
node sends a packet while away from home, it could generally use register its current binding at the correspondent node. Packets
a tunnel via the home agent to send this packet. However, if the from the correspondent node can be routed directly to the care-of
correspondent node in question has a binding for this mobile node, address of the mobile node. When sending a packet to any IPv6
the mobile node can deliver packets directly to the correspondent destination, the correspondent node checks its cached bindings for
node. The mobile node sets the Source Address in the packet's IPv6 an entry for the packet's destination address. If a cached binding
header to one of its current care-of addresses, and include a "Home for this destination address is found, the node uses a new type of
Address" destination option in the packet, giving the mobile node's IPv6 routing header [11] (see Section 6.4) to route the packet to the
home address. By also including the Home Address destination option mobile node by way of the care-of address indicated in this binding.
in each packet, the sending mobile node can communicate its home
address to the correspondent node receiving this packet. This makes
the use of the care-of address transparent above the Mobile IPv6
support level (e.g., at the transport layer).
It is possible that while a mobile node is away from home, some nodes Routing packets directly to the mobile node's care-of address allows
on its home link may be reconfigured. The router that was operating the shortest communications path to be used. It also eliminates
as the mobile node's home agent can be replaced by a different congestion at the mobile node's home agent and home link. In
router serving the same role. In this case, the mobile node may not addition, the impact of any possible failure of the home agent or
know the IP address of its own home agent. Mobile IPv6 provides a networks on the path to or from it is reduced.
mechanism, known as "dynamic home agent address discovery", that
allows a mobile node to dynamically discover the IP address of a
home agent on its home link with which it may register its (primary)
care-of address while away from home. The mobile node sends an ICMP
"Home Agent Address Discovery Request" message to the "Mobile IPv6
Home-Agents" anycast address for its own home subnet prefix [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 When routing packets directly to the mobile node, the correspondent
address, it is desirable for packets arriving at the previous care-of node sets the Destination Address in the IPv6 header to the care-of
address to still reach the mobile node. The mobile node may still address of the mobile node. A new type of IPv6 routing header (see
accept packets at the previous address, if it is still attached to Section 6.4) is also added to the packet to carry the desired home
the previous link as well as the new one. This is discussed in address. Similarly, the mobile node sets the Source Address in
Section 11.4.3. If the mobile node is no longer attached to the the packet's IPv6 header to its current care-of addresses. The
previous link, procedures described in Section 11.6.6 may be used to mobile node adds a new IPv6 "Home Address" destination option (see
establish temporary tunneling from the previous link. Section 6.3) to carry its home address. The inclusion of home
addresses in these packets makes the use of the care-of address
transparent above the network layer (e.g., at the transport layer).
4.2. New IPv6 Protocols Mobile IPv6 also provides support for multiple home agents, and the
reconfiguration of the home network. In these cases, the mobile
node may not know the IP address of its own home agent, and even
the home subnet prefixes may change over time. A mechanism, known
as "dynamic home agent address discovery" allows a mobile node to
dynamically discover the IP address of a home agent on its home link,
even when the mobile node is away from home. Mobile nodes can also
learn new information about home subnet prefixes through the "prefix
discovery" mechanism. These mechanisms are described in Sections 6.5
through 6.8.
4.2. New IPv6 Protocol
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
(see Section 6.1). This Header is used to carry the following (see Section 6.1). This Header is used to carry the following
messages: messages:
Home Test Init Home Test Init
Home Test Home Test
Care-of Test Init Care-of Test Init
Care-of Test 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.
These four messages are used to initiate the return routability The format of the messages are defined in Sections 6.1.3
procedure from the mobile node to a correspondent node. This through 6.1.6.
ensures authorization of subsequent Binding Updates, as
described in Section 5.2.5. The format of the messages are
defined in Sections 6.1.3 through 6.1.6.
Binding Update Binding Update
A Binding Update is used by a mobile node to notify a
A Binding Update message is used by a mobile node to notify correspondent node or the mobile node's home agent of its
a correspondent node or the mobile node's home agent of its current binding. The Binding Update sent to the mobile
current binding. The Binding Update sent to the mobile node's node's home agent to register its primary care-of address is
home agent to register its primary care-of address is marked as marked as a "home registration". The Binding Update message
a "home registration". The Binding Update message is described is described in detail in Section 6.1.7.
in detail in Section 6.1.7.
Binding Acknowledgement Binding Acknowledgement
A Binding Acknowledgement is used to acknowledge receipt of
A Binding Acknowledgement message is used to acknowledge a Binding Update, if an acknowledgement was requested in the
receipt of a Binding Update, if an acknowledgement was Binding Update. The Binding Acknowledgement is described in
requested in the Binding Update. The Binding Acknowledgement detail in Section 6.1.8.
message is described in detail in Section 6.1.8.
Binding Refresh Request Binding Refresh Request
A Binding Refresh Request is used to request a mobile node
A Binding Refresh Request message is used to request a mobile to re-establish its binding with the correspondent node.
node to re-establish its binding with the correspondent node. This message is typically used when the cached binding
This message is typically used when the cached binding is in is in active use but the binding's lifetime is close to
active use but the binding's lifetime is close to expiration. expiration. The correspondent node may use, for instance,
The correspondent node may use, for instance, recent traffic recent traffic and open transport layer connections as an
and open transport layer connections as an indication of active indication of active use. The Binding Refresh Request is
use. The Binding Refresh Request message is described in described in detail in Section 6.1.2.
detail in Section 6.1.2.
Binding Error Binding Error
The Binding Error 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.
The Binding Error message is used by the correspondent node to 4.3. New IPv6 Destination Option
signal an error related to mobility, such as an inappropriate
attempt to use the Home Address destination option without
an existing binding. This message is described in detail in
Section 6.1.9.
4.3. New IPv6 Destination Options
Mobile IPv6 defines a new IPv6 destination option, the Home Mobile IPv6 defines a new IPv6 destination option, the Home
Address destination option. This option is described in detail in Address destination option. This option is described in detail in
Section 6.3. Section 6.3.
4.4. New IPv6 ICMP Messages 4.4. New IPv6 ICMP Messages
Mobile IPv6 also introduces four new ICMP message types, two for use Mobile IPv6 also introduces four new ICMP message types, two for use
in the dynamic home agent address discovery mechanism, and two for in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in renumbering and mobile configuration mechanisms. As described in
general in Section 4.1, the following two new ICMP message types are Sections 10.5 and 11.4.1, the following two new ICMP message types
used for home agent address discovery: are used for home agent address discovery:
- Home Agent Address Discovery Request, described in Section 6.5. - Home Agent Address Discovery Request, described in Section 6.5.
- Home Agent Address Discovery Reply, described in Section 6.6. - Home Agent Address Discovery Reply, described in Section 6.6.
The next two message types are used for network renumbering The next two message types are used for network renumbering
and address configuration on the mobile node, as described in and address configuration on the mobile node, as described in
Section 10.9.1: Section 10.6:
- Mobile Prefix Solicitation, described in Section 6.7. - Mobile Prefix Solicitation, described in Section 6.7.
- Mobile Prefix Advertisement, described in Section Section 10.9.3. - Mobile Prefix Advertisement, described in Section 6.8.
4.5. Conceptual Data Structures 4.5. Conceptual Data Structure Terminology
This document describes the Mobile IPv6 protocol in terms of the This document describes the Mobile IPv6 protocol in terms of the
following three conceptual data structures: following conceptual data structures:
Binding Cache Binding Cache
A cache, maintained by each IPv6 node, of bindings for other A cache of bindings for other nodes. This cache is maintained
nodes. A separate Binding Cache is maintained by each IPv6 by home agents and correspondent nodes. The cache contains
node for each of its IPv6 addresses. When sending a packet, both "correspondent registration" entries (see Section 9.1) and
the Binding Cache is searched before the Neighbor Discovery "home registration" entries (see Section 10.1).
conceptual Destination Cache [12].
The Binding Cache for any one of a node's IPv6 addresses may
contain at most one entry for each mobile node home address.
The contents of all of a node's Binding Cache entries are
cleared when it reboots.
Binding Cache entries are marked either as "home registration"
entries or "correspondent registration" entries. Home
registration entries are deleted when its binding lifetime
expires, while other entries may be replaced at any time
through a local cache replacement policy.
Binding Update List Binding Update List
A list, maintained by each mobile node, recording information This list is maintained by each mobile node. The list has an
for each Binding Update sent by this mobile node, for which the item for every binding that the mobile node has or is trying
Lifetime sent in that Binding Update has not yet expired. The to establish with a specific other node. Both correspondent
Binding Update List includes all bindings sent by the mobile and home registrations are included in this list. Entries from
node: those to correspondent nodes, those to the mobile node's the list are deleted as the Lifetime sent in the Binding Update
home agent, and those to a home agent on the link on which the expires. See Section 11.1.
mobile node's previous care-of address is located.
Home Agents List Home Agents List
A list, maintained by each home agent and each mobile node, Home agents need to know which other home agents are on the
recording information about each home agent from which this same link. This information is stored in the Home Agents List,
node has recently received a Router Advertisement in which the as described in more detail in Section 10.1. The list is used
Home Agent (H) bit is set. This list is similar to the Default for informing mobile nodes during dynamic home agent address
Router List conceptual data structure maintained by each host discovery.
for Neighbor Discovery [12].
Each home agent maintains a separate Home Agents List for each 4.6. Site-Local Addressability
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 Mobile nodes are free to move from site to site, but the use of
mechanism. Each mobile node, while away from home, also site-local addresses must be carefully managed. When a mobile node
maintains a Home Agents List, to enable it to notify a home or home agent address is site-local, then packets that use those
agent on its previous link when it moves to a new link. address need to stay within the site. The mobile node SHOULD use
such addresses only when it somehow has a guarantee - for instance,
by configuration - that it is safe to do so. Thus, a mobile node MAY
use a site-local home address for roaming within a site, but not for
roaming to another site. This is true even though the mobile node
may be able to obtain a 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 mobile node might
move to a different site.
Operations affecting multi-sited IPv6 nodes are not completely
understood, especially when mobility management is involved. For
this reason, home agents SHOULD NOT be multi-sited. Similarly,
a mobile node that uses site-local home, care-of, or home agent
addresses SHOULD NOT be multi-sited.
5. Overview of Mobile IPv6 Security 5. Overview of Mobile IPv6 Security
This specification provides a number of security features. These This specification provides a number of security features. These
include the protection of Binding Updates both to home agents and include the protection of Binding Updates both to home agents and
correspondent nodes, and the protection of tunnels, home address correspondent nodes, and the protection of tunnels, home address
information, and routing instructions in data packets. information, and routing instructions in data packets.
5.1. Binding Updates to Home Agents Binding Updates are protected by the use of IPsec extension headers,
or by the use of the Binding Authorization Data option. This option
employs a binding management key, Kbm, which can be established
through the return routability procedure.
Signaling between the mobile node and the home agent requires message 5.1. Binding Updates to Home Agents
integrity, correct ordering and replay protection.
The mobile node and the home agent must have an security association The mobile node and the home agent must have a security association
to protect this signaling. Authentication Header (AH) or to protect this signaling. Authentication Header (AH) or
Encapsulating Security Payload (ESP) can be used for integrity Encapsulating Security Payload (ESP) MUST be used. For ESP, a
protection. For ESP we require that a non-null authentication non-null authentication algorithm MUST be applied.
algorithm is 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 In order to protect messages exchanged between the mobile node and
the home agent with IPsec, appropriate security policy database the home agent with IPsec, appropriate security policy database
entries must be created. We need to avoid the possibility that a entries must be created. A mobile node must be prevented from
mobile node could use its security association to send a Binding using its security association to send a Binding Update on behalf
Update on behalf of another mobile node using the same home agent. of another mobile node using the same home agent. This MUST be
In order to do this, the security policy database entries MUST achieved by checking that the given home address has been used with
unequivocally identify a single SA for any given home address and the right security association. Such a check can be provided in
home agent. In order for the home address of the mobile node to be IPsec processing, by having the security policy database entries
visible when the policy check is made, the mobile node MUST use the unequivocally identify a single security association for any given
Home Address destination option in Binding Updates sent to the home home address and home agent. The check may also be provided as
agent. a part of Mobile IPv6 processing, if information about the used
security association is available in there. In any case, it is
necessary that the home address of the mobile node is visible in
the Binding Updates and Acknowledgements. The home address is used
in these packets as a source or destination, or in the Home Address
Destination option or the type 2 routing header.
As with all IPsec security associations in 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 5.2. Binding Updates to Correspondent Nodes
Binding Updates to correspondent nodes can be protected by using data Binding Updates to correspondent nodes can be protected by using
exchanged during the return routability procedure. We will first a binding management key, Kbm. Kbm may be established using data
discuss a number of preliminary concepts such as node keys, nonces, exchanged during the return routability procedure. The data exchange
and cookies and the cryptographic functions used. Section 5.2.5 is accomplished by use of node keys, nonces, cookies, tokens, and
outlines the basic return routability procedure. Section 5.2.6 shows certain cryptographic functions. Section 5.2.5 outlines the basic
how the results of this procedure are used to authorize a Binding return routability procedure. Section 5.2.6 shows how the results
Update to a correspondent node. Finally, Sections 5.2.7 and 5.2.8 of this procedure are used to authorize a Binding Update to a
discuss some additional issues. correspondent node. Finally, Sections 5.2.7 and 5.2.8 discuss some
additional issues.
5.2.1. Node Keys 5.2.1. Node Keys
Each correspondent node has a secret key, Kcn. The correspondent Each correspondent node has a secret key, Kcn, called the "node key",
node uses this key to verify that the cookies it receives in messages which it uses to produce the keygen tokens sent to the mobile nodes.
are those which it has created itself. This key does not need to be The node key MUST be a random number, 20 octets in length. The node
shared with any other entity. key allows the correspondent node to verify that the keygen tokens
used by the mobile node in authorizing a Binding Update are indeed
A correspondent node can generate a fresh Kcn each time that it boots its own. This key MUST NOT be shared with any other entity.
to avoid the need for secure persistent storage for Kcn. Kcn can be
either a fixed value or regularly updated. Procedures for updating
Kcn are discussed later in Section 5.2.7.
Kcn consists of 20 octets. A correspondent node MAY generate a fresh node key at any time;
this avoid the need for secure persistent key storage. Procedures
for optionally updating the node key are discussed later in
Section 5.2.7.
5.2.2. Nonces 5.2.2. Nonces
Each correspondent node also generates nonces at regular intervals, Each correspondent node also generates nonces at regular
for example every few minutes. The nonces should be generated by intervals. The nonces should be generated by using a random number
using a random number generator that is known to have good randomness generator that is known to have good randomness properties [1].
properties [1]. A correspondent node may use the same Kcn and nonce A correspondent node may use the same Kcn and nonce with all the
with all the mobiles it is in communication with, so that it does not mobiles it is in communication with.
need to generate and store a new nonce when a new mobile contacts it.
Each nonce is identified by a nonce index. Nonce indices are Each nonce is identified by a nonce index. When a new nonce is
16-bit values that are e.g. incremented each time a new nonce is generated, it must be associated with a new nonce index; this may be
created. The index value is communicated in the protocol, so that if done, for example, by incrementing the value of the previous nonce
a nonce is replaced by new nonce during the run of a protocol, the index, if the nonce index is used as an array pointer into a linear
correspondent node can distinguish messages that should be checked array of nonces. However, there is no requirement that nonces be
against the old nonce from messages that should be checked against stored that way, or that the values of subsequent nonce indices
the new nonce. Strictly speaking, indices are not necessary in the have any particular relationship to each other. The index value
authentication, but allow the correspondent node to efficiently find is communicated in the protocol, so that if a nonce is replaced by
the nonce value that it used in creating a cookie. 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 keygen token.
Correspondent nodes keep both the current nonce and a small set of Correspondent nodes keep both the current nonce and a small set of
old nonces. Older values can be discarded, and messages using them valid previous nonces whose lifetime has not yet expired. Expired
will be rejected as replays. values MUST be discarded, and messages using stale or unknown indices
will be rejected.
The specific nonce index values can not be used by mobile nodes to The specific nonce index values can not be used by mobile nodes to
determine the validity of the nonce. Expected validity times for determine the validity of the nonce. Expected validity times for
the nonces values and the procedures for updating them are discussed the nonces values and the procedures for updating them are discussed
later in Section 5.2.7. later in Section 5.2.7.
Nonce is an octet string of any length. The recommended length is A nonce is an octet string of any length. The recommended length is
64-bit. 64 bits.
5.2.3. Cookies
Three different types of cookies are used in the protocol: 5.2.3. Cookies and Tokens
- Two mobile cookies are sent to the correspondent node from the The return routability address test procedure uses cookies and keygen
mobile node, and later returned to the mobile node. The mobile tokens as opaque values within the test init and test messages,
cookies are produced randomly, and used to verify that the respectively.
response matches the request, and to ensure that parties who have
not seen the request can not spoof responses. One of the mobile
cookies is sent in the HoTI message, and returned in the HoT
message. This is called the HoT cookie. The other mobile cookie
is sent in the CoTI message, and returned in the CoT message.
This is called the CoT cookie.
- A home cookie sent to the mobile node from the correspondent node - The "home init cookie" and "care-of init cookie" are 64 bit
via the home agent. Home cookies are produced cryptographically values sent to the correspondent node from the mobile node, and
from nonces. later returned to the mobile node. The home init cookie is sent
in the Home Test Init message, and returned in the Home Test
message. The care-of init cookie is sent in the Care-of Test
Init message, and returned in the Care-of Test message.
- A care-of cookie is similar to a home cookie, but sent directly - The "home keygen token" and "care-of keygen token" are 64-bit
to the mobile node from the correspondent node. values sent by the correspondent node to the mobile node via the
home agent (via the Home Test message) and the care-of address
(by the Care-of Test message), respectively.
A newly generated random number is typically used for each request The mobile node should use a newly generated random number for each
that carries a mobile cookie. request that carries a 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
cookies also serve to ensure that parties who have not seen the
request cannot spoof responses.
Home and care-of cookies are produced by the correspondent node, and Home and care-of keygen tokens are produced by the correspondent node
they are based on the currently active secret keys and nonces of the based on its currently active secret key (Kcn) and nonces, as well as
correspondent node as well as the home or care-of address. Such a the home or care-of address (respectively). A keygen token is valid
cookie is valid as long as both the secret key and the nonce used to as long as both the secret key (Kcn) and the nonce used to create it
create it are valid. are valid.
5.2.4. Cryptographic Functions 5.2.4. Cryptographic Functions
MAC_K(m) denotes a Message Authentication Code computed on message In this specification, the function used to compute hash values is
m with key K. In this specification, HMAC SHA1 function [26, 19] is SHA1 [19]. Message Authentication Codes (MACs) are computed using
used to compute these codes. HMAC_SHA1 [25, 19]. HMAC_SHA1(K,m) denotes such a MAC computed on
message m with key K.
Hash(m) denotes a hash of message m. In this specification, the
function used to compute the hash is SHA1 [19].
5.2.5. Return Routability Procedure 5.2.5. Return Routability Procedure
The return routability signaling happens as follows: The Return Routability Procedure enables the correspondent node to
obtain some reasonable assurance that the mobile node is in fact
addressable at its claimed care-of address as well as at its home
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 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, and the Home and Care-of Test messages can be returned quickly,
perhaps nearly simultaneously. These four messages form the return
routability procedure.
Home Test Init
A mobile node sends a Home Test Init message to the
correspondent node to acquire the home keygen token. The
contents of the message can be summarized as follows:
Source Address = home address
Mobile node Home agent Correspondent node Mobile node Home agent Correspondent node
| | | |
| 1a. | | Home Test Init (HoTI) | |
| Home Test Init(HoTI) |
| Src = home address, |
| Dst = correspondent | |
| Parameters: | |
| - HoT cookie | |
|------------------------->|------------------------->| |------------------------->|------------------------->|
| | | | | |
| |
| 1b. |
| Care-of Test Init(CoTI) | | Care-of Test Init(CoTI) |
| Src = care-of address |
| Dst = correspondent |
| Parameters: |
| - CoT cookie |
|---------------------------------------------------->| |---------------------------------------------------->|
| | | |
| 2a. | | | Home Test (HoT) |
| Home Test (HoT) |
| Src = correspondent, |
| Dst = home address |
| Parameters: |
| - HoT cookie |
| | - home cookie |
| | - home nonce index |
|<-------------------------|<-------------------------| |<-------------------------|<-------------------------|
| | | | | |
| |
| 2b. |
| Care-of Test(CoT) | | Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - CoT cookie |
| - care-of cookie |
| - care-of nonce index |
|<----------------------------------------------------| |<----------------------------------------------------|
| | | |
The Home and Care-of Test Init messages are sent at the same Figure 1: Message Flow for Return Routability Address Testing
time. The correspondent node returns the Home and Care-of Test
messages as quickly as possible, and perhaps nearly simultaneously,
requiring very little processing. Those 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. The contents of
the message can be summarized as follows:
Src = home address Destination Address = correspondent
Dst = correspondent
Parameters: Parameters:
- HoT cookie - home init cookie
This message conveys the mobile node's home address to the The Home Test Init message conveys the mobile node's home
correspondent node. The mobile node also sends along a 64 bit address to the correspondent node. The mobile node also sends
HoT cookie that the correspondent node must return later. The along a home init cookie that the correspondent node must
Home Test Init message is reverse tunneled through the home return later. The Home Test Init message is reverse tunneled
agent. through the home agent. The mobile node remembers these cookie
values to obtain some assurance that its protocol messages are
being processed by the desired correspondent node.
1b. Care-of Test Init Care-of Test Init
The mobile node sends a Care-of Test Init message to the The mobile node sends a Care-of Test Init message to the
correspondent node to acquire the care-of cookie. The contents correspondent node to acquire the care-of keygen token. The
of this message can be summarized as follows: contents of this message can be summarized as follows:
Src = care-of address Source Address = care-of address
Dst = correspondent Destination Address = correspondent
Parameters: Parameters:
- CoT cookie - care-of init cookie
The second message conveys the mobile node's care-of address The Care-of Test Init message conveys the mobile node's care-of
to the correspondent node. The mobile node also sends along address to the correspondent node. The mobile node also sends
a 64 bit CoT cookie that the correspondent node must return along a care-of init cookie that the correspondent node must
later. The Care-of Test Init message is sent directly to the return later. The Care-of Test Init message is sent directly
correspondent node. to the correspondent node.
2a. Home Test Home Test
This message is sent in response to a Home Test Init message. The Home Test message is sent in response to a Home Test Init
The contents of the message are: message. The contents of the message are:
Src = correspondent Source Address = correspondent
Dst = home address Destination Address = home address
Parameters: Parameters:
- HoT cookie - home init cookie
- home cookie - home keygen token
- home nonce index - home nonce index
When the correspondent node receives the Home Test Init When the correspondent node receives the Home Test Init
message, it generates a 64-bit home cookie as follows: message, it generates a home keygen token as follows:
home cookie = First64(MAC_Kcn(home address | nonce)) home keygen token :=
First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
The home cookie is formed from the first 64 bits of the MAC where | denotes concatenation. The final "0" inside the
result. The message is sent to the mobile node via the home HMAC_SHA1 function is a single zero octet, used to distinguish
agent; the protocol relies on the assumption that the route home and care-of cookies from each other.
between the home agent and the mobile node is secure. The home
cookie also acts as a challenge to test that the mobile can
receive messages sent to its home address. Kcn is used in the
production of home cookie in order to allow the correspondent
node to verify that it generated the home and care-of cookies,
without forcing the correspondent node to remember a list of
all cookies it has handed out.
The HoT cookie from the mobile node is returned in the Home The home keygen token is formed from the first 64 bits of
Test message, to ensure that the message comes from a node on the MAC. The home keygen token tests that the mobile can
the route between the home agent and the correspondent node. receive messages sent to its home address. Kcn is used in
the production of home keygen token in order to allow the
correspondent node to verify that it generated the home and
care-of nonces, without forcing the correspondent node to
remember a list of all tokens it has handed out.
The Home Test message is sent to the mobile node via the home
network, where it is presumed that the home agent will tunnel
the message to the mobile node. This means that the mobile
node needs to already have sent a Binding Update to the home
agent, so that the home 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 The home nonce index is delivered to the mobile node to later
allow the correspondent node to efficiently find the nonce allow the correspondent node to efficiently find the nonce
value that it used in creating the home cookie. value that it used in creating the home keygen token.
2b. Care-of Test Care-of Test
This message is sent in response to a Care-of Test Init This message is sent in response to a Care-of Test Init
message. The contents of the message are: message. The contents of the message are:
Src = correspondent Source Address = correspondent
Dst = care-of address Destination Address = care-of address
Parameters: Parameters:
- CoT cookie - care-of init cookie
- care-of cookie - care-of keygen token
- care-of nonce index - care-of nonce index
The correspondent node also sends a challenge to the mobile's The correspondent node sends a challenge also to the mobile's
care-of address. When the correspondent node receives the care-of address. When the correspondent node receives the
Care-of Test Init message, it generates a 64-bit care-of cookie Care-of Test Init message, it generates a care-of keygen token
as follows: as follows:
care-of cookie = First64(MAC_Kcn(care-of address | nonce)) care-of keygen token :=
First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))
The cookie is formed from the first 64 bits of the MAC result. Here, the final "1" inside the HMAC_SHA1 function is a single
The cookie is sent directly to the mobile node at its care-of octet containing the hex value 0x01, and is used to distinguish
address. The CoT cookie from the from CoTI message is returne home and care-of cookies from each other. The keygen token is
to ensure that the message comes from a node on the route to formed from the first 64 bits of the MAC, and sent directly
the correspondent node. to the mobile node at its care-of address. The care-of init
cookie from the from Care-of Test Init message is 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 The care-of nonce index is provided to identify the nonce used
for the care-of cookie. The home and care-of nonce indices are for the care-of keygen token. The home and care-of nonce
often the same in the Home and Care-of Test messages. indices MAY be the same, or different, in the Home and Care-of
Test messages.
When the mobile node has received both the Home and Care-of Test When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a result, messages, the return routability procedure is complete. As a result
the mobile node has the means to prove its authority to send a of the procedure, the mobile node has the data it needs to send a
Binding Update to the correspondent node. The mobile node hashes Binding Update to the correspondent node. The mobile node hashes the
together the challenges to form a 16 octet session key Kbu: tokens together to form a 20 octet binding key Kbm:
Kbu = Hash(home cookie | care-of cookie) Kbm = SHA1 (home keygen token | care-of 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 Note that the correspondent node does not create any state specific
to the mobile node, until it receives the Binding Update from that to the mobile node, until it receives the Binding Update from that
mobile node. The correspondent node is unaware of the session mobile node. The correspondent node does not maintain the value for
key Kbu, though it can recreate Kbu if it is presented the right the binding management key Kbm; it creates Kbm when given the nonce
addresses and nonce indices. indices and the mobile node's addresses.
5.2.6. Applying Return Routability for Correspondent Bindings 5.2.6. Authorizing Binding Management Messages
After the above procedure has completed, the mobile node can supply a After the mobile node has created the binding management key (Kbm),
Binding Update to the correspondent node. An overview of the binding it can supply a verifiable Binding Update to the correspondent
procedure is shown below. node. This section provides an overview of this binding procedure.
Figure 2 shows the message flow. The Binding Update creates a
binding, and the Binding Acknowledgement is optional.
Mobile Node Correspondent node Mobile node Correspondent node
| | | |
| 1. Binding Update | | Binding Update (BU) |
| Src = care-of address, Dst = correspondent | |---------------------------------------------->|
| Parameters: | | (MAC, seq#, nonce indices, care-of address) |
| - home address |
| - a MAC |
| - home nonce index |
| - care-of nonce index |
| - sequence number |
| - ... |
|---------------------------------------------------->|
| | | |
| 2. Binding Acknowledgement |
| (if requested) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - sequence number |
| - a MAC |
| - ... |
|<----------------------------------------------------|
| | | |
| Binding Acknowledgement (BA) (if sent) |
|<----------------------------------------------|
| (MAC, seq#, status) |
Message 1 actually creates a binding, and message 2 is optional. The Figure 2: Message Flow for Establishing Binding at
correspondent binding procedure consists of the return routability the Correspondent Node
procedure followed by the messages 1 and 2.
1. Binding Update Binding Update
The mobile node uses the created session key Kbu to authorize To authorize a Binding Update, the mobile node creates a
the Binding Update. The contents of the message are as binding management key Kbm from the keygen tokens as described
follows: in the previous section. The contents of the Binding Update
include the following:
Src = care-of address Source Address = care-of address
Dst = correspondent Destination Address = correspondent
Parameters: Parameters:
- home address - home address (within the Home Address destination
- MAC_Kbu(care-of address | correspondent node address | BU) option or in the Source Address)
- home nonce index - sequence number (within the Binding Update message
- care-of nonce index header)
- sequence number - home nonce index (within the Nonce Indices option)
- ... - care-of nonce index (within the Nonce Indices option)
- HMAC_SHA1 (Kbm, (care-of address | CN address | BU))
The Binding Update message contains Nonce Index option, so that The Binding Update may contain a Nonce Indices option,
the correspondent node knows which home and care-of nonces to indicating to the correspondent node which home and care-of
use to recompute the session key. "BU" is the content of the nonces to use to recompute Kbm, the binding management key.
Binding Update message, excluding (1) the IP header, (2) any
extension headers between the IP header the Mobility Header, The MAC is computed as described in Section 6.2.6, using the
and (3) the Authenticator field inside the Binding Update. The correspondent node's address as the destination address and the
first 96 bits from the MAC result are used as the Authenticator Binding Update message itself as the Mobility Header Data.
field. A sequence number will be used to match an eventual
acknowledgement with this message. The sequence numbers
start from a random value. The three dots represent all the
remaining (not security related) information in the message.
Once the correspondent node has verified the MAC, it can create Once the correspondent node has verified the MAC, it can create
a binding cache entry for the mobile. a Binding Cache entry for the mobile.
2. Binding Acknowledgement Binding Acknowledgement
The Binding Update is optionally acknowledged by the The Binding Update is optionally acknowledged by the
correspondent node. The contents of the message are as correspondent node. The contents of the message are as
follows: follows:
Src = correspondent Source Address = correspondent
Dst = care-of address Destination Address = care-of address
Parameters: Parameters:
- sequence number - sequence number (within the Binding Update message
- MAC_Kbu(care-of address | correspondent node address | BA) header)
- ... - HMAC_SHA1 (Kbm, (care-of address | CN address | BA))
The Binding Acknowledgement contains the same sequence number The Binding Acknowledgement contains the same sequence number
as the Binding Update did. "BA" is the content of the Binding as the Binding Update. The MAC is computed as described in
Acknowledgement message, excluding (1) the IP header, (2) Section 6.2.6, using the correspondent node's address as the
any extension headers between the IP header the Mobility destination address and the message itself as the Mobility
Header, and (3) the Authenticator field inside the Binding Header Data.
Acknowledgement. The first 96 bits from the MAC result are
used as the Authenticator field. The three dots represent
all the remaining (not security related) information in the
message.
Bindings established with correspondent nodes using the return Bindings established with correspondent nodes using keys created
routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE seconds. by way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFE seconds (see Section 12).
The value in the Source Address field in the IPv6 header carrying The value in the Source Address field in the IPv6 header carrying the
the Binding Update message is normally also the care-of address Binding Update is normally also the care-of address which is used in
which is used in the binding. However, a different care-of address the binding. However, a different care-of address MAY be specified
MAY be specified by including an Alternate Care-of Address mobility by including an Alternate Care-of Address mobility option in the
option in the Binding Update message (see Section 6.2.5). When such Binding Update (see Section 6.2.4). When such a message is sent to
message is sent to the correspondent node and the return routability the correspondent node and the return routability procedure is used
procedure is used as the authorization method, the Care-of Test Init as the authorization method, the Care-of Test Init and Care-of Test
and Care-of Test messages MUST have been performed for the address in messages MUST have been performed for the address in the Alternate
the Alternate Care-of Address option (not the Source Address). The Care-of Address option (not the Source Address). The nonce indices
nonce indices MAC value MUST be based on information gained in this and MAC value MUST be based on information gained in this test.
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 5.2.7. Updating Node Keys and Nonces
An update of Kcn can be done at the same time as an update of a Correspondent nodes generate nonces at regular intervals. It
nonce, so that the nonce index identifies both the nonce and the key. is recommended to keep each nonce (identified by a nonce index)
acceptable for at least MAX_TOKEN_LIFE seconds (see Section 12)
after it has been first used in constructing a return routability
message response. However, the correspondent node MUST NOT accept
nonces beyond MAX_NONCE_LIFE seconds (see Section 12) after the first
use. As the difference between these two constants is 30 seconds,
a convenient way to enforce the above lifetimes is to generate a
new nonce every 30 seconds. The node can then 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
node may also attempt to generate new nonces on demand, or only if
the old nonces have been used. This is possible, as long as 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 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 Old Kcn values have to be therefore remembered as long as old nonce
values. values.
Before sending a Binding Update, the mobile node has to wait for both Given that the tokens are normally expected to be usable for
the Home and Care-of Cookies to arrive. Due to resource limitations, MAX_TOKEN_LIFE seconds, the mobile node MAY use them beyond a single
rapid deletion of bindings, or reboots it can not be guaranteed that run of the return routability procedure until MAX_TOKEN_LIFE expires.
the cookies are still fresh and acceptable when the correspondent After this the mobile node SHOULD NOT use the tokens. A fast moving
node uses them in the processing of the Binding Update. If the mobile node may reuse a recent home keygen token from a correspondent
cookies have become too old, the correspondent node replies with node when moving to a new location, and just acquire a new care-of
an an error code in the Binding Acknowledgement. The mobile node keygen token to show routability in the new location.
can then retry the return routability procedure. However, it is
recommended that correspondent nodes try to keep these cookies
acceptable as long as possible and SHOULD NOT accept them beyond
MAX_COOKIE_LIFE seconds.
Given that the cookies are normally expected to be usable for While this does not save the number of round-trips due to the
some time, the mobile node MAY use them beyond a single run of the simultaneous processing of home and care-of return routability tests,
return routability procedure. A fast moving mobile node may reuse there are fewer messages being exchanged, and a potentially long
a recent Home Cookie from a correspondent node when moving to a new round-trip through the home agent is avoided. Consequently, this
location, and just acquire a new Care-of Cookie to show routability
in the new location. While this does not save roundtrips due to the
parallel nature of the home and care-of return routability tests, the
roundtrip through the home agent may be longer, and consequently this
optimization is often useful. A mobile node that has multiple home optimization is often useful. A mobile node that has multiple home
addresses, may also use the same Care-of Cookie for Binding Updates addresses, may also use the same care-of keygen token for Binding
concerning all of these addresses. Updates concerning all of these addresses.
5.2.8. Preventing Replay Attacks 5.2.8. Preventing Replay Attacks
The return routability procedure also protects the participants The return routability procedure also protects the participants
against replayed Binding Updates through the use of the sequence against replayed Binding Updates through the use of the sequence
number and a MAC. Care must be taken when removing bindings at number and a MAC. Care must be taken when removing bindings at
the correspondent node, however. Correspondent nodes must retain the correspondent node, however. Correspondent nodes must retain
bindings and the associated sequence number information at least as bindings and the associated sequence number information at least as
long as the nonces used in the authorization of the binding are still long as the nonces used in the authorization of the binding are still
valid. The correspondent node can, for instance, change the nonce valid. The correspondent node can, for instance, change the nonce
often enough to ensure that the nonces used when removed entries often enough to ensure that the nonces used when removed entries
were created are no longer valid. If many such deletions occur were created are no longer valid. If many such deletions occur
the correspondent node can batch them together to avoid having to the correspondent node can batch them together to avoid having to
increment the nonce index too often. increment the nonce index too often.
5.3. Payload Packets 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 Payload packets exchanged with mobile nodes can be protected in the
usual manner, in the same way as stationary hosts can protect them. usual manner, in the same way as stationary hosts can protect them.
However, Mobile IPv6 introduces the Home Address destination option, However, Mobile IPv6 introduces the Home Address destination option,
a Routing Header, and tunneling headers in the payload packets. In a routing header, and tunneling headers in the payload packets. In
the following we define the security measures taken to protect these, the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties. and to prevent their use in attacks against other parties.
This specification limits the use of the Home Address destination This specification limits the use of the Home Address destination
option to the situation where the correspondent node already has a option to the situation where the correspondent node already has a
binding cache entry for the given home address. This avoids the use 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 of the Home Address option in attacks described in Section 14.1.
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. Mobile IPv6 uses a Mobile IPv6 specific type of a routing header.
This type provides the necessary functionality but does not open This type provides the necessary functionality but does not open
vulnerabilities discussed in Section 14.1. vulnerabilities discussed in Section 14.1.
Tunnels between the mobile node and the home agent are protected by Tunnels between the mobile node and the home agent are protected by
ensuring proper use of source addresses, and optional cryptographic ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node verifies that the outer IP address protection. The mobile node verifies that the outer IP address
corresponds to its home agent. The home agent verifies that the corresponds to its home agent. The home agent verifies that the
outer IP address corresponds to the current location of the mobile outer IP address corresponds to the current location of the mobile
node (Binding Updates sent to the home agents are secure). These node (Binding Updates sent to the home agents are secure). These
measures protect the tunnels against vulnerabilities discussed in measures protect the tunnels against vulnerabilities discussed in
Section 14.1. Section 14.1.
For tunneled traffic to and from the mobile node, encapsulating For traffic tunneled via the home agent, additional IPsec AH or ESP
the traffic inside IPsec AH or ESP offers an optional mechanism to encapsulation MAY be supported and used.
protect the integrity and confidentiality of the traffic against
on-path attackers.
6. New IPv6 Protocols, Message Types, and Destination Option 6. New IPv6 Protocol, Message Types, and Destination Option
6.1. Mobility Header 6.1. Mobility Header
The Mobility Header is used by mobile nodes, correspondent nodes, and The Mobility Header is an extension header used by mobile nodes,
home agents in all messaging related to the creation and management correspondent nodes, and home agents in all messaging related to
of bindings. Sections 6.1.2 through 6.1.9 describe the message types the creation and management of bindings. The subsections within
used in this protocol. These sections also define which addresses to this section describe the message types that may be sent using the
use in the IPv6 header in these messages. Mobility Header.
6.1.1. Format 6.1.1. Format
The Mobility Header is identified by a Next Header value of TBD in The Mobility Header is identified by a Next Header value of TBD <To
the immediately preceding header, and has the following format: be assigned by IANA> in the immediately preceding header, and has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | | Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. . . .
. Message Data . . Message Data .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto Payload Proto
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the following the Mobility Header. Uses the same values as the
IPv6 Next Header field [11]. IPv6 Next Header field [11].
This field is intended to be used by a future specification This field is intended to be used by a future specification
of piggybacking binding messages on payload packets (see of piggybacking binding messages on payload packets (see
Section C.1). Section B.1).
Implementations conforming to this specification SHOULD set the Implementations conforming to this specification SHOULD set the
payload protocol type to NO_NXTHDR (59 decimal). payload protocol type to IPPROTO_NONE (59 decimal).
Header Len Header Len
8-bit unsigned integer. Length of the Mobility Header in units 8-bit unsigned integer, representing the length of the Mobility
of 8 octets, including the the Payload Proto, MH Type, Header Header in units of 8 octets, excluding the first 8 octets.
Len, Checksum, and Message Data fields.
We require that the Mobility Header length is a multiple of 8 The length of the Mobility Header MUST be a multiple of 8
octets. octets.
MH Type MH Type
16-bit selector. Identifies the particular mobility message 8-bit selector. Identifies the particular mobility message
in question. Current values are specified in Sections 6.1.2 in question. Current values are specified in Sections 6.1.2
to 6.1.9. An unrecognized MH Type field causes an error to be to 6.1.9. An unrecognized MH Type field causes an error
sent to the source. indication to be sent.
Reserved
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Checksum Checksum
16-bit unsigned integer. This field contains the checksum of 16-bit unsigned integer. This field contains the checksum of
the Mobility Header. The checksum is calculated from the octet the Mobility Header. The checksum is calculated from the octet
string consisting of a "pseudo-header" followed by the entire string consisting of a "pseudo-header" followed by the entire
Mobility Header starting with the Payload Proto field. The Mobility Header starting with the Payload Proto field. The
checksum is the 16-bit one's complement of the one's complement checksum is the 16-bit one's complement of the one's complement
sum of this string. sum of this string.
The pseudo-header contains IPv6 header fields, as specified The pseudo-header contains IPv6 header fields, as specified
in Section 8.1 of [11]. The Next Header value used in the in Section 8.1 of [11]. The Next Header value used in the
pseudo-header is TBD. The addresses used in the pseudo-header pseudo-header is TBD <To be assigned by IANA>. The addresses
are the addresses that appear in the Source and Destination used in the pseudo-header are the addresses that appear in
Address fields in the IPv6 packet carrying the Mobility Header. 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. For computing the checksum, the checksum field is set to zero.
Message Data Message Data
A variable length field containing the data specific to the A variable length field containing the data specific to the
indicated Mobility Header type. indicated Mobility Header type.
Mobile IPv6 also defines a number of "mobility options" for use Mobile IPv6 also defines a number of "mobility options" for use
within these messages; if included, any options MUST appear after within these messages; if included, any options MUST appear after the
the fixed portion of the message data specified in this document. fixed portion of the message data specified in this document. The
The presence of such options will be indicated by the Header Len presence of such options will be indicated by the Header Len field
field within the message. When the Header Len is greater than the within the message. When the Header Len value is greater than the
length required for the message specified here, the remaining octets length required for the message specified here, the remaining octets
are interpreted as mobility options. These options include padding are interpreted as mobility options. These options include padding
options that can be used to ensure that other options are aligned options that can be used to ensure that other options are aligned
properly, and that the total length of the message is divisible by properly, and that the total length of the message is divisible
8. The encoding and format of defined options are described in by 8. The encoding and format of defined options are described in
Section 6.2. Section 6.2.
Alignment requirements for the Mobility Header are the same as for Alignment requirements for the Mobility Header are the same as for
any IPv6 protocol Header. That is, they MUST be aligned on an any IPv6 protocol Header. That is, they MUST be aligned on an
8-octet boundary. 8-octet boundary.
6.1.2. Binding Refresh Request (BRR) Message 6.1.2. Binding Refresh Request Message
The Binding Refresh Request (BRR) message is used to request a The Binding Refresh Request (BRR) message is used to request a
mobile node's binding from the mobile node. It is sent according mobile node's binding from the mobile node. It is sent according to
to the rules in Section 9.4.5. When a mobile node receives a the rules in Section 9.5.5. When a mobile node receives a packet
packet containing a Binding Refresh Request message and there containing a Binding Refresh Request message it processes the message
already exists a Binding Update List entry for the source of the according to the rules in Section 11.7.4.
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
the mobile node SHOULD NOT respond to Binding Refresh Requests from
previously unknown correspondent nodes due to Denial-of-Service
concerns.
The Binding Refresh Request message uses the MH Type value 0. When 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 this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows: Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
skipping to change at page 24, line 25 skipping to change at page 26, line 5
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
16-bit field reserved for future use. The value MUST be 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand. MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Refresh Request message, that need not be present in Binding Refresh Request message, that need not be present in
all Binding Requests sent. This use of mobility options also all Binding Refresh Request messages sent. Mobility options
allows for future extensions to the format of the Binding allow future extensions to the format of the Binding Refresh
Refresh Request message to be defined. The following options Request message to be defined. This specification does not
are valid in a Binding Refresh Request message: define any options valid for the Binding Refresh Request
message.
- Unique Identifier Option
- Binding Authorization option
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Length field will be set to 1. necessary and the Header Len field will be set to 0.
6.1.3. Home Test Init (HoTI) Message 6.1.3. Home Test Init Message
A mobile node uses the Home Test Init (HoTI) message to initiate A mobile node uses the Home Test Init (HoTI) message to initiate the
the return routability procedure and request a home cookie from a return routability procedure and request a home keygen token from a
correspondent node (see Section 11.5.1). The Home Test Init message correspondent node (see Section 11.6.1). The Home Test Init message
uses the MH Type value 1. When this value is indicated in the MH uses the MH Type value 1. When this value is indicated in the MH
Type field, the format of the Message Data field in the Mobility Type field, the format of the Message Data field in the Mobility
Header is as follows: Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ HoT cookie + + Home Init Cookie +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility Options . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
16-bit field reserved for future use. This value MUST be 16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
HoT cookie Home Init Cookie
64-bit field which contains a random value, the HoT cookie. 64-bit field which contains a random value, the home init
cookie.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains Header is an integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST one or more TLV-encoded mobility options. The receiver MUST
ignore and skip any options which it does not understand. This ignore and skip any options which it does not understand. This
specification does not define any options valid for the Home specification does not define any options valid for the Home
Test Init message. Test Init message.
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Length field will be set to 2. necessary and the Header Len field will be set to 1.
This message is sent with the Source Address set to the home This message is tunneled through the home agent when the mobile node
address of the mobile node, and the Destination Address set to the is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel
correspondent node's address. The message is tunneled through the mode between the home agent and the mobile node. This protection
home agent when the mobile node is away from home. Such tunneling is indicated by the IPsec policy data base. The protection of Home
SHOULD employ IPsec ESP in tunnel mode between the home agent and Test Init messages is unrelated to the requirement to protect regular
the mobile node. This protection is indicated by the IPsec policy payload traffic, which MAY use such tunnels as well.
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.
6.1.4. Care-of Test Init (CoTI) Message 6.1.4. Care-of Test Init Message
A mobile node uses the Care-of Test Init (CoTI) message to initiate A mobile node uses the Care-of Test Init (CoTI) message to initiate
the return routability procedure and request a care-of cookie from the return routability procedure and request a care-of keygen token
a correspondent node (see Section 11.5.1). The Care-of Test Init from a correspondent node (see Section 11.6.1). The Care-of Test
message uses the MH Type value 2. When this value is indicated 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 in the MH Type field, the format of the Message Data field in the
Mobility Header is as follows: Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ CoT cookie + + Care-of Init Cookie +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility Options . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
16-bit field reserved for future use. The value MUST be 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
CoT cookie Care-of Init Cookie
64-bit field which contains a random value, the CoT cookie. 64-bit field which contains a random value, the care-of init
cookie.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains Header is an integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST one or more TLV-encoded mobility options. The receiver MUST
ignore and skip any options which it does not understand. This ignore and skip any options which it does not understand. This
specification does not define any options valid for the Care-of specification does not define any options valid for the Care-of
Test Init message. Test Init message.
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Length field will be set to 2. necessary and the Header Len field will be set to 1.
This message is always sent with the Source Address set to the
care-of address of the mobile node, and is sent directly to the
correspondent node. A packet that includes a Care-of Test Init
message MUST NOT include a Home Address destination option between
the Mobility Header and the preceding IPv6 header.
6.1.5. Home Test (HoT) Message 6.1.5. Home Test Message
The Home Test (HoT) message is a response to the HoTI message, The Home Test (HoT) message is a response to the Home Test Init
and is sent from the correspondent node to the mobile node (see message, and is sent from the correspondent node to the mobile node
Section 5.2.5). The Home Test message uses the MH Type value 3. (see Section 5.2.5). The Home Test message uses the MH Type value 3.
When this value is indicated in the MH Type field, the format of the When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows: Message Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | | Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ HoT cookie + + Home Init Cookie +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Home Cookie + + Home Keygen Nonce +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Nonce Index Home Nonce Index
This field will be echoed back by the mobile node to the This field will be echoed back by the mobile node to the
correspondent node in a subsequent binding update. correspondent node in a subsequent Binding Update.
HoT cookie Home Init Cookie
64-bit field which contains the HoT cookie. 64-bit field which contains the home init cookie.
Home Cookie Home Keygen Nonce
This field contains the 64 bit home cookie in the return This field contains the 64 bit home keygen token used in the
routability procedure; it is the first of two cookies which return routability procedure.
are to be processed to form a key which is then used to
authenticate a binding update.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains Header is an integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST one or more TLV-encoded mobility options. The receiver MUST
ignore and skip any options which it does not understand. This ignore and skip any options which it does not understand. This
specification does not define any options valid for the Home specification does not define any options valid for the Home
Test message. Test message.
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Length field will be set to 3. This necessary and the Header Len field will be set to 2.
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.
6.1.6. Care-of Test (CoT) Message 6.1.6. Care-of Test Message
The Care-of Test (CoT) message is a response to the CoTI message, The Care-of Test (CoT) message is a response to the Care-of Test
and is sent from the correspondent node to the mobile node (see Init message, and is sent from the correspondent node to the mobile
Section 11.5.2). The Care-of Test message uses the MH Type value 4. node (see Section 11.6.2). The Care-of Test message uses the MH
When this value is indicated in the MH Type field, the format of the Type value 4. When this value is indicated in the MH Type field,
Message Data field in the Mobility Header is as follows: the format of the Message Data field in the Mobility Header is as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index | | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ CoT cookie + + Care-of Init Cookie +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Care-of Cookie + + Care-of Keygen Nonce +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility Options . . 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 Care-of Nonce Index
This field will be echoed back by the mobile node to the This value will be echoed back by the mobile node to the
correspondent node in a subsequent binding update. correspondent node in a subsequent Binding Update.
CoT cookie Care-of Init Cookie
64-bit field which contains the CoT cookie. 64-bit field which contains the care-of init cookie.
Care-of Cookie Care-of Keygen Nonce
This field contains the 64 bit care-of cookie in the return This field contains the 64 bit care-of keygen token used in the
routability procedure; it is the second of two cookies which return routability procedure.
are to be processed to form a key which is then used to
authenticate a binding update.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains Header is an integer multiple of 8 octets long. Contains
one or more TLV-encoded mobility options. The receiver MUST one or more TLV-encoded mobility options. The receiver MUST
ignore and skip any options which it does not understand. This ignore and skip any options which it does not understand. This
specification does not define any options valid for the Care-of specification does not define any options valid for the Care-of
Test message. Test message.
The CoT message is always sent with the Source Address set to the If no actual options are present in this message, no padding is
address of the correspondent node, and the Destination Address set to necessary and the Header Len field will be set to 2.
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.
6.1.7. Binding Update (BU) Message 6.1.7. Binding Update Message
The Binding Update (BU) message is used by a mobile node to notify 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 other nodes of a new care-of address for itself. Binding Updates are
a Binding Update message is sent with the Source Address set to the sent as described in Section 11.7.1 and 11.7.2.
care-of address of the mobile node and the Destination Address set to
the correspondent node's address.
The Binding Update message uses the MH Type value 5. When this value The Binding Update uses the MH Type value 5. When this value is
is indicated in the MH Type field, the format of the Message Data indicated in the MH Type field, the format of the Message Data field
field in the Mobility Header is as follows: in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|L| Reserved | Lifetime | |A|H|S|D|L| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
skipping to change at page 30, line 20 skipping to change at page 31, line 43
Home Registration (H) Home Registration (H)
The Home Registration (H) bit is set by the sending mobile The Home Registration (H) bit is set by the sending mobile
node to request that the receiving node should act as this node to request that the receiving node should act as this
node's home agent. The destination of the packet carrying this node's home agent. The destination of the packet carrying this
message MUST be that of a router sharing the same subnet prefix message MUST be that of a router sharing the same subnet prefix
as the home address of the mobile node in the binding. as the home address of the mobile node in the binding.
Single Address Only (S) Single Address Only (S)
If the `S' bit is set, the mobile node requests that the home If this bit is set, the mobile node requests that the home
agent make no changes to any other Binding Cache entry except agent make no changes to any other Binding Cache entry except
for the particular one containing the home address specified for the particular one containing the home address specified
in the Home Address destination option. This disables home in the Home Address destination option. This disables home
agent processing for other related addresses, as is described agent processing for other related addresses, as is described
in Section 10.2. in Section 10.3.1.
Duplicate Address Detection (D) Duplicate Address Detection (D)
The Duplicate Address Detection (D) bit is set by the sending The Duplicate Address Detection (D) bit is set by the sending
mobile node to request that the receiving node (the mobile mobile node to request that the receiving node (the mobile
node's home agent) perform Duplicate Address Detection [13] node's home agent) perform Duplicate Address Detection [13]
on the mobile node's home link for the home address in this on the mobile node's home link for the home address in this
binding. This bit is only valid when the Home Registration (H) binding. This bit is only valid when the Home Registration (H)
and Acknowledge (A) bits are also set, and MUST NOT be set and Acknowledge (A) bits are also set, and MUST NOT be set
otherwise. otherwise.
skipping to change at page 31, line 8 skipping to change at page 32, line 28
Sequence # Sequence #
A 16-bit number used by the receiving node to sequence Binding A 16-bit number used by the receiving node to sequence Binding
Updates and by the sending node to match a returned Binding Updates and by the sending node to match a returned Binding
Acknowledgement with this Binding Update. Acknowledgement with this Binding Update.
Lifetime Lifetime
16-bit unsigned integer. The number of time units remaining 16-bit unsigned integer. The number of time units remaining
before the binding MUST be considered expired. A value of all before the binding MUST be considered expired. A value of
one bits (0xffffffff) indicates infinity. A value of zero all one bits (0xffff) indicates infinity. A value of zero
indicates that the Binding Cache entry for the mobile node MUST indicates that the Binding Cache entry for the mobile node MUST
be deleted. One time unit is 16 seconds. be deleted. One time unit is 4 seconds.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand. MUST ignore and skip any options which it does not understand.
The following options are valid in a Binding Update message: The following options are valid in a Binding Update:
- Unique Identifier option
- Binding Authorization Data option - Binding Authorization Data option
- Nonce Indices option. - Nonce Indices option.
- Alternate Care-of Address option - Alternate Care-of Address option
If no actual options are present in this message, no padding is If no options are present in this message, 4 bytes of padding is
necessary and the Header Len field will be set to 4. necessary and the Header Len field will be set to 1.
A Binding Update to the home agent 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 The care-of address MUST be a unicast routable address. Binding
for use within a Routing Header; thus multicast addresses, the Updates for a care-of address which is not a unicast routable address
unspecified address, loop-back address, and link-local addresses MUST be silently discarded.
are excluded. Binding Updates indicating any such excluded care-of
address MUST be silently discarded.
The deletion of a binding can be indicated by setting the Lifetime 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 field to 0 or by setting the care-of address equal to the home
address. Correspondent nodes SHOULD NOT expire the binding cache address. In either case, generation of the binding management
entry before the lifetime expires, if any application hosted by the key depends exclusively on the home keygen token (Section 5.2.5).
correspondent node is still likely to require communication with the Correspondent nodes SHOULD NOT expire the Binding Cache entry before
mobile node. A binding cache entry that is deallocated prematurely the lifetime expires, if any application hosted by the correspondent
might cause subsequent packets to be dropped from the mobile node, node is still likely to require communication with the mobile node.
if they contain the Home Address destination option. This situation A Binding Cache entry that is deallocated prematurely might cause
is recoverable, since an error message is sent to the mobile node; subsequent packets to be dropped from the mobile node, if they
however, it causes unnecessary delay in the communications. contain the Home Address destination option. This situation is
recoverable, since an Binding Error message is sent to the mobile
node (see Section 6.1.9); however, it causes unnecessary delay in the
communications.
6.1.8. Binding Acknowledgement (BA) Message 6.1.8. Binding Acknowledgement Message
The Binding Acknowledgement message is used to acknowledge receipt The Binding Acknowledgement is used to acknowledge receipt of a
of a Binding Update message (Section 6.1.7). When a node receives Binding Update (Section 6.1.7). This packet is sent as described in
a packet containing a Binding Update message, with this node being Sections 9.5.4 and 10.3.1.
the destination of the packet, this node MUST return a Binding
Acknowledgement to the mobile node, if the Acknowledge (A) bit is
set in the the Binding Update. The Binding Acknowledgement message
is sent to the Source Address of the Binding Update message which
is being acknowledged. The packet includes a Routing header if
the Source Address was not the home address of the mobile node, as
described in Sections 10.2 and 9.4.4. The Source Address of the
Binding Acknowledgement is the Destination Address from the Binding
Update.
The Binding Acknowledgement message has the MH Type value 6. When The Binding Acknowledgement has the MH Type value 6. When this value
this value is indicated in the MH Type field, the format of the is indicated in the MH Type field, the format of the Message Data
Message Data field in the Mobility Header is as follows: field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
skipping to change at page 33, line 7 skipping to change at page 34, line 14
0 Binding Update accepted 0 Binding Update accepted
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Insufficient resources 130 Insufficient resources
131 Home registration not supported 131 Home registration not supported
132 Not home subnet 132 Not home subnet
133 Not home agent for this mobile node 133 Not home agent for this mobile node
134 Duplicate Address Detection failed 134 Duplicate Address Detection failed
135 Sequence number out of window 135 Sequence number out of window
136 Route optimization unnecessary due to low traffic 136 Expired home nonce index
137 Invalid authenticator 137 Expired care-of nonce index
138 Expired Home Nonce Index 138 Expired nonces
139 Expired Care-of Nonce Index
Up-to-date values of the Status field are to be specified in Up-to-date values of the Status field are to be specified in
the IANA registry of assigned numbers [18]. the IANA registry of assigned numbers [18].
Sequence # Sequence #
The Sequence Number in the Binding Acknowledgement is copied The Sequence Number in the Binding Acknowledgement is
from the Sequence Number field in the Binding Update. It used copied from the Sequence Number field in the Binding Update.
by the mobile node in matching this Acknowledgement with an It is used by the mobile node in matching this Binding
outstanding Binding Update. Acknowledgement with an outstanding Binding Update.
Lifetime Lifetime
The granted lifetime, in time units of 4 seconds, for which The granted lifetime, in time units of 4 seconds, for which
this node SHOULD retain the entry for this mobile node in its this node SHOULD retain the entry for this mobile node in its
Binding Cache. A value of all one bits (0xffffffff) indicates Binding Cache. A value of all one bits (0xffff) indicates
infinity. infinity.
The value of this field is undefined if the Status field The value of this field is undefined if the Status field
indicates that the Binding Update was rejected. indicates that the Binding Update was rejected.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand. MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Acknowledgement message, that need not be present Binding Acknowledgement, that need not be present in all
in all Binding Acknowledgements sent. This use of mobility Binding Acknowledgements sent. Mobility options allow future
options also allows for future extensions to the format of the extensions to the format of the Binding Acknowledgement to
Binding Acknowledgement message to be defined. The following be defined. The following options are valid for the Binding
options are valid for the Binding Acknowledgement message: Acknowledgement:
- Binding Authorization Data option - Binding Authorization Data option
- Binding Refresh Advice option - Binding Refresh Advice option
If no options are present in this message, 4 bytes of padding is If no options are present in this message, 4 bytes of padding is
necessary and the Header Len field will be set to 2. necessary and the Header Len field will be set to 1.
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.
6.1.9. Binding Error (BE) Message 6.1.9. Binding Error Message
The Binding Error (BE) message is used by the correspondent node to The Binding Error (BE) message is used by the correspondent node to
signal an error related to mobility, such as an inappropriate attempt signal an error related to mobility, such as an inappropriate attempt
to use the Home Address destination option without an existing to use the Home Address destination option without an existing
binding. A packet containing a Binding Error message is sent to the binding; see Section 9.3.3 for details.
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.
The Binding Error message uses the MH Type value 7. When this value 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 is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows: field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 34, line 46 skipping to change at page 35, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Mobility Options . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status Status
8-bit unsigned integer indicating the reason for this message. 8-bit unsigned integer indicating the reason for this message.
The following such Status values are currently defined: The following values are currently defined:
1 Home Address destination option used without a binding 1 Unknown binding for Home Address destination option
2 Received message had an unknown value for the MH Type 2 Unrecognized MH Type value
field
Reserved Reserved
A 8-bit field reserved for future use. The value MUST be A 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
Home Address Home Address
The home address that was contained in the Home Address The home address that was contained in the Home Address
destination option. The mobile node uses this information to destination option. The mobile node uses this information to
determine which binding does not exist, in cases where the determine which binding does not exist, in cases where the
mobile node has several home addresses. mobile node has several home addresses.
Mobility options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand. and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Error message, that need not be present in all Binding Binding Error message, that need not be present in all Binding
Error messages sent. This use of mobility options also allows Error messages sent. Mobility options allow future extensions
for future extensions to the format of the Binding Error to the format of the format of the Binding Error message to
message to be defined. The encoding and format of defined be defined. The encoding and format of defined options are
options are described in Section 6.2. This specification does described in Section 6.2. This specification does not define
not define any options valid for the Binding Error message. any options valid for the Binding Error message.
If no actual options are present in this message, no padding is If no actual options are present in this message, no padding is
necessary and the Header Len field will be set to 3. necessary and the Header Len field will be set to 2.
6.2. Mobility Options 6.2. Mobility Options
6.2.1. Format Mobility messages can include one or more mobility options. This
allows optional fields that may not be needed in every use of a
In order to allow optional fields that may not be needed in every use particular Mobility Header, as well as future extensions to the
of any given Mobility Header, and to allow future extensions to the format of the messages. Such options are included in the Message
format of these messages to be defined, the Mobility Header messages Data field of the message itself, after the fixed portion of the
defined in this document can include one or more mobility options. message data specified in the message subsections of Section 6.1.
Such options are included in the data portion of the message itself,
after the fixed portion of the message data specified in the message
subsections of section 6.1.
The presence of such options will be indicated by the Header Len of The presence of such options will be indicated by the Header Len of
the Mobility Header. 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.
These options are encoded within the remaining space of the message 6.2.1. Format
data for that message, using a type-length-value (TLV) format as
follows: Mobility options are encoded within the remaining space of the
Message Data field of a mobility message, using a type-length-value
(TLV) format as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | Option Data... | Option Type | Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type Option Type
8-bit identifier of the type of mobility option. When 8-bit identifier of the type of mobility option. When
processing a Mobility Header containing an option for which processing a Mobility Header containing an option for which
the Option Type value is not recognized by the receiver, the Option Type value is not recognized by the receiver,
the receiver MUST quietly ignore and skip over the option, the receiver MUST quietly ignore and skip over the option,
correctly handling any remaining options in the message. correctly handling any remaining options in the message.
Option Len Option Length
8-bit unsigned integer. Length of this mobility option, in 8-bit unsigned integer, representing the length in octets of
octets. The Option Len does not include the length of the the mobility option, not including the Option Type and Option
Option Type and Option Len fields. Length fields.
Option Data Option Data
A variable length field that contains data specific to the A variable length field that contains data specific to the
option. option.
The following subsections specify the Option types which are The following subsections specify the Option types which are
currently defined for use in the Mobility Header. currently defined for use in the Mobility Header.
Implementations MUST silently ignore any mobility options that they Implementations MUST silently ignore any mobility options that they
do not understand. do not understand.
6.2.2. Pad1 6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format The Pad1 option does not have any alignment requirements. Its format
is as follows: is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case -- it has NOTE! the format of the Pad1 option is a special case - it has
neither Option Len nor Option Data fields. neither Option Length nor Option Data fields.
The Pad1 option is used to insert one octet of padding in the 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 Mobility Options area of a Mobility Header. If more than one octet
of padding is required, the PadN option, described next, should be of padding is required, the PadN option, described next, should be
used rather than multiple Pad1 options. used rather than multiple Pad1 options.
6.2.3. PadN 6.2.3. PadN
The PadN option does not have any alignment requirements. Its format The PadN option does not have any alignment requirements. Its format
is as follows: is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Option Len | Option Data | Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding in The PadN option is used to insert two or more octets of padding in
the Mobility Options area of a Mobility Header message. For N octets the Mobility Options area of a mobility message. For N octets of
of padding, the Option Len field contains the value N-2, and the padding, the Option Length field contains the value N-2, and the
Option Data consists of N-2 zero-valued octets. Option data MUST be Option Data consists of N-2 zero-valued octets. Option data MUST be
ignored by the receiver. ignored by the receiver.
6.2.4. Unique Identifier 6.2.4. Alternate Care-of Address
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.
6.2.5. Alternate Care-of Address
The Alternate Care-of Address option has an alignment requirement of The Alternate Care-of Address option has an alignment requirement of
8n+6. Its format is as follows: 8n+6. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 16 | | Type = 3 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Alternate Care-of Address + + Alternate Care-of Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address option is valid only in Binding Update The Alternate Care-of Address option is valid only in Binding Update.
message. The Alternate Care-of Address field contains an address to The Alternate Care-of Address field contains an address to use as the
use as the care-of address for the binding, rather than using the care-of address for the binding, rather than using the Source Address
Source Address of the packet as the care-of address. of the packet as the care-of address.
6.2.6. Nonce Indices 6.2.5. Nonce Indices
The Nonce Indices option has an alignment requirement of 2n. Its The Nonce Indices option has an alignment requirement of 2n. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 | | Type = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index | | Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices option is valid only in the Binding Update message, The Nonce Indices option is valid only in the Binding Update message,
and only when present together with an Binding Authorization Data and only when present together with an Binding Authorization Data
option. option.
The Home Nonce Index field tells the correspondent node that receives The Home Nonce Index field tells the correspondent node that receives
the message which of the challenge values (Ni) are to be used to the message which of its stored random nonce values is to be used to
authenticate the Binding Update. produce the home keygen token to authorize the Binding Update.
The Care-of Nonce Index field tells the correspondent node that The Care-of Nonce Index field tells the correspondent node that
receives the message which of the challenge values (Nj) are to be receives the message which of its stored random nonce values is to
used to authenticate the Binding Update. be used to produce the care-of keygen token to authorize the Binding
Update.
6.2.7. Binding Authorization Data 6.2.6. Binding Authorization Data
The Binding Authorization Data option has an alignment requirement of The Binding Authorization Data option has an alignment requirement of
4n+2. Its format is as follows: 8n+2. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Len | | Type = 5 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Authenticator | | Authenticator |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is valid only in the Binding The Binding Authorization Data option is valid in the Binding Update
Refresh Request, Binding Update, and Binding Acknowledgment messages. and Binding Acknowledgment.
The Option Len field contains the length of the authenticator in The Option Length field contains the length of the authenticator in
octets. octets.
The Authenticator field contains a cryptographic value which can be The Authenticator field contains a cryptographic value which can be
used to determine that the message in question comes from the right used to determine that the message in question comes from the right
authority. Rules for calculating this value depend on the used authority. Rules for calculating this value depend on the used
authorization procedure. This specification gives the rules only for authorization procedure.
the return routability procedure. For this procedure, this option
can only appear in a Binding Update message and rules for calculating
the Authenticator value are described in Section 6.1.7.
6.2.8. Binding Refresh Advice For the return routability procedure, this option can appear in the
Binding Update and Binding Acknowledgements. Rules for calculating
the Authenticator value are the following:
Mobility Data = care-of address | final dest | Mobility Header Data
Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
Where | denotes concatenation and "final dest" is the IPv6 address
of the final destination of the packet. "Mobility Header Data" is
the content of the Mobility 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. The Binding Refresh Advice option has an alignment requirement of 2n.
Its format is as follows: Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 2 | | Type = 6 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval | | Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option is only valid in the Binding The Binding Refresh Advice option is only valid in the Binding
Acknowledgement message, and only on Acknowledgements sent from Acknowledgement, and only on Binding Acknowledgements sent from
the mobile node's home agent in reply to a home registration. The the mobile node's home agent in reply to a home registration. The
Refresh Interval is measured in seconds, and indicates how long Refresh Interval is measured in units of four seconds, and indicates
before the mobile node SHOULD send a new home registration to the how long before the mobile node SHOULD send a new home registration
home agent. The Refresh Interval MUST be set to indicate a smaller to the home agent. The Refresh Interval MUST be set to indicate
time interval than the Lifetime value of the Binding Acknowledgement. a smaller time interval than the Lifetime value of the Binding
Acknowledgement.
6.3. Home Address Destination Option
The Home Address destination option is used in a packet sent by a 6.3. Home Address Option
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 The Home Address option is carried by the Destination Option
mapped addresses, and the unspecified address, MUST NOT be used extension header (Next Header value = 60). It is used in a packet
within a Home Address option. The Home Address Option MUST NOT sent by a mobile node while away from home, to inform the recipient
appear more than once in any given packet, except inside the payload of the mobile node's home address.
part of the packet if tunneling is involved.
The Home Address option is encoded in type-length-value (TLV) format The Home Address option is encoded in type-length-value (TLV) format
as follows: as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Next Header | Header Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 48 skipping to change at page 41, line 43
201 = 0xC9 201 = 0xC9
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field excluding the Option Type and Option Length fields. This field
MUST be set to 16. MUST be set to 16.
Home Address Home Address
The home address of the mobile node sending the packet. 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 IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at on natural boundaries (i.e., fields of width n octets are placed at
an integer multiple of n octets from the start of the header, for 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 n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Home
Address option is 8n+6. Address option is 8n+6.
The three highest-order bits of the Option Type are encoded to The three highest-order bits of the Option Type field are encoded
indicate specific processing of the option [11]. For the Home to indicate specific processing of the option [11]; for the Home
Address option, these three bits are set to 110, indicating that any Address option, these three bits are set to 110. This indicates the
IPv6 node processing this option that does not recognize the Option following processing requirements:
Type must discard the packet and, only if the packet's Destination
Address was not a multicast address, return an ICMP Parameter
Problem, Code 2, message to the packet's Source Address; and that the
data within the option cannot change en-route to the packet's final
destination.
A packet MUST NOT contain more than one Home Address option, except - Any IPv6 node that does not recognize the Option Type must
that an encapsulated packet [15] MAY contain a separate Home Address discard the packet.
option associated with each encapsulating IP header.
- 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; 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.
The Home Address option MUST be placed as follows: The Home Address option MUST be placed as follows:
- After the Routing Header, if that header is present - After the routing header, if that header is present
- Before the Fragment Header, if that header is present - Before the Fragment Header, if that header is present
- Before the AH Header or ESP Header, if either one of those - Before the AH Header or ESP Header, if either one of those
headers is present headers is present
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 The inclusion of a Home Address destination option in a packet
affects the receiving node's processing of only this single packet; affects the receiving node's processing of only this single packet.
no state is created or modified in the receiving node as a result 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 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 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 the contents of the receiver's Binding Cache and MUST NOT cause any
changes in the routing of subsequent packets sent by this receiving changes in the routing of subsequent packets sent by this receiving
node. node.
6.4. Routing Header type 2 6.4. Type 2 Routing Header
Mobile IPv6 uses a Routing header to carry the Home Address for Mobile IPv6 defines a new routing header variant, the type 2
packets sent from a correspondent node to a mobile node. The Care of routing header, to allow the packet to be routed directly from a
Address of the mobile node is carried in the IPv6 destination field. correspondent to the mobile node's care-of address. The mobile
node's care-of address is inserted into the IPv6 Destination Address
field. Once the packet arrives at the care-of address, the mobile
node retrieves its home address from the routing header, and this is
used as the final destination address for the packet.
The new Routing header uses a different type than defined for The new routing header uses a different type than defined for
"regular" IPv6 source routing, enabling firewalls to apply different "regular" IPv6 source routing, enabling firewalls to apply different
rules to source routed packets than to MIPv6. This Routing header rules to source routed packets than to Mobile IPv6. This routing
type (Type 2) is restricted to carry only one IPv6 address. All IPv6 header type (type 2) is restricted to carry only one IPv6 address.
nodes which process this Routing header MUST verify that the address All IPv6 nodes which process this routing header MUST verify that
contained within is the node's own home address in order to prevent the address contained within is the node's own home address in
packets from being forwarded outside the node. 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 6.4.1. Format
The Type 2 Routing header has the following format: The type 2 routing header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Routing header. Uses the same values as the IPv6 following the routing header. Uses the same values as the IPv6
Next Header field [11]. Next Header field [11].
Hdr Ext Len Hdr Ext Len
8-bit unsigned integer. Length of the Routing header in 2 (8-bit unsigned integer); length of the routing header in
8-octet units, not including the first 8 octets. For the Type 8-octet units, not including the first 8 octets
2 Routing header, Hdr Ext Len is always 2.
Routing Type Routing Type
8-bit unsigned integer that contains the value 2. 2 (8-bit unsigned integer).
Segments Left Segments Left
8-bit unsigned integer. Number of route segments remaining; 1 (8-bit unsigned integer).
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 Reserved
32-bit reserved field. Initialized to zero for transmission, 32-bit reserved field. Initialized to zero for transmission,
and ignored on reception. and ignored on reception.
Home Address Home Address
The Home Address of the destination Mobile Node. The Home Address of the destination Mobile Node.
The ordering rules for extension headers in an IPv6 packet are For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments
described in Section 4.1 of [11]. The new Routing header (Type 2) Left value describes the number of route segments remaining; i.e.,
defined for Mobile IPv6 follows the same ordering as other routing number of explicitly listed intermediate nodes still to be visited
headers. If more than one Routing header (e.g., both a Type 0 and a before reaching the final destination. Segments Left MUST be 1. The
Type 2 Routing header are present), the Type 2 Routing header should ordering rules for extension headers in an IPv6 packet are described
follow all other Routing headers. Otherwise the order of routing in Section 4.1 of [11]. The type 2 routing header defined for Mobile
headers is independent of their type and follows [11]. IPv6 follows the same ordering as other routing headers. If both a
Type 0 and a type 2 routing header are present, the type 2 routing
header should follow the other routing header.
In addition, the general procedures defined by IPv6 for Routing In addition, the general procedures defined by IPv6 for routing
headers suggest that a received Routing header MAY be automatically headers suggest that a received routing header MAY be automatically
"reversed" to construct a Routing header for use in any response "reversed" to construct a routing header for use in any response
packets sent by upper-layer protocols, if the received packet is packets sent by upper-layer protocols, if the received packet is
authenticated [6]. This MUST NOT be done automatically for Type 2 authenticated [6]. This MUST NOT be done automatically for type 2
Routing headers. routing headers.
6.5. ICMP Home Agent Address Discovery Request Message 6.5. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Section 11.3.2. The mobile node sends mechanism, as described in Section 11.4.1. The mobile node sends
a Home Agent Address Discovery Request message to the "Mobile IPv6 the Home Agent Address Discovery Request message to the Mobile IPv6
Home-Agents" anycast address for its own home subnet prefix [16]. Home-Agents anycast address for its own home subnet prefix [16].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
150 <To Be Assigned by IANA> 150 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
skipping to change at page 44, line 32 skipping to change at page 45, line 43
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Source Address of the Home Agent Address Discovery Request The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of message packet MUST be one of the mobile node's current care-of
addresses. The home agent MUST then return the Home Agent Address addresses. The home agent MUST then return the Home Agent Address
Discovery Reply message directly to the Source Address chosen by the Discovery Reply message directly to the Source Address chosen by the
mobile node. Note that, at the time of performing this dynamic home mobile node. Note that, at the time of performing this dynamic home
agent address discovery, it is likely that the mobile node is not agent address discovery procedure, it is likely that the mobile node
registered with any home agent within the specified anycast group. is not registered with any home agent within the specified anycast
group.
6.6. ICMP Home Agent Address Discovery Reply Message 6.6. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a home 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 agent to respond to a mobile node that uses the dynamic home agent
address discovery mechanism, as described in Section 10.9. One of address discovery mechanism, as described in Section 10.5.
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.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Home Agent Addresses . . Home Agent Addresses .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 47, line 7 skipping to change at page 47, line 7
Home Agent Addresses Home Agent Addresses
A list of addresses of home agents on the home link for the A list of addresses of home agents on the home link for the
mobile node. The number of addresses present in the list is mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message. the Home Agent Address Discovery Reply message.
6.7. ICMP Mobile Prefix Solicitation Message Format 6.7. ICMP Mobile Prefix Solicitation Message Format
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node The ICMP Mobile Prefix Solicitation Message is sent by a mobile
to its home agent while it is away from home. The purpose of the node to its home agent while it is away from home. The purpose
message is to solicit a Mobile Prefix Advertisement from the home of the message is to solicit a Mobile Prefix Advertisement from
agent, which will allow the mobile node to gather prefix information the home agent, which will allow the mobile node to gather prefix
about its home network. This information can be used to configure information about its home network. This information can be used to
home address(es) by stateless address autoconfiguration [13], configure and update home address(es) according to changes in prefix
or update address(es) according to changes in prefix information information supplied by the home agent.
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields: IP Fields:
skipping to change at page 47, line 46 skipping to change at page 47, line 40
The address of the mobile node's home agent. This home agent The address of the mobile node's home agent. This home agent
must be on the link which the mobile node wishes to learn must be on the link which the mobile node wishes to learn
prefix information about. prefix information about.
Hop Limit Hop Limit
Set to an initial hop limit value, similarly to any other Set to an initial hop limit value, similarly to any other
unicast packet sent by the mobile node. unicast packet sent by the mobile node.
Authentication Header Destination Option:
If a Security Association for the IP Authentication Header A Home Address destination option MUST be included.
exists between the sender and the destination address, then the
sender SHOULD include this header. [subject to change] AH or ESP header:
IPsec headers SHOULD be supported and used as described in
Section 5.4.
ICMP Fields: ICMP Fields:
Type Type
152 <To Be Assigned by IANA> 152 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [14]. The ICMP checksum [14].
Identifier Identifier
An identifier to aid in matching a future Mobile Prefix An identifier to aid in matching a future Mobile Prefix
Advertisement message to this Mobile Prefix Solicitation Advertisement to this Mobile Prefix Solicitation.
message.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
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.
6.8. ICMP Mobile Prefix Advertisement Message Format 6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement message to a A home agent will send a Mobile Prefix Advertisement to a mobile
mobile node to distribute prefix information about the home link node to distribute prefix information about the home link while the
while the mobile node is traveling away from the home network. This mobile node is traveling away from the home network. This will occur
will occur in response to a Mobile Prefix Solicitation with an in response to a Mobile Prefix Solicitation with an Advertisement,
Advertisement, or by an unsolicited Advertisement sent according to or by an unsolicited Advertisement sent according to the rules in
the rules in Section 10.9.1. Section 10.6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Options ... | Identifier | Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields: IP Fields:
skipping to change at page 49, line 37 skipping to change at page 49, line 37
Destination Address Destination Address
If this message is a response to a Mobile Prefix If this message is a response to a Mobile Prefix
Solicitation, this field contains the Source Address Solicitation, this field contains the Source Address
field from that packet. For unsolicited messages, field from that packet. For unsolicited messages,
the mobile node's care-of address SHOULD be used. the mobile node's care-of address SHOULD be used.
Note that unsolicited messages can only be sent if Note that unsolicited messages can only be sent if
the mobile node is currently registered with the the mobile node is currently registered with the
home agent. home agent.
Authentication Header Routing header:
An AH header MUST be included unless the mobile node
has yet to configure a home address. A type 2 routing header MUST be included.
AH or ESP header:
IPsec headers SHOULD be supported and used as described in
Section 5.4.
ICMP Fields: ICMP Fields:
Type Type
153 <To Be Assigned by IANA> 153 <To Be Assigned by IANA>
Code Code
0 0
Checksum Checksum
The ICMP checksum [14]. The ICMP checksum [14].
Identifier Identifier
skipping to change at page 50, line 8 skipping to change at page 50, line 15
0 0
Checksum Checksum
The ICMP checksum [14]. The ICMP checksum [14].
Identifier Identifier
An identifier to aid in matching this Mobile Prefix An identifier to aid in matching this Mobile Prefix
Advertisement message to a previous Mobile Prefix Solicitation Advertisement to a previous Mobile Prefix Solicitation.
message.
Options: Options:
Prefix Information Prefix Information
Each message contains one or more Prefix Information options. Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node Each option carries the prefix(es) that the mobile node should
should use to configure its home address(es). Section 10.9.1 use to configure its home address(es). Section 10.6 describes
describes which prefixes should be advertised to the mobile which prefixes should be advertised to the mobile node.
node.
The Prefix Information option is defined in Section 4.6.2 The Prefix Information option is defined in Section 4.6.2
of [12], with modifications defined in Section 7.2 of this of [12], with modifications defined in Section 7.2 of this
specification. The home agent MUST use this modified Prefix specification. The home agent MUST use this modified Prefix
Information option to send the aggregate list of home network Information option to send the aggregate list of home network
prefixes as defined in Section 10.9.1. prefixes as defined in Section 10.6.1.
The Mobile Prefix Advertisement sent by the home agent MAY include The Mobile Prefix Advertisement sent by the home agent MAY include
the Source Link-layer Address option defined in RFC 2461 [12], or the the Source Link-layer Address option defined in RFC 2461 [12], or the
Advertisement Interval option specified in Section 7.3. Advertisement Interval option specified in Section 7.3.
Future versions of this protocol may define new option types. Mobile Future versions of this protocol may define new option types. Mobile
nodes MUST silently ignore any options they do not recognize and nodes MUST silently ignore any options they do not recognize and
continue processing the message. continue processing the message.
If the Advertisement is sent in response to a Mobile Prefix If the Advertisement is sent in response to a Mobile Prefix
skipping to change at page 51, line 36 skipping to change at page 51, line 36
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [12]: specified for Neighbor Discovery [12]:
Home Agent (H) Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is indicate that the router sending this Router Advertisement is
also functioning as a Mobile IP home agent on this link. also functioning as a Mobile IPv6 home agent on this link.
Reserved Reserved
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Home Agent (H) bit. addition of the above bit.
7.2. Modified Prefix Information Option Format 7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address for two Mobile IPv6 requires knowledge of a router's global address in
reasons: building a Home Agents List as part of the dynamic home agent address
discovery mechanism (Sections 10.5 and 11.4.1).
- 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 Home Agents List as
part of the dynamic home agent address discovery mechanism
(Sections 10.9 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).
However, Neighbor Discovery [12] only advertises a router's However, Neighbor Discovery [12] only advertises a router's
link-local address, by requiring this address to be used as the IP link-local address, by requiring this address to be used as the IP
Source Address of each Router Advertisement. Source Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to easily Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
and efficiently advertise its global address, by the addition of a its global address, by the addition of a single flag bit in the
single flag bit in the format of a Prefix Information option for format of a Prefix Information option for use in Router Advertisement
use in Router Advertisement messages. The format of the Prefix messages. The format of the Prefix Information option is as follows:
Information option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1| | Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime | | Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 13 skipping to change at page 52, line 51
specified for Neighbor Discovery [12]: specified for Neighbor Discovery [12]:
Router Address (R) Router Address (R)
1-bit router address flag. When set, indicates that the 1-bit router address flag. When set, indicates that the
Prefix field, in addition to advertising the indicated prefix, Prefix field, in addition to advertising the indicated prefix,
contains a complete IP address assigned to the sending router. contains a complete IP address assigned to the sending router.
This router IP address has the same scope and conforms to the This router IP address has the same scope and conforms to the
same lifetime values as the advertised prefix. This use of same lifetime values as the advertised prefix. This use of
the Prefix field is compatible with its use in advertising the Prefix field is compatible with its use in advertising
the prefix itself, since prefix advertisement uses only the the prefix itself, since Prefix Advertisement uses only the
leading number Prefix bits specified by the Prefix Length leading number Prefix bits specified by the Prefix Length
field. Interpretation of this flag bit is thus independent field. Interpretation of this flag bit is thus independent
of the processing required for the On-Link (L) and Autonomous of the processing required for the On-Link (L) and Autonomous
Address-Configuration (A) flag bits. Address-Configuration (A) flag bits.
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the Router Address (R) bit. addition of the above bit.
In a solicited Router Advertisement, a home agent MUST, and all other
routers SHOULD, include at least one Prefix Information option with
the Router 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 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 In a Router Advertisement, a home agent MUST, and all other routers
with the Router Address (R) bit set, in each unsolicited multicast MAY, include at least one Prefix Information option with the Router
Router Advertisement that they send. If multiple Advertisements Address (R) bit set. Neighbor Discovery specifies that, if including
are being sent instead of a single larger unsolicited multicast all options in a Router Advertisement causes the size of the
Advertisement, at least one of these multiple Advertisements SHOULD Advertisement to exceed the link MTU, multiple Advertisements can be
include a Prefix Information option with the Router Address (R) bit sent, each containing a subset of the options [12]. In this case, at
set. least one (not all) of these multiple Advertisements being sent needs
to satisfy the above requirement.
7.3. New Advertisement Interval Option Format 7.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the interval at which the Router Advertisement messages to advertise the interval at which the
sending router sends unsolicited multicast Router Advertisements. sending router sends unsolicited multicast Router Advertisements.
The format of the Advertisement Interval option is as follows: The format of the Advertisement Interval option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 54, line 47 skipping to change at page 54, line 47
32-bit unsigned integer. The maximum time, in milliseconds, 32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited router Router Advertisement between successive unsolicited router Router Advertisement
messages sent by this router on this network interface. Using messages sent by this router on this network interface. Using
the conceptual router configuration variables defined by the conceptual router configuration variables defined by
Neighbor Discovery [12], this field MUST be equal to the value Neighbor Discovery [12], this field MUST be equal to the value
MaxRtrAdvInterval, expressed in milliseconds. MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option in their Router Advertisements. A Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.4.1. in its movement detection algorithm, as described in Section 11.5.1.
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
7.4. New Home Agent Information Option Format 7.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used in Mobile IPv6 defines a new Home Agent Information option, used in
Router Advertisement messages sent by a home agent to advertise Router Advertisements sent by a home agent to advertise information
information specific to this router's functionality as a home agent. specific to this router's functionality as a home agent. The format
The format of the Home Agent Information option is as follows: of the Home Agent Information option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime | | Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 55, line 37 skipping to change at page 55, line 37
the type and length fields) in units of 8 octets. The value of the type and length fields) in units of 8 octets. The value of
this field MUST be 1. this field MUST be 1.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Home Agent Preference Home Agent Preference
16-bit signed, twos-complement integer. The preference for 16-bit signed, two's complement integer. The preference for
the home agent sending this Router Advertisement, for use in the home agent sending this Router Advertisement, for use in
ordering the addresses returned to a mobile node in the Home ordering the addresses returned to a mobile node in the Home
Agent Addresses field of a Home Agent Address Discovery Reply Agent Addresses field of a Home Agent Address Discovery Reply
message. Higher values mean more preferable. If this option message. Higher values mean more preferable. If this option
is not included in a Router Advertisement in which the Home is not included in a Router Advertisement in which the Home
Agent (H) bit is set, the preference value for this home agent Agent (H) bit is set, the preference value for this home agent
SHOULD be considered to be 0. Values greater than 0 indicate a SHOULD be considered to be 0. Values greater than 0 indicate a
home agent more preferable than this default value, and values home agent more preferable than this default value, and values
less than 0 indicate a less preferable home agent. less than 0 indicate a less preferable home agent.
skipping to change at page 56, line 15 skipping to change at page 56, line 15
may be in use by some home agents on this link (i.e., a home may be in use by some home agents on this link (i.e., a home
agent not including a Home Agent Information option in its agent not including a Home Agent Information option in its
Router Advertisements will be considered to have a Home Agent Router Advertisements will be considered to have a Home Agent
Preference value of 0). Preference value of 0).
Home Agent Lifetime Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the 16-bit unsigned integer. The lifetime associated with the
home agent in units of seconds. The default value is the same home agent in units of seconds. The default value is the same
as the Router Lifetime, as specified in the main body of the as the Router Lifetime, as specified in the main body of the
Router Advertisement message. The maximum value corresponds Router Advertisement. The maximum value corresponds to 18.2
to 18.2 hours. A value of 0 MUST NOT be used. The Home Agent hours. A value of 0 MUST NOT be used. The Home Agent Lifetime
Lifetime applies only to this router's usefulness as a home applies only to this router's usefulness as a home agent; it
agent; it does not apply to information contained in other does not apply to information contained in other message fields
message fields or options. or options.
Home agents MAY include this option in their Router Advertisements. Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which 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 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) 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 bit is set, the lifetime for this home agent MUST be considered to
be the same as the Router Lifetime in the Router Advertisement. be the same as the Router Lifetime in the Router Advertisement.
If multiple Advertisements are being sent instead of a single If multiple Advertisements are being sent instead of a single
larger unsolicited multicast Advertisement, all of the multiple larger unsolicited multicast Advertisement, all of the multiple
Advertisements with the Router Address (R) bit set MUST include this Advertisements with the Router Address (R) bit set MUST include this
skipping to change at page 57, line 30 skipping to change at page 57, line 30
movement detection for mobile nodes. Mobile nodes detect their movement detection for mobile nodes. Mobile nodes detect their
own movement by learning the presence of new routers as the mobile own movement by learning the presence of new routers as the mobile
node moves into wireless transmission range of them (or physically node moves into wireless transmission range of them (or physically
connects to a new wired network), and by learning that previous connects to a new wired network), and by learning that previous
routers are no longer reachable. Mobile nodes MUST be able to 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 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 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 to register this care-of address with their home agent and to notify
correspondent nodes as needed. correspondent nodes as needed.
Thus, to provide good support for mobile nodes, Mobile IPv6 relaxes Mobile IPv6 relaxes this limit such that routers MAY send unsolicited
this limit such that routers MAY send unsolicited multicast Router multicast Router Advertisements more frequently. This is important
Advertisements more frequently. In particular, on network interfaces on network interfaces where the router is expecting to provide
where the router is expecting to provide service to visiting mobile service to visiting mobile nodes (e.g., wireless network interfaces),
nodes (e.g., wireless network interfaces), or on which it is serving or on which it is serving as a home agent to one or more mobile
as a home agent to one or more mobile nodes (who may return home and nodes (who may return home and need to hear its Advertisements).
need to hear its Advertisements), the router SHOULD be configured Such routers SHOULD be configured with a smaller MinRtrAdvInterval
with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value, value and MaxRtrAdvInterval value, to allow sending of unsolicited
to allow sending of unsolicited multicast Router Advertisements more multicast Router Advertisements more often. Recommended values for
often. Recommended values for these limits are: these limits are:
- MinRtrAdvInterval 0.05 seconds - MinRtrAdvInterval 0.05 seconds
- MaxRtrAdvInterval 1.5 seconds - MaxRtrAdvInterval 1.5 seconds
Use of these modified limits MUST be configurable, and specific Use of these modified limits MUST be configurable, and specific
knowledge of the type of network interface in use SHOULD be taken knowledge of the type of network interface in use SHOULD be taken
into account in configuring these limits for each network interface. into account in configuring these limits for each network interface.
Note that multicast Router Advertisements are not 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.
When sending unsolicited multicast Router Advertisements more When sending unsolicited multicast Router Advertisements more
frequently than the standard limit on unsolicited multicast frequently than the standard limit on unsolicited multicast
Advertisement frequency, the sending router need not include all Advertisement frequency, the sending router need not include all
options in each of these Advertisements, but it SHOULD include at options in each of these Advertisements, but it SHOULD include at
least one Prefix Information option with the Router Address (R) bit least one Prefix Information option with the Router Address (R) bit
set (Section 7.2) in each. set (Section 7.2) in each.
7.6. Changes to Sending Router Solicitations 7.6. Changes to Sending Router Solicitations
skipping to change at page 58, line 39 skipping to change at page 59, line 39
more frequently than the defined Neighbor Discovery limit of more frequently than the defined Neighbor Discovery limit of
RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST RTR_SOLICITATION_INTERVAL seconds. The minimum interval MUST
be configurable, and specific knowledge of the type of network be configurable, and specific knowledge of the type of network
interface in use SHOULD be taken into account in configuring this interface in use SHOULD be taken into account in configuring this
limit for each network interface. A recommended minimum interval limit for each network interface. A recommended minimum interval
is 1 second. is 1 second.
- After sending at most MAX_RTR_SOLICITATIONS Router Solicitations, - After sending at most MAX_RTR_SOLICITATIONS Router Solicitations,
a mobile node MUST reduce the rate at which it sends subsequent a mobile node MUST reduce the rate at which it sends subsequent
Router Solicitations. Subsequent Router Solicitations SHOULD Router Solicitations. Subsequent Router Solicitations SHOULD
be sent using a binary exponential backoff mechanism, doubling be sent using a binary exponential back-off mechanism, doubling
the interval between consecutive Router Solicitations, up to a the interval between consecutive Router Solicitations, up to a
maximum interval. The maximum interval MUST be configurable and maximum interval. The maximum interval MUST be configurable and
SHOULD be chosen appropriately based on the characteristics of SHOULD be chosen appropriately based on the characteristics of
the type of network interface in use. the type of network interface in use.
- While still searching for a new default router and care-of - While still searching for a new default router and care-of
address, a mobile node MUST NOT increase the rate at which it address, a mobile node MUST NOT increase the rate at which it
sends Router Solicitations unless it has received a positive sends Router Solicitations unless it has received a positive
indication (such as from lower network layers) that it has moved indication (such as from lower network layers) that it has moved
to a new link. After successfully acquiring a new care-of to a new link. After successfully acquiring a new care-of
address, the mobile node SHOULD also increase the rate at which address, the mobile node SHOULD also increase the rate at which
it will send Router Solicitations when it next begins searching it will send Router Solicitations when it next begins searching
for a new default router and care-of address. for a new default router and care-of address.
- A mobile node that is currently configured with a care-of address - A mobile node that is currently configured with a care-of address
SHOULD NOT send Router Solicitations to the default router SHOULD NOT send Router Solicitations to the default router
on its current link, until its movement detection algorithm on its current link, until its movement detection algorithm
(Section 11.4.1) determines that it has moved and that its (Section 11.5.1) determines that it has moved and that its
current care-of address might no longer be valid. 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 8. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions Mobile IPv6 places some special requirements on the functions
provided by different types of IPv6 nodes. This section summarizes provided by different types of IPv6 nodes. This section summarizes
those requirements, identifying the functionality each requirement is those requirements, identifying the functionality each requirement is
intended to support. intended to support.
The requirements are set for the following groups of nodes: The requirements are set for the following groups of nodes:
- All IPv6 nodes. - All IPv6 nodes.
skipping to change at page 59, line 32 skipping to change at page 61, line 10
- All Mobile IPv6 home agents. - All Mobile IPv6 home agents.
- All Mobile IPv6 mobile nodes. - All Mobile IPv6 mobile nodes.
It is outside the scope of this specification to specify which It is outside the scope of this specification to specify which
of these groups are mandatory in IPv6. We only describe what is of these groups are mandatory in IPv6. We only describe what is
mandatory for a node that supports, for instance, route optimization. mandatory for a node that supports, for instance, route optimization.
Other specifications are expected to define the extent of IPv6. Other specifications are expected to define the extent of IPv6.
8.1. General Requirements for All IPv6 Nodes 8.1. All IPv6 Nodes
Any IPv6 node may at any time be a correspondent node of a mobile 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 node, either sending a packet to a mobile node or receiving a packet
packet from a mobile node. The following requirements are necessary from a mobile node. There are no Mobile IPv6 specific requirements
for every IPv6 node (whether host or router, whether mobile or for such nodes, and standard IPv6 techniques are sufficient.
stationary), since otherwise communications may be impossible:
- The node MUST be able to validate a Home Address option received 8.2. IPv6 Nodes with Support for Route Optimization
in any IPv6 packet as described in Section 9.2.2.
- The node MUST be able to send a Binding Error message as Nodes that implement route optimization are a subset of all IPv6
described in Section 9.4.6. 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. The following requirements apply to all
correspondent nodes that support route optimization:
8.2. Route Optimization Requirements for All IPv6 Nodes - The node MUST be able validate a Home Address option using an
existing Binding Cache entry, as described in Section 9.3.1.
The ability of a correspondent node to participate in route - The node MUST be able to insert a type 2 routing header
optimization is essential for the efficient operation of the IPv6 into packets to be sent to a mobile node, as described in
Internet, beneficial for robustness and reduction of jitter and Section 9.3.2.
latency, and necessary to avoid congestion in the home network.
The following requirements apply to all nodes that support route - Unless the correspondent node is also acting as a mobile node, it
optimization: MUST ignore type 2 routing headers and drop all packets that it
has received with such headers.
- The node SHOULD be able to 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 able to process Mobility Headers as described in
Section 9.2.
- The node MUST be able to participate in a return routability - The node MUST be able to participate in a return routability
procedure (Section 9.3). procedure (Section 9.4).
- The node MUST be able to process Binding Update messages - The node MUST be able to process Binding Update messages
(Section 9.4). (Section 9.5).
- The node MUST be able to return a Binding Acknowledgement message - The node MUST be able to return a Binding Acknowledgement
(Section 6.1.8). (Section 9.5.4).
- The node MUST be able to maintain a Binding Cache of the - The node MUST be able to maintain a Binding Cache of the
bindings received in accepted Binding Updates, as described in bindings received in accepted Binding Updates, as described in
Sections 9.1 and 9.5. Sections 9.1 and 9.6.
- The node MUST be able to insert a Routing Header type 2 into
packets to be sent to a mobile node, as described in Section 9.6.
- The node SHOULD be able to interpret ICMP messages as described
in Section 9.7.
8.3. Requirements for All IPv6 Routers 8.3. All IPv6 Routers
All IPv6 routers, even those not serving as a home agent for All IPv6 routers, even those not serving as a home agent for
Mobile IPv6, have an effect on how well mobile nodes can communicate: Mobile IPv6, have an effect on how well mobile nodes can communicate:
- Every IPv6 router SHOULD be able to send an Advertisement - Every IPv6 router SHOULD be able to send an Advertisement
Interval option (Section 7.3) in each of its Router Interval option (Section 7.3) in each of its Router
Advertisements [12], to aid movement detection by mobile nodes Advertisements [12], to aid movement detection by mobile nodes
(as in Section 11.4.1). The use of this option in Router (as in Section 11.5.1). The use of this option in Router
Advertisements MUST be configurable. Advertisements MUST be configurable.
- Every IPv6 router SHOULD be able to support sending unsolicited - Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in multicast Router Advertisements at the faster rate described in
Section 7.5. The use of this faster rate MUST be configurable. Section 7.5. The use of this faster rate MUST be configurable.
- Each router SHOULD include at least one prefix with the `R' bit - Each router SHOULD include at least one prefix with the Router
set and with its full IP address in its router advertisements (as Address (R) bit set and with its full IP address in its Router
described in Section 7.2). Advertisements (as described in Section 7.2).
- Filtering routers SHOULD support different rules for Type 0 and - Filtering routers SHOULD support different rules for type 0
Type 2 Routing headers (see Section 6.4) so that filtering of and type 2 routing headers (see Section 6.4) so that filtering
source routed packets (Type 0) will not necessarily limit MIPv6 of source routed packets (type 0) will not necessarily limit
traffic which is delivered via Type 2 Routing headers. Mobile IPv6 traffic which is delivered via type 2 routing
headers.
8.4. Requirements for IPv6 Home Agents 8.4. IPv6 Home Agents
In order for a mobile node to operate correctly while away from home, In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function at least one IPv6 router on the mobile node's home link must function
as a home agent for the mobile node. The following additional as a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers capable of serving as a home requirements apply to all IPv6 routers that serve as a home agent:
agent:
- Every home agent MUST be able to maintain an entry in its Binding - Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as the home Cache for each mobile node for which it is serving as the home
agent (Section 10.1). Each such Binding Cache entry records the agent (Sections 10.1 and 10.3.1).
mobile node's binding with its primary care-of address and is
marked as a "home registration" (Section 10.2).
- Every home agent MUST be able to intercept packets (using - Every home agent MUST be able to intercept packets (using
proxy Neighbor Discovery [12]) addressed to a mobile node for proxy Neighbor Discovery [12]) addressed to a mobile node for
which it is currently serving as the home agent, on that mobile which it is currently serving as the home agent, on that mobile
node's home link, while the mobile node is away from home node's home link, while the mobile node is away from home
(Section 10.4). (Section 10.4.1).
- Every home agent MUST be able to encapsulate [15] such - Every home agent MUST be able to encapsulate [15] such
intercepted packets in order to tunnel them to the primary intercepted packets in order to tunnel them to the primary
care-of address for the mobile node indicated in its binding in care-of address for the mobile node indicated in its binding in
the home agent's Binding Cache (Section 10.5). the home agent's Binding Cache (Section 10.4.2).
- Every home agent MUST support decapsulating [15] reverse tunneled - Every home agent MUST support decapsulating [15] reverse tunneled
packets sent to it from a mobile node's home address. Every home packets sent to it from a mobile node's home address. Every home
agent MUST also check that the source address in the tunneled agent MUST also check that the source address in the tunneled
packets corresponds to the currently registered location of the packets corresponds to the currently registered location of the
mobile node (Section 10.6). mobile node (Section 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 - Every home agent MUST be able to return a Binding Acknowledgement
message in response to a Binding Update option received with the in response to a Binding Update (Section 10.3.1).
Acknowledge (A) bit set (Section 10.2).
- Every home agent MUST maintain a separate Home Agents List for - Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in each link on which it is serving as a home agent, as described in
Section 4.5. Sections 10.1 and 10.5.1.
- Every home agent MUST be able to accept packets addressed to - Every home agent MUST be able to accept packets addressed to
the "Mobile IPv6 Home-Agents" anycast address for the subnet the Mobile IPv6 Home-Agents anycast address for the subnet
on which it is serving as a home agent [16], and MUST be on which it is serving as a home agent [16], and MUST be
able to participate in dynamic home agent address discovery able to participate in dynamic home agent address discovery
(Section 10.9). (Section 10.5).
- Every home agent SHOULD support a configuration mechanism to - Every home agent SHOULD support a configuration mechanism to
allow a system administrator to manually set the value to be sent allow a system administrator to manually set the value to be sent
by this home agent in the Home Agent Preference field of the Home by this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends Agent Information Option in Router Advertisements that it sends
(Section 7.4). (Section 7.4).
- Every home agent SHOULD support sending ICMP Mobile Prefix - Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
Solicitations (Section 6.7). This behavior MUST be configurable, Solicitations (Section 6.7). This behavior MUST be configurable,
so that home agents can be configured to avoid sending such so that home agents can be configured to avoid sending such
Prefix Advertisements according to the needs of the network Prefix Advertisements according to the needs of the network
administration in the home domain. administration in the home domain.
8.5. Requirements for IPv6 Mobile Nodes - 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 Finally, the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes: of functioning as mobile nodes:
- Every IPv6 mobile node MUST be able to perform IPv6 encapsulation - The node MUST maintain a Binding Update List (Section 11.1).
and decapsulation [15].
- Every IPv6 mobile node MUST support the return routability - The node MUST support sending packets containing a Home
procedure (Section 5.2.5). Address option (Section 11.3.1), and follow the required IPsec
interaction (Section 11.3.2).
- Every IPv6 mobile node MUST be able to send Binding Update - The node MUST be able to perform IPv6 encapsulation and
messages, as specified in Sections 11.6.1, 11.6.2, and 11.6.6. decapsulation [15].
- Every IPv6 mobile node MUST be able to receive and process - The node MUST be able to process type 2 routing header as defined
Binding Acknowledgement messages, as specified in Section 11.6.3. in Sections 6.4 and 11.3.3.
- Every IPv6 mobile node MUST maintain a Binding Update List in - The node MUST support receiving a Binding Error message
which it records the IP address of each other node to which it (Section 11.7.5).
has sent a Binding Update, for which the Lifetime sent in that
binding has not yet expired (Section 11.1).
- Every IPv6 mobile node MUST support receiving a Binding Refresh - The node SHOULD support receiving ICMP errors (Section 11.3.4).
Request (Section 6.1.2), by responding with a Binding Update
message.
- Every IPv6 mobile node MUST support sending packets containing a - The node MUST support movement detection, care-of address
Home Address option (Section 11.2.1). formation, and returning home (Section 11.5).
- Every IPv6 mobile node MUST maintain a Home Agents List, as - The node MUST be able to process Mobility Headers as described in
described in Section 4.5. Section 11.2.
- Every mobile node MUST support receiving Mobile Prefix - The node MUST support the return routability procedure
Advertisements (Section 11.3.4) and reconfiguring its home (Section 11.6).
address based on the prefix information contained therein.
- Every IPv6 mobile node SHOULD support use of the dynamic - The node MUST be able to send Binding Updates, as specified in
home agent address discovery mechanism, as described in Sections 11.7.1 and 11.7.2.
Section 11.3.2.
9. Correspondent Node Operation - The node MUST be able to receive and process Binding
Acknowledgements, as specified in Section 11.7.3.
This section explains the special processing required for the return - The node MUST support receiving a Binding Refresh Request
routability and binding procedures, as well as to manage the binding (Section 6.1.2), by responding with a Binding Update.
cache, handle ICMP messages and send packets to a mobile node.
- The node MUST support receiving Mobile Prefix Advertisements
(Section 11.4.3) and reconfiguring its home address based on the
prefix information contained therein.
- The node SHOULD support use of the dynamic home agent address
discovery mechanism, as described in Section 11.4.1.
9. Correspondent Node Operation
9.1. Conceptual Data Structures 9.1. Conceptual Data Structures
Each IPv6 node maintains a Binding Cache of bindings for other nodes. IPv6 nodes with route optimization support maintain a Binding Cache
A separate Binding Cache SHOULD be maintained by each IPv6 node for of bindings for other nodes. A separate Binding Cache SHOULD be
each of its IPv6 addresses. The Binding Cache MAY be implemented in maintained by each IPv6 node for each of its IPv6 addresses. The
any manner consistent with the external behavior described in this Binding Cache MAY be implemented in any manner consistent with the
document, for example by being combined with the node's Destination external behavior described in this document, for example by being
Cache as maintained by Neighbor Discovery [12]. When sending a combined with the node's Destination Cache as maintained by Neighbor
packet, the Binding Cache is searched before the Neighbor Discovery Discovery [12]. When sending a packet, the Binding Cache is searched
conceptual Destination Cache [12] (i.e., any Binding Cache entry for before the Neighbor Discovery conceptual Destination Cache [12].
this destination SHOULD take precedence over any Destination Cache That is, any Binding Cache entry for this destination SHOULD take
entry for the same destination). precedence over any Destination Cache entry for the same destination.
Each Binding Cache entry conceptually contains the following fields: Each Binding Cache entry conceptually contains the following fields:
- The home address of the mobile node for which this is the Binding - 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 Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent. Binding Cache for the destination address of a packet being sent.
If the destination address of the packet matches the home address If the destination address of the packet matches the home address
in the Binding Cache entry, this entry SHOULD be used in routing in the Binding Cache entry, this entry SHOULD be used in routing
that packet. that packet.
- The care-of address for the mobile node indicated by the home - The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry. If the destination address field in this Binding Cache entry. If the destination
address of a packet being routed by a node matches the home address of a packet being routed by a node matches the home
address in this entry, the packet SHOULD be routed to this address in this entry, the packet SHOULD be routed to this
care-of address. This is described in Section 9.6 for packets care-of address. This is described in Section 9.3.2 for packets
originated by this node, and in Section 10.5 if this node is the originated by this node.
mobile node's home agent and the packet was intercepted by it on
the home link.
- A lifetime value, indicating the remaining lifetime for this - A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from Binding Cache entry. The lifetime value is initialized from
the Lifetime field in the Binding Update that created or last the Lifetime field in the Binding Update that created or last
modified this Binding Cache entry. Once the lifetime of this modified this Binding Cache entry. Once the lifetime of this
entry expires, the entry MUST be deleted from the Binding Cache. entry expires, the entry MUST be deleted from the Binding Cache.
- A flag indicating whether or not this Binding Cache entry is a - A flag indicating whether or not this Binding Cache entry is a
"home registration" entry. home registration entry.
- The maximum value of the Sequence Number field received in - The maximum value of the Sequence Number field received in
previous Binding Updates for this mobile node home address. previous Binding Updates for this mobile node home address. The
The Sequence Number field is 16 bits long, and all comparisons Sequence Number field is 16 bits long. Sequence Number values
between Sequence Number values MUST be performed modulo 2**15 as MUST be compared modulo 2**16 as explained in Section 9.5.1.
explained in Section 9.4.1.
- Recent usage information for this Binding Cache entry, as needed - Usage information for this Binding Cache entry. This is needed
to implement the cache replacement policy in use in the Binding to implement the cache replacement policy in use in the Binding
Cache and to assist in determining whether a Binding Refresh Cache. Recent use of a cache entry also serves as an indication
Request should be sent when the lifetime of this entry nears that a Binding Refresh Request should be sent when the lifetime
expiration. of this entry nears expiration.
Binding Cache entries not marked as "home registrations" MAY be Binding Cache entries not marked as home registrations MAY be
replaced at any time by any reasonable local cache replacement policy replaced at any time by any reasonable local cache replacement policy
but SHOULD NOT be unnecessarily deleted. The Binding Cache for any 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 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 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 Cache MUST NOT be changed in response to a Home Address option in a
a received packet. The contents of all of a node's Binding Cache received packet.
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 9.2. Processing Mobility Headers
option or a Mobility Header (or both) require special processing at
the correspondent node as explained below.
9.2.1. Processing Mobility Header (MH) Messages Mobility Header processing MUST observe the following rules:
All IPv6 correspondent nodes MUST observe the following rules when 1. The MH Type field MUST have a known value (Section 6.1.1).
processing Mobility Header messages: Otherwise, the node MUST discard the message and SHOULD issue a
Binding Error message as described in Section 9.3.3, with Status
field set to 2 (unrecognized MH Type value).
1. If an MH message of unknown type is received (Section 6.1, the 2. The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
correspondent node SHOULD issue a Binding Error message to the Otherwise, the node MUST silently discard the message.
packet's Source Address with Status field set to 2. Finally, the
correspondent node MUST discard the packet.
2. If the "Next Header" field is not NO_NXTHDR (59 decimal), the 3. The checksum must be verified as per Section 6.1. Otherwise, the
packet MUST be silently discarded. node MUST silently discard the message.
3. The checksum must be verified as per Section 6.1. Subsequent checks depend on the particular Mobility Header, as
specified in Sections 9.4 and 9.5.
Subsequent checks depend on the particular Mobility Header message, 9.3. Packet Processing
as specified in Sections 9.3 and 9.4. Subsequent checks depend
on the particular Mobility Header message. There are two types
of Mobility Header messages. The return routability procedure
(Section 9.3) is used to verify liveness of the mobile node at both
its home address as well as its care-of address. These liveness
probes are used to secure binding updates.
The other type of Mobility Header messages are directly concerned This section describes how the correspondent node sends packets to
with managing bindings (Section 9.4). the mobile node, and receives packets from it.
9.2.2. Receiving Packets with Home Address Destination Option 9.3.1. Receiving Packets with Home Address Destination Option
If the correspondent node has a Binding Cache Entry for the home If the correspondent node has a Binding Cache entry for the home
address of a mobile node, packets sent by the mobile node MAY include address of a mobile node, packets sent by the mobile node MAY include
a Home Address destination option. The correspondent node MUST a Home Address destination option.
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 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.
Due to the threat of reflection attacks, this specification requires Packets containing a Home Address option MUST be dropped if the given
that packets containing a Home Address option MUST be dropped if home address is not a unicast routable address.
there is no corresponding Binding Cache Entry for the given home
address and the packet was not protected by IPsec. A corresponding
Binding Cache Entry MUST have the currently registered care-of
address equal to the source address of the packet. A packet that
contains 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.
If the packet is dropped due the above tests, the correspondent nodes Packets containing a Home Address option MUST also be dropped if
SHOULD send the Binding Error message to the source address of the there is no corresponding Binding Cache entry for the given home
packet that contained the Home Address option (see Section 6.1.9). address. A corresponding Binding Cache entry MUST have the currently
The Status field in this message should be set to 1. These messages registered care-of address equal to the source address of the packet.
SHOULD be rate-limited. These tests MUST NOT be done for packets that contain a Binding
Update and a Home Address option.
If the packet is dropped due the above tests, the correspondent node
SHOULD send the Binding Error message as described in Section 9.3.3.
The Status field in this message should be set to 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 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 No additional authentication of the Home Address option is
required, except that if the IPv6 header of a packet is covered required, except that if the IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the by authentication, then that authentication MUST also cover the
Home Address option; this coverage is achieved automatically by the Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en-route 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 to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication the authentication computation. By requiring that any authentication
of the IPv6 header also cover the Home Address option, the security 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 of the Source Address field in the IPv6 header is not compromised by
the presence of a Home Address option. Security issues related to the presence of a Home Address option. When attempting to verify
the Home Address option are discussed further in Section 5. When authentication data in a packet that contains a Home Address option,
attempting to verify authentication data in a packet that contains the receiving node MUST make the calculation as if the care-of
a Home Address option, the receiving node MUST make the calculation address were present in the Home Address option, and the home address
as if the care-of address were present in the Home Address option, were present in the source IPv6 address field of the IPv6 header.
and the home address were present in the source IPv6 address field This conforms with the calculation specified in Section 11.3.2.
of the IPv6 header. This conforms with the calculation specified in
section 11.2.2.
9.3. Return Routability Procedure 9.3.2. 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 the
packet is being sent. If the sending node has a Binding Cache entry
for this address, the sending node SHOULD use a type 2 routing header
to route the packet to this mobile node (the destination node) by way
of its care-of address. Assuming there are no additional routing
headers in this packet beyond those needed by Mobile IPv6, the mobile
node sets the fields in the packet's IPv6 header and routing header
as follows:
- The Destination Address in the packet's IPv6 header is set to the
mobile node's home address (the original destination address to
which the packet was being sent).
- The routing header is initialized to contain a single route
segment, containing the mobile node's care-of address copied from
the Binding Cache entry. The Segments Left field is, however,
temporarily set to zero.
The IP layer will insert the routing header before performing IPsec
processing. The IPsec Security Policy Database will be consulted
based on the IP source address and the 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 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 (the mobile node has
associated the care-of address with its network interface).
Note that following the above conceptual model in an implementation
creates some additional requirements for path MTU discovery since the
layer that decides the packet size (e.g., TCP and 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 packet will be delivered directly 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 the mobile node's home agent and tunneled to the
mobile node's current primary care-of address.
9.3.3. Sending Binding Error Messages
Sections 9.2 and 9.3.1 describe error conditions that lead to a need
to send a Binding Error message.
A Binding Error message is sent to the 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 field in the Binding Error message MUST be copied
from the Home Address field in the Home Address destination option of
the offending packet, or set to the unspecified address if no such
option appeared in the packet.
Binding Error messages are subject to rate limiting in the same
manner as is done for ICMPv6 messages [14].
9.3.4. Receiving ICMP Error Messages
When the correspondent node has a Binding Cache entry for a mobile
node, all traffic destined to the mobile node goes directly to the
current care-of address of the mobile node using a routing header.
Any ICMP error message caused by packets on their way to the care-of
address will be returned in the normal manner to the correspondent
node.
On the other hand, if the correspondent node has no Binding Cache
entry for the mobile node, the packet will be routed through the
mobile node's home link. Any ICMP error message caused by the
packet on its way to the mobile node while in the tunnel, will be
transmitted to the mobile node's home agent. By the definition of
IPv6 encapsulation [15], the home agent MUST relay certain ICMP error
messages back to the original sender of the packet, which in this
case is the correspondent node.
Thus, in all cases, any meaningful ICMP error messages caused by
packets from a correspondent node to a mobile node will be returned
to the correspondent node. If the correspondent node receives
persistent ICMP Destination Unreachable messages after sending
packets to a mobile node based on an entry in its Binding Cache, the
correspondent node SHOULD delete this Binding Cache entry.
9.4. Return Routability Procedure
This subsection specifies actions taken by a correspondent node This subsection specifies actions taken by a correspondent node
during the return routability procedure. during the return routability procedure.
9.3.1. Receiving Home Test Init Messages 9.4.1. Receiving Home Test Init Messages
Upon receiving a Home Test Init message, the correspondent node Upon receiving a Home Test Init message, the correspondent node
verifies the following: verifies the following:
- MH Type field for this message is 1. - The Header Len field in the Mobility Header MUST NOT be less than
the length specified in Section 6.1.3.
- 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. - The packet MUST NOT include a Home Address destination option.
In preparation for sending the corresponding Home Test Message, Any packet carrying a Home Test Init message which fails to satisfy
the correspondent node checks that it has the necessary material all of these tests MUST be silently ignored.
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 this material yet,
it MUST produce it before continuing with the return routability
procedure.
Section 9.3.3 specifies further processing. Otherwise, in preparation for sending the corresponding Home Test
Message, the correspondent node checks that it has the necessary
material to engage in a return routability procedure, as specified
in Section 5.2. The correspondent node MUST have a secret Kcn and
a nonce. If it does not have this material yet, it MUST produce it
before continuing with the return routability procedure.
9.3.2. Receiving Care-of Test Init Messages Section 9.4.3 specifies further processing.
9.4.2. Receiving Care-of Test Init Messages
Upon receiving a Care-of Test Init message, the correspondent node Upon receiving a Care-of Test Init message, the correspondent node
verifies the following: verifies the following:
- MH Type field for this message is 2. - The Header Len field in the Mobility Header MUST NOT be less than
the length specified in Section 6.1.4.
- The Header Extension Length field MUST be greater than or equal
to the length specified in Section 6.1.4.
- The packet MUST NOT include a Home Address destination option. - The packet MUST NOT include a Home Address destination option.
In preparation for sending the corresponding Care-of Test Message, Any packet carrying a Care-of Test Init message which fails to
the correspondent node checks that it has the necessary material satisfy all of these tests MUST be silently ignored.
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 Nl. If it does not have this material yet,
it MUST produce it before continuing with the return routability
procedure.
Section 9.3.4 specifies further processing. Otherwise, in preparation for sending the corresponding Care-of Test
Message, the correspondent node checks that it has the necessary
material to engage in a return routability procedure in the manner
described in Section 9.4.1.
9.3.3. Sending Home Test Messages Section 9.4.4 specifies further processing.
Unless already created, the correspondent node creates a "Home 9.4.3. Sending Home Test Messages
Cookie" and an associated "Home Nonce Index". It then creates a Home
The correspondent node creates a home keygen token and uses the
current nonce index as the Home Nonce Index. It then creates a Home
Test message (Section 6.1.5) and sends it to the mobile node at the Test message (Section 6.1.5) and sends it to the mobile node at the
latter's home address. latter's home address. 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.
9.3.4. Sending Care-of Test Messages 9.4.4. Sending Care-of Test Messages
Unless already created, the correspondent node creates a "Care-of The correspondent node creates a care-of nonce and uses the current
Cookie" and an associated "Care-of Nonce Index". It then creates a nonce index as the Care-of Nonce Index. It then creates a Care-of
Care-of Test message (Section 6.1.6) and sends it to the mobile node Test message (Section 6.1.6) and sends it to the mobile node at the
at the latter's care-of address. latter's care-of address.
9.4. Processing Bindings 9.5. Processing Bindings
This section explains how the correspondent node processes the This section explains how the correspondent node processes messages
binding cache messages. These messages are: related to bindings. These messages are:
- Binding Update - Binding Update
- Binding Refresh Request - Binding Refresh Request
- Binding Acknowledgement - Binding Acknowledgement
- Binding Error - Binding Error
9.4.1. Receiving Binding Updates 9.5.1. Receiving Binding Updates
Before accepting a Binding Update message, the receiving node MUST Before accepting a Binding Update, the receiving node MUST validate
validate the Binding Update according to the following tests: the Binding Update according to the following tests:
- The packet MUST contain a Home Address option. - The packet MUST contain a Home Address option with a unicast
routable home address, unless the Source Address is the home
address of the mobile node
- The Header Len field in the Binding Update option is greater than - The Header Len field in the Mobility Header is no less than the
or equal to the length specified in Section 6.1.7. length specified in Section 6.1.7.
- The Sequence Number field in the Binding Update message is - The Sequence Number field in the Binding Update is greater than
greater than the Sequence Number received in the previous Binding the Sequence Number received in the previous Binding Update for
Update for this home address, if any. this home address, if any.
This Sequence Number comparison MUST be performed modulo 2**16, This Sequence Number comparison MUST be performed modulo 2**16,
i.e., the number is a free running counter represented modulo i.e., the number is a free running counter represented modulo
65536. A Sequence Number in a received Binding Update is 65536. A Sequence Number in a received Binding Update is
considered less than or equal to the last received number if considered less than or equal to the last received number if
its value lies in the range of the last received number and the its value lies in the range of the last received number and the
preceding 32767 values, inclusive. For example, if the last preceding 32767 values, inclusive. For example, if the last
received sequence number was 15, then messages with sequence received sequence number was 15, then messages with sequence
numbers 0 through 15, as well as 32784 through 65535, would be numbers 0 through 15, as well as 32784 through 65535, would be
considered less than or equal. considered less than or equal.
When the return routability procedure is used as an authorization When the return routability procedure is used to enable the
method, the following are also required: establishment of nonce indices as inputs to the creation of the
binding key Kbm, the following are also required:
- The Home and Care-of Nonce Index values in the Nonce Indices - A Nonce Indices mobility option MUST be present, and the Home and
mobility option are recognized by the correspondent node. As Care-of Nonce Index values in this option MUST be recent enough
described in Section 5.2, the correspondent node discards Nonce to be recognized by the correspondent node.
values that are too old.
- The correspondent node MUST re-generate the Home Cookie and the - The correspondent node MUST re-generate the home keygen token and
Care-of Cookie from the information contained in the packet. the care-of keygen token from the information contained in the
It then generates the session key Kbu and uses it to verify packet. It then generates the binding management key Kbm and
the authenticator field in the Binding Update as specified in uses it to verify the authenticator field in the Binding Update
Section 6.1.7. Note that a care-of address different from the as specified in Section 6.1.7.
Source Address MAY have been specified by including an Alternate
Care-of Address mobility option in the Binding Update message.
When such message is received and the return routability
procedure is used as an authorization method, the correspondent
node MUST verify the authenticator by using the address within
the Alternate Care-of Address in the calculations.
- The Binding Authorization Data option MUST be present, and its When using Kbm for validating the Binding Update, the following are
contents MUST be satisfy rules presented in Section 5.2.6. required:
- The Binding Authorization Data mobility option MUST be present,
and its contents MUST satisfy rules presented in Section 5.2.6.
Note that a care-of address different from the Source Address MAY
have been specified by including an Alternate Care-of Address
mobility option in the Binding Update. When such message is
received and the return routability procedure is used as an
authorization method, the correspondent node MUST verify the
authenticator by using the address within the Alternate Care-of
Address in the calculations.
- The Binding Authorization Data mobility option MUST be the last
option and MUST NOT have trailing padding.
- The Home Registration (H) bit MUST NOT be set.
If the mobile node sends a sequence number which is not greater than If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the the sequence number from the last successful Binding Update, then the
receiving node MUST send back a Binding Acknowledgement with status receiving node MUST send back a Binding Acknowledgement with status
code 141, and the last accepted sequence number in the Sequence code 135, and the last accepted sequence number in the Sequence
Number field of the Binding Acknowledgement. Number field of the Binding Acknowledgement.
If the mobile node sends a Home or Care-of Nonce Index value which is If the receiving node no longer recognizes the Home Nonce
no longer recognized by the correspondent node, then the receiving Index value, Care-of Nonce Index value, or both values from the
node MUST send back a Binding Acknowledgement with status code 144 or Binding Update, then the receiving node MUST send back a Binding
145, respectively. Acknowledgement with status code 136, 137, or 138, respectively.
Any Binding Update which fails to satisfy all of these tests for
any reason other than insufficiency of the Sequence Number or Nonce
Indices MUST be silently ignored, and the packet carrying the Binding
Update MUST be discarded.
In this section, the care-of address refers to the IPv6 address, Packets carrying Binding Updates that fail to satisfy all of these
which was originally located in the IPv6 header when the packet was tests for any reason other than insufficiency of the Sequence Number
transmitted by the mobile node. or expired nonce index values MUST be silently discarded.
If the Binding Update is valid according to the tests above, then the If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows: Binding Update is processed further as follows:
- If the Lifetime specified in the Binding Update is nonzero and - If the Lifetime specified in the Binding Update is nonzero and
the specified Care-of Address is not equal to the home address the specified care-of address is not equal to the home address
for the binding, then this is a request to cache a binding for for the binding, then this is a request to cache a binding for
the mobile node. If the Home Registration (H) bit is set in the the mobile node. If the Home Registration (H) bit is set in the
Binding Update, the Binding Update is processed according to the Binding Update, the Binding Update is processed according to the
procedure specified in Section 10.2; otherwise, it is processed procedure specified in Section 10.3.1; otherwise, it is processed
according to the procedure specified in Section 9.4.2. according to the procedure specified in Section 9.5.2.
- If the Lifetime specified in the Binding Update is zero or the - If the Lifetime specified in the Binding Update is zero or the
specified Care-of Address matches the home address for the specified care-of address matches the home address for the
binding, then this is a request to delete the mobile node's binding, then this is a request to delete the mobile node's
cached binding. If the Home Registration (H) bit is set in the cached binding. The update MUST include a valid home nonce index
Binding Update, the Binding Update is processed according to the (the care-of nonce index MUST be ignored by the correspondent
procedure specified in Section 10.3; otherwise, it is processed node). In this case, generation of the binding management key
according to the procedure specified in Section 9.4.3. 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.
9.4.2. Requests to Cache a Binding The specified care-of address MUST be 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 Source Address field in the
packet's IPv6 header.
The home address for the binding MUST be determined as follows:
- If the Home Address destination option is present, the home
address is the address in that option.
- Otherwise, the home address is the Source Address field in the
packet's IPv6 header. This implies that the mobile node is at
home and is about to perform de-registration.
9.5.2. Requests to Cache a Binding
This section describes the processing of a valid Binding Update that 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 requests a node to cache a mobile node's binding, for which the Home
Registration (H) bit is not set in the Binding Update. Registration (H) bit is not set in the Binding Update.
In this case, the receiving node SHOULD create a new entry in its In this case, the receiving node SHOULD create a new entry in its
Binding Cache for this mobile node, or update its existing Binding Binding Cache for this mobile node, or update its existing Binding
Cache entry for this mobile node, if such an entry already exists. Cache entry for this mobile node, if such an entry already exists.
The lifetime for the Binding Cache entry is initialized from the The lifetime for the Binding Cache entry is initialized from the
Lifetime field specified in the Binding Update, although this Lifetime field specified in the Binding Update, although this
skipping to change at page 69, line 41 skipping to change at page 73, line 43
value specified in the Binding Update. Any Binding Cache entry MUST value specified in the Binding Update. Any Binding Cache entry MUST
be deleted after the expiration of its lifetime. be deleted after the expiration of its lifetime.
The Sequence Number value received from a mobile node in a Binding The Sequence Number value received from a mobile node in a Binding
Update is stored by a correspondent node in its Binding Cache entry Update is stored by a correspondent node in its Binding Cache entry
for that mobile node. If the receiving correspondent node has no for that mobile node. If the receiving correspondent node has no
Binding Cache entry for the sending mobile node, it MUST accept any Binding Cache entry for the sending mobile node, it MUST accept any
Sequence Number value in a received Binding Update from this mobile Sequence Number value in a received Binding Update from this mobile
node. node.
9.4.3. Requests to Delete a Binding The correspondent node MAY refuse to accept a new Binding Cache
entry, if it does not have sufficient resources. A new entry MAY
also be refused if the 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 Acknowledgement with
status value 130.
9.5.3. Requests to Delete a Binding
This section describes the processing of a valid Binding Update that This section describes the processing of a valid Binding Update that
requests a node to delete a mobile node's binding from its Binding requests a node to delete a mobile node's binding from its Binding
Cache, for which the Home Registration (H) bit is not set in the Cache, for which the Home Registration (H) bit is not set in the
Binding Update. Binding Update.
Any existing binding for the mobile node MUST be deleted. A Binding Any existing binding for the mobile node MUST be deleted. A Binding
Cache entry for the mobile node MUST NOT be created in response to Cache entry for the mobile node MUST NOT be created in response to
receiving the Binding Update. receiving the Binding Update.
If the binding cache entry was created by use of return routability If the Binding Cache entry was created by use of return routability
nonces, the correspondent node MUST ensure that the same nonces are nonces, the correspondent node MUST ensure that the same nonces are
not used again with the particular home and care-of address. If not used again with the particular home and care-of address. If
both nonces are still valid, the correspondent node has to remember both nonces are still valid, the correspondent node has to remember
the particular combination of nonce indexes, addresses, and sequence the particular combination of nonce indexes, addresses, and sequence
number as illegal, until at least one of the nonces has become too number as illegal, until at least one of the nonces has become too
old. old.
9.4.4. Sending Binding Acknowledgements 9.5.4. Sending Binding Acknowledgements
When any node receives a packet containing a Binding Update message A Binding Acknowledgement may be sent to indicate receipt of a
in which the Acknowledge (A) bit is set, it MUST return a Binding Binding Update as follows:
Acknowledgement message acknowledging receipt of the Binding Update.
If the node accepts the Binding Update and creates or updates an
entry in its Binding Cache for this binding, the Status field in the
Binding Acknowledgement MUST be set to a value less than 128; if, on
the other hand the Binding Update is accepted and the `A' bit is not
set, the node SHOULD NOT send a Binding Acknowledgement. If the node
rejects the Binding Update and does not create or update an entry for
this binding, a Binding Acknowledgement MUST be sent even if the `A'
bit was not set, and the Status field in the Binding Acknowledgement
MUST be set to a value greater than or equal to 128. Specific values
for the Status field are described in Section 6.1.8 and in the IANA
registry of assigned numbers [18].
The packet in which the Binding Acknowledgement is returned - If the Binding Update was silently discarded as described in
MUST meet the specific authentication requirements for Binding Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
Acknowledgements, defined in Section 5.2. Furthermore, if the packet
is to be sent to the mobile node at any address other than the mobile
node's home address, it MUST be sent using a Routing header (even if
the binding was rejected). The intermediate IP address, to which
the packet will be delivered immediately before the home address, is
determined as follows:
- Whenever the Binding Update is accepted with a nonzero lifetime, - Otherwise, if the Acknowledge (A) bit set is set in the Binding
the routing header will be constructed using the care-of address Update, a Binding Acknowledgement MUST be sent.
as described in Section 9.6.
- Otherwise, if the Source IP Address of the packet containing - Otherwise, if the node rejects the Binding Update, a Binding
the Binding Update, is legal for inclusion in a Routing Header, Acknowledgement MUST be sent.
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 the Binding
Acknowledgement.
Otherwise, if the Binding Update has a zero lifetime but the Source - Otherwise, if the node accepts the Binding Update, a Binding
IP address is not allowable for use within the Routing Header, Acknowledgement SHOULD NOT be sent.
the Binding Acknowledgment MUST be sent to the mobile node's home
address. If the node accepts the Binding Update and creates or updates
an entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value less than 128. Otherwise, the
Status field MUST be set to a value greater than or equal to 128.
Values for the Status field are described in Section 6.1.8 and in the
IANA registry of assigned numbers [18].
If the Status field in the Binding Acknowledgement contains the value
136 (expired home nonce index), 137 (expired care-of nonce index),
or 138 (expired nonces), then the message MUST NOT include the
Binding Authorization Data mobility option. Otherwise, the Binding
Authorization Data mobility option MUST be included, and MUST meet
the specific authentication requirements for Binding Acknowledgements
as defined in Section 5.2.
If the Source Address field of the IPv6 header that carried the
Binding Update does not contain a unicast address, the Binding
Acknowledgement MUST NOT be sent, and the Binding Update packet MUST
be silently discarded. Otherwise, the acknowledgement MUST be sent
to the Source Address. Unlike the treatment of regular packets, this
addressing procedure does not use information from the Binding Cache.
If the Source Address is the home address of the mobile node, i.e.,
the Binding Update did not contain a Home Address destination option,
then the Binding Acknowledgement MUST be sent to that address,
and the routing header MUST NOT be used. Otherwise, the Binding
Acknowledgement MUST be sent using a type 2 routing header which
contains the mobile node's home address.
Entries in a node's Binding Cache MUST be deleted when their lifetime Entries in a node's Binding Cache MUST be deleted when their lifetime
expires. expires.
9.4.5. Sending Binding Refresh Requests 9.5.5. Sending Binding Refresh Requests
If a Binding Cache entry being deleted is still in active use If a Binding Cache entry being deleted is still in active use
in sending packets to a mobile node, the next packet sent to the in sending packets to a mobile node, the next packet sent to the
mobile node will be routed normally to the mobile node's home link. mobile node will be routed normally to the mobile node's home link.
Communication with the mobile node continues, but the tunneling Communication with the mobile node continues, but the tunneling
from the home network creates additional overhead and latency in from the home network creates additional overhead and latency in
delivering packets to the mobile node. delivering packets to the mobile node.
If the sender knows that the Binding Cache entry is still in active If the sender knows that the Binding Cache entry is still in active
use, it MAY send a Binding Refresh Request message to the mobile node use, it MAY send a Binding Refresh Request message to the mobile node
in an attempt to avoid this overhead and latency due to deleting and in an attempt to avoid this overhead and latency due to deleting and
recreating the Binding Cache entry. The Binding Refresh Request recreating the Binding Cache entry. The Binding Refresh Request
message is sent in the same way as any packet addressed to the mobile message is sent in the same way as any packet addressed to the mobile
node (Section 9.6). node (Section 9.3.2).
The correspondent node MAY retransmit Binding Refresh Request The correspondent node MAY retransmit Binding Refresh Request
messages provided that rate limitation is applied. The correspondent messages provided that rate limitation is applied. The correspondent
node SHOULD stop retransmitting when it receive a Home Test Init node SHOULD stop retransmitting when it receives a Binding Update.
message, as the mobile node is responsible for retransmissions during
the return routability procedure.
9.4.6. Sending Binding Error Messages
If the correspondent node receives a packet with a Home Address
destination option it MUST verify that it has a binding for that
mobile node. Specifically, it MUST have a binding entry for the
mobile node's home address (as obtained from the Home Address option)
at the mobile node's care-of address (from the IP source address of
the packet). If the correspondent node does not find such a binding
entry, it MUST discard the packet. It MUST also return a Binding
Error message (Section 6.1.9), subject to rate limiting in the same
manner as is done for ICMPv6 messages [14].
9.5. Cache Replacement Policy 9.6. Cache Replacement Policy
Conceptually, a node maintains a separate timer for each entry in its Conceptually, a node maintains a separate timer for each entry in its
Binding Cache. When creating or updating a Binding Cache entry in Binding Cache. When creating or updating a Binding Cache entry in
response to a received and accepted Binding Update, the node sets the response to a received and accepted Binding Update, the node sets the
timer for this entry to the specified Lifetime period. Any entry in timer for this entry to the specified Lifetime period. Any entry in
a node's Binding Cache MUST be deleted after the expiration of the a node's Binding Cache MUST be deleted after the expiration of the
Lifetime specified in the Binding Update from which the entry was Lifetime specified in the Binding Update from which the entry was
created or last updated. created or last updated.
Each node's Binding Cache will, by necessity, have a finite size. Each node's Binding Cache will, by necessity, have a finite size.
A node MAY use any reasonable local policy for managing the space A node MAY use any reasonable local policy for managing the space
within its Binding Cache, except that any entry marked as a "home within its Binding Cache, except that any entry marked as a home
registration" (Section 10.2) MUST NOT be deleted from the cache until registration (Section 10.3.1) MUST NOT be deleted from the cache
the expiration of its lifetime period. When such "home registration" until the expiration of its lifetime period. When such home
entries are deleted, the home agent MUST also cease intercepting registration entries are deleted, the home agent MUST also cease
packets on the mobile node's home link addressed to the mobile node intercepting packets on the mobile node's home link addressed to
(Section 10.4), just as if the mobile node had de-registered its the mobile node (Section 10.4.1), just as if the mobile node had
primary care-of address (see Section 10.3). de-registered its primary care-of address (see Section 10.3.2).
When attempting to add a new "home registration" entry in response When attempting to add a new home registration entry in response
to a Binding Update with