draft-ietf-mobileip-ipv6-16.txt   draft-ietf-mobileip-ipv6-17.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 Perkins
Nokia Research Center Nokia Research Center
22 March 2002 Jari Arkko
Ericsson
1 May 2002
Mobility Support in IPv6 Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-16.txt> <draft-ietf-mobileip-ipv6-17.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 33 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.
Abstract
This document specifies the operation of mobile computers using IPv6. This document specifies the operation of mobile computers using IPv6.
Each mobile node is always identified by its home address, regardless Each mobile node is always identified by its home address, regardless
of its current point of attachment to the Internet. While situated of its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a care-of away from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current address, which provides information about the mobile node's current
location. IPv6 packets addressed to a mobile node's home address are location. IPv6 packets addressed to a mobile node's home address are
transparently routed to its care-of address. The protocol enables transparently routed to its care-of address. The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with IPv6 nodes to cache the binding of a mobile node's home address
its care-of address, and to then send any packets destined for the with its care-of address, and to then send any packets destined for
mobile node directly to it at this care-of address. To support this the mobile node directly to it at this care-of address. To support
operation, Mobile IPv6 defines four new IPv6 destination options, this operation, Mobile IPv6 defines a new IPv6 protocol and a new
including one that MUST be supported in packets received by any node, destination option. All IPv6 nodes, whether mobile or stationary,
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 3 2. Comparison with Mobile IP for IPv4 2
3. Terminology 6 3. Terminology 4
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 7 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Mobile IPv6 8 4. Overview of Mobile IPv6 9
4.1. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9
4.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 4.2. New IPv6 Protocols . . . . . . . . . . . . . . . . . . . 12
4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13 4.3. New IPv6 Destination Options . . . . . . . . . . . . . . 13
4.4. Alignment Requirements for New Destination Options . . . 13 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 14
4.5. Security Design . . . . . . . . . . . . . . . . . . . . . 14 4.5. Conceptual Data Structures . . . . . . . . . . . . . . . 15
4.5.1. Security Threats . . . . . . . . . . . . . . . . 14 4.6. Binding Management . . . . . . . . . . . . . . . . . . . 16
4.5.2. Security Features . . . . . . . . . . . . . . . . 15
4.5.3. Securing Tunnels to and from the Home Agents . . 17
4.5.4. Securing Binding Updates to Home Agents . . . . . 17
4.5.5. Securing Binding Updates to Correspondent Nodes . 18
4.5.6. Preventing Denial-of-Service Attacks . . . . . . 22
4.5.7. Design Rationale . . . . . . . . . . . . . . . . 23
4.6. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 24
4.7. Conceptual Data Structures . . . . . . . . . . . . . . . 25
4.8. Binding Management . . . . . . . . . . . . . . . . . . . 30
5. New IPv6 Destination Options and Message Types 31 5. Overview of Mobile IPv6 Security 17
5.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31 5.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32 5.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Binding Request (BR) Message . . . . . . . . . . 33 5.3. Tunnels to and from the Home Agents . . . . . . . . . . . 20
5.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34 5.4. Binding Updates to Home Agents . . . . . . . . . . . . . 20
5.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 35 5.5. Binding Updates to Correspondent Nodes . . . . . . . . . 21
5.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 36 5.5.1. Node Keys . . . . . . . . . . . . . . . . . . . . 22
5.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 38 5.5.2. Nonces . . . . . . . . . . . . . . . . . . . . . 23
5.1.7. Binding Update (BU) Message . . . . . . . . . . . 40 5.5.3. Cookies . . . . . . . . . . . . . . . . . . . . . 23
5.1.8. Binding Acknowledgement (BA) Message . . . . . . 44 5.5.4. Cryptographic Functions . . . . . . . . . . . . . 24
5.1.9. Binding Missing (BM) Message . . . . . . . . . . 49 5.5.5. Return Routability Procedure . . . . . . . . . . 24
5.2. Mobility Header Parameters . . . . . . . . . . . . . . . 51 5.5.6. Applying Return Routability for Correspondent
5.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51 Bindings . . . . . . . . . . . . . . . . . 28
5.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52 5.5.7. Updating Node Keys and Nonces . . . . . . . . . . 29
5.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52 5.5.8. Preventing Replay Attacks . . . . . . . . . . . . 30
5.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53 5.5.9. Preventing Denial-of-Service Attacks . . . . . . 30
5.2.5. Alternate Care-of Address . . . . . . . . . . . . 53 5.5.10. Correspondent Binding Procedure Extensibility . . 31
5.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54
5.2.7. Authentication Data . . . . . . . . . . . . . . . 54
5.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55
5.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58
5.4.1. Routing Header Packet format . . . . . . . . . . 58
5.4.2. Sending RH type 2 . . . . . . . . . . . . . . . . 59
5.4.3. Verification by receiver . . . . . . . . . . . . 60
5.4.4. Extension header ordering . . . . . . . . . . . . 60
5.4.5. Reversing type 2 routing headers . . . . . . . . 60
5.5. Mobile IPv6 Destination Option Sub-Options . . . . . . . 61
5.5.1. Pad1 . . . . . . . . . . . . . . . . . . . . . . 62
5.5.2. PadN . . . . . . . . . . . . . . . . . . . . . . 62
5.6. ICMP Home Agent Address Discovery Request Message . . . . 63
5.7. ICMP Home Agent Address Discovery Reply Message . . . . . 64
5.8. ICMP Mobile Prefix Solicitation Message Format . . . . . 66
5.9. ICMP Mobile Prefix Advertisement Message Format . . . . . 68
6. Modifications to IPv6 Neighbor Discovery 70 6. New IPv6 Protocols, Message Types, and Destination Option 31
6.1. Modified Router Advertisement Message Format . . . . . . 70 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 31
6.2. Modified Prefix Information Option Format . . . . . . . . 71 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . 32
6.3. New Advertisement Interval Option Format . . . . . . . . 73 6.1.2. Binding Refresh Request (BRR) Message . . . . . . 33
6.4. New Home Agent Information Option Format . . . . . . . . 74 6.1.3. Home Test Init (HoTI) Message . . . . . . . . . . 34
6.5. Changes to Sending Router Advertisements . . . . . . . . 76 6.1.4. Care-of Test Init (CoTI) Message . . . . . . . . 36
6.6. Changes to Sending Router Solicitations . . . . . . . . . 77 6.1.5. Home Test (HoT) Message . . . . . . . . . . . . . 37
6.1.6. Care-of Test (CoT) Message . . . . . . . . . . . 39
6.1.7. Binding Update (BU) Message . . . . . . . . . . . 41
6.1.8. Binding Acknowledgement (BA) Message . . . . . . 45
6.1.9. Binding Error (BE) Message . . . . . . . . . . . 49
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 51
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . 51
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . 52
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4. Unique Identifier . . . . . . . . . . . . . . . . 53
6.2.5. Alternate Care-of Address . . . . . . . . . . . . 53
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . 54
6.2.7. Binding Authorization Data . . . . . . . . . . . 54
6.3. Home Address Destination Option . . . . . . . . . . . . . 55
6.4. Routing Header type 2 . . . . . . . . . . . . . . . . . . 58
6.4.1. Routing Header Packet format . . . . . . . . . . 58
6.5. ICMP Home Agent Address Discovery Request Message . . . . 59
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 61
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 63
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 65
7. Requirements for Types of IPv6 Nodes 79 7. Modifications to IPv6 Neighbor Discovery 67
7.1. Requirements for All IPv6 Routers . . . . . . . . . . . . 79 7.1. Modified Router Advertisement Message Format . . . . . . 67
7.2. Requirements for IPv6 Home Agents . . . . . . . . . . . . 79 7.2. Modified Prefix Information Option Format . . . . . . . . 68
7.3. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 80 7.3. New Advertisement Interval Option Format . . . . . . . . 70
8. Correspondent Node Operation 82 7.4. New Home Agent Information Option Format . . . . . . . . 71
8.1. Receiving Packets from a Mobile Node . . . . . . . . . . 82 7.5. Changes to Sending Router Advertisements . . . . . . . . 73
8.2. Receiving Binding Updates . . . . . . . . . . . . . . . . 82 7.6. Changes to Sending Router Solicitations . . . . . . . . . 74
8.3. Requests to Cache a Binding . . . . . . . . . . . . . . . 83
8.4. Requests to Delete a Binding . . . . . . . . . . . . . . 84
8.5. Sending Binding Acknowledgements . . . . . . . . . . . . 84
8.6. Sending Binding Requests . . . . . . . . . . . . . . . . 85
8.7. Cache Replacement Policy . . . . . . . . . . . . . . . . 85
8.8. Receiving ICMP Error Messages . . . . . . . . . . . . . . 86
8.9. Sending Packets to a Mobile Node . . . . . . . . . . . . 87
9. Home Agent Operation 89 8. Requirements for Types of IPv6 Nodes 75
9.1. Primary Care-of Address Registration . . . . . . . . . . 89 8.1. Requirements for All IPv6 Hosts and Routers . . . . . . . 75
9.2. Primary Care-of Address De-Registration . . . . . . . . . 92 8.2. Requirements for All IPv6 Routers . . . . . . . . . . . . 75
9.3. Intercepting Packets for a Mobile Node . . . . . . . . . 92 8.3. Requirements for IPv6 Home Agents . . . . . . . . . . . . 76
9.4. Tunneling Intercepted Packets to a Mobile Node . . . . . 94 8.4. Requirements for IPv6 Mobile Nodes . . . . . . . . . . . 77
9.5. Handling Reverse Tunneled Packets from a Mobile Node . . 96
9.6. Protecting Return Routability Packets . . . . . . . . . . 96
9.7. Home Prefix Propagation . . . . . . . . . . . . . . . . . 96
9.8. Receiving Router Advertisement Messages . . . . . . . . . 97
9.9. Dynamic Home Agent Address Discovery . . . . . . . . . . 98
9.9.1. Aggregate List of Home Network Prefixes . . . . . 100
9.9.2. Scheduling Prefix Deliveries to the Mobile Node . 101
9.9.3. Sending Advertisements to the Mobile Node . . . . 103
9.9.4. Lifetimes for Changed Prefixes . . . . . . . . . 105
10. Mobile Node Operation 105 9. Correspondent Node Operation 78
10.1. Sending Packets While Away from Home . . . . . . . . . . 105 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 78
10.2. Interaction with Outbound IPsec Processing . . . . . . . 107 9.2. Receiving Packets from a Mobile Node . . . . . . . . . . 79
10.3. Receiving Packets While Away from Home . . . . . . . . . 108 9.2.1. Processing Mobility Header (MH) Messages . . . . 79
10.4. Movement Detection . . . . . . . . . . . . . . . . . . . 109 9.2.2. Receiving Packets with Home Address Destination
10.5. Receiving Local Router Advertisement Messages . . . . . . 112 Option . . . . . . . . . . . . . . . . . . 80
10.6. Forming New Care-of Addresses . . . . . . . . . . . . . . 114 9.3. Return Routability Procedure . . . . . . . . . . . . . . 80
10.7. Sending Binding Updates to the Home Agent . . . . . . . . 115 9.3.1. Receiving HoTI Messages . . . . . . . . . . . . . 81
10.8. Dynamic Home Agent Address Discovery . . . . . . . . . . 117 9.3.2. Receiving CoTI Messages . . . . . . . . . . . . . 81
10.9. Sending Binding Updates to Correspondent Nodes . . . . . 118 9.3.3. Sending HoT Messages . . . . . . . . . . . . . . 82
10.10. Receiving RR Messages . . . . . . . . . . . . . . . . . . 121 9.3.4. Sending CoT Messages . . . . . . . . . . . . . . 82
10.11. Establishing Forwarding from a Previous Care-of Address . 122 9.4. Processing Bindings . . . . . . . . . . . . . . . . . . . 82
10.12. Retransmitting Binding Updates . . . . . . . . . . . . . 123 9.4.1. Receiving Binding Updates . . . . . . . . . . . . 82
10.13. Rate Limiting for Sending Binding Updates . . . . . . . . 124 9.4.2. Requests to Cache a Binding . . . . . . . . . . . 84
10.14. Receiving Binding Acknowledgements . . . . . . . . . . . 124 9.4.3. Requests to Delete a Binding . . . . . . . . . . 84
10.15. Receiving Binding Requests . . . . . . . . . . . . . . . 125 9.4.4. Sending Binding Acknowledgements . . . . . . . . 85
10.16. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126 9.4.5. Sending Binding Refresh Requests . . . . . . . . 86
10.17. Receiving ICMP Error Messages . . . . . . . . . . . . . . 126 9.4.6. Sending Binding Error Messages . . . . . . . . . 87
10.18. Sending Mobile Prefix Solicitations . . . . . . . . . . . 126 9.5. Cache Replacement Policy . . . . . . . . . . . . . . . . 87
10.19. Receiving Mobile Prefix Advertisements . . . . . . . . . 127 9.6. Sending Packets to a Mobile Node . . . . . . . . . . . . 88
10.20. Using Multiple Care-of Addresses . . . . . . . . . . . . 128 9.7. Receiving ICMP Error Messages . . . . . . . . . . . . . . 89
10.21. Routing Multicast Packets . . . . . . . . . . . . . . . . 128
10.22. Returning Home . . . . . . . . . . . . . . . . . . . . . 129
11. Protocol Constants 131 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
12. Future Extensions 132 11. Mobile Node Operation 107
12.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 132 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 107
12.2. Triangular Routing and Unverified HAOs . . . . . . . . . 132 11.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 110
12.3. New Authorization Methods beyond RR . . . . . . . . . . . 132 11.2.1. Sending Packets While Away from Home . . . . . . 110
11.2.2. Interaction with Outbound IPsec Processing . . . 112
11.2.3. Receiving Packets While Away from Home . . . . . 114
11.2.4. Routing Multicast Packets . . . . . . . . . . . . 116
11.3. Home Agent and Prefix Management . . . . . . . . . . . . 116
11.3.1. Receiving Local Router Advertisement Messages . . 116
11.3.2. Dynamic Home Agent Address Discovery . . . . . . 118
11.3.3. Sending Mobile Prefix Solicitations . . . . . . . 119
11.3.4. Receiving Mobile Prefix Advertisements . . . . . 120
11.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . 121
11.4.1. Movement Detection . . . . . . . . . . . . . . . 121
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
13. IANA Considerations 133 12. Protocol Constants 141
14. Security Considerations 134 13. IANA Considerations 142
14.1. Security for the Tunneling to and from the Home Agent . . 134
14.2. Security for the Binding Updates to the Home Agent . . . 135 14. Security Considerations 143
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 14.3. Security for the Binding Updates to the Correspondent
Nodes . . . . . . . . . . . . . . . . . . . . . . . . 135 Nodes . . . . . . . . . . . . . . . . . . . . . . . . 144
14.4. Security for the Home Address Option . . . . . . . . . . 135 14.4. Security for the Home Address Destination Option . . . . 145
14.5. Firewall considerations . . . . . . . . . . . . . . . . . 136 14.5. Firewall considerations . . . . . . . . . . . . . . . . . 145
Acknowledgements 137 Acknowledgements 146
References 138 References 147
A. Changes from Previous Version of the Draft 140 A. State Machine for the Correspondent Binding Procedure 150
A.1. Changes from Draft Version ...-15 . . . . . . . . . . . . 140
A.2. Changes from Previous Versions of the Draft . . . . . . . 142
B. Remote Home Address Configuration 144 B. Changes from Previous Version of the Draft 159
B.1. Changes from Draft Version 16 . . . . . . . . . . . . . . 159
B.2. Changes from Draft Version 15 . . . . . . . . . . . . . . 161
B.3. Changes from Earlier Versions of the Draft . . . . . . . 162
Chairs' Addresses 145 C. Remote Home Address Configuration 164
Authors' Addresses 146 D. Future Extensions 165
D.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 165
D.2. Triangular Routing and Unverified Home Addresses . . . . 166
D.3. New Authorization Methods beyond Return Routability . . . 166
Chairs' Addresses 167
Authors' Addresses 167
1. Introduction 1. Introduction
This document specifies the operation of mobile computers using This document specifies the operation of mobile computers using
Internet Protocol Version 6 (IPv6) [6]. Without specific support Internet Protocol Version 6 (IPv6) [6]. Without specific support
for mobility in IPv6, packets destined to a mobile node (host or for mobility in IPv6, packets destined to a mobile node (host or
router) would not be able to reach it while the mobile node is away router) would not be able to reach it while the mobile node is away
from its home link (the link on which its home IPv6 subnet prefix is from its home link (the link on which its home IPv6 subnet prefix is
in use), since routing is based on the subnet prefix in a packet's in use), since routing is based on the subnet prefix in a packet's
destination IP address. In order to continue communication in spite destination IP address. In order to continue communication in spite
of its movement, a mobile node could change its IP address each time of its movement, a mobile node could change its IP address each time
it moves to a new link, but the mobile node would then not be able it moves to a new link, but the mobile node would then not be able
to maintain transport and higher-layer connections when it changes to maintain transport and higher-layer connections when it changes
location. Mobility support in IPv6 is particularly important, as location. Mobility support in IPv6 is particularly important, as
mobile computers are likely to account for a majority or at least a mobile computers are likely to account for a majority or at least a
substantial fraction of the population of the Internet during the substantial fraction of the population of the Internet during the
lifetime of IPv6. lifetime of IPv6.
The protocol operation defined here, known as Mobile IPv6, allows a The protocol defined in this document, known as Mobile IPv6, allows
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, and the mobile node may
continue to communicate with other nodes (stationary or mobile) after continue to communicate with other nodes (stationary or mobile) after
moving to a new link. The movement of a mobile node away from its moving to a new link. The movement of a mobile node away from its
home link is thus transparent to transport and higher-layer protocols home link is thus transparent to transport and higher-layer protocols
and applications. and applications.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
hierarchical form of mobility management, but such extensions are hierarchical form of mobility management, but such extensions are
beyond the scope of this document. beyond the scope of this document.
The protocol specified in this document solves the problem of The protocol specified in this document solves the problem of
transparently routing packets to and from mobile nodes while away transparently routing packets to and from mobile nodes while away
from home. However, it does not attempt to solve all general from home. However, it does not attempt to solve all general
problems related to the use of mobile computers or wireless networks. problems related to the use of mobile computers or wireless networks.
In particular, this protocol does not attempt to solve: 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. Some connectivity, such as are often found in wireless networks (but
aspects of this problem are addressed by the movement detection see Section 11.4.1).
procedure described in Section 10.4, but no attempt has been made
to fully solve this problem in its general form. Most aspects of
this problem can be solved by the workaround of restricting such
networks to only one router per link, although there are still
possible hidden terminal problems when two nodes on the same
link (on opposite sides of the router) attempt to communicate
directly.
- Access control on a link being visited by a mobile node. This - Access control on a link being visited by a mobile node.
is a general problem any time an unauthenticated node is allowed
to connect to any link layer. It is independent of whether the - Assistance for adaptive applications
connecting node uses Mobile IP, DHCP [2], or just "borrows" an IP
address on the link. - Mobile routers
- Service Discovery
- Distinguishing between packets lost due to bit errors vs.
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 Mobile IP support in IPv4 (Mobile IPv4) [25, 24, 26], together of Mobile IP support in IPv4 (Mobile IPv4) [25, 24, 26], together
with the opportunities provided by the design and deployment of a new with the opportunities provided by the design and deployment of a new
version of IP itself (IPv6) and the new protocol features offered version of IP itself (IPv6) and the new protocol features offered
by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4,
but the protocol is now fully integrated into IP and provides many but the protocol is now fully integrated into IP and provides many
skipping to change at page 3, line 32 skipping to change at page 2, line 53
functionality allows direct routing from any correspondent functionality allows direct routing from any correspondent
node to any mobile node, without needing to pass through node to any mobile node, without needing to pass through
the mobile node's home network and be forwarded by its home the mobile node's home network and be forwarded by its home
agent, and thus eliminates the problem of "triangle routing" agent, and thus eliminates the problem of "triangle routing"
present in the base Mobile IPv4 protocol [25]. The Mobile IPv4 present in the base Mobile IPv4 protocol [25]. The Mobile IPv4
"registration" functionality and the Mobile IPv4 Route "registration" functionality and the Mobile IPv4 Route
Optimization functionality are performed by a single protocol Optimization functionality are performed by a single protocol
rather than two separate (and different) protocols. rather than two separate (and different) protocols.
- Support is also integrated into Mobile IPv6 -- and into IPv6 - Support is also integrated into Mobile IPv6 -- and into IPv6
itself -- for allowing mobile nodes and Mobile IP to coexist itself -- for allowing Route Optimization to coexist efficiently
efficiently with routers that perform "ingress filtering" [7]. A with routers that perform "ingress filtering" [7]. A mobile
mobile node now uses its care-of address as the Source Address in node uses its care-of address as the Source Address in the
the IP header of packets it sends, allowing the packets to pass IP header of packets it sends, allowing the packets to pass
normally through ingress filtering routers. The home address normally through ingress filtering routers. The home address
of the mobile node is carried in the packet in a 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 destination option, allowing the use of the care-of address in
the packet to be transparent above the IP layer. The ability the packet to be transparent above the IP layer. The ability to
to correctly process a Home Address option in a received packet correctly process a Home Address option in a received packet is
is required in all IPv6 nodes, whether mobile nor stationary, required in all IPv6 nodes, whether mobile or stationary, whether
whether host or router. host or router.
- The use of IPv6 destination options allows all Mobile IPv6
control traffic to be piggybacked on any existing IPv6 packets,
whereas in Mobile IPv4 and its Route Optimization extensions,
separate UDP packets were required for each control message.
- The use of the care-of address as the Source Address in each - The use of the care-of address as the Source Address in each
packet's IP header also simplifies routing of multicast packets packet's IP header also simplifies routing of multicast packets
sent by a mobile node. With Mobile IPv4, the mobile node sent by a mobile node. With Mobile IPv4, the mobile node
had to tunnel multicast packets to its home agent in order to had to tunnel multicast packets to its home agent in order to
transparently use its home address as the source of the multicast transparently use its home address as the source of the multicast
packets. With Mobile IPv6, the use of the Home Address option packets. With Mobile IPv6, the use of the Home Address option
allows the home address to be used but still be compatible with allows the home address to be used but still be compatible with
multicast routing that is based in part on the packet's Source multicast routing that is based in part on the packet's Source
Address. Address.
- There is no longer any need to deploy special routers as - There is no longer any need to deploy special routers as
"foreign agents" as are used in Mobile IPv4. In Mobile IPv6, "foreign agents" as are used in Mobile IPv4. In Mobile IPv6,
mobile nodes make use of IPv6 features, such as Neighbor mobile nodes make use of IPv6 features, such as Neighbor
Discovery [20] and Address Autoconfiguration [35], to operate in Discovery [20] and Address Autoconfiguration [33], to operate in
any location away from home without any special support required any location away from home without any special support required
from its local router. from the local router.
- 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 router sends are reaching the mobile node, and
packets that the mobile node sends are reaching the router). packets that the mobile node sends are reaching the router).
This confirmation provides a detection of the "black hole" This confirmation provides a detection of the "black hole"
situation that may exist in some wireless environments where the situation that may exist in some wireless environments where the
link to the router does not work equally well in both directions, link to the router does not work equally well in both directions,
such as when the mobile node has moved out of good wireless such as when the mobile node has moved out of good wireless
skipping to change at page 4, line 45 skipping to change at page 4, line 12
of Mobile IP packet delivery. To avoid modifying the packet in of Mobile IP packet delivery. To avoid modifying the packet in
flight, however, packets intercepted and tunneled by a mobile flight, however, packets intercepted and tunneled by a mobile
node's home agent in Mobile IPv6 must still use encapsulation for node's home agent in Mobile IPv6 must still use encapsulation for
delivery to the mobile node. delivery to the mobile node.
- While a mobile node is away from home, its home agent intercepts - While a mobile node is away from home, its home agent intercepts
any packets for the mobile node that arrive at the home network, any packets for the mobile node that arrive at the home network,
using IPv6 Neighbor Discovery [20] rather than ARP [29] as is using IPv6 Neighbor Discovery [20] rather than ARP [29] as is
used in Mobile IPv4. The use of Neighbor Discovery improves used in Mobile IPv4. The use of Neighbor Discovery improves
the robustness of the protocol (e.g., due to the Neighbor the robustness of the protocol (e.g., due to the Neighbor
Advertisement "override" bit) and simplifies implementation Advertisement "override" bit) and decouples Mobile IP from any
of Mobile IP due to the ability to not be concerned with any particular link layer, unlike in ARP.
particular link layer as is required 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", which was
required in Mobile IPv4 due to limitations in ICMP for IPv4. Due 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 to the definition of ICMP for IPv6, the use of tunnel soft state
is no longer required in IPv6 for correctly relaying ICMP error is no longer required in IPv6 for correctly relaying ICMP error
messages from within the tunnel back to the original sender of messages from within the tunnel back to the original sender of
the packet. 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 uses IPv6 anycast [11] and returns a single reply to the mobile
node, rather than the corresponding Mobile IPv4 mechanism that node, rather than the corresponding Mobile IPv4 mechanism that
used IPv4 directed broadcast and returned a separate reply from uses IPv4 directed broadcast and returns a separate reply from
each home agent on the mobile node's home link. The Mobile IPv6 each home agent on the mobile node's home link. The Mobile IPv6
mechanism is more efficient and more reliable, since only one mechanism is more efficient and more reliable, since only one
packet need be sent back to the mobile node. The mobile node is packet has to be sent back to the mobile node.
less likely to lose one of the replies because no "implosion" of
replies is required by the protocol.
- Mobile IPv6 defines an Advertisement Interval option on - Mobile IPv6 defines an Advertisement Interval option for
Router Advertisements (equivalent to Agent Advertisements in Router Advertisements (equivalent to Agent Advertisements in
Mobile IPv4), allowing a mobile node to decide for itself how Mobile IPv4), allowing a mobile node to decide for itself how
many Router Advertisements (Agent Advertisements) it is willing many Router Advertisements (Agent Advertisements) it is willing
to miss before declaring its current router unreachable. 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 [3].
3.1. General Terms 3.1. General Terms
IP Internet Protocol Version 6 (IPv6). IP
node A device that implements IP. Internet Protocol Version 6 (IPv6).
router A node that forwards IP packets not explicitly node
addressed to itself.
host Any node that is not a router. A device that implements IP.
link A communication facility or medium over which nodes router
can communicate at the link layer, such as an
Ethernet (simple or bridged). A link is the layer
immediately below IP.
interface A node's attachment to a link. A node that forwards IP packets not explicitly addressed to
itself.
host
Any node that is not a router.
link
A communication facility or medium over which nodes can
communicate at the link layer, such as an Ethernet (simple or
bridged). A link is the layer immediately below IP.
interface
A node's attachment to a link.
subnet prefix subnet prefix
A bit string that consists of some number of initial
bits of an IP address. A bit string that consists of some number of initial bits of an
IP address.
interface identifier interface identifier
A number used to identify a node's interface on a
link. The interface identifier is the remaining A number used to identify a node's interface on a link. The
low-order bits in the node's IP address after the interface identifier is the remaining low-order bits in the
subnet prefix. node's IP address after the subnet prefix.
link-layer address link-layer address
A link-layer identifier for an interface, such as
IEEE 802 addresses on Ethernet links.
packet An IP header plus payload. A link-layer identifier for an interface, such as IEEE 802
addresses on Ethernet links.
Security Association packet
a security object shared between two nodes which
includes the data mutually agreed on for operation
of some cryptographic algorithm (typically including
a key, as defined above).
Security Policy Database (SPD) An IP header plus payload.
A database of security associations selectable by
rulesets (policies) that determine the packets for security association
which each security association is to be applied.
A security object shared between two nodes which includes the
data mutually agreed on for operation of some cryptographic
algorithm (typically including a key).
security policy database
A database of rules that describe what security associations
should be applied for different kinds of packets.
destination option
Destination options are carried by the IPv6 Destination Options
extension header. Mobile IPv6 defines one new destination
option, the Home Address destination option.
3.2. Mobile IPv6 Terms 3.2. Mobile IPv6 Terms
home address An IP address assigned to a mobile node within its home address
home link.
An IP address assigned to a mobile node, used as the permanent
address of the mobile node. This address is within the mobile
node's home link. Standard IP routing mechanisms will deliver
packets destined for a mobile node's home address to its home
link.
home subnet prefix home subnet prefix
The IP subnet prefix corresponding to a mobile
node's home address.
home link The link on which a mobile node's home subnet prefix The IP subnet prefix corresponding to a mobile node's home
is defined. Standard IP routing mechanisms will address.
deliver packets destined for a mobile node's home
address to its home link.
mobile node A node that can change its point of attachment from home link
one link to another, while still being reachable via
its home address.
movement A change in a mobile node's point of attachment to The link on which a mobile node's home subnet prefix is
the Internet such that it is no longer connected to defined.
the same link as it was previously. If a mobile
node is not currently attached to its home link, the mobile node
mobile node is said to be "away from home".
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
movement
A change in a mobile node's point of attachment to the Internet
such that it is no longer connected to the same link as it was
previously. If a mobile node is not currently attached to its
home link, the mobile node is said to be "away from home".
correspondent node correspondent node
A peer node with which a mobile node is
communicating. The correspondent node may be either A peer node with which a mobile node is communicating. The
mobile or stationary. correspondent node may be either mobile or stationary.
foreign subnet prefix foreign subnet prefix
Any IP subnet prefix other than the mobile node's
home subnet prefix.
foreign link Any link other than the mobile node's home link. Any IP subnet prefix other than the mobile node's home subnet
prefix.
home agent A router on a mobile node's home link with which foreign link
the mobile node has registered its current care-of
address. While the mobile node is away from home, Any link other than the mobile node's home link.
the home agent intercepts packets on the home
link destined to the mobile node's home address,
encapsulates them, and tunnels them to the mobile
node's registered care-of address.
care-of address care-of address
An IP address associated with a mobile node while
visiting a foreign link; the subnet prefix of this An IP address associated with a mobile node while visiting a
IP address is a foreign subnet prefix. Among the foreign link; the subnet prefix of this IP address is a foreign
multiple care-of addresses that a mobile node subnet prefix. Among the multiple care-of addresses that a
may have at a time (e.g., with different subnet mobile node may have at any given time (e.g., with different
prefixes), the one registered with the mobile node's subnet 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.
binding The association of the home address of a mobile node home agent
with a care-of address for that mobile node, along
with the remaining lifetime of that association.
Binding Key A router on a mobile node's home link with which the mobile
a key used for authenticating Binding Update node has registered its current care-of address. While the
messages. mobile node is away from home, the home agent intercepts
packets on the home link destined to the mobile node's home
address, encapsulates them, and tunnels them to the mobile
node's registered care-of address.
Binding Security Association (BSA) binding
a security association established specifically
for the purpose of producing and verifying
authentication data passed with a Binding Update
destination option.
4. Overview of Mobile IPv6 The association of the home address of a mobile node with a
care-of address for that mobile node, along with the remaining
lifetime of that association.
4.1. New IPv6 Protocols binding procedure
As mentioned in Section 4.2, Mobile IPv6 defines a new IPv6 protocol, A binding procedure is initiated by the mobile node to inform
the Mobility Header. This protocol is used to carry the following either a correspondent node or the mobile node's home agent of
messages: the current binding of the mobile node.
Home Test Init binding authorization
The Home Test Init message is used to initiate the Return Binding procedure needs to be authorized to allow the recipient
Routability procedure from the mobile node to a correspondent to believe that the sender has the right to specify a new
node. This procedure ensures that subsequence Binding Updates binding.
are properly authorized to redirect the traffic of a particular
home address. The Home Test Init message is described in
detail in Section 5.1.3.
Care-of Test Init return routability procedure
The Care-of Test Init message is also used to initiate the The return routability procedure authorizes binding procedures
Return Routability procedure, for a particular care-of address. by the use of a cryptographic cookie exchange.
The Care-of Test Init message is described in detail in
Section 5.1.4.
Home Test correspondent binding procedure
The Home Test message carries a cookie which the mobile node A return routability procedure followed by a binding procedure,
needs before it can properly authorize itself for sending a run between the mobile node and a correspondent node.
Binding Update. This message is an answer to the Home Test
Init message, and is described in detail in Section 5.1.5.
Care-of Test home binding procedure
The Care-of Test message carries a cookie which the mobile node A binding procedure between the mobile node and its home agent,
needs before it can properly authorize itself for sending a authorized by the use of IPsec.
Binding Update. This message is an answer to the Care-of Test
Init message, and is described in detail in Section 5.1.6.
Binding Update nonce
A Binding Update message is used by a mobile node to notify Nonces are random numbers used internally by the correspondent
a correspondent node or the mobile node's home agent of its node in the creation of cookies related to the return
current binding. The Binding Update sent to the mobile node's routability procedure. The nonces are not specific to a mobile
home agent to register its primary care-of address is marked as node, and are kept secret within the correspondent node, only
a "home registration". A home registration MUST be protected used as one input in the creation of the cookies.
with IPsec, while other Binding Updates MUST be protected with
an authenticator as described in Section 4.5. The Binding
Update message and its specific authentication requirements are
described in detail in Section 5.1.7.
Binding Acknowledgement cookie
A Binding Acknowledgement message is used to acknowledge Cookies are numbers that are used by mobile nodes in the return
receipt of a Binding Update, if an acknowledgement was routability procedure.
requested in the Binding Update. An acknowledgement of a home
registration MUST be protected with IPsec, while other Binding
Update acknowledgements MUST be protected with an authenticator
as described in Section 4.5. The Binding Acknowledgement
message and its specific authentication requirements are
described in detail in Section 5.1.8.
Binding Request care-of cookie
A Binding Request message is used to request a mobile node A cookie sent directly to the mobile node's claimed care-of
to send to the requesting node a Binding Update containing address from the correspondent node.
the mobile node's current binding. This message is typically
used by a correspondent node to refresh a cached binding for a
mobile node, when the cached binding is in active use but the
binding's lifetime is close to expiration. No authentication
is required for the Binding Request message. The Binding
Request message is described in detail in Section 5.1.2.
Binding Missing home cookie
The Binding Missing message is used by the correspondent node A cookie sent to the mobile node's claimed home address from
to signal an inappropriate attempt to use the Home Address the correspondent node.
Option without an existing binding. This message is described
in detail in Section 5.1.9.
Mobile IPv6 also defines a number of "parameters" for use within mobile cookie
these messages; if included, any parameters MUST appear after the
fixed portion of the option data specified in this document. The
presence of such parameters will be indicated by the Header Len
field within the message. When the Header Len is greater than the
length required for the message specified here, the remaining octets
are interpreted as parameters. The encoding and format of defined
parameters are described in Section 5.2.
Alignment requirements for the Mobility Header are same as for any A cookie sent to the correspondent node from the mobile node,
IPv6 protocol, i.e. they MUST be aligned on an 8-octet boundary. and later returned to the mobile node. Mobile cookies are
We also require that the Mobility Header length is a multiple of 8 produced randomly.
octets.
4.2. Basic Operation nonce index
A mobile node is always addressable by its home address, whether it The mobile node uses a particular set of cookies in the return
routability procedure. The cookies have been produced using a
particular set of nonces. A nonce index is used to indicate
which nonces have been used, without revealing the nonces
themselves.
binding key
a key used for authenticating binding cache management
messages.
binding security association
a security association established specifically for the purpose
of producing and verifying authentication data passed with a
Binding Authorization Data option.
4. Overview of Mobile IPv6
4.1. Basic Operation
A mobile node is always addressable at its home address, whether it
is currently attached to its home link or is away from home. While 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 are
routed to it using conventional Internet routing mechanisms in the routed to it using conventional Internet routing mechanisms in the
same way as if the node were never mobile. Since the subnet prefix same way as if the node were stationary. Since the subnet prefix of
of a mobile node's home address is the subnet prefix (or one of the a mobile node's home address is one of the subnet prefixes of the
subnet prefixes) on the mobile node's home link (it is the mobile mobile node's home link, packets addressed to the mobile node will be
node's home subnet prefix), packets addressed to it will be routed to routed to its home link.
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 by one or more care-of addresses, in addition it is also addressable at one or more care-of addresses, in addition
to its home address. A care-of address is an IP address associated to its home address. A care-of address is an IP address associated
with a mobile node while visiting a particular foreign link. The with a mobile node while visiting a particular foreign link. The
subnet prefix of a mobile node's care-of address is the subnet prefix subnet prefix of a mobile node's care-of address is one of the subnet
(or one of the subnet prefixes) on the foreign link being visited by prefixes on the foreign link being visited by the mobile node; if
the mobile node; if the mobile node is connected to this foreign link the mobile node is connected to this foreign link while using that
while using that care-of address, packets addressed to this care-of care-of address, packets addressed to this care-of address will be
address will be routed to the mobile node in its location away from routed to the mobile node in its location away from home.
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 [35] or typically acquires its care-of address through stateless [33] or
stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according stateful (e.g., DHCPv6 [2]) Address Autoconfiguration, according
to the methods of IPv6 Neighbor Discovery [20]. Other methods to the methods of IPv6 Neighbor Discovery [20]. Other methods
of acquiring a care-of address are also possible, such as static of acquiring a care-of address are also possible, such as static
pre-assignment by the owner or manager of a particular foreign link, pre-assignment by the owner or manager of a particular foreign
but details of such other methods are beyond the scope of this link, but details of such other methods are beyond the scope of
document. 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 addresses with a router on its home link, requesting this router to
to function as the "home agent" for the mobile node. This binding function as the "home agent" for the mobile node. The mobile node
registration is done by the mobile node sending to the home agent performs this binding registration by sending a "Binding Update"
a packet containing a "Binding Update" destination option; the message to the home agent; the home agent then replies to the mobile
home agent then replies to the mobile node by returning a packet node by returning a "Binding Acknowledgement" message. The care-of
containing a "Binding Acknowledgement" destination option. The address associated with this binding registration is known as the
care-of address in this binding registered with its home agent is mobile node's "primary care-of address". The mobile node's home
known as the mobile node's "primary care-of address". The mobile agent thereafter uses proxy Neighbor Discovery to intercept any
node's home agent thereafter uses proxy Neighbor Discovery to IPv6 packets addressed to the mobile node's home address (or home
intercept any IPv6 packets addressed to the mobile node's home addresses) on the home link, and tunnels each intercepted packet
address (or home addresses) on the home link, and tunnels each to the mobile node's primary care-of address. To tunnel each
intercepted packet to the mobile node's primary care-of address. intercepted packet, the home agent encapsulates the packet using IPv6
To tunnel each intercepted packet, the home agent encapsulates the encapsulation [4], with the outer IPv6 header addressed to the mobile
packet using IPv6 encapsulation [4], with the outer IPv6 header node's primary care-of address. The operation of the home agent is
addressed to the mobile node's primary care-of address. specified in Section 10.
When a mobile node moves from one care-of address to a new care-of The Binding Update and Binding Acknowledgement messages, together
address on a new link, it is desirable for packets arriving at the with a "Binding Refresh Request" message, are also used to allow IPv6
previous care-of address to be tunneled to the mobile node's care-of nodes communicating with a mobile node are capable of dynamically
address. Since the purpose of a Binding Update is to establish learning and caching the mobile node's binding. This happens
exactly this kind of tunneling, it is specified to be used (at through the correspondent binding procedure which involves a return
least temporarily) for tunnels originating at the mobile node's routability test in order to authorize the establishment of the
previous care-of address, in exactly the same way that it is used binding, as specified in Sections 5.5.5 and 5.5.6. When sending a
for establishing tunnels from the mobile node's home address to the packet to any IPv6 destination, a node checks its cached bindings
mobile node's current care-of address. Section 10.11 describes the for an entry for the packet's destination address. If a cached
use of the Binding Update for this purpose. binding for this destination address is found, the node uses a new
type of IPv6 Routing header [6] (see section 6.4) to route the packet
to the mobile node by way of the care-of address indicated in this
binding. If, instead, the sending node has no cached binding for
this destination address, the node sends the packet normally (with
no Routing header), and the packet is subsequently intercepted and
tunneled by the mobile node's home agent as described above. Any
node communicating with a mobile node is referred to in this document
as a "correspondent node" of the mobile node, and may itself be
either a stationary node or a mobile node. The operation of the
correspondent node is specified in Section 9.
Section 10.20 discusses the reasons why it may be desirable for Mobile IPv6 also defines one additional IPv6 destination option.
a mobile node to use more than one care-of address at the same When a mobile node sends a packet while away from home, it could
time. However, a mobile node's primary care-of address is distinct generally use a tunnel via the home agent to send this packet.
among these in that the home agent maintains only a single care-of However, if the correspondent node in question has a binding for this
address registered for each mobile node, and always tunnels a mobile mobile node it can use deliver packets more directly. In this case
node's packets intercepted from its home link to this mobile node's the mobile node can the Source Address in the packet's IPv6 header to
registered primary care-of address. The home agent thus need not one of its current care-of addresses, and include a "Home Address"
implement any policy to determine the particular care-of address to destination option in the packet, giving the mobile node's home
which it will tunnel each intercepted packet. The mobile node alone address. Many routers implement security policies such as "ingress
controls the policy by which it selects the care-of addresses to filtering" [7] that do not allow forwarding of packets having a
register with its home agent. Source Address that appears topologically incorrect. By using the
care-of address as the IPv6 header Source Address, the packet will
be able to pass normally through such routers, and ingress filtering
rules will still be able to locate the true topological source of
the packet in the same way as packets from non-mobile nodes. By
also including the Home Address destination option in each packet,
the sending mobile node can communicate its home address to the
correspondent node receiving this packet, allowing the use of the
care-of address to be transparent above the Mobile IPv6 support level
(e.g., at the transport layer). The inclusion of a Home Address
destination option in a packet affects only the correspondent node's
receipt of this single packet; no state is created or modified in
the correspondent node as a result of receiving a Home Address
destination option in a packet.
It is possible that while a mobile node is away from home, some nodes 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, such that the router that was
operating as the mobile node's home agent is replaced by a different operating as the mobile node's home agent is replaced by a different
router serving this role. In this case, the mobile node may not router serving this 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 [11] and
thus reaches one of the (possibly many) routers on its home link thus reaches one of the routers on its home link currently operating
currently operating as a home agent. This home agent then returns an as a home agent. This home agent then returns an ICMP "Home Agent
ICMP "Home Agent Address Discovery Reply" message to the mobile node, Address Discovery Reply" message to the mobile node, including a list
including a list of home agents on the home link. This list of home of home agents on the home link. This procedure is specified in
agents is maintained by each home agent on the home link through use Sections 10.9 and 11.3.2.
of the Home Agent (H) bit in each home agent's periodic unsolicited
multicast Router Advertisements.
The Binding Update and Binding Acknowledgement destination options, When a mobile node moves from one care-of address to a new care-of
together with a "Binding Request" destination option, are also used address on a new link, it is desirable for packets arriving at
to allow IPv6 nodes communicating with a mobile node, to dynamically the previous care-of address to be tunneled to the mobile node's
learn and cache the mobile node's binding. When sending a packet new care-of address. Since the purpose of a Binding Update is
to any IPv6 destination, a node checks its cached bindings for an to establish exactly this kind of tunneling, it can be used (at
entry for the packet's destination address. If a cached binding for least temporarily) for tunnels originating at the mobile node's
this destination address is found, the node uses an IPv6 Routing previous care-of address, in exactly the same way that it is used
header [6] (instead of IPv6 encapsulation) to route the packet to for establishing tunnels from the mobile node's home address to the
the mobile node by way of the care-of address indicated in this mobile node's current care-of address. Section 11.6.6 describes the
binding. If, instead, the sending node has no cached binding for use of the Binding Update for this purpose.
this destination address, the node sends the packet normally (with
no Routing header), and the packet is subsequently intercepted and
tunneled by the mobile node's home agent as described above. Any
node communicating with a mobile node is referred to in this document
as a "correspondent node" of the mobile node, and may itself be
either a stationary node or a mobile node.
Since a Binding Update, Binding Acknowledgement, and Binding Request Section 11.4.3 discusses the reasons why it may be desirable for a
are each represented in a packet as an IPv6 destination option [6], mobile node to use more than one care-of address at the same time.
they may be included in any IPv6 packet. Any of these options can be However, a mobile node's primary care-of address is distinct among
sent in either of two ways: 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.
- the messages can be included within any IPv6 packet carrying any 4.2. New IPv6 Protocols
payload such as TCP [31] or UDP [30].
- the messages can be sent as a separate IPv6 packet containing Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
no payload. In this case, the Next Header field in the last (see Section 6.1). This Header is used to carry the following
extension header in the packet is set to the value 59, to messages:
indicate "No Next Header" [6].
Mobile IPv6 also defines one additional IPv6 destination option. Home Test Init
When a mobile node sends a packet while away from home, it will
generally set the Source Address in the packet's IPv6 header to one The Home Test Init message is used to initiate the return
of its current care-of addresses, and will also include a "Home routability procedure from the mobile node to a correspondent
Address" destination option in the packet, giving the mobile node's node. This procedure ensures that subsequent Binding Updates
home address. Many routers implement security policies such as are properly authorized to redirect the traffic of a particular
"ingress filtering" [7] that do not allow forwarding of packets home address. The Home Test Init message is described in
that have a Source Address which appears topologically incorrect. detail in Section 6.1.3.
By using the care-of address as the IPv6 header Source Address,
the packet will be able to pass normally through such routers, Care-of Test Init
yet ingress filtering rules will still be able to locate the true
topological source of the packet in the same way as packets from The Care-of Test Init message is used to initiate the
non-mobile nodes. By also including the Home Address option in each correspondent routability procedure, for a particular care-of
packet, the sending mobile node can communicate its home address to address. The Care-of Test Init message is described in detail
the correspondent node receiving this packet, allowing the use of in Section 6.1.4.
the care-of address to be transparent above the Mobile IPv6 support
level (e.g., at the transport layer). The inclusion of a Home Home Test
Address option in a packet affects only the correspondent node's
receipt of this single packet; no state is created or modified in the The Home Test message carries a cookie which the mobile node
correspondent node as a result of receiving a Home Address option in needs before it can properly authorize itself for sending a
a packet. Binding Update. This message is sent in reply to the Home Test
Init message, and is described in detail in Section 6.1.5.
Care-of Test
The Care-of Test message carries another cookie which the
mobile node needs before it can properly authorize itself for
sending a Binding Update. This message is sent in reply to
the Care-of Test Init message, and is described in detail in
Section 6.1.6.
Binding Update
A Binding Update message is used by a mobile node to notify
a correspondent node or the mobile node's home agent of its
current binding. The Binding Update sent to the mobile node's
home agent to register its primary care-of address is marked
as a "home registration". The Binding Update message and its
specific authentication requirements are described in detail in
Section 6.1.7.
Binding Acknowledgement
A Binding Acknowledgement message is used to acknowledge
receipt of a Binding Update, if an acknowledgement was
requested in the Binding Update. The Binding Acknowledgement
message and its specific authentication requirements are
described in detail in Section 6.1.8.
Binding Refresh Request
A Binding Refresh Request message is used to request that
a mobile node send to the requesting node a Binding Update
containing the mobile node's current binding. This message
is typically used by a correspondent node to refresh a cached
binding for a mobile node, when the cached binding is in active
use but the binding's lifetime is close to expiration. The
Binding Refresh Request message is described in detail in
Section 6.1.2.
No authentication is required for the Binding Refresh Request
message.
Binding Error
The Binding Error message is used by the correspondent node to
signal an error related to mobility, such as an inappropriate
attempt to use the Home Address destination option without
an existing binding. This message is described in detail in
Section 6.1.9.
4.3. New IPv6 Destination Options 4.3. New IPv6 Destination Options
As mentioned in Section 4.2, the following new IPv6 destination Mobile IPv6 defines a new IPv6 destination option, the Home Address
option is defined for Mobile IPv6: destination option. This option is used in a packet sent by a mobile
node to inform the recipient of that packet of the mobile node's home
address. For packets sent by a mobile node while away from home,
the mobile node generally uses one of its care-of addresses as the
Source Address in the packet's IPv6 header. By including a Home
Address option in the packet, the correspondent node receiving the
packet is able to substitute the mobile node's home address for this
care-of address when processing the packet, thus making the use of
the care-of address transparent to the correspondent node above the
Mobile IPv6 support level. If the IP header of a packet carrying
a Home Address option is covered by authentication, then the Home
Address option MUST also be covered by this authentication, but no
other authentication is required for the Home Address option. See
Sections 6.3 and 11.2.2 for additional details about requirements
for the calculation and verification of the authentication data.
The Home Address destination option is described in detail in
Section 6.3.
Home Address 4.4. New IPv6 ICMP Messages
A Home Address option is used in a packet sent by a mobile Mobile IPv6 also introduces four new ICMP message types, two for use
node to inform the recipient of that packet of the mobile in the dynamic home agent address discovery mechanism, and two for
node's home address. For packets sent by a mobile node while renumbering and mobile configuration mechanisms. As discussed in
away from home, the mobile node generally uses one of its general in Section 4.1, the following two new ICMP message types are
care-of addresses as the Source Address in the packet's IPv6 used for home agent address discovery:
header. By including a Home Address option in the packet, the
correspondent node receiving the packet is able to substitute
the mobile node's home address for this care-of address when
processing the packet, thus making the use of the care-of
address transparent to the correspondent node. If the IP
header of a packet carrying a Home Address option is covered
by authentication, then the Home Address option MUST also be
covered by this authentication, but no other authentication
is required for the Home Address option. See sections 10.2
and 5.3 for additional details about requirements for the
calculation and verification of the authentication data. The
Home Address option is described in detail in Section 5.3.
Mobile IPv6 also defines a number of "sub-options" for use within Home Agent Address Discovery Request
destination options. If included, any sub-options MUST appear after
the fixed portion of the option data specified in this document. The
presence of such sub-options will be indicated by the Option Length
field within the option. When the Option Length is greater than the
length required for the option specified here, the remaining octets
are interpreted as sub-options. The encoding and format of defined
sub-options are described in Section 5.5.
4.4. Alignment Requirements for New Destination Options 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.
IPv6 requires that options appearing in a Hop-by-Hop Options Home Agent Address Discovery Reply
header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed
at an integer multiple of n octets from the start of the header,
for n = 1, 2, 4, or 8) [6]. Mobile IPv6 sub-options have similar
alignment requirements, so that multi-octet values within the
Sub-Option Data field of each sub-option fall on natural boundaries.
The alignment requirement of an option or sub-option is specified in
this document using the standard notation used elsewhere for IPv6
alignment requirements [6]. Specifically, the notation xn+y means
that the Option Type or Sub-Option Type field must fall at an integer
multiple of x octets from the start of the header, plus y octets.
For example:
2n means any 2-octet offset from the start of the header. The ICMP Home Agent Address Discovery Reply message is used by
a home agent to respond to a mobile node using the dynamic home
agent address discovery mechanism. When a home agent receives
a Home Agent Address Discovery Request message, it replies with
a Home Agent Address Discovery Reply message, giving a list
of the routers on the mobile node's home link serving as home
agents. The Home Agent Address Discovery Reply message is
described in detail in Section 6.6.
8n+2 means any 8-octet offset from the start of the header, The next two message types are used for network renumbering
plus 2 octets. and address configuration on the mobile node, as described in
Section 10.9.1:
4.5. Security Design Mobile Prefix Solicitation
4.5.1. Security Threats 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.
The MIPv6 protocol needs to protect itself against the following main Mobile Prefix Advertisement
threats:
1. Threats against Binding Updates sent to home agents: a attacker The ICMP Mobile Prefix Advertisement is used by a home agent
might claim that a certain mobile node is currently at a to distribute information to a mobile node about prefixes on
different location than it really is. If the home agent accepts the home link which are available for use by the mobile node
the information sent to it as is, the mobile node might not get while away from home. This message may be sent as a response
traffic destined to it, and other nodes might get traffic they to a Mobile Prefix Solicitation, or due to network renumbering
didn't want. or other prefix changes. This message is specified in Section
Section 10.9.3.
2. Threats against route optimization with correspondent nodes: 4.5. Conceptual Data Structures
A malicious mobile node might lie about its home address. A
malicious mobile node might send a correspondent node binding This document describes the Mobile IPv6 protocol in terms of the
updates in which the home address is set to the address of following three conceptual data structures:
another node, the victim. If the correspondent node accepted
this forged binding update, then communications between the Binding Cache
correspondent node and the victim would be disrupted, because
packets that the correspondent node intended to send to the A cache, maintained by each IPv6 node, of bindings for other
victim would be sent to the wrong care-of address. This is a nodes. A separate Binding Cache is maintained by each IPv6
threat to confidentiality as well as availability, because an node for each of its IPv6 addresses. When sending a packet,
the Binding Cache is searched before the Neighbor Discovery
conceptual Destination Cache [20].
The Binding Cache for any one of a node's IPv6 addresses may
contain at most one entry for each mobile node home address.
The contents of all of a node's Binding Cache entries are
cleared when it reboots.
Binding Cache entries are marked either as "home registration"
entries or "correspondent registration" entries. Home
registration entries are deleted when its binding lifetime
expires, while other entries may be replaced at any time
through a local cache replacement policy.
Binding Update List
A list, maintained by each mobile node, recording information
for each Binding Update sent by this mobile node, for which the
Lifetime sent in that Binding Update has not yet expired. The
Binding Update List includes all bindings sent by the mobile
node: those to correspondent nodes, those to the mobile node's
home agent, and those to a home agent on the link on which the
mobile node's previous care-of address is located.
Home Agents List
A list, maintained by each home agent and each mobile node,
recording information about each home agent from which this
node has received recent a Router Advertisement in which the
Home Agent (H) bit is set. The home agents list is thus
similar to the Default Router List conceptual data structure
maintained by each host for Neighbor Discovery [20].
Each home agent maintains a separate Home Agents List for each
link on which it is serving as a home agent; this list is used
by a home agent in the dynamic home agent address discovery
mechanism. Each mobile node, while away from home, also
maintains a Home Agents List, to enable it to notify a home
agent on its previous link when it moves to a new link.
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.1. Threats
Any mobility solution must protect itself against misuses of the
mobility features. In Mobile IPv6, most of the potential threats
are concerned with denial of service. Some 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 attacker might redirect packets meant for another node to itself
in order to learn the content of those packets. in order to learn the content of those packets.
A malicious mobile node might lie about its care-of address. A A malicious mobile node might also send Binding Updates in
malicious mobile node might send a correspondent node binding which the care-of address is set to the address of a victim
updates in which the care-of address is set to the address of node or an address within a victim network. If such Binding
a victim node or an address within a victim network. If the Updates were accepted, the malicious mobile node could force the
correspondent node accepted this forged binding update, then the correspondent node into sending data to the victim node or the
malicious mobile could trick the correspondent into sending data victim network; the correspondent node's replies to messages sent
to the victim node or the victim network; the correspondent's by the malicious mobile node will be sent to the victim host
replies to messages sent by the malicious mobile will be sent or network. This could be used to cause a distributed denial
to the victim host or network. This could be used to cause a of service attack. Variations of this threat are described
distributed denial of service attack; the malicious mobile could elsewhere [1][31].
trick a large number of servers so that they all send a large
amount of data to the same victim node or network. Several
variations of this threat are described elsewhere [1][33].
A malicious node might also send a large number of invalid A malicious node might also send a large number of invalid
binding updates to a victim correspondent node. If each invalid Binding Updates to a victim node. If each Binding Update takes a
binding update took a significant amount of resources (such as significant amount of resources (such as CPU) to process before
CPU) to process before it could be recognized as invalid, then it it can be recognized either as valid or as invalid, then a denial
might be possible to cause a denial of service attack by sending of service attack can be caused by sending the correspondent node
the correspondent so may invalid binding updates that it has no so many invalid Binding Updates that it has no resources left for
resources left for other tasks. other tasks.
An attacker might also replay an old binding update. An attacker
might attempt to disrupt a mobile node's communications by
replaying a binding update that the node had sent earlier. If
the old binding update was accepted, packets destined for the
mobile node would be sent to its old location and not its current
location.
3. Threats where MIPv6 correspondent node functionality is used An attacker might also attempt to disrupt a mobile node's
to launch reflection attacks against other parties [34] [23]. communications by replaying a Binding Update that the node had
The Home Address Option can be used to direct response traffic sent earlier. If the old Binding Update was accepted, packets
against a node whose IP address appears in the option, without destined for the mobile node would be sent to its old location
giving a possibility for ingress filtering to catch the forged and not its current location.
"return address".
4. Threats where the tunnels between the mobile node and the home 2. Reflection attack threats against third partied with the help
agent are attacked to make it appear like the mobile node is of Mobile IPv6 correspondent nodes that do not use appropriate
sending traffic while it is not. 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].
5. Threats where IPv6 Routing Header -- which is employed in 3. Threats where an attacker forges tunneled packets between the
MIPv6 -- is used to circumvent IP-address based rules in mobile node and the home agent, making it appear that the traffic
firewalls or to reflect traffic from other nodes. The generality is coming from the mobile node when it is not.
of the Routing Header allows the kind of usage that opens
vulnerabilities, even if the usage that MIPv6 needs is safe.
6. The security mechanisms of MIPv6 may also be attacked themselves, 4. Threats against IPv6 functionality used by Mobile IPv6, such as
e.g. in order to force the participants to execute expensive the Routing header. The generality of the regular Routing Header
cryptographic operations or allocate memory for the purpose of would allow circumvention of IP-address based rules in firewalls
keeping state. or reflection of traffic to other nodes, even if the usage that
Mobile IPv6 requires is safe.
Most of the above threats are concerned with denial of service. Some 5. The security mechanisms of Mobile IPv6 may also be attacked
of the threats also open up possibilities for man-in-the-middle, themselves, e.g. in order to force the participants to execute
hijacking, and impersonation attacks. expensive cryptographic operations or allocate memory for the
purpose of keeping state.
4.5.2. Security Features 5.2. Features
This specification provides a number of security features. The main This specification provides a number of security features. The main
features are: features are:
- Protection of Binding Updates to home agents. - Protection of Binding Updates to home agents.
- Protection of Binding Updates to correspondent nodes. - Protection of Binding Updates to correspondent nodes.
- Protection against reflection attacks through the Home Address - Protection against reflection attacks through the Home Address
Option. destination option.
- Protection of tunnels between the mobile node and the home agent. - Protection of tunnels between the mobile node and the home agent.
- Preventing Routing Header vulnerabilities. - Preventing Routing Header vulnerabilities.
- Preventing Denial-of-Service attacks to the MIPv6 security - Preventing Denial-of-Service attacks to the Mobile IPv6 security
mechanisms themselves. mechanisms themselves.
Protecting the Binding Updates to home agents and to correspondent Protecting the Binding Updates to home agents and to arbitrary
nodes require very different security solutions due to the different correspondent nodes require very different security solutions due
situations. Mobile nodes and home agents know each other, and can to the different situations. Mobile nodes and home agents are
thus have a strong security association to reliably authenticate expected to be naturally subject to the network administration of
the exchanged messages. In this environment, IPsec Encapsulating the home domain, and thus to have a strong security association to
Security Payload (ESP) can be used to implement the necessary reliably authenticate the exchanged messages. With such a security
security features. See Section 4.5.5. arrangement, IPsec Encapsulating Security Payload (ESP) can be used
to implement the necessary security features. See Section 5.4.
The protection of Binding Updates to correspondents is a much harder It is expected that Mobile IPv6 will be used on a global basis
problem for the traditional strong authentication approach. It is between nodes belonging to different administrative domains.
expected that MIPv6 will be used on a global basis between nodes Building an authentication infrastructure to authenticate mobile
belonging under different administrative domains, hence building nodes and correspondent nodes would be a very demanding task in this
an authentication infrastructure to authenticate mobile nodes scale. Furthermore, traditional authentication infrastructure keep
and correspondent nodes would be a very demanding task. Thus, an track of correct IP addresses for all hosts is either impossible or
infrastructureless approach is necessary. Furthermore, making a at least very hard. That is, it isn't sufficient to authenticate
traditional authentication infrastructure keep track of correct mobile nodes, authorization to claim right to use an address is
IP addresses for all hosts is either impossible or at least very needed. Thus, an "infrastructureless" approach is necessary.
hard. That is, it isn't sufficient to authenticate mobile nodes,
authorization to claim right to use an address is needed.
A different approach is therefore necessary. The chosen method The chosen infrastructureless method verifies that the mobile
verifies that the mobile node is ``live'' (that is, it responds to node is "live" (that is, it responds to probes) at its home and
probes) at its home and care-of addresses by performing a cookie care-of addresses by performing a cookie exchange with the nodes
exchange with the addresses, and by requiring that the eventual in question, and by requiring that the eventual Binding Update is
binding update is cryptographically bound to the sent cookies. cryptographically bound to the exchanged cookies. Some additional
Some additional protection is provided by requiring the cookies be protection is provided by requiring the cookies be protected by
protected by ESP when forwarded by the Home Agent to the mobile node. ESP when exchanged between the mobile node and the correspondent
This method limits the vulnerabilities to those attackers who are node via the home agent. This method limits the vulnerabilities to
on the path between the Home Agent and the correspondent node. As those attackers who are on the path between the home agent and the
adversaries on this path would be able to cause also other types of correspondent node. As adversaries on this path would be able to
attacks, this is seen as sufficient base security between mobile and cause also other types of attacks, this is seen as sufficient base
correspondent nodes. security between mobile and correspondent nodes.
Vulnerabilities relating to the use of correspondent nodes as Vulnerabilities relating to the use of correspondent nodes as
reflectors via the Home Address Option can be solved as follows. We reflectors via the Home Address destination option can be solved as
ensure that the mobile node is authorized to use a given home address follows: We ensure that the mobile node is authorized to use a given
before HAO can be used. Such authorization is already performed in home address before this option can be used. Such authorization is
the context of Route Optimization, and therefore this specification already performed in the context of Route Optimization, and therefore
limits the use of the HAO to the situation where the correspondent this specification limits the use of the Home Address option to the
node already has a binding cache entry for the given home address. 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 Tunnels between the mobile node and the home agent can be
protected by ensuring proper use of source addresses, and optional protected by ensuring proper use of source addresses, and optional
cryptographic protection. These procedures are discussed in cryptographic protection. These procedures are discussed in
Section 4.5.3. Section 5.3.
Vulnerabilities related to the Routing Header can be prevented by Potential abuses of the Routing Header can be prevented by using a
using a MIPv6 specific type of a Routing Header. This type provides Mobile IPv6 specific type of a Routing Header. This type provides
the necessary functionality but does not open vulnerabilities. the necessary functionality but does not open vulnerabilities.
Denial-of-Service threats against MIPv6 security mechanisms Denial-of-Service threats against Mobile IPv6 security mechanisms
themselves concern mainly the Binding Update procedures with themselves concern mainly the Binding Update procedures with
correspondent nodes. The protocol has been designed to limit the correspondent nodes. The protocol has been designed to limit the
effects of such attacks, as will be described in Section 4.5.6. effects of such attacks, as will be described in Section 5.5.9.
4.5.3. Securing Tunnels to and from the Home Agents 5.3. Tunnels to and from the Home Agents
Tunnels between the mobile node and the home agent need protection 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 so that it isn't possible for anyone to send traffic through the
home agent, pose as the mobile node, and escape detection through home agent, pose as the mobile node, and escape detection through
traditional tracing mechanisms. traditional tracing mechanisms.
If Binding Updates sent to the home agents are secure, and the home Binding Updates sent to the home agents are secure. The home
agent verifies the outer IP address corresponds to the current agent verifies that the outer IP address corresponds to the current
location of the mobile node, this prevents attacks against the tunnel location of the mobile node, to prevent attacks against the tunnel
from other IP addresses. This prevents attacks where the attacker from other IP addresses.
is controlled by ingress filtering, as well as attacks where the
attacker does not know the current care-of address of the mobile
node. Attackers who know the care-of address are not controlled by
ingress filtering could still send traffic through the home agent,
but they could also send spoofed packets without using a tunnel.
Encapsulating the tunneled traffic inside IPsec ESP offers an For tunneled traffic to and from the mobile node, encapsulating the
optional mechanism to protect the confidentiality and integrity of traffic inside IPsec ESP offers an optional mechanism to protect
the traffic against on-path attackers. the confidentiality and integrity of the traffic against on-path
attackers.
4.5.4. Securing Binding Updates to Home Agents 5.4. 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 In order to have this protection, the mobile node and the home agent
must have a security association. IPsec Encapsulating Security must have a security association. IPsec Encapsulating Security
Payload (ESP) can be used to for integrity protection when a non-null Payload (ESP) can be used for integrity protection when a non-null
authentication algorithm is applied. authentication algorithm is applied.
However, IPsec can provide replay protection only when dynamic However, IPsec can easily provide replay protection only if dynamic
security association establishment is used. This may not always be security association establishment is used. This may not always be
possible, and manual keying would be preferred in some cases. IPsec possible, and manual keying would be preferred in some cases. IPsec
also does not guarantee correct ordering of packets, only that they also does not guarantee correct ordering of packets, only that they
have not been replayed. Because of this, Mobile IPv6 does not rely have not been replayed. Because of this, Mobile IPv6 provides its
on IPsec replay protection and provides its own mechanism inside the own mechanism inside the Binding Update and Acknowledgement messages.
Binding Update and Acknowledgement messages. A sequence number field
is used to ensure correct ordering and to prevent replay protection.
Both the mobile node and the home agent MUST use non-volatile memory
to store the sequence number so that a reboot does not prevent the
acceptance of new Binding Updates.
A sliding window scheme is used for the sequence numbers. Therefore A sequence number field is used to ensure correct ordering. If the
the protection against replays and reordering attacks works when mobile node reboots and forgets its current sequence number, the home
the attacker remembers up to a maximum of 2^31 Binding Updates. agent uses the status value 141 (Sequence number out of window, see
The mobile node and the home agent MAY agree on a new key for the Section 6.1.8) to inform the mobile node of the use of an improper
security association before this many Binding Updates have been sent sequence number.
if this is an issue.
Note that while the required non-volatile memory is an additional Note that the the sequence number mechanism provides also a weak form
burden in particular for the mobile node, the use of sequence numbers of replay protection. However, if a home agent reboots and loses its
reduces the number of roundtrips necessary for the update procedure state regarding the sequence numbers, replay attacks become possible.
compared to other schemes that would not have required non-volatile If the home agent is vulnerable to this, the use of a key management
memory. Note also that implementations do not necessarily have to mechanism together with IPsec can be used to prevent replay attacks.
write the non-volatile memory every time they send a Binding Update,
if they always write a somewhat larger sequence number to the memory A sliding window scheme is used for the sequence numbers. The
and only update the memory again once the used sequence numbers go protection against replays and reordering attacks without a key
beyond this larger number. For instance, if the sequence number management mechanism works when the attacker remembers up to a
starts at 0, the value 100 can be written to the memory so that maximum of 2**15 Binding Updates.
the next write can be done when the sequence numbers from 0 to 99
have been used. This reduces the need for frequent updates to the
non-volatile memory, which improves performance and may be necessary
in some cases to lengthen the lifetime of the used memory components.
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 (SPD) 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 SPD entries MUST unequivocally identify a In order to do this, the security policy database entries MUST
single SA for any given home address and home agent. In order for unequivocally identify a single SA for any given home address and
the home address of the mobile node to be visible when the policy home agent. In order for the home address of the mobile node to be
check is made, the mobile node MUST use the Home Address Option in visible when the policy check is made, the mobile node MUST use the
Binding Updates sent to the home agent. The home address in the Home Home Address destination option in Binding Updates sent to the home
Address Option and the Binding Update message MUST be equal and MUST agent. The home address in the Home Address destination option and
be checked by the home agent. the Binding Update message MUST be equal and MUST be checked by the
home agent.
4.5.5. Securing Binding Updates to Correspondent Nodes 5.5. Binding Updates to Correspondent Nodes
Binding Updates to correspondent nodes are protected using the Return Binding Updates to correspondent nodes are protected using the return
Routability (RR) method. This method uses the following principles: 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.
- A cookie exchange verifies that the mobile node is ``live'' at This protocol also protects against denial of service attacks in
its addresses, or is at least able to receive traffic on them. 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.
- Protecting the eventual binding update cryptographically using 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. the cookies.
- Requiring that the cookies be protected by ESP when forwarded by - Requiring that the cookies be protected by ESP when forwarded by
the Home Agent to the mobile node. the home agent to the mobile node.
- The use of symmetric exchanges were responses are sent to the - The use of symmetric exchanges where responses are sent to the
same address as the request was sent from, to avoid the use of same address as the request was sent from, to avoid the use of
this protocol in reflection attacks. this protocol in reflection attacks.
- Stateless operation at correspondent nodes until they receive the - Correspondent nodes operate in a stateless manner until they
a binding update that can be authorized. receive a Binding Update that can be authorized.
The RR protocol can be broken by an attacker on the route between the
home agent and the correspondent node, but not by attackers on the
network the mobile node is currently at and not from elsewhere on the
Internet.
Each correspondent node has a secret key, Kcn. This key does not
need to be shared with any other entity, so no key distribution
mechanism is needed for it. Each correspondent node also generates
a nonce, Nj, at regular intervals, for example every few minutes. A
correspondent node uses the same Kcn and Nj with all the mobiles it
is in communication with, so that it does not need to generate and
store a new Nj when a new mobile contacts it. Each value of Nj is
identified by the subscript j. This subscript is communicated in the
protocol, so that if Nj is replaced by N(j+1) part way through a run
of a protocol, the correspondent can distinguish messages that should
be checked against the old nonce from messages that should be checked
against the new nonce. Correspondent nodes keep both the current
value of Nj and a small set of previous values N(j-1), N(j-2), ...
Older values can be discarded, and messages using them will can be
rejected as replays.
Kcn can be either a fixed value or regularly updated. An update
of Kcn can be done at the same time as an update of Nj, so that j
identifies both the nonce and the key. A correspondent node can
generate a fresh Kcn each time that it boots to avoid the need for
secure persistent storage for Kcn.
The RR signaling happens as follows:
1. MN(HoA) -> CN: HoTI(HoA)
2. MN(CoA) -> CN: CoTI(CoA)
3. CN -> MN(HoA): HoT(K0, j)
4. CN -> MN(CoA): CoT(K1, l)
5. MN(CoA) -> CN: BU(HoA, CoA, MAC, j, l)
6. CN -> MN(CoA): BA(MAC)
7. CN -> MN(HoA): BR(MAC)
Messages 1 and 2 are sent simultaneously, as are messages 3 and
4. Message 5 actually creates a binding, and messages 6 and 7 are
optional. The messages are described in more detail below:
1. HoTI (Home Test Init) Message:
When a mobile nodes wants to perform route optimization it sends
a HoTI message to the correspondent node in order to initiate the
return routability verification for the Home Address.
MN(HoA) -> CN: HoA
This message tells the mobile node's home address to the
correspondent node. The address is used later to create a
cookie. This message is reverse tunneled through the Home Agent.
2. CoTI (Care-of Test Init) Message:
When a mobile nodes wants to perform route optimization it sends
a CoTI message to the correspondent node in order to initiate the
return routability verification for the care-of Address.
MN(CoA) -> CN: CoA
The second message is sent in parallel with the first one. It
tells the correspondent node the mobile node's care-of address,
which is later used to create a cookie. This message is sent
directly to the correspondent node.
3. HoT (Home Test) Message:
This message is sent in response to a HoTI message.
CN -> MN(HoA): K0, j
When the correspondent node receives the HoTI message, it
generates a cookie K0 as follows:
K0 = MAC_Kcn(HoA | Nj | 0)
The cookie and the value j are sent to the mobile node via the
Home Agent; it is an assumption of the protocol that the home
agent - mobile node route is secure. K0 also acts as a challenge
to test that the mobile can receive messages sent to its home
address.
The index j is carried along in the protocol to allow the CN
to later efficiently find the nonce value Nj that it used in
creating this cookie.
The notation used here is as follows. MAC_K(m) denotes a
message authentication code computed on message m with key K.
H(m) denotes a hash of message m. HMAC SHA1 function [15][21]
is used to compute the message authentication code, and SHA1
function [21] is used to compute the hash. The final ``0''
inside the MAC function is a 32-bit integer used to distinguish
home and care-of cookies from each other.
4. CoT (Care-of Test) Message:
This message is sent in response to a CoTI message.
CN -> MN(CoA): K1, i
The correspondent also sends a challenge to the mobile's care-of
address. When the correspondent node receives the CoTI message,
it generates a cookie K1 as follows:
K1 = MAC_Kcn(CoA | Ni | 1) The return routability procedure can be broken by an attacker on the
route between the home agent and the correspondent node, but not by
attackers on the network the mobile node is currently at and not from
elsewhere on the Internet.
The cookie and the value i are sent directly the mobile node. 5.5.1. Node Keys
The final 1 inside the MAC function is a 32-bit integer, again
used for distinguishing home and care-of cookies from each other.
Again, an index is sent along the cookie in order to identify Each correspondent node has a secret key, Kcn. This key is used by
the used nonce Ni. Note that i and j are likely to be the same the correspondent node to accept only the use of cookies which it has
in HoT and CoT messages, except when nonce values happen to have created itself. This key does not need to be shared with any other
changed between the reception of HoT and the CoT messages. entity, so no key distribution mechanism is needed for it.
5. BU (Binding Update) Message: 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
either a fixed value or regularly updated. Procedures for updating
Kcn are discussed later in Section 5.5.7.
When the MN has received both the HoT and CoT is has the cookies Kcn consists of 20 octets.
necessary to send the Binding Update.
MN(CoA) -> CN: BU, HoA, CoA, 5.5.2. Nonces
MAC_Kbu(CoA | HoA | BU | 0),
j, i
The mobile node hashes together the challenges and to form a Each correspondent node also generates a nonce at regular intervals,
session key (Kbu), and then uses this session key to authenticate for example every few minutes. A correspondent node uses the same
a binding update: Kcn and nonce with all the mobiles it is in communication with, so
that it does not need to generate and store a new nonce when a new
mobile contacts it. Each nonce is identified by a nonce index.
Nonce indices are 16-bit values that are e.g. incremented each time
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
of a protocol, the correspondent node can distinguish messages that
should be checked against the old nonce from messages that should be
checked against the new nonce. 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.
Kbu = H(K0 | K1) The specific nonce index values can not be used by mobile nodes to
determine the validity of the nonce. Expected validity times for
the nonces values and the procedures for updating them are discussed
later in Section 5.5.7.
The message contains j and i, so that the correspondent knows Nonce is an octet string of any length. The recommended length is 16
which value of Nj and Ni to use to recompute the session key. octets.
"BU" is the content of the BU message. Once the correspondent
node has verified the MAC, it can create a binding cache entry
for the mobile.
6. BA (Binding Acknowledgement) Message: 5.5.3. Cookies
The Binding Update is optionally acknowledged by the Three different types of cookies are used in the protocol:
correspondent node.
CN -> MN(CoA): BA, - Mobile cookie is sent to the correspondent node from the mobile
MAC_Kbu(CoA | HoA | BA | 0), node, and later returned to the mobile node. Mobile cookies are
produced randomly, and used to verify that the response matches
the request, and to ensure that parties who have not seen the
request can not spoof responses.
The correspondent node uses the same key (Kbu) to authenticate a - A home cookie sent to the mobile node from the correspondent node
binding acknowledgement. "BA" is the content of the BA message. via the home agent. Home cookies are produced cryptographically
from nonces.
7. BR (Binding Request) Message: - A care-of cookie sent directly to the mobile node from the
correspondent node. Home cookies are produced cryptographically
from nonces.
The correspondent node can optionally request a binding to be Mobile cookies are typically newly generated random values for each
refreshed using the Binding Request message. This message can be new request that needs them. They could also be changed periodically
authenticated using the same Kbu that was created earlier. only. The policy to use new or old mobile cookies is purely a local
matter for the mobile node.
CN -> MN(HoA): BR, Home and care-of cookies are produced by the correspondent node, and
MAC_Kbu(HoA | BR | 0), 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
cookie is valid as long as both the secret key and the nonce used to
create it are valid.
"BR" is the content of the BR message. 5.5.4. Cryptographic Functions
This protocol also protects the participants against replayed binding MAC_K(m) denotes a Message Authentication Code computed on message
updates. The attacker can't replay the same message due to the m with key K. In this specification, HMAC SHA1 function [15][21] is
sequence number which is a part of the MIPv6 binding update itself, used to compute these codes.
and the attacker can't modify the binding update since the MAC would
not verify after that. Care must be taken when removing bindings
at the correspondent node, however. If a binding is removed either
due to garbage collection, request, or expiration and the nonce
used in its creation is still valid, an attacker can replay the old
binding update. This can be prevented by having the correspondent
node change the nonce often enough to ensure that the nonces used
when removed entries were created are no longer valid. If many such
deletions occur the correspondent can batch them together to avoid
having to increment the nonce index too often.
4.5.6. Preventing Denial-of-Service Attacks H(m) denotes a hash of message m. In this specification, SHA1
function [21] is used to compute the hash.
The RR protocol has been designed with protection against resource 5.5.5. Return Routability Procedure
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 The return routability signaling happens as follows:
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. Yet the cookies are
specific, but they can be reconstructed based on the CoA and HoA
information that arrives with the binding update. This means that
the correspondent nodes are safe against memory exhaustion attacks
except where on-path attackers are concerned. Due to the use of
symmetric cryptography, the correspondent nodes are relatively safe
against CPU resource exhaustion attacks as well.
Nevertheless, as [1] describes, there are situations it is impossible Mobile node Home agent Correspondent node
for the mobile and correspondent nodes to determine if they actually | |
need a binding or whether they just have been fooled into believing | Home Test Init(HoTI) |
so by an attacker. Therefore, it is necessary to treat situations | Src = home address, |
where such attacks are being made. | Dst = correspondent | |
| Parameters: | |
| - mobile cookie 1 | |
|------------------------->|------------------------->|
| | |
| |
| Care-of Test Init(CoTI) |
| Src = care-of address |
| Dst = correspondent |
| Parameters: |
| - mobile cookie 2 |
|---------------------------------------------------->|
| |
| Home Test (HoT) |
| Src = correspondent, |
| Dst = home address |
| Parameters: |
| - mobile cookie 1 |
| | - home cookie |
| | - home nonce index |
|<-------------------------|<-------------------------|
| | |
| |
| Care-of Test(CoT) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - mobile cookie 2 |
| - care-of cookie |
| - care-of nonce index |
|<----------------------------------------------------|
| |
The binding updates that are used in mobile IPv6 are only an The HoTI and CoTI messages are sent at the same time. The
optimization. A mobile node can communicate with a correspondent correspondent node returns the HoT and CoT messages as quickly as
node even if the correspondent refuses to accept any of its binding possible, and perhaps nearly simultaneously, requiring very little
updates. However, performance will suffer because packets from the processing. The four messages form the return routability procedure.
correspondent to the mobile will be routed via the mobile's home (After the return routability procedure, a binding will be created
agent rather than a more direct route. A correspondent can protect with a single request with an optional response.) Due to the
itself against some of the resource exhaustion attacks by stopping simultaneous sending of messages, the return routability procedure
processing binding updates when it is flooded with a large number of completes in 1 roundtrip (and the whole process completes in 1.5
binding updates that fail the cryptographic integrity checks. If a roundtrips excluding the acknowledgement message).
correspondent 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 can decide to reject all binding updates
without performing any cryptographic operations.
Additional information needed to make this decisions about responding The four messages (HoTI, CoTI, HoT, and CoT) belonging to the return
to requests will usually originate in layers above IP. For example, routability procedure are described in more detail below. The use of
TCP knows if the node has a queue of data that it is trying to send the results of the return routability procedure for authenticating a
to a peer. It is possible to produce a conforming implementation of correspondent binding procedure is described in Section 5.5.6.
the protocols in this memo without making use of information from
higher protocol layers, but implementations MAY be able to manage
resources more effectively by making use of such information.
4.5.7. Design Rationale HoTI
The motivation for designing the RR protocol was to have sufficient Home Test Init Message:
support for mobile IP, without creating major new security problems.
A protocol was needed against the new vulnerabilities introduced by
IP mobility. It was not our goal to protect against attacks that
were already possible before the introduction of IP mobility. This
protocol does not defend against an attacker who can monitor the home
agent 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 irrespective of whether mobile IP is in use or not.
This protocol also protects against denial of service attacks in When a mobile nodes wants to perform route optimization it
which the attacker pretends to be a mobile, but uses the victim's sends a HoTI message to the correspondent node in order to
address as the care of address, and so causes the correspondent initiate the return routability verification for the Home
to send the victim traffic that it does not want. For example, Address.
suppose that the correspondent 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 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 of RR and other protocols, Src = home address
see [1] [33] [22] [23]. Dst = correspondent
Parameters:
- mobile cookie 1
4.6. New IPv6 ICMP Messages This message conveys the mobile node's home address to the
correspondent node. The mobile node also sends along mobile
cookie C0 that the correspondent node must return later,
along with its own cookie that it generates based on the home
address. The HoTI message is reverse tunneled through the home
agent.
Mobile IPv6 also introduces four new ICMP message types, two for use CoTI
in the dynamic home agent address discovery mechanism, and two for
renumbering and mobile configuration mechanisms. As discussed in
general in Section 4.2, the following two new ICMP message types are
used for home agent address discovery:
Home Agent Address Discovery Request Care-of Test Init Message:
The ICMP Home Agent Address Discovery Request message is used When a mobile nodes wants to perform route optimization it
by a mobile node to initiate the dynamic home agent address sends a CoTI message to the correspondent node in order to
discovery mechanism. When attempting a home registration, the initiate the return routability verification for the care-of
mobile node may use this mechanism to discover the address of Address.
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 5.6.
Home Agent Address Discovery Reply Src = care-of address
Dst = correspondent
Parameters:
- mobile cookie 2
The ICMP Home Agent Address Discovery Reply message is used by The second message is sent in parallel with the first one. It
a home agent to respond to a mobile node using the dynamic home conveys the mobile node's care-of address to the correspondent
agent address discovery mechanism. When a home agent receives node. The mobile node also sends along mobile cookie C1 that
a Home Agent Address Discovery Request message, it replies with the correspondent node must return later, along with its own
a Home Agent Address Discovery Reply message, giving a list cookie that it generates based on the care-of address. The
of the routers on the mobile node's home link serving as home CoTI message is sent directly to the correspondent node.
agents. The Home Agent Address Discovery Reply message is
described in detail in Section 5.7.
The next two message types are used for network renumbering HoT
and address configuration on the mobile node, as described in
Section 9.7:
Mobile Prefix Solicitation Home Test Message:
The ICMP Mobile Prefix Solicitation message is used by a mobile This message is sent in response to a HoTI message.
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 5.8.
Mobile Prefix Advertisement Src = correspondent
Dst = home address
Parameters:
- mobile cookie 1
- home cookie
- home nonce index
The ICMP Mobile Prefix Advertisement is used by a home agent to When the correspondent node receives the HoTI message, it
distribute information to a mobile node about prefixes on the generates a 16 octet home cookie as follows:
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 as specified in Section 9.9.3
4.7. Conceptual Data Structures home cookie = MAC_Kcn(home address | nonce)
This document describes the Mobile IPv6 protocol in terms of the The cookie is sent in the message to the mobile node via the
following three conceptual data structures: 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.
Binding Cache Mobile cookie 1 from the mobile node is returned as well in the
HoT message, to ensure that the message comes from someone on
the path to the correspondent node.
A cache, maintained by each IPv6 node, of bindings for other The home nonce index is carried along in the protocol to allow
nodes. A separate Binding Cache SHOULD be maintained by each the correspondent node to later efficiently find the nonce
IPv6 node for each of its IPv6 addresses. The Binding Cache value Ni that it used in creating this cookie.
MAY be implemented in any manner consistent with the external
behavior described in this document, for example by being
combined with the node's Destination Cache as maintained by
Neighbor Discovery [20]. When sending a packet, the Binding
Cache is searched before the Neighbor Discovery conceptual
Destination Cache [20] (i.e., any Binding Cache entry for this
destination SHOULD take precedence over any Destination Cache
entry for the same destination). Each Binding Cache entry
conceptually contains the following fields:
- The home address of the mobile node for which this is the CoT
Binding Cache entry. This field is used as the key for
searching the Binding Cache for the destination address of
a packet being sent. If the destination address of the
packet matches the home address in the Binding Cache entry,
this entry SHOULD be used in routing that packet.
- The care-of address for the mobile node indicated by Care-of Test Message:
the home address field in this Binding Cache entry. If
the destination address of a packet being routed by a
node matches the home address in this entry, the packet
SHOULD be routed to this care-of address, as described in
Section 8.9, for packets originated by this node, or in
Section 9.4, if this node is the mobile node's home agent
and the packet was intercepted by it on the home link.
- A lifetime value, indicating the remaining lifetime This message is sent in response to a CoTI message.
for this Binding Cache entry. The lifetime value is
initialized from the Lifetime field in the Binding Update
that created or last modified this Binding Cache entry.
Once the lifetime on this entry expires, the entry MUST be
deleted from the Binding Cache.
- A flag indicating whether or not this Binding Cache entry Src = correspondent
is a "home registration" entry. Dst = care-of address
Parameters:
- mobile cookie 2
- care-of cookie
- care-of nonce index
- A flag indicating whether or not this Binding Cache entry The correspondent node also sends a challenge to the mobile's
represents a mobile node that should be advertised as a care-of address. When the correspondent node receives the CoTI
router in proxy Neighbor Advertisements sent by this node message, it generates a 16 octet care-of cookie as follows:
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. care-of cookie = MAC_Kcn(care-of address | nonce)
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 The cookie is sent directly to the mobile node at its care-of
in previous Binding Updates for this mobile node home address. Mobile cookie 2 from the mobile node is returned as
address. The Sequence Number field is 8 bits long, well, to ensure that the message comes from someone on the path
and all comparisons between Sequence Number values to the correspondent node.
MUST be performed modulo 2**8. For example, using an
implementation in the C programming language, a Sequence
Number value A is greater than another Sequence Number
value B if ((char)((a) - (b)) > 0), if the "int" data type
is a 8-bit signed integer.
- Recent usage information for this Binding Cache entry, as Again, an index is sent along the cookie in order to identify
needed to implement the cache replacement policy in use in the used nonce. Note that home and care-of nonce indices are
the Binding Cache and to assist in determining whether a likely to be the same in HoT and CoT messages, except when
Binding Request should be sent when the lifetime on this the correspondent node changed its nonce value between the
entry nears expiration. reception of HoTI and the CoTI messages.
- The Binding Security Association (BSA) to be be used when When the mobile node has received both the HoT and CoT messages, the
authenticating Binding Updates that are received for this return routability procedure is complete. As a result, the mobile
Binding Cache entry. node has the means to prove its authority to send a Binding Update
to the correspondent node. The mobile node hashes together the
challenges to form a 20 octet session key (Kbu):
- The Binding Security Association (BSA) to be be used when Kbu = H(home cookie | care-of cookie)
calculating authentication data for inclusion in Binding
Acknowledgements in response to Binding Updates that are
received for this Binding Cache entry.
An entry in a node's Binding Cache for which the node is Note that the correspondent node has not created any state at this
serving as a home agent is marked as a "home registration" point. It is unaware of the session key Kbu, though it can recreate
entry and SHOULD NOT be deleted by the home agent until the Kbu if it is presented the right addresses and nonce indices.
expiration of its binding lifetime. Other Binding Cache
entries MAY be replaced at any time by any reasonable local
cache replacement policy but SHOULD NOT be unnecessarily
deleted. The Binding Cache for any one of a node's IPv6
addresses may contain at most one entry for each mobile node
home address. The contents of a node's Binding Cache MUST NOT
be changed in response to a Home Address option in a received
packet. The contents of all of a node's Binding Cache entries,
for each of its IPv6 addresses, must be cleared when the node
reboots.
Binding Update List 5.5.6. Applying Return Routability for Correspondent Bindings
A list, maintained by each mobile node, recording information After the return routability procedure, the mobile node can proceed
for each Binding Update sent by this mobile node, for which the to perform a binding procedure with the correspondent node. An
Lifetime sent in that Binding Update has not yet expired. The overview of the binding procedure is shown below.
Binding Update List includes all bindings sent by the mobile
node: those to correspondent nodes, those to the mobile node's
home agent, and those to a home agent on the link on which the
mobile node's previous care-of address is located. However,
for multiple Binding Updates sent to the same destination
address, the Binding Update List contains only the most recent
Binding Update (i.e., with the greatest Sequence Number value)
sent to that destination. The Binding Update List MAY be
implemented in any manner consistent with the external behavior
described in this document. Each Binding Update List entry
conceptually contains the following fields:
- The IP address of the node to which a Binding Update was Mobile Node Correspondent node
sent. That node might still have a Binding Cache entry | |
created or updated from this Binding Update, if the Binding | 1. Binding Update |
Update was successfully received by that node (e.g., not | Src = care-of address, Dst = correspondent |
lost by the network) and if that node has not deleted the | Parameters: |
entry before its expiration (e.g., to reclaim space in its | - home address |
Binding Cache for other entries). | - a MAC |
| - home nonce index |
| - care-of nonce index |
| - sequence number |
| - ... |
|---------------------------------------------------->|
| |
| 2. Binding Acknowledgement |
| (if requested) |
| Src = correspondent, |
| Dst = care-of address |
| Parameters: |
| - sequence number |
| - ... |
|<----------------------------------------------------|
| |
- The home address for which that Binding Update was sent. Message 1 actually creates a binding, and message 2 is optional. The
This will be one of the following: correspondent binding procedure consists of the return routability
procedure followed by the messages 1 and 2.
* the mobile node's home addresses for typical Binding 1.
Updates (Sections 10.7 and 10.9), or
* the mobile node's previous care-of address for Binding Binding Update (BU) Message:
Updates sent to establish forwarding from the mobile
node's previous care-of address by a home agent from
this previous care-of address (Section 10.11).
- The care-of address sent in that Binding Update. This The mobile node uses the created session key Kbu to authorize
value is necessary for the mobile node to determine if it the Binding Update.
has sent a Binding Update giving its new care-of address to
this destination after changing its care-of address.
- The initial value of the Lifetime field sent in that Src = care-of address
Binding Update. Dst = correspondent
Parameters:
- home address
- MAC_Kbu(care-of address | correspondent node address | BU)
- home nonce index
- care-of nonce index
- sequence number
- ...
- The remaining lifetime of that binding. This lifetime is The message contains home and care-of nonce indices, so that
initialized from the Lifetime value sent in the Binding the correspondent node knows which nonces to use to recompute
Update and is decremented until it reaches zero, at which the session key. "BU" is the content of the Binding Update
time this entry MUST be deleted from the Binding Update message, excluding (1) the IP header, (2) any extension
List. headers between the IP header the Mobility Header, and (3) the
Authenticator field inside the Binding Update. The result of
the MAC_Kbu function is used as the Authenticator field in
the Binding Update. A sequence number will be used to match
an eventual acknowledgement with this message. The sequence
numbers start from a random value, which offers a weak form
of authentication also to the acknowledgement messages. The
three dots represent all the remaining (not security related)
information in the message.
- The maximum value of the Sequence Number field sent in Once the correspondent node has verified the MAC, it can create
previous Binding Updates to this destination. The Sequence a binding cache entry for the mobile.
Number field is 8 bits long, and all comparisons between
Sequence Number values MUST be performed modulo 2**8. For
example, using an implementation in the C programming
language, a Sequence Number value A is greater than another
Sequence Number value B if ((char)((a) - (b)) > 0), if the
"char" data type is a 8-bit signed integer.
- The time at which a Binding Update was last sent to this 2.
destination, as needed to implement the rate limiting
restriction for sending Binding Updates.
- The state of any retransmissions needed for this Binding Binding Acknowledgement (BA) Message:
Update, if the Acknowledge (A) bit was set in this Binding
Update. This state includes the time remaining until the
next retransmission attempt for the Binding Update, and the
current state of the exponential back-off mechanism for
retransmissions.
- A flag that, when set, indicates that future Binding The Binding Update is optionally acknowledged by the
Updates should not be sent to this destination. The correspondent node.
mobile node sets this flag in the Binding Update List
entry when it receives an ICMP Parameter Problem, Code 2,
error message in response to a Binding Update sent to that
destination, as described in Section 10.17.
Home Agents List Src = correspondent
Dst = care-of address
Parameters:
- sequence number
- ...
A list, maintained by each home agent and each mobile node, The Binding Acknowledgement is not authenticated in other ways
recording information about each home agent from which this than including the right sequence number in the reply. The
node has received a Router Advertisement in which the Home three dots represent all the remaining (not security related)
Agent (H) bit is set, for which the remaining lifetime for information in the message.
this list entry (defined below) has not yet expired. The
home agents list is thus similar to the Default Router
List conceptual data structure maintained by each host for
Neighbor Discovery [20], although the Home Agents List MAY be
implemented in any manner consistent with the external behavior
described in this document.
Each home agent maintains a separate Home Agents List for 5.5.7. Updating Node Keys and Nonces
each link on which it is serving as a home agent; this list
is used by a home agent in the dynamic home agent address
discovery mechanism. Each mobile node, while away from home,
also maintains a Home Agents List, to enable it to notify a
home agent on its previous link when it moves to a new link; a
mobile node MAY maintain a separate Home Agents List for each
link to which it is (or has recently) connected, or it MAY
maintain a single list for all links. Each Home Agents List
entry conceptually contains the following fields:
- The link-local IP address of a router on the link, that An update of Kcn can be done at the same time as an update of Ni, so
this node currently believes is operating as a home agent that i identifies both the nonce and the key. Old Kcn values have to
for that link. A new entry is created or an existing be therefore remembered as long as old nonce values.
entry is updated in the Home Agents List in response to
receipt of a valid Router Advertisement in which the Home
Agent (H) bit is set. The link-local address of the home
agent is learned through the Source Address of the Router
Advertisements received from it [20].
- One or more global IP addresses for this home agent, Before sending a Binding Update in Step 3, the mobile node has
learned through Prefix Information options with to wait for both the Home and Care-of Cookies to arrive. Due
the Router Address (R) bit set, received in Router to resource limitations, rapid deletion of bindings, or reboots
Advertisements from this link-local address. Global it can not be guaranteed that the cookies are still fresh and
addresses for the router in a Home Agents List entry MUST acceptable when the correspondent node uses them in the processing
be deleted once the prefix associated with that address is of the Binding Update. If the cookies have become too old, the
no longer valid [20]. 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.
Are there interactions with the new Router Given that the cookies are normally expected to be usable for
Advertisement stuff? some time, the mobile node MAY use them beyond a single run of the
return routability procedure. A fast moving mobile node may reuse
a recent Home Cookie from a correspondent node when moving to a new
location, and just acquire a new Care-of Cookie to show routability
in the new location. While this does not save roundtrips due to the
parallel nature of the home and care-of return routability tests, the
roundtrip through the home agent may be longer, and consequently this
optimization is often useful. A mobile node that has multiple home
addresses, may also use the same Care-of Cookie for Binding Updates
concerning all of these addresses.
- The remaining lifetime of this Home Agents List entry. If 5.5.8. Preventing Replay Attacks
a Home Agent Information Option is present in a Router
Advertisement received from a home agent, the lifetime of
the Home Agents List entry representing that home agent
is initialized from the Home Agent Lifetime field in the
option; otherwise, the lifetime is initialized from the
Router Lifetime field in the received Router Advertisement.
The Home Agents List entry lifetime is decremented until it
reaches zero, at which time this entry MUST be deleted from
the Home Agents List.
- The preference for this home agent; higher values The return routability procedure also protects the participants
indicate a more preferable home agent. The preference against replayed Binding Updates. The attacker can't replay the
value is taken from the Home Agent Preference field (a same message due to the sequence number which is a part of the
signed, twos-complement integer) in the received Router Binding Update, and the attacker can't modify the Binding Update
Advertisement, if the Router Advertisement contains a Home since the MAC would not verify after that. Care must be taken when
Agent Information Option, and is otherwise set to the removing bindings at the correspondent node, however. If a binding
default value of 0. A home agent uses this preference in is removed either due to garbage collection, request, or expiration
ordering the Home Agents List returned in an ICMP Home and the nonce used in its creation is still valid, an attacker can
Agent Address Discovery message in response to a mobile replay the old Binding Update. This can be prevented by having the
node's initiation of dynamic home agent address discovery. correspondent node change the nonce often enough to ensure that the
A mobile node uses this preference in determining which nonces used when removed entries were created are no longer valid.
of the home agents on its previous link to notify when it If many such deletions occur the correspondent node can batch them
moves to a new link. together to avoid having to increment the nonce index too often.
Can we delete the preference stuff? Is anyone using 5.5.9. Preventing Denial-of-Service Attacks
it?
4.8. Binding Management 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.
When a mobile node configures a new care-of address and decides to The correspondent nodes do not have to retain any state about
use this new address as its primary care-of address, the mobile individual mobile nodes until an authentic Binding Update arrives.
node registers this new binding with its home agent by sending This is achieved through the use of the nonces and Kcn that are not
the home agent a Binding Update. The mobile node indicates specific to individual mobile nodes. The cookies are specific, but
that an acknowledgement is needed for this Binding Update and they can be reconstructed based on the home and care-of address
continues to periodically retransmit it until acknowledged. The information that arrives with the Binding Update. This means that
home agent acknowledges the Binding Update by returning a Binding the correspondent nodes are safe against memory exhaustion attacks
Acknowledgement to the mobile node. 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.
When a mobile node receives a packet tunneled to it from its home Nevertheless, as [1] describes, there are situations in which it is
agent, the mobile node uses that as an indication that the original impossible for the mobile and correspondent nodes to determine if
sending correspondent node has no Binding Cache entry for the mobile they actually need a binding or whether they just have been fooled
node, since the correspondent node would otherwise have sent the into believing so by an attacker. Therefore, it is necessary to
packet directly to the mobile node using a Routing header. If the consider situations where such attacks are being made.
mobile node has a Binding Security Association (BSA) with that
correspondent node, the mobile node thus returns a Binding Update
to the correspondent node, allowing it to cache the mobile node's
binding for routing future packets to it. Although the mobile node
may request an acknowledgement for this Binding Update, it need not,
since subsequent packets from the correspondent node will continue
to be intercepted and tunneled by the mobile node's home agent,
effectively causing any needed Binding Update retransmission.
If the mobile node receives such a tunneled packet but does not have The binding updates that are used in Mobile IPv6 are only an
a BSA with the correspondent node, the mobile node SHOULD initiate optimization, albeit a very important optimization. A mobile node
the process of establishing the necessary security association by can communicate with a correspondent node even if the correspondent
following the procedures outlined in Section 4.5 refuses to accept any of its binding updates. However, performance
will suffer because packets from the correspondent node to the mobile
node will be routed via the mobile's home agent rather than a more
direct route. A correspondent node can protect itself against some
of the resource exhaustion attacks by not processing binding updates
when it is flooded with a large number of binding updates that fail
the cryptographic integrity checks. If a correspondent 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.
A correspondent node with a Binding Cache entry for a mobile node Additional information needed to make this decision about responding
may refresh this binding, for example if the binding's lifetime to requests will usually originate in layers above IP. For example,
is near expiration, by sending a Binding Request to the mobile TCP knows if the node has a queue of data that it is trying to send
node. Normally, a correspondent node will only refresh a Binding to a peer. A conformant implementation of the protocols in this
Cache entry in this way if it is actively communicating with the specification is not required to make use of information from higher
mobile node and has indications, such as an open TCP connection to protocol layers, but implementations are likely to be able to manage
the mobile node, that it will continue this communication in the resources more effectively by making use of such information.
future. When a mobile node receives a Binding Request, it replies by
returning a Binding Update to the node sending the Binding Request.
A mobile node may use more than one care-of address at the same time, 5.5.10. Correspondent Binding Procedure Extensibility
although only one care-of address may be registered for it at its
home agent as its primary care-of address. The mobile node's home
agent will tunnel all intercepted packets for the mobile node to its
(single) registered primary care-of address, but the mobile node
will accept packets that it receives at any of its current care-of
addresses. 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 As discussed in Appendix D.3, in the future there may be other
correspondent nodes usually will route packets directly to the mobile mechanisms beyond the return routability procedure for authorizing
node's care-of address, so that the home agent is rarely involved mobile nodes to correspondent nodes. The nodes can use other methods
with packet transmission to the mobile node. This is essential for based on future definition of flag values in the Reserved fields of
scalability and reliability, and for minimizing overall network load. HoTI, HoT, CoTI, CoT, and BU messages. Nodes need assurance against
By caching the care-of address of a mobile node, optimal routing of bidding down attacks in this selection by following the procedure
packets can be achieved from the correspondent node to the mobile described in Section 14.3.
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. New IPv6 Destination Options and Message Types 6. New IPv6 Protocols, Message Types, and Destination Option
5.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. The Mobility Header is an IPv6 protocol. Rules
regarding how it is sent and what addresses are used in the IPv6 regarding how it is sent and what addresses are used in the IPv6
header are given separately in Sections 5.1.2 to 5.1.9. Mobile nodes header are given separately in Sections 6.1.2 through 6.1.9, which
MUST use reverse tunneling to send Mobility Header messages when the describe the message types used in this protocol.
source address is set to the home address of the mobile node.
5.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 62 (XXX)
in the immediately preceding header, and has the following format: in the immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Payload Proto | Header Len | MH Type | |Payload Proto | Header Len | MH Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
skipping to change at page 32, line 30 skipping to change at page 32, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]. IPv4 Protocol field [10].
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 12.1). Section D.1).
Thus implementations conforming to this specification MUST set Implementations conforming to this specification SHOULD set the
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.
MH Type MH Type
16-bit selector. Identifies the particular mobility message in 16-bit selector. Identifies the particular mobility message
question. Legal values are defined in Sections 5.1.2 to 5.1.8. in question. Current values are specified in Sections 6.1.2
An unrecognized MH Type field SHOULD cause an error to be sent to 6.1.9. An unrecognized MH Type field causes an error to be
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 the Mobility Header. The checksum is the 16-bit one's of the Mobility Header. The checksum is the 16-bit one's
complement of the one's complement sum of the entire Mobility complement of the one's complement sum of an octet string
Header starting with the Payload Proto field, prepended with a consisting of a "pseudo-header" followed by the entire
"pseudo-header" of IPv6 header fields, as specified in [IPv6, Mobility Header starting with the Payload Proto field. The
section 8.1]. The Next Header value used in the pseudo-header pseudo-header contains IPv6 header fields, as specified
is 62 (XXX). For computing the checksum, the checksum field is in Section 8.1 of [6]. The Next Header value used in the
set to zero. pseudo-header is 62 (XXX). 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.
5.1.2. Binding Request (BR) Message Mobile IPv6 also defines a number of "mobility options" for use
within these messages; if included, any options MUST appear after the
fixed portion of the message data specified in this document. The
presence of such options will be indicated by the Header Len field
within the message. When the Header Len is greater than the length
required for the message specified here, the remaining octets are
interpreted as mobility options options. The encoding and format of
defined options are described in Section 6.2.
The Binding Request (BR) message is used to request a mobile node's Alignment requirements for the Mobility Header are same as for any
binding from the mobile node. A packet containing a Binding Request IPv6 protocol Header. That is, they MUST be aligned on an 8-octet
message is sent in the same way as any packet to a mobile node boundary. We also require that the Mobility Header length is a
(Section 8.9). When a mobile node receives a packet containing a multiple of 8 octets.
Binding Request message and there already exists a Binding Update
List entry for the source of the Binding Request, it MAY start
a Return Routability Procedure (see Section 4.5) if it believes
the amount of traffic with the correspondent justifies the use of
Route Optimization. Note that the mobile node SHOULD NOT respond
Binding Requests from previously unknown correspondent nodes due to
Denial-of-Service concerns.
The Binding Request message uses the MH Type value 0. When this 6.1.2. Binding Refresh Request (BRR) Message
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows: The Binding Refresh Request (BRR) message is used to request a
mobile node's binding from the mobile node. A packet containing
a Binding Refresh Request message is sent in the same way as any
packet to a mobile node (Section 9.6). When a mobile node receives
a packet containing a Binding Refresh Request message and there
already exists a Binding Update List entry for the source of the
Binding Refresh Request, it MAY start a return routability procedure
(see Section 5.5) if it believes the amount of traffic with the
correspondent justifies the use of Route Optimization. Note that
the mobile node SHOULD NOT respond to Binding Refresh Requests from
previously unknown correspondent nodes due to Denial-of-Service
concerns.
The Binding Refresh Request message uses the MH Type value 0. When
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
16-bit field reserved for future flags. These flag bits are 16-bit field reserved for future use. The value MUST be
reserved for future use, and MUST be initialized to zero by the initialized to zero by the sender, and MUST be ignored by the
sender, and MUST be ignored by the receiver. receiver.
Parameters
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand. A
Binding Request MUST include the following parameter:
- Authentication Data parameter. This parameter contains a
cryptographic hash value which is used to ensure that it
has been sent by the correspondent node. The authenticator
covering a Binding Acknowledgement MUST be computed over
a bitstring containing the following fields of the IPv6
header and the Mobility Header, in order:
* The Home Address of the mobile node, from the
Destination Address field of the IPv6 header.
* The address of the correspondent node, from the Source
Address field of the IPv6 header.
* The contents of the Mobility Header, excluding the
Authenticator field (inside the Authentication Data
parameter) which is included as zeroes for the purposes
of calculating the Authenticator.
* Four bytes of zero. This is included for a potential Mobility options
future extension.
The actual authenticator calculation over sequence of bits Variable-length field of such length that the complete Mobility
is described in Section 4.5. Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Request message, that need not be present in all Binding Refresh Request message, that need not be present in
Binding Requests sent. This use of MH parameters also allows all Binding Requests sent. This use of mobility options also
for future extensions to the format of the Binding Request allows for future extensions to the format of the Binding
message to be defined. The encoding and format of defined Refresh Request message to be defined. The following options
parameters are described in Section 5.2. The following are valid in a Binding Refresh Request message:
parameters are valid in a Binding Request message:
- Unique Identifier Parameter - Unique Identifier Option
If no actual parameters are present in this message, no padding is - Binding Authorization option
necessary.
5.1.3. Home Test Init (HoTI) Message The Header Length field in the Mobility Header for this message
MUST be set to 1 (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.
The Home Test Init (HoTI) message is used to initiate the Return 6.1.3. Home Test Init (HoTI) Message
Routability procedure from the mobile node to a correspondent node
(see Section 10.9). This message is always sent with the Source The Home Test Init (HoTI) message is used to initiate the return
Address set to the home address of the mobile node, Destination routability procedure from the mobile node to a correspondent node
Address set to the correspondent node's address, and is tunneled (see Section 11.6.2). The purpose of this message is to test the
through the home agent when the mobile node is away from home. reachability of the home address. This message is always sent with
the Source Address set to the home address of the mobile node,
Destination Address set to the correspondent node's address, and is
tunneled through the home agent when the mobile node is away from
home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between
the home agent and the mobile node. This protection is guided by the
IPsec Policy Data Base. (Note the protection of HoTI messages is
different from the requirement to protect regular payload traffic,
which MAY use such tunnels as well.)
The HoTI message uses the MH Type value 1. When this value is 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 indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows: in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags Reserved
16-bit field reserved for future flags. These flag bits are 16-bit field reserved for future use. This value MUST be
reserved for future use, and MUST be initialized to zero by the initialized to zero by the sender, and MUST be ignored by the
sender, and MUST be ignored by the receiver. receiver.
Parameters Mobile cookie
Variable-length field, of length such that the complete 32-bit field which contains a random value, mobile cookie 1,
Mobility Header is an integer multiple of 8 octets long. selected by the mobile node.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
There MAY be additional information, associated with this Mobility options
message that need not be present in all HoTI messages. This
use of MH parameters also allows for future extensions to the
format of the HoTI message to be defined. The encoding and
format of defined parameters are described in Section 5.2. The
following parameters are valid in a HoTI message:
- Unique Identifier Parameter Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
If no actual parameters are present in this message, 4 bytes of Pad1 There MAY be additional information, associated with this
or PadN parameters are needed to make the length of the message a message that need not be present in all HoTI messages. This
multiple of 8. 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:
The HoTI message SHOULD be protected by an IPsec policy that employs - Unique Identifier Option
ESP between the home agent and the mobile node. The Header Length field in the Mobility Header for this message
MUST be set to 2 (since unit is 8 octets) plus the total length of
all mobility options present (also in 8 octet units). 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 A packet that includes a HoTI message MUST NOT include a Home Address
option. destination option.
5.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 The Care-of Test Init (CoTI) message is used to initiate the return
Routability procedure from the mobile node to a correspondent node routability procedure from the mobile node to a correspondent node
(see Section 10.9). This message is always sent with the Source (see Section 11.6.2). The purpose of this message is to test the
Address set to the care-of address of the mobile node, and is sent reachability of the care-of address. This message is always sent
directly to the correspondent node. with the Source Address set to the care-of address of the mobile
node, and is sent directly to the correspondent node.
The CoTI message uses the MH Type value 2. When this value is 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 indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows: in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
16-bit field reserved for future flags. These flag bits are 16-bit field reserved for future use. The value MUST be
reserved for future use, and MUST be initialized to zero by the initialized to zero by the sender, and MUST be ignored by the
sender, and MUST be ignored by the receiver. receiver.
Parameters Mobile cookie
Variable-length field, of length such that the complete 32-bit field which contains a random value, mobile cookie 2,
Mobility Header is an integer multiple of 8 octets long. selected by the mobile node.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand. Mobility options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
message that need not be present in all CoTI messages. This message that need not be present in all CoTI messages. This
use of MH parameters also allows for future extensions to the use of mobility options also allows for future extensions to
format of the CoTI message to be defined. The encoding and the format of the CoTI message to be defined. The encoding and
format of defined parameters are described in Section 5.2. The format of defined options are described in Section 6.2. The
following parameters are valid in a CoTI message: following options are valid in a CoTI message:
- Unique Identifier Parameter - Unique Identifier Option
If no actual parameters are present in this message, no padding is The Header Length field in the Mobility Header for this message
necessary. 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 CoTI message MUST NOT include a Home Address A packet that includes a CoTI message MUST NOT include a Home Address
option. destination option.
5.1.5. Home Test (HoT) Message 6.1.5. Home Test (HoT) Message
The Home Test (HoT) message is an answer to the HoTI message, and The Home Test (HoT) message is a response to the HoTI message, and
is sent from the correspondent node to the mobile node (see Section is sent from the correspondent node to the mobile node (see Section
8.2). This message is always sent with the Destination Address set 8.2). This message is always sent with the Destination Address set
to the home address of the mobile node, Source Address set to the to the home address of the mobile node, Source Address set to the
address of the correspondent node, and is tunneled through the home address of the correspondent node, and is tunneled through the home
agent when the mobile node is away from 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.
The HoT message uses the MH Type value 3. When this value is 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 indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows: in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | | | Home Nonce Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Home Cookie (128 bits) | | Home Cookie (128 bits) |
+ + + +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
32-bit field reserved for future flags. These flag bits are The two 16-bit fields are reserved for future use. These
reserved for future use, and MUST be set to zero, otherwise an values MUST be initialized to zero by the sender, and MUST be
error MUST be returned to the sender. 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. It correspondent node in a subsequent binding update. Strictly
will allow the correspondent node to select the appropriate speaking, this value is not necessary in the authentication,
challenge values to authenticate the binding update. 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
32-bit field which contains mobile cookie 1, returned by the
correspondent node.
Home Cookie Home Cookie
This field contains the cookie K0 in the Return Routability This field contains the home cookie in the return routability
Procedure; it is the first of two cookies which are to be procedure; it is the first of two cookies which are to be
processed to form a key which is then used to authenticate a processed to form a key which is then used to authenticate a
binding update. binding update.
Parameters Mobility options
Variable-length field, of length such that the complete Variable-length field of such length that the complete Mobility
Mobility Header is an integer multiple of 8 octets long. Header is an integer multiple of 8 octets long. Contains one
Contains one or more TLV-encoded parameters. The receiver MUST or more TLV-encoded mobility options. The receiver MUST ignore
ignore and skip any parameters 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
message that need not be present in all HoT messages. MH message that need not be present in all HoT messages. Mobility
parameters are used to carry that information. The encoding options are used to carry that information. The encoding and
and format of defined parameters are described in Section 5.2. format of defined options are described in Section 6.2. This
This use of MH parameters also allows for future extensions use of mobility options also allows for future extensions
to the format of the HoT message to be defined. This to the format of the HoT message to be defined. This
specification does not define any optional parameters for the specification does not define any options valid for the HoT
HoT message. message.
If no actual parameters are present in this message, 4 bytes of Pad1
or PadN parameters are needed to make the length of the message a
multiple of 8.
The HoT message SHOULD be protected by an IPsec policy that employs The Header Length field in the Mobility Header for this message
ESP between the home agent and the mobile node, in order to prevent MUST be set to 4 (since unit is 8 octets) plus the total length of
attackets e.g. on the same link as the MN to receive the Home all mobility options present (also in 8 octet units). If no actual
Cookie. options are present in this message, no padding is necessary.
5.1.6. Care-of Test (CoT) Message 6.1.6. Care-of Test (CoT) Message
The Care-of Test (CoT) message is an answer to the CoTI message, and The Care-of Test (CoT) message is a response to the CoTI message, and
is sent from the correspondent node to the mobile node (see Section is sent from the correspondent node to the mobile node (see Section
8.2). This message is always sent with the Source Address set to the 8.2). This message is always sent with the Source Address set to the
address of the correspondent node, the Destination Address set to address of the correspondent node, the Destination Address set to
the care-of address of the mobile node, and is sent directly to the the care-of address of the mobile node, and is sent directly to the
mobile node. mobile node.
The CoT message uses the MH Type value 4. When this value is 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 indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows: in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index | | | Care-of Nonce Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Care-of Cookie (128 bits) | | Care-of Cookie (128 bits) |
+ + + +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
32-bit field reserved for future flags. These flag bits are The two 16-bit fields and the one 32-bit field are reserved for
reserved for future use, and MUST be set to zero, otherwise an future use. These values MUST be initialized to zero by the
error MUST be returned to the sender. sender, and MUST be ignored by the receiver.
Care-of Nonce Index Care-of Nonce Index
This field will be echoed back by the mobile node to the This 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. It
will allow the correspondent node to select the appropriate will allow the correspondent node to select the appropriate
challenge values to authenticate the binding update. challenge values to authenticate the binding update.
Mobile cookie
32-bit field which contains the mobile cookie 2, returned by
the correspondent node.
Care-of Cookie Care-of Cookie
This field contains the cookie K1 in the Return Routability This field contains the care-of cookie in the return
Procedure; it is the second of two cookies which are to be routability procedure; it is the second 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.
Parameters Mobility options
Variable-length field, of length such that the complete Variable-length field of such length that the complete Mobility
Mobility Header is an integer multiple of 8 octets long. Header is an integer multiple of 8 octets long. Contains one
Contains one or more TLV-encoded parameters. The receiver MUST or more TLV-encoded mobility options. The receiver MUST ignore
ignore and skip any parameters 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
message that need not be present in all CoT messages. MH message that need not be present in all CoT messages. Mobility
parameters are used to carry that information. The encoding options are used to carry that information. The encoding and
and format of defined parameters are described in Section 5.2. format of defined options are described in Section 6.2. This
This use of MH parameters also allows for future extensions use of mobility options also allows for future extensions
to the format of the CoT message to be defined. This to the format of the CoT message to be defined. This
specification does not define any optional parameters for the specification does not define any options valid for the CoT
CoT message. message.
If no actual parameters are present in this message, 4 bytes of Pad1 The Header Length field in the Mobility Header for this message
or PadN parameters are needed to make the length of the message a MUST be set to 4 (since unit is 8 octets) plus the total length of
multiple of 8. all mobility options present (also in 8 octet units). If no actual
options are present in this message, no padding is necessary.
5.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:
skipping to change at page 40, line 47 skipping to change at page 42, line 26
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . 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 5.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 node The Home Registration (H) bit is set by the sending mobile
to request the receiving node to act as this node's home agent. node to request that the receiving node should act as this
The destination of the packet carrying this message MUST be node's home agent. The destination of the packet carrying this
that of a router sharing the same subnet prefix as the home message MUST be that of a router sharing the same subnet prefix
address of the mobile node in the binding (given by the Home as the home address of the mobile node in the binding.
Address field in the Home Address option in the packet).
Single Address Only (S) Single Address Only (S)
If the `S' bit is set, the mobile node requests that the home If the `S' bit is set, the mobile node requests that the home
agent make no changes to any other Binding Cache entry except agent make no changes to any other Binding Cache entry except
for the particular one containing the home address specified in for the particular one containing the home address specified
the Home Address option. This disables home agent processing in the Home Address destination option. This disables home
for other related addresses, as is described in Section 9.1. agent processing for other related addresses, as is described
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 the receiving node (the mobile node's mobile node to request that the receiving node (the mobile
home agent) to perform Duplicate Address Detection [35] on node's home agent) perform Duplicate Address Detection [33]
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. If the Duplicate Address Detection performed by
the home agent fails, the Status field in the returned Binding the home agent fails, the Status field in the returned Binding
Acknowledgement will be set to 138 (Duplicate Address Detection Acknowledgement will be set to 138 (Duplicate Address Detection
failed). failed).
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.
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. Each Binding Update
sent by a mobile node MUST use a Sequence Number greater than sent by a mobile node MUST use a Sequence Number greater than
the Sequence Number value sent in the previous Binding Update the Sequence Number value sent in the previous Binding Update
(if any) to the same destination address (modulo 2**16, as (if any) to the same destination address (modulo 2**16, as
defined in Section 4.7). There is no requirement, however, defined in Section 4.5). There is no requirement, however,
that the Sequence Number value strictly increase by 1 with each that the Sequence Number value strictly increase by 1 with each
new Binding Update sent or received. Both home agents and 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 correspondent nodes use the sequence number also to prevent
replay attacks. replay attacks.
Lifetime Lifetime
32-bit unsigned integer. The number of seconds remaining 32-bit unsigned integer. The number of seconds 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.
Bindings established with correspondent nodes using the return
routability procedure MUST NOT exceed MAX_RR_BINDING_LIFE
seconds.
Home Address Home Address
This field tells the correspondent node the home address of the The home address of the mobile node associated with this
mobile node. Binding Update.
Parameters Mobility options
Variable-length field, of length such that the complete Variable-length field of such length that the complete Mobility
Mobility Header is an integer multiple of 8 octets long. Header is an integer multiple of 8 octets long. Contains one
Contains one or more TLV-encoded parameters. The receiver MUST or more TLV-encoded mobility options. The encoding and format
ignore and skip any parameters which it does not understand. A of defined options are described in Section 6.2. The receiver
Binding Update sent to a correspondent node MUST include the MUST ignore and skip any options which it does not understand.
following parameters: 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 parameter. This parameter contains - Nonce Indices option. This option contains information the
information the correspondent node needs in order to find correspondent node needs in order to find the challenge
the challenge values Nj and Ni. values Ni and Nj.
- Authentication Data parameter. This parameter contains a - Binding Authorization Data option. This option contains
cryptographic hash value which is used to ensure that it a cryptographic hash value which is used to ensure that
has been sent by the same party who received the HoT and it has been sent by the same party who received the HoT
CoT messages. The authenticator covering a Binding Update and CoT messages. The authenticator covering a Binding
MUST be computed over a bitstring containing the following Update MUST be 96 bits and computed over a string of octets
fields of the IPv6 header and the Mobility Header, in containing the following fields of the IPv6 header and the
order: Mobility Header, in order:
* Care-of Address, in the Source Address field of the * Care-of Address, in the Source Address field of the
IPv6 header IPv6 header
* The address of the correspondent node, in the * The address of the correspondent node, in the
Destination Address field of the IPv6 header. Destination Address field of the IPv6 header.
* The contents of the Mobility Header, excluding the * The contents of the Mobility Header, excluding the
Authenticator field (within the Authentication Data Authenticator field (within the Binding Authorization
parameter) which is included as zeroes for the purposes Data mobility option) which is not included for the
of calculating the Authenticator. Parameters of the purposes of calculating the Authenticator. Options of
Mobility Header are included in the calculation. the Mobility Header are included in the calculation.
* Four bytes of zero.
The actual authenticator calculation over sequence of bits The actual authenticator calculation over a sequence of
is described in Section 4.5. bits is described in Section 5.5.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Update message, that need not be present in all Binding Binding Update message, that need not be present in all Binding
Updates sent. This use of MH parameters also allows for future Updates sent. This use of mobility options also allows for
extensions to the format of the Binding Update message to be future extensions to the format of the Binding Update message
defined. The encoding and format of defined parameters are to be defined. The following options are valid in a Binding
described in Section 5.2. The following parameters are valid Update message:
in a Binding Update message:
- Unique Identifier Parameter - Unique Identifier option
- Alternate Care-of Address Parameter - Binding Authorization Data option
If no actual parameters are present in this message, 4 bytes of Pad1 - Alternate Care-of Address option
or PadN parameters are needed to make the length of the message a The Header Length field in the Mobility Header for this message
multiple of 8. 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 message to the correspondent node MUST NOT include A Binding Update to the home agent MUST include the Home Address
the Home Address option in order to avoid reflection attacks destination option in order to allow for the use of manually keyed
described in Section 4.5. A Binding Update to the home agent MUST IPsec in the protection of these messages. Note also that as
include the Home Address option in order to allow for the use of described in Section 6.3, the Home Address destination option is not
manually keyed IPsec in the protection of these messages. accepted by correspondent nodes that do not have an existing binding
with the sender.
When a packet contains both a Home Address Option and a Binding When a packet contains both a Home Address destination option and a
Update message, the sender MUST use the same address in both. The Binding Update message, the sender MUST use the same address in both.
receiver MUST check for the equal values and MUST silently discard a The receiver MUST check for equal values and MUST silently discard a
packet that does not pass this test. packet that does not pass this test.
The home address of the mobile node in the binding given in the
Binding Update message is that which was received as the value of the
Home Address field in the Home Address option in the packet.
The care-of address for the binding given in the Binding Update The care-of address for the binding given in the Binding Update
message is normally that which was received as the value in the message is normally that which was received as the value in the
Source Address field in the IPv6 header of the packet carrying the Source Address field in the IPv6 header of the packet carrying the
Binding Update message. However, a care-of address different from Binding Update message. However, a care-of address different from
the Source Address MAY be specified by including an Alternate Care-of the Source Address MAY be specified by including an Alternate Care-of
Address parameter in the Binding Update message. In any case, the Address mobility option in the Binding Update message. When such
care-of address MUST NOT be any IPv6 address which is prohibited message is sent to the correspondent node and the return routability
for use within a Routing Header; thus multicast addresses, the procedure is used as the authorization method, the Care-of Test Init
unspecified address, loop-back address, and link-local addresses and Care-of Test messages MUST have been performed for the address in
are excluded. Binding Updates indicating any such excluded care-of the Alternate Care-of Address option (not the Source Address). The
address MUST be silently discarded. contents of the Nonce Indices and the Authenticator mobility options
MUST be based on information gained in this test.
If the care-of address for the binding (specified either in an
Alternate Care-of Address parameter in the Binding Update message, if
present, or in the Source Address field in the packet's IPv6 header)
is equal to the home address of the mobile node, the Binding Update
message indicates that any existing binding for the mobile node MUST
be deleted. Likewise, if the Lifetime field in the Binding parameter
is equal to 0, the Binding Update message indicates that any existing
binding for the mobile node MUST be deleted. In each of these cases,
a Binding Cache entry for the mobile node MUST NOT be created in
response to receiving the Binding Update.
When the care-of address is NOT equal to the home address, In any case, the care-of address MUST NOT be any IPv6 address
what if we just delete that particular care-of address? which is prohibited for use within a Routing Header; thus multicast
addresses, the unspecified address, loop-back address, and link-local
addresses are excluded. Binding Updates indicating any such excluded
care-of address MUST be silently discarded.
The last Sequence Number value sent to a destination in a Binding The deletion of a binding can be indicated by setting the Lifetime
parameter is stored by the mobile node in its Binding Update List field to 0 or by setting the care-of address as equal to the home
entry for that destination; the last Sequence Number value received address (the care-of address can be specified either in an Alternate
from a mobile node in a Binding Update is stored by a correspondent Care-of Address mobility option in the Binding Update message, if
node in its Binding Cache entry for that mobile node. Thus, the present, or in the Source Address field in the packet's IPv6 header).
mobile node's and the correspondent node's knowledge of the last
sequence number expire at the same time. If the sending mobile node
has no Binding Update List entry, the Sequence Number may start at
any value; if the receiving correspondent node has no Binding Cache
entry for the sending mobile node, it MUST accept any Sequence Number
value in a received Binding Update from this mobile node. The mobile
node MUST NOT use the same Sequence Number in two different Binding
Updates to the same correspondent node, even if the Binding Updates
provide different care-of addresses.
5.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 5.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 is Acknowledgement to the mobile node, if the Acknowledge (A) bit
set in the Binding Parameter carried in the Binding Update. The is set in the the Binding Update. The Binding Acknowledgement
Binding Acknowledgement message is sent to the Source Address of the message is sent to the Source Address of the Binding Update message
Binding Update message it is an answer to, with the source being the which is being acknowledged. The Source Address of the Binding
Destination Address from the Binding Update. 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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | Sequence # | | Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh | | Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Parameters . . 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
skipping to change at page 46, line 34 skipping to change at page 47, line 38
142 142
Route optimization unnecessary due to low traffic Route optimization unnecessary due to low traffic
143 143
Invalid authenticator Invalid authenticator
144 144
Too old Home Nonce Index Expired Home Nonce Index
145 145
Too old Care-of Nonce Index 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" [32]. the most recent "Assigned Numbers" [30].
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 being
acknowledged, for use by the mobile node in matching this acknowledged, for use by the mobile node in matching this
Acknowledgement with an outstanding Binding Update. Acknowledgement with an outstanding Binding Update.
Lifetime Lifetime
The granted lifetime, in seconds, for which this node will The granted lifetime, in seconds, for which this node SHOULD
SHOULD retain the entry for this mobile node in its Binding retain the entry for this mobile node in its Binding Cache.
Cache. Correspondent nodes should make an effort to honor Correspondent nodes should make an effort to honor the
the lifetimes, since an entry that was garbage collected too lifetimes, since an entry that was garbage collected too early
early might cause subsequent packets from the mobile node to might cause subsequent packets from the mobile node to be
be dropped, if they contained the Home Address Option. While dropped, if they contained the Home Address destination option.
this situation is recoverable since an error message is sent While this situation is recoverable since an error message is
to the mobile node, it causes an unnecessary break in the sent to the mobile node, it causes an unnecessary break in the
communications. communications.
Correspondent nodes SHOULD also retain a BCE entry for the Mobile nodes SHOULD send a new Binding Update well before the
purposes of accepting Home Address Options somewhat longer than expiration of this period in order to extend the lifetime and
they keep on using the entry for Route Optimization of outgoing not cause a disruption in communications. This is particularly
packets. This helps to avoid dropped packets, particularly necessary in order to prevent packets from being dropped due
when clock drift can be a problem. 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 If the node sending the Binding Acknowledgement is serving
as the mobile node's home agent, the Lifetime period also as the mobile node's home agent, the Lifetime period also
indicates the period for which this node will continue this indicates the period for which this node will continue this
service; if the mobile node requires home agent service from service; if the mobile node requires home agent service from
this node beyond this period, the mobile node MUST send a new this node beyond this period, the mobile node MUST send a new
Binding Update to it before the expiration of this period (even Binding Update to it before the expiration of this period (even
if it is not changing its primary care-of address), in order if it is not changing its primary care-of address), in order
to extend the lifetime. The value of this field is undefined to extend the lifetime. The value of this field is undefined
if the Status field indicates that the Binding Update was if the Status field indicates that the Binding Update was
skipping to change at page 47, line 38 skipping to change at page 48, line 46
Refresh Refresh
The recommended interval, in seconds, at which the mobile The recommended interval, in seconds, at which the mobile
node SHOULD send a new Binding Update to this node in order node SHOULD send a new Binding Update to this node in order
to "refresh" the mobile node's binding in this node's Binding to "refresh" the mobile node's binding in this node's Binding
Cache. This refreshing of the binding is useful in case the Cache. This refreshing of the binding is useful in case the
node fails and loses its cache state. The Refresh period is node fails and loses its cache state. The Refresh period is
determined by the node sending the Binding Acknowledgement (the determined by the node sending the Binding Acknowledgement (the
node caching the binding). If this node is serving as the node caching the binding). If this node is serving as the
mobile node's home agent, the Refresh value may be set, for mobile node's home agent, the Refresh value may be set, for
example, based on whether the node stores its Binding Cache example, based on whether the node stores its Binding Cache in
in volatile storage or in nonvolatile storage. Note that as volatile storage or in nonvolatile storage.
discussed in Section 4.5.4, home agents need to keep at least
some information about sequence numbers in non-volatile memory.
If the node sending the Binding Acknowledgement is not If the node sending the Binding Acknowledgement is not
serving as the mobile node's home agent, the Refresh period serving as the mobile node's home agent, the Refresh period
SHOULD be set equal to the Lifetime period in the Binding SHOULD be set equal to the Lifetime period in the Binding
Acknowledgement; even if this node loses this cache entry due Acknowledgement; even if this node loses this cache entry due
to a failure of the node, packets from it can still reach the 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 mobile node through the mobile node's home agent, causing a new
Binding Update to this node to allow it to recreate this cache Binding Update to this node to allow it to recreate this cache
entry. The value of this field is undefined if the Status entry. The value of this field is undefined if the Status
field indicates that the Binding Update was rejected. field indicates that the Binding Update was rejected.
Parameters Mobility options
Variable-length field, of length such that the complete
Mobility Header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded parameters. The receiver MUST
ignore and skip any parameters which it does not understand.
A Binding Acknowledgement sent by a correspondent node MUST
include the following parameter:
- Authentication Data parameter. This parameter contains a
cryptographic hash value which is used to ensure that it
has been sent by the correspondent node. The authenticator
covering a Binding Acknowledgement MUST be computed over
a bitstring containing the following fields of the IPv6
header and the Mobility Header, in order:
* Care-of Address, in the Destination Address field of
the IPv6 header
* The address of the correspondent node, in the Source
Address field of the IPv6 header.
* The contents of the Mobility Header, excluding the
Authenticator field (inside the Authentication Data
parameter) which is included as zeroes for the purposes
of calculating the Authenticator.
* Four bytes of zero.
The actual authenticator calculation over sequence of bits Variable-length field of such length that the complete Mobility
is described in Section 4.5. Header is an integer multiple of 8 octets long. Contains one
or more TLV-encoded mobility options. The encoding and format
of defined options are described in Section 6.2. The receiver
MUST ignore and skip any options which it does not understand.
There MAY be additional information, associated with this There MAY be additional information, associated with this
Binding Acknowledgement message, that need not be present in Binding Acknowledgement message, that need not be present
all Binding Acknowledgements sent. This use of MH parameters in all Binding Acknowledgements sent. This use of mobility
also allows for future extensions to the format of the Binding options also allows for future extensions to the format of the
Acknowledgement message to be defined. The encoding and format Binding Acknowledgement message to be defined. The following
of defined parameters are described in Section 5.2. This options are valid for the Binding Acknowledgement message:
specification does not define any parameters valid for the
Binding Acknowledgement message.
If no actual parameters are present in this message, no padding is - Binding Authorization Data option
needed.
The Header Length field in the Mobility Header for this message
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
options are present in this message, 4 bytes of Pad1 or PadN mobility
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 inserted 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 If the mobile node sends a sequence number which is not within the
window of acceptable sequence numbers, then the home agent MUST send window of acceptable sequence numbers, then the home agent MUST send
back a Binding Acknowledgement with status code 141, and the last back a Binding Acknowledgement with status code 141, and the last
accepted sequence number in the Sequence Number field of the Binding accepted sequence number in the Sequence Number field of the Binding
Ack Parameter. Acknowledgement message.
5.1.9. Binding Missing (BM) Message 6.1.9. Binding Error (BE) Message
The Binding Missing (BM) message is used by the correspondent node The Binding Error (BE) message is used by the correspondent node to
to signal an inappropriate attempt to use the Home Address Option signal an error related to mobility, such as an inappropriate attempt
without an existing binding. A packet containing a Binding Missing to use the Home Address destination option without an existing
message is sent to the source address of the packet that contained binding. A packet containing a Binding Error message is sent to the
the Home Address Option i.e. to the care-of address of the mobile source address of the offending packet. For instance, in the case
node. The source address of the Binding Missing message is the of the Home Address destination option error, the packet is the one
that contained the Home Address destination option and therefore
the Binding Error message is sent to the care-of address of the
mobile node. The source address of the Binding Error message is the
correspondent node's address. correspondent node's address.
When a mobile node receives a packet containing a Binding Missing The Binding Error message uses the MH Type value 7. When this value
message, it should perform one of the following three actions: is indicated in the MH Type field, the format of the Message Data
field in the Mobility Header is as follows:
- If the mobile node does not have a Binding Update List entry for
the source of the Binding Missing message, it MUST ignore the
message. This is necessary to prevent loss of resources spent on
the Route Optimization signaling due to spoofed Binding Missing
messages.
- If the mobile node does have a Binding Update List entry but
has recent upper layer progress information that indicates
communications with the correspondent node are progressing, it
MAY ignore the message. This can be done in order to limit the
damage that spoofed Binding Missing messages can cause to ongoing
communications.
- If the mobile node does have a Binding Update List entry but
no upper layer progress information, it MUST remove the entry
and route further communications through the home agent. It
may also optionally start a Return Routability Procedure (see
Section 4.5).
The Binding Missing message uses the MH Type value 7. When this
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . . .
. Parameters . . Mobility Options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
8-bit unsigned integer indicating the reason for this message.
The following such Status values are currently defined:
1
Home Address destination option used without a binding
2
Received message had an unknown value for the MH Type field
Reserved Reserved
16-bit field reserved for future flags. These flag bits are A 8-bit field reserved for future use. The value MUST be
reserved for future use, and MUST be initialized to zero by the initialized to zero by the sender, and MUST be ignored 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 Option. The home address that was contained in the Home Address
The mobile node uses this information to determine which destination option. The mobile node uses this information to
binding does not exist, if there mobile node has several home determine which binding does not exist, in cases where the
addresses. mobile node has several home addresses.
Parameters Mobility options
Variable-length field, of length such that the complete Variable-length field of such length that the complete Mobility
Mobility Header is an integer multiple of 8 octets long. Header is an integer multiple of 8 octets long. Contains one
Contains one or more TLV-encoded parameters. The receiver MUST or more TLV-encoded mobility options. The receiver MUST ignore
ignore and skip any parameters 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 Missing message, that need not be present in all Binding Error message, that need not be present in all Binding
Binding Missings sent. This use of MH parameters also allows Error messages sent. This use of mobility options also allows
for future extensions to the format of the Binding Missing 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
parameters are described in Section 5.2. This specification options are described in Section 6.2. This specification does
does not define any parameters for the Binding Missing message. not define any options valid for the Binding Error message.
If no actual parameters are present in this message, no padding is The Header Length field in the Mobility Header for this message
needed. 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
options are present in this message, no padding is necessary.
5.2. Mobility Header Parameters 6.2. Mobility Options
5.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, any of the Mobility Header
messages defined in this document MAY include one or more parameters. messages defined in this document MAY include one or more mobility
options.
Such parameters are included in the data portion of the message Such options are included in the data portion of the message itself,
itself, after the fixed portion of the message data specified in after the fixed portion of the message data specified in section 6.1.
section 5.1.
The presence of such parameters will be indicated by the Header Len The presence of such options will be indicated by the Header Len of
of the Mobility Header. the Mobility Header.
These parameters are encoded within the remaining space of the These options are encoded within the remaining space of the message
message data for that message, using a type-length-value (TLV) format data for that message, using a type-length-value (TLV) format as
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Parameter Type | Parameter Len | Parameter Data... |Option Type | Option Len | Option Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type Option Type
8-bit identifier of the type of parameter. When processing a
Mobility Header containing a parameter for which the Parameter
Type value is not recognized by the receiver, the receiver MUST
quietly ignore and skip over the parameter, correctly handling
any remaining sub-options in the option.
Parameter Length 8-bit identifier of the type of mobility option. When
processing a Mobility Header containing an option for which
the Option Type value is not recognized by the receiver,
the receiver MUST quietly ignore and skip over the option,
correctly handling any remaining options in the message.
8-bit unsigned integer. Length of the Parameter Data field Option Length
of this parameter, in octets. The Parameter Len includes the
length of the Parameter Type and Parameter Len fields.
Parameter Data 8-bit unsigned integer. Length of this mobility option, in
octets. The Option Len does not include the length of the
Option Type and Option Len fields.
Variable-length field. Parameter -Type-specific data. Option Data
Parameters MUST be aligned on an 8-byte boundary, and have a length A variable length field that contains data specific to the
which is a multiple of 8. option.
The following subsections specify the Parameter types which are The following subsections specify the Option types which are
currently defined for use in the Mobility Header. currently defined for use in the Mobility Header.
Implementations MUST silently ignore any parameters that they do not Implementations MUST silently ignore any mobility options that they
understand. do not understand.
5.2.2. Pad1 6.2.2. Pad1
Pad1 Parameter (alignment requirement: none) The Pad1 option does not have any alignment requirements. Its format
is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 | | 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 parameter is a special case -- it has NOTE! the format of the Pad1 option is a special case -- it has
neither Parameter Len nor Parameter Data fields. neither Option Len nor Option Data fields.
The Pad1 parameter is used to insert one octet of padding into the The Pad1 option is used to insert one octet of padding in the
Parameters area of a Mobility Header. If more than one octet of Mobility Options area of a Mobility Header. If more than one octet
padding is required, the PadN parameter, described next, should be of padding is required, the PadN option, described next, should be
used, rather than multiple Pad1 parameters. used rather than multiple Pad1 options.
5.2.3. PadN 6.2.3. PadN
PadN Parameter (alignment requirement: none) The PadN option does not have any alignment requirements. Its format
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 | Parameter Len | Parameter Data | 1 | Option Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN parameter is used to insert two or more octets of padding The PadN option is used to insert two or more octets of padding in
into the Parameters area of some Mobility Header message. For N the Mobility Options area of a Mobility Header message. For N octets
octets of padding, the Parameter Len field contains the value N, and of padding, the Option Len field contains the value N, and the Option
the Parameter Data consists of N-2 zero-valued octets. Parameter Data consists of N-2 zero-valued octets. Option data MUST be ignored
data MUST be ignored by the receiver. by the receiver.
5.2.4. Unique Identifier 6.2.4. Unique Identifier
Unique Identifier parameter (alignment requirement: 2n) The Unique Identifier option has the alignment requirement of 2n.
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 | | 2 | 4 | Unique Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unique Identifier parameter is valid only in Binding Request and The Unique Identifier option is valid only in Binding Refresh
Binding Update messages. The Unique Identifier field contains a Request, HoTI, CoTI, and Binding Update messages. The Unique
16-bit value that serves to uniquely identify a Binding Request among Identifier field contains a 16-bit value that serves to uniquely
those sent by this Source Address, and to allow the Binding Update identify a Binding Request among those sent by this Source Address,
to identify the specific Binding Request to which it responds. This and to allow the HoTI, CoTI, and Binding Update to identify the
matching of Binding Updates to Binding Requests is required in the specific Binding Refresh Request to which it responds. This matching
of Binding Updates to Binding Refresh Requests is required in the
procedure for renumbering the home subnet while a mobile node is away procedure for renumbering the home subnet while a mobile node is away
from home (Section 9.7). from home (Section 10.9.1).
5.2.5. Alternate Care-of Address 6.2.5. Alternate Care-of Address
Alternate Care-of Address parameter (alignment requirement: 8n+6) The Alternate Care-of Address option has an alignment requirement of
8n+6. Its format is as follows:
0 1 2 3 0 1 2 3
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 | | 3 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Alternate Care-of Address + + Alternate Care-of Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Alternate Care-of Address parameter is valid only in Binding The Alternate Care-of Address option is valid only in Binding Update
Update message. The Alternate Care-of Address field contains an message. The Alternate Care-of Address field contains an address to
address to use as the care-of address for the binding, rather than use as the care-of address for the binding, rather than using the
using the Source Address of the packet as the care-of address. Source Address of the packet as the care-of address.
5.2.6. Nonce Indices 6.2.6. Nonce Indices
Nonce Indices parameter (alignment requirement: 8n+6) The Nonce Indices option has an alignment requirement of 2n. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 6 | | 4 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index | | Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices parameter is valid only in the Binding Update The Nonce Indices option is valid only in the Binding Update message,
message, and only when present together with an Authentication Data and only when present together with an Binding Authorization Data
parameter. 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 (Nj) are to be used to the message which of the challenge values (Ni) are to be used to
authenticate the Binding Update. authenticate the Binding Update.
The Care-of Nonce Index field tells the correspondent node that The Care-of Nonce Index field tells the correspondent node that
receives the message which of the challenge values (Ni) are to be receives the message which of the challenge values (Nj) are to be
used to authenticate the Binding Update. used to authenticate the Binding Update.
5.2.7. Authentication Data 6.2.7. Binding Authorization Data
Authentication Data parameter (alignment requirement: 8n+6) The Binding Authorization Data option has an alignment requirement of
4n+2. Its format is as follows:
0 1 2 3 0 1 2 3
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 | 18 | | 5 | 2 + Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Authenticator | | Authenticator |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Authentication Data parameter is valid only in the Binding The Binding Authorization Data option is valid only in the Binding
Request, Binding Update, and Binding Acknowledgment messages. Refresh Request, Binding Update, and Binding Acknowledgment messages.
The Security Parameters Index (SPI) field contains an arbitrary The Option Len field contains the value 2 + Len, where Len is the
32-bit value that uniquely identifies the used security association. length of the authenticator in octets.
This document specifies only one legal value for the SPI field. This
value, 0, signifies that no security association is present and the
cryptographic context MUST be established temporarily only for the
duration of processing this message. Messages that contain other
values of the SPI field SHOULD be silently discarded.
The Authenticator field contains a 96-bit cryptographic hash The Authenticator field contains a cryptographic value which can be
value. Rules for calculating this value are different for different used to determine that the message in question comes from the right
messages, and are described in Sections 5.1.2, 5.1.7 and 5.1.8. authority. Rules for calculating this value depend on the used
authorization procedure. This specification gives the rules only for
the return routability procedure. For this procedure, this option
can only appear in a Binding Update message and rules for calculating
the Authenticator value are described in Section 6.1.7.
5.3. Home Address 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 that
packet of the mobile node's home address. For packets sent by a 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 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 of its care-of addresses as the Source Address in the packet's IPv6
header. By including a Home Address option in the IPv6 Destination header. By including a Home Address option in the IPv6 Destination
Options header of the packet, the correspondent node receiving the Options header of the packet, the correspondent node receiving the
packet is able to substitute the mobile node's home address for this packet is able to substitute the mobile node's home address for
care-of address when processing the packet. This makes the use of this care-of address when processing the packet. This makes the
the care-of address transparent to the correspondent node. Note use of the care-of address transparent to the correspondent node
that multicast addresses, link-local addresses, loopback addresses, above the Mobile IPv6 support level. Note that multicast addresses,
IPv4 mapped addresses, and the unspecified address, MUST NOT be used link-local addresses, loopback addresses, IPv4 mapped addresses,
within a Home Address option. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Option Type Option Type
201 = 0xC9 201 = 0xC9
Option Length Option Length
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field excluding the Option Type and Option Length fields. This field
MUST be set to 16 plus the total length of all sub-options MUST be set to 16.
present, including their Sub-Option Type and Sub-Option Len
fields.
Home Address Home Address
The home address of the mobile node sending the packet. The home address of the mobile node sending the packet.
Sub-Options IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that
Additional information, associated with this Home Address multi-octet values within the Option Data field of each option fall
option, that need not be present in all Home Address options on natural boundaries (i.e., fields of width n octets are placed at
sent. This use of sub-options also allows for future an integer multiple of n octets from the start of the header, for
extensions to the format of the Home Address option to be n = 1, 2, 4, or 8) [6]. The alignment requirement [6] for the Home
defined. Currently, no valid sub-options are defined for use Address option is 8n+6.
in a Home Address option.
The alignment requirement [6] for the Home Address option is 8n+6. The three highest-order bits of the Option Type are encoded to
indicate specific processing of the option [6]. For the Home Address
option, these three bits are set to 110, indicating that any IPv6
node processing this option that does not recognize the Option Type
must discard the packet and, only if the packet's Destination Address
was not a multicast address, return an ICMP Parameter Problem,
Code 2, message to the packet's Source Address; and that the data
within the option cannot change en-route to the packet's final
destination.
The inclusion of a Home Address option in a packet affects the A packet MUST NOT contain more than one Home Address option, except
receiving node's processing of only this single packet; no state is that an encapsulated packet [4] MAY contain a separate Home Address
created or modified in the receiving node as a result of receiving a option associated with each encapsulating IP header.
Home Address option in a packet. In particular, the presence of a
Home Address option in a received packet MUST NOT alter the contents
of the receiver's Binding Cache and MUST NOT cause any changes in the
routing of subsequent packets sent by this receiving node.
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 Due to the threat of reflection attacks through the use of this
option, this specification requires that packets containing Home option, this specification requires that packets containing Home
Address Option MUST be dropped if there is no corresponding Binding Address option MUST be dropped if there is no corresponding Binding
Cache Entry for that home address with the currently registered Cache Entry for that home address with the currently registered
care-of address matching the source address of the packet. If the care-of address matching the source address of the packet. If the
packet is dropped, the correspondent nodes SHOULD send the Binding packet is dropped, the correspondent nodes SHOULD send the Binding
Missing message to the source address of the packet that contained Error message to the source address of the packet that contained the
the Home Address Option (see Section 5.1.9). These messages SHOULD Home Address option (see Section 6.1.9). The Status field in this
be rate-limited. message should be set to 1. These messages SHOULD be rate-limited.
No additional authentication of the Home Address option is No additional authentication of the Home Address option is
required, except that if the IPv6 header of a packet is covered required, except that if the IPv6 header of a packet is covered
by authentication, then that authentication MUST also cover the by authentication, then that authentication MUST also cover the
Home Address option; this coverage is achieved automatically by the Home Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en-route it indicates that the data within the option cannot change en-route
to the packet's final destination, and thus the option is included in to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication the authentication computation. By requiring that any authentication
of the IPv6 header also cover the Home Address option, the security of the IPv6 header also cover the Home Address option, the security
of the Source Address field in the IPv6 header is not compromised by of the Source Address field in the IPv6 header is not compromised by
the presence of a Home Address option. Security issues related to the presence of a Home Address option. Security issues related to
the Home Address option are discussed further in Section 4.5. When the Home Address option are discussed further in Section 5. When
attempting to verify authentication data in a packet that contains attempting to verify authentication data in a packet that contains
a Home Address option, the receiving node MUST make the calculation a Home Address option, the receiving node MUST make the calculation
as if the care-of address were present in the Home Address option, 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 and the home address were present in the source IPv6 address field
of the IPv6 header. This conforms with the calculation specified in of the IPv6 header. This conforms with the calculation specified in
section 10.2. section 11.2.2.
A packet MUST NOT contain more than one Home Address option, except
that an encapsulated packet [4] MAY contain a separate Home Address
option associated with each encapsulating IP header.
The three highest-order bits of the Option Type are encoded to The inclusion of a Home Address destination option in a packet
indicate specific processing of the option [6]. For the Home Address affects the receiving node's processing of only this single packet;
option, these three bits are set to 110, indicating that any IPv6 no state is created or modified in the receiving node as a result
node processing this option that does not recognize the Option Type of receiving a Home Address option in a packet. In particular, the
must discard the packet and, only if the packet's Destination Address presence of a Home Address option in a received packet MUST NOT alter
was not a multicast address, return an ICMP Parameter Problem, the contents of the receiver's Binding Cache and MUST NOT cause any
Code 2, message to the packet's Source Address; and that the data changes in the routing of subsequent packets sent by this receiving
within the option cannot change en-route to the packet's final node.
destination.
5.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, which the packets sent from a correspondent node to a mobile node. The Care of
Care of Address of the MN 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 what is defined This uses a different Routing header type than defined for "regular"
for ``regular'' IPv6 source routing to make it possible for e.g., IPv6 source routing, enabling firewalls to apply different rules
firewalls to have different rules for source routing versus MIPv6. to source routed packets than to MIPv6. This Routing header type
This routing header type (type 2) is restricted to only carry one (Type 2) is restricted to carry only one IPv6 address. All IPv6
IPv6 address and all IPv6 nodes which process it MUST verify that the nodes which process this Routing header MUST verify that the address
address contained in the routing header is the home address of the contained within is the node's own home address in order to prevent
node in order to prevent packets with this routing header type to be packets from being forwarded outside the node.
forwarded after decrementing the segments left field.
5.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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 58, line 52 skipping to change at page 58, line 51
Protocol field [10]. Protocol field [10].
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
2. 8-bit unsigned integer that contains the value 2.
Segments Left Segments Left
8-bit unsigned integer. Number of route segments remaining, 8-bit unsigned integer. Number of route segments remaining;
i.e., number of explicitly listed intermediate nodes still to i.e., number of explicitly listed intermediate nodes still to
be visited before reaching the final destination. For the type be visited before reaching the final destination. Packets
2 routing header, Segments left is always 1. transmitted through an interface have Segments left is always 1
in this type of Routing header.
Reserved Reserved
32-bit reserved field. Initialized to zero for transmission; 32-bit reserved field. Initialized to zero for transmission,
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.
5.4.2. Sending RH type 2 The ordering rules for extension headers in an IPv6 packet are
described in Section 4.1 of [6]. The new Routing header (Type 2)
A correspondent node sends packets with a routing header based on the defined for Mobile IPv6 follows the same ordering as other routing
content of the binding cache. Conceptually this is done by the IP headers. If more than one Routing header (e.g., both a Type 0 and a
layer inspecting the binding cache and if there is an entry for the Type 2 Routing header are present), the Type 2 Routing header should
destination address (the Home Address) then the IP layer inserts a follow all other Routing headers. Otherwise the order of routing
routing header of type 2 based on the ordering rules below and moves headers is independent of their type and follows [6].
the Home Address to the Home Address field in the RH and places the
Care of Address in the IPv6 destination field.
Note that following the above conceptually model in an implementation
creates some additional requirements for path MTU discovery since the
packetization layer (e.g., TCP and applications using UDP) need to be
aware of the size of the headers added by the IP layer on the sending
node.
The IP layer will insert the routing header before performing IPsec
processing. The IPsec Security Policy Database will be consulted
based on the IP source address and the final IP destination (which
will be in the routing header). The definition of AH ensures that
the AH calculation is done on the packet in the form it will have on
the receiver after advancing the routing header.
5.4.3. Verification by receiver
A node receiving a packet addressed to itself (i.e., one of the
node's addresses is in the IPv6 destination field) follows the next
header chain of headers and processes them. When it encounters a
routing header of type 2 during this processing it performs the
following checks. If any of these checks fail the node MUST silently
discard the packet.
- The node is a mobile node.
- The length field in the RH is exactly 2
- The segments left field in the RH is exactly 1
- The Home Address field in the RH is (one of) the node's Home
Address(es)
Once the above checks have been performed the routing header
processing. Conceptually this follows the same model as in RFC 2460
i.e. swap the IPv6 destination field with the Home Address field
in the RH, decrement segments left, and resubmit the packet to IP
for processing the next header. However, in the case of RH type 2
this can be simplified since it is known that the packet will not be
forwarded to a different node.
Since IPsec headers follow the Routing Header any IPsec processing
will operate on the packet with the HoA in the IP destination field
and segments left being zero. Thus AH will see the packet in the
same "shape" as the AH calculation on the sender.
5.4.4. Extension header ordering
Section 4.1 in RFC 2460 lists the extension header ordering. The
introduction of Routing Header type 2 potentially allows there to be
multiple routing headers in a single packet. If this is the case
the Routing Header type 2 should follow any Routing header of other
type but otherwise the order constraints for routing headers is
independent of their type and follows RFC 2460.
5.4.5. Reversing type 2 routing headers
In addition, the 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 packets sent by upper-layer protocols, if the received packet is
is authenticated [6]. This MUST NOT be done to type 2 routing authenticated [6]. This MUST NOT be done automatically for Type 2
headers. Routing headers.
5.5. Mobile IPv6 Destination Option Sub-Options
In order to allow future extensions to the format of MIPv6
destination options, any of the Mobile IPv6 destination options
defined in this document MAY include one or more sub-options.
Such sub-options are included in the data portion of the destination
option itself, after the fixed portion of the option data specified
for that particular destination option (Section 5.3). The presence
of such sub-options will be indicated by the Option Length field.
When the Option Length is greater than the standard length defined
for that destination option, the remaining octets are interpreted as
sub-options.
These sub-options are encoded within the remaining space of the
option data for that option, using a type-length-value (TLV) format
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len| Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type
8-bit identifier of the type of sub-option. When processing
a Mobile IPv6 destination option containing a sub-option for
which the Sub-Option Type value is not recognized by the
receiver, the receiver SHOULD quietly ignore and skip over the
sub-option, correctly handling any remaining sub-options in the
option.
Sub-Option Length
8-bit unsigned integer. Length of the Sub-Option Data field
of this sub-option, in octets. The Sub-Option Len does not
include the length of the Sub-Option Type and Sub-Option Len
fields.
Sub-Option Data
Variable-length field. Sub-Option-Type-specific data.
As with IPv6 options appearing in a Hop-by-Hop Options header
or Destination Options header [6], individual sub-options within
a Mobile IPv6 destination option may have specific alignment
requirements, to ensure that multi-octet values within Sub-Option
Data fields fall on natural boundaries. The alignment requirement
of each sub-option is specified as part of the definition of each
sub-option below.
Each section above defining the Mobile IPv6 destination options
specifies which of the defined sub-options is valid for that
destination option. In addition, there are two padding sub-options,
Pad1 and PadN (defined below), which are used when necessary to align
subsequent sub-options. The Pad1 and PadN sub-options are valid for
all Mobile IPv6 destination options. Unlike the padding options
used in Hop-by-Hop Options header or Destination Options header [6],
there is no requirement for padding the total size of any Mobile IPv6
destination option to a multiple of 8 octets in length, and the
Pad1 and PadN sub-options SHOULD NOT be used for this purpose. All
Mobile IPv6 sub-options defined in this document MUST be recognized
by all Mobile IPv6 implementations.
5.5.1. Pad1
Pad1 Sub-Option (alignment requirement: none)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 sub-option is a special
case -- it has neither Sub-Option Len nor Sub-Option Data
fields.
The Pad1 sub-option is used to insert one octet of padding
into the Sub-Options area of a Mobile IPv6 option. If more
than one octet of padding is required, the PadN sub-option,
described next, should be used, rather than multiple Pad1
sub-options.
5.5.2. PadN
PadN Sub-Option (alignment requirement: none)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Sub-Option Len| Sub-Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN sub-option is used to insert two or more octets of
padding into the Sub-Options area of a Mobile IPv6 option.
For N octets of padding, the Sub-Option Len field contains
the value N-2, and the Sub-Option Data consists of N-2
zero-valued octets.
5.6. 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 9.9 and 10.8. The mobile mechanism, as described in Sections 10.9 and 11.3.2. The mobile
node sends a Home Agent Address Discovery Request message to the node sends a Home Agent Address Discovery Request message to the
"Mobile IPv6 Home-Agents" anycast address for its own home subnet "Mobile IPv6 Home-Agents" anycast address for its own home subnet
prefix [11], and one of the home agents there responds to the mobile prefix [11], and one of the home agents responds to the mobile node
node with a Home Agent Address Discovery Reply message giving a list 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. 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
skipping to change at page 63, line 49 skipping to change at page 60, line 29
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
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
The Source Address of the Home Agent Address Discovery Request The Source Address of the Home Agent Address Discovery Request
message packet MUST be one of the mobile node's current care-of message packet MUST be one of the mobile node's current care-of
addresses. The home agent then MUST 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 Discovery Reply message directly to the Source Address chosen by the
the mobile node Note that, at the time of performing this dynamic mobile node. Note that, at the time of performing this dynamic home
home agent address discovery, it is likely that the mobile node 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.
5.7. ICMP Home Agent Address Discovery Reply Message 6.6. ICMP Home Agent Address Discovery Reply Message
The ICMP Home Agent Address Discovery Reply message is used by a The ICMP Home Agent Address Discovery Reply message is used by
home agent to respond to a mobile node using the dynamic home agent a home agent to respond to a mobile node using the dynamic home
address discovery mechanism, as described in Sections 9.9 and 10.8. agent address discovery mechanism, as described in Sections 10.9
The mobile node sends a Home Agent Address Discovery Request message and 11.3.2. The mobile node sends a Home Agent Address Discovery
to the "Mobile IPv6 Home-Agents" anycast address for its own home Request message to the "Mobile IPv6 Home-Agents" anycast address
subnet prefix [11], and one of the home agents there responds to the for its own home subnet prefix [11], and one of the home agents
mobile node with a Home Agent Address Discovery Reply message giving responds to the mobile node with a Home Agent Address Discovery Reply
a list of the routers on the mobile node's home link serving as home message, providing a list of the routers on the mobile node's home
agents. 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 66, line 5 skipping to change at page 63, line 5
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Home Agent Addresses Home Agent Addresses
A list of addresses of home agents on the home link for the A list of addresses of home agents on the home link for the
mobile node. The number of addresses present in the list is mobile node. The number of addresses present in the list is
indicated by the remaining length of the IPv6 packet carrying indicated by the remaining length of the IPv6 packet carrying
the Home Agent Address Discovery Reply message. the Home Agent Address Discovery Reply message.
5.8. 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 [35], home address(es) by stateless address autoconfiguration [33],
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 [20], 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
skipping to change at page 66, line 45 skipping to change at page 63, line 45
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, and this message is routed
according to the rules of a typical unicast packet. A hop according to the rules of a typical unicast packet. A hop
limit of 64 is currently suggested [32]. 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
skipping to change at page 68, line 5 skipping to change at page 65, line 5
Checksum Checksum
The ICMP checksum [5]. The ICMP checksum [5].
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.
5.9. 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 5.9. 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 ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
The home agent's address as the