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