draft-ietf-mext-rfc3775bis-05.txt   draft-ietf-mext-rfc3775bis-06.txt 
IETF Mobile IP Working Group D. Johnson IETF Mobile IP Working Group C. Perkins (Ed.)
Internet-Draft Rice University Internet-Draft Tellabs Inc.
Obsoletes: 3775 (if approved) C. Perkins (Ed.) Obsoletes: 3775 (if approved) D. Johnson
Expires: April 22, 2010 WiChorus Inc. Expires: January 13, 2011 Rice University
J. Arkko J. Arkko
Ericsson Ericsson
October 19, 2009 July 12, 2010
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-05.txt draft-ietf-mext-rfc3775bis-06.txt
Abstract
This document specifies a protocol which allows nodes to remain
reachable while moving around in the IPv6 Internet. Each mobile node
is always identified by its home address, regardless of its current
point of attachment to the Internet. While situated away from its
home, a mobile node is also associated with a care-of address, which
provides information about the mobile node's current location. IPv6
packets addressed to a mobile node's home address are transparently
routed to its care-of address. The protocol enables IPv6 nodes to
cache the binding of a mobile node's home address with its care-of
address, and to then send any packets destined for the mobile node
directly to it at this care-of address. To support this operation,
Mobile IPv6 defines a new IPv6 protocol and a new destination option.
All IPv6 nodes, whether mobile or stationary, can communicate with
mobile nodes.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies a protocol which allows nodes to remain described in the Simplified BSD License.
reachable while moving around in the IPv6 Internet. Each mobile node
is always identified by its home address, regardless of its current
point of attachment to the Internet. While situated away from its
home, a mobile node is also associated with a care-of address, which
provides information about the mobile node's current location. IPv6
packets addressed to a mobile node's home address are transparently
routed to its care-of address. The protocol enables IPv6 nodes to
cache the binding of a mobile node's home address with its care-of
address, and to then send any packets destined for the mobile node
directly to it at this care-of address. To support this operation,
Mobile IPv6 defines a new IPv6 protocol and a new destination option.
All IPv6 nodes, whether mobile or stationary, can communicate with
mobile nodes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 9 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 8
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 10 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 12 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 11
4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 16 4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 15
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 16 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 15
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 18 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 17
4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 19 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 18
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 19 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 18
4.5. Conceptual Data Structure Terminology . . . . . . . . . . 20 4.5. Conceptual Data Structure Terminology . . . . . . . . . . 19
4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 20 4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 19
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 22 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 21
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 22 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 21
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 23 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 22
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 24 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 25 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 23
5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 25 5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 24
5.2.5. Return Routability Procedure . . . . . . . . . . . . 26 5.2.5. Return Routability Procedure . . . . . . . . . . . . 24
5.2.6. Authorizing Binding Management Messages . . . . . . . 30 5.2.6. Authorizing Binding Management Messages . . . . . . . 29
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 32 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 31
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 33 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 32
5.2.9. Handling Interruptions to Return Routability . . . . 33 5.2.9. Handling Interruptions to Return Routability . . . . 32
5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 34 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 33
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 34 5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 33
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 34 5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 33
6. New IPv6 Protocol, Message Types, and Destination Option . . 36 6. New IPv6 Protocol, Message Types, and Destination Option . . 35
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 36 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 35
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.2. Binding Refresh Request Message . . . . . . . . . . . 38 6.1.2. Binding Refresh Request Message . . . . . . . . . . . 37
6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 39 6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 38
6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 40 6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 39
6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 41 6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 40
6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 42 6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 41
6.1.7. Binding Update Message . . . . . . . . . . . . . . . 44 6.1.7. Binding Update Message . . . . . . . . . . . . . . . 43
6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 46 6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 45
6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 49 6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 48
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 50 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 49
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 52 6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 51
6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 53 6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 51
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 53 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 52
6.2.7. Binding Authorization Data . . . . . . . . . . . . . 54 6.2.7. Binding Authorization Data . . . . . . . . . . . . . 53
6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 54
6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 56
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 57 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 56
6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 58 6.5. ICMP Home Agent Address Discovery Request Message . . . . 58
6.5. ICMP Home Agent Address Discovery Request Message . . . . 59 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 59
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 60 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 60
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 61 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 61
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 63 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 65
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 66 7.1. Modified Router Advertisement Message Format . . . . . . 65
7.1. Modified Router Advertisement Message Format . . . . . . 66 7.2. Modified Prefix Information Option Format . . . . . . . . 65
7.2. Modified Prefix Information Option Format . . . . . . . . 66 7.3. New Advertisement Interval Option Format . . . . . . . . 67
7.3. New Advertisement Interval Option Format . . . . . . . . 68 7.4. New Home Agent Information Option Format . . . . . . . . 68
7.4. New Home Agent Information Option Format . . . . . . . . 69 7.5. Changes to Sending Router Advertisements . . . . . . . . 70
7.5. Changes to Sending Router Advertisements . . . . . . . . 71 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 72
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 73 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 72
8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 73 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 72
8.2. IPv6 Nodes with Support for Route Optimization . . . . . 73 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 74
8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 75 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 74
8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 75 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 76
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 77 9. Correspondent Node Operation . . . . . . . . . . . . . . . . 78
9. Correspondent Node Operation . . . . . . . . . . . . . . . . 79 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 78
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 79 9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 79
9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 80 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 79
9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 80 9.3.1. Receiving Packets with Home Address Option . . . . . 79
9.3.1. Receiving Packets with Home Address Option . . . . . 80 9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 80
9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 81 9.3.3. Sending Binding Error Messages . . . . . . . . . . . 82
9.3.3. Sending Binding Error Messages . . . . . . . . . . . 83 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 82
9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 83 9.4. Return Routability Procedure . . . . . . . . . . . . . . 83
9.4. Return Routability Procedure . . . . . . . . . . . . . . 84 9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 83
9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 84 9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 83
9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 84 9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 84
9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 85 9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 84
9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 85 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 84
9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 85 9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 84
9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 85 9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 87
9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 88 9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 87
9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 88 9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 88
9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 89 9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 89
9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 90 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 89
9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 90 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 91
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 92 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 91
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 92 10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 92
10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 93 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 92
10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 93 10.3.1. Primary Care-of Address Registration . . . . . . . . 92
10.3.1. Primary Care-of Address Registration . . . . . . . . 93 10.3.2. Primary Care-of Address De-Registration . . . . . . . 96
10.3.2. Primary Care-of Address De-Registration . . . . . . . 97 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 97
10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 99 10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 97
10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 99 10.4.2. Processing Intercepted Packets . . . . . . . . . . . 99
10.4.2. Processing Intercepted Packets . . . . . . . . . . . 100 10.4.3. Multicast Membership Control . . . . . . . . . . . . 100
10.4.3. Multicast Membership Control . . . . . . . . . . . . 101 10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 101
10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 103 10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 102
10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 103 10.4.6. Protecting Return Routability Packets . . . . . . . . 102
10.4.6. Protecting Return Routability Packets . . . . . . . . 104 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 103
10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 104 10.5.1. Receiving Router Advertisement Messages . . . . . . . 103
10.5.1. Receiving Router Advertisement Messages . . . . . . . 105 10.6. Sending Prefix Information to the Mobile Node . . . . . . 106
10.6. Sending Prefix Information to the Mobile Node . . . . . . 107 10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 106
10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 107 10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 106
10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 107 10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 108
10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 109 10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 109
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 110 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 110
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 111 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 110
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 111 11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 111
11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 112 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 112
11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 113 11.3.1. Sending Packets While Away from Home . . . . . . . . 112
11.3.1. Sending Packets While Away from Home . . . . . . . . 113 11.3.2. Interaction with Outbound IPsec Processing . . . . . 115
11.3.2. Interaction with Outbound IPsec Processing . . . . . 116 11.3.3. Receiving Packets While Away from Home . . . . . . . 117
11.3.3. Receiving Packets While Away from Home . . . . . . . 118 11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 118
11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 119 11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 120
11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 121 11.3.6. Receiving Binding Error Messages . . . . . . . . . . 120
11.3.6. Receiving Binding Error Messages . . . . . . . . . . 121 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 121
11.4. Home Agent and Prefix Management . . . . . . . . . . . . 122 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 121
11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 122 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 122
11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 123 11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 123
11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 124 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 124
11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 125 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 124
11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 125 11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 127
11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 128 11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 127
11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 128 11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 128
11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 129 11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 129
11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 130 11.6. Return Routability Procedure . . . . . . . . . . . . . . 131
11.6. Return Routability Procedure . . . . . . . . . . . . . . 132 11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 131
11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 132 11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 132
11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 133 11.6.3. Protecting Return Routability Packets . . . . . . . . 133
11.6.3. Protecting Return Routability Packets . . . . . . . . 134 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 133
11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 134 11.7.1. Sending Binding Updates to the Home Agent . . . . . . 133
11.7.1. Sending Binding Updates to the Home Agent . . . . . . 134 11.7.2. Correspondent Registration . . . . . . . . . . . . . 136
11.7.2. Correspondent Registration . . . . . . . . . . . . . 137 11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 139
11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 140 11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 141
11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 142 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 142
11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 143 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 144
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 145 13. Protocol Configuration Variables . . . . . . . . . . . . . . 145
13. Protocol Configuration Variables . . . . . . . . . . . . . . 146 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 146
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 15. Security Considerations . . . . . . . . . . . . . . . . . . . 149
15. Security Considerations . . . . . . . . . . . . . . . . . . . 150 15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 149
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 150 15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 151
15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 152 15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 153
15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 154 15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 155
15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 157 15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 155
15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 157 15.4.2. Achieved Security Properties . . . . . . . . . . . . 156
15.4.2. Achieved Security Properties . . . . . . . . . . . . 158 15.4.3. Comparison to Regular IPv6 Communications . . . . . . 157
15.4.3. Comparison to Regular IPv6 Communications . . . . . . 158 15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 159
15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 160 15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 159
15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 160 15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 160
15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 161 15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 161
15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 162 15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 162
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 163 15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 162
15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 163 15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 163
15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 164 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 163
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 165 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 166
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 167
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168 18.1. Normative References . . . . . . . . . . . . . . . . . . 167
18.1. Normative References . . . . . . . . . . . . . . . . . . 168 18.2. Informative References . . . . . . . . . . . . . . . . . 168
18.2. Informative References . . . . . . . . . . . . . . . . . 169 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 171
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 171
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 171
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172 A.3. New Authorization Methods . . . . . . . . . . . . . . . . 171
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 172 A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 171
A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
1. Introduction 1. Introduction
This document specifies a protocol which allows nodes to remain This document specifies a protocol which allows nodes to remain
reachable while moving around in the IPv6 Internet. Without specific reachable while moving around in the IPv6 Internet. Without specific
support for mobility in IPv6 [8], packets destined to a mobile node support for mobility in IPv6 [5], packets destined to a mobile node
would not be able to reach it while the mobile node is away from its would not be able to reach it while the mobile node is away from its
home link. In order to continue communication in spite of its home link. In order to continue communication in spite of its
movement, a mobile node could change its IP address each time it movement, a mobile node could change its IP address each time it
moves to a new link, but the mobile node would then not be able to moves to a new link, but the mobile node would then not be able to
maintain transport and higher-layer connections when it changes 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.
skipping to change at page 9, line 9 skipping to change at page 8, line 9
o Service Discovery. o Service Discovery.
o Distinguishing between packets lost due to bit errors vs. network o Distinguishing between packets lost due to bit errors vs. network
congestion. 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) benefits both The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both
from the experiences gained from the development of Mobile IP support from the experiences gained from the development of Mobile IP support
in IPv4 (Mobile IPv4) [33] [27] [28], and from the opportunities in IPv4 (Mobile IPv4) [30] [24] [25], and from the opportunities
provided by IPv6. Mobile IPv6 thus shares many features with Mobile provided by IPv6. Mobile IPv6 thus shares many features with Mobile
IPv4, but is integrated into IPv6 and offers many other improvements. IPv4, but is integrated into IPv6 and offers many other improvements.
This section summarizes the major differences between Mobile IPv4 and This section summarizes the major differences between Mobile IPv4 and
Mobile IPv6: Mobile IPv6:
o There is no need to deploy special routers as "foreign agents", as o There is no need to deploy special routers as "foreign agents", as
in Mobile IPv4. Mobile IPv6 operates in any location without any in Mobile IPv4. Mobile IPv6 operates in any location without any
special support required from the local router. special support required from the local router.
o Support for route optimization is a fundamental part of the o Support for route optimization is a fundamental part of the
protocol, rather than a nonstandard set of extensions. protocol, rather than a nonstandard set of extensions.
o Mobile IPv6 route optimization can operate securely even without o Mobile IPv6 route optimization can operate securely even without
pre-arranged security associations. It is expected that route pre-arranged security associations. It is expected that route
optimization can be deployed on a global scale between all mobile optimization can be deployed on a global scale between all mobile
nodes and correspondent nodes. nodes and correspondent nodes.
o Support is also integrated into Mobile IPv6 for allowing route o Support is also integrated into Mobile IPv6 for allowing route
optimization to coexist efficiently with routers that perform optimization to coexist efficiently with routers that perform
"ingress filtering" [30]. "ingress filtering" [27].
o The IPv6 Neighbor Unreachability Detection assures symmetric o The IPv6 Neighbor Unreachability Detection assures symmetric
reachability between the mobile node and its default router in the reachability between the mobile node and its default router in the
current location. current location.
o Most packets sent to a mobile node while away from home in Mobile o Most packets sent to a mobile node while away from home in Mobile
IPv6 are sent using an IPv6 routing header rather than IP IPv6 are sent using an IPv6 routing header rather than IP
encapsulation, reducing the amount of resulting overhead compared encapsulation, reducing the amount of resulting overhead compared
to Mobile IPv4. to Mobile IPv4.
o Mobile IPv6 is decoupled from any particular link layer, as it o Mobile IPv6 is decoupled from any particular link layer, as it
uses IPv6 Neighbor Discovery [20] instead of ARP. This also uses IPv6 Neighbor Discovery [17] instead of ARP. This also
improves the robustness of the protocol. improves the robustness of the protocol.
o The use of IPv6 encapsulation (and the routing header) removes the o The use of IPv6 encapsulation (and the routing header) removes the
need in Mobile IPv6 to manage "tunnel soft state". need in Mobile IPv6 to manage "tunnel soft state".
o The dynamic home agent address discovery mechanism in Mobile IPv6 o The dynamic home agent address discovery mechanism in Mobile IPv6
returns a single reply to the mobile node. The directed broadcast returns a single reply to the mobile node. The directed broadcast
approach used in IPv4 returns separate replies from each home approach used in IPv4 returns separate replies from each home
agent. agent.
skipping to change at page 12, line 21 skipping to change at page 11, line 21
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
3.2. Mobile IPv6 Terms 3.2. Mobile IPv6 Terms
These terms are intended to be compatible with the definitions given These terms are intended to be compatible with the definitions given
in RFC 3753[40]. However, if there is any conflict, the definitions in RFC 3753[37]. However, if there is any conflict, the definitions
given here should be considered to supersede those in RFC 3753. given here should be considered to supersede those in RFC 3753.
home address home address
A unicast routable address assigned to a mobile node, used as the A unicast routable address assigned to a mobile node, used as the
permanent address of the mobile node. This address is within the permanent address of the mobile node. This address is within the
mobile node's home link. Standard IP routing mechanisms will mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its deliver packets destined for a mobile node's home address to its
home link. Mobile nodes can have multiple home addresses, for home link. Mobile nodes can have multiple home addresses, for
instance when there are multiple home prefixes on the home link. instance when there are multiple home prefixes on the home link.
skipping to change at page 17, line 12 skipping to change at page 16, line 12
correspondent node and is available even if the mobile node has not correspondent node and is available even if the mobile node has not
registered its current binding with the correspondent node. Packets registered its current binding with the correspondent node. Packets
from the correspondent node are routed to the home agent and then from the correspondent node are routed to the home agent and then
tunneled to the mobile node. Packets to the correspondent node are tunneled to the mobile node. Packets to the correspondent node are
tunneled from the mobile node to the home agent ("reverse tunneled") tunneled from the mobile node to the home agent ("reverse tunneled")
and then routed normally from the home network to the correspondent and then routed normally from the home network to the correspondent
node. In this mode, the home agent uses proxy Neighbor Discovery to node. In this mode, the home agent uses proxy Neighbor Discovery to
intercept any IPv6 packets addressed to the mobile node's home intercept any IPv6 packets addressed to the mobile node's home
address (or home addresses) on the home link. Each intercepted address (or home addresses) on the home link. Each intercepted
packet is tunneled to the mobile node's primary care-of address. packet is tunneled to the mobile node's primary care-of address.
This tunneling is performed using IPv6 encapsulation [9]. This tunneling is performed using IPv6 encapsulation [6].
The second mode, "route optimization", requires the mobile node to The second mode, "route optimization", requires the mobile node to
register its current binding at the correspondent node. Packets from register its current binding at the correspondent node. Packets from
the correspondent node can be routed directly to the care-of address the correspondent node can be routed directly to the care-of address
of the mobile node. When sending a packet to any IPv6 destination, of the mobile node. When sending a packet to any IPv6 destination,
the correspondent node checks its cached bindings for an entry for the correspondent node checks its cached bindings for an entry for
the packet's destination address. If a cached binding for this the packet's destination address. If a cached binding for this
destination address is found, the node uses a new type of IPv6 destination address is found, the node uses a new type of IPv6
routing header [8] (see Section 6.4) to route the packet to the routing header [5] (see Section 6.4) to route the packet to the
mobile node by way of the care-of address indicated in this binding. mobile node by way of the care-of address indicated in this binding.
Routing packets directly to the mobile node's care-of address allows Routing packets directly to the mobile node's care-of address allows
the shortest communications path to be used. It also eliminates the shortest communications path to be used. It also eliminates
congestion at the mobile node's home agent and home link. In congestion at the mobile node's home agent and home link. In
addition, the impact of temporary failures of the home agent or addition, the impact of temporary failures of the home agent or
networks on the path to or from the home agent is reduced. networks on the path to or from the home agent is reduced.
When routing packets directly to the mobile node, the correspondent When routing packets directly to the mobile node, the correspondent
node sets the Destination Address in the IPv6 header to the care-of node sets the Destination Address in the IPv6 header to the care-of
skipping to change at page 18, line 13 skipping to change at page 17, line 13
are described starting from Section 6.5. are described starting from Section 6.5.
This document is written under the assumption that the mobile node is This document is written under the assumption that the mobile node is
configured with the home prefix for the mobile node to be able to configured with the home prefix for the mobile node to be able to
discover a home agent and configure a home address. This might be discover a home agent and configure a home address. This might be
limiting in deployments where the home agent and the home address for limiting in deployments where the home agent and the home address for
the mobile node needs to be assigned dynamically. Additional the mobile node needs to be assigned dynamically. Additional
mechanisms have been specified for the mobile node to dynamically mechanisms have been specified for the mobile node to dynamically
configure a home agent, a home address and the home prefix. These configure a home agent, a home address and the home prefix. These
mechanisms are described in "Mobile IPv6 Bootstrapping in Split mechanisms are described in "Mobile IPv6 Bootstrapping in Split
Scenario" [25] and "MIP6 bootstrapping for the Integrated Scenario" Scenario" [22] and "MIP6 bootstrapping for the Integrated Scenario"
[37]. [34].
4.2. New IPv6 Protocol 4.2. New IPv6 Protocol
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
(see Section 6.1). This Header is used to carry the following (see Section 6.1). This Header is used to carry the following
messages: messages:
Home Test Init Home Test Init
Home Test Home Test
skipping to change at page 20, line 38 skipping to change at page 19, line 38
Home agents need to know which other home agents are on the same Home agents need to know which other home agents are on the same
link. This information is stored in the Home Agents List, as link. This information is stored in the Home Agents List, as
described in more detail in Section 10.1. The list is used for described in more detail in Section 10.1. The list is used for
informing mobile nodes during dynamic home agent address informing mobile nodes during dynamic home agent address
discovery. discovery.
4.6. Unique-Local Addressability 4.6. Unique-Local Addressability
This specification requires that home and care-of addresses MUST be This specification requires that home and care-of addresses MUST be
unicast routable addresses. Unique-local IPv6 unicast addresses unicast routable addresses. Unique-local IPv6 unicast addresses
(ULAs) RFC4193 [22] may be usable on networks that use such non- (ULAs) RFC4193 [19] may be usable on networks that use such non-
globally routable addresses but this specification does not define globally routable addresses but this specification does not define
when such usage is safe and when it is not. Mobile nodes may not be when such usage is safe and when it is not. Mobile nodes may not be
able to distinguish between their home site and the site at which able to distinguish between their home site and the site at which
they are currently located. This can make it hard to prevent they are currently located. This can make it hard to prevent
accidental attachment to other sites, because the mobile node might accidental attachment to other sites, because the mobile node might
use the ULA at another site, which could not be used to successfully use the ULA at another site, which could not be used to successfully
send packets to the mobile node's HA. This would result in send packets to the mobile node's HA. This would result in
unreachability between the MN and the HA, when unique-local IPv6 unreachability between the MN and the HA, when unique-local IPv6
routable addresses are used as care-of addresses. Similarly, CNs routable addresses are used as care-of addresses. Similarly, CNs
outside the MN's own site will not be reachable when ULAs are used as outside the MN's own site will not be reachable when ULAs are used as
home addresses. Therefore, unique-local IPv6 unicast addresses home addresses. Therefore, unique-local IPv6 unicast addresses
SHOULD NOT be used as home or care-of addresses when other address SHOULD NOT be used as home or care-of addresses when other address
choices are available. If such addresses are used, however, choices are available. If such addresses are used, however,
according to RFC4193 [22], they are treated as any global unicast according to RFC4193 [19], they are treated as any global unicast
IPv6 address so, for the remainder of this specification, use of IPv6 address so, for the remainder of this specification, use of
unique-local IPv6 unicast addresses is not differentiated from other unique-local IPv6 unicast addresses is not differentiated from other
globally unique IPv6 addresses. globally unique IPv6 addresses.
5. Overview of Mobile IPv6 Security 5. Overview of Mobile IPv6 Security
This specification provides a number of security features. These This specification provides a number of security features. These
include the protection of Binding Updates both to home agents and include the protection of Binding Updates both to home agents and
correspondent nodes, the protection of mobile prefix discovery, and correspondent nodes, the protection of mobile prefix discovery, and
the protection of the mechanisms that Mobile IPv6 uses for the protection of the mechanisms that Mobile IPv6 uses for
skipping to change at page 22, line 51 skipping to change at page 21, line 51
in the IPsec processing, by having the security policy database in the IPsec processing, by having the security policy database
entries unequivocally identify a single security association for entries unequivocally identify a single security association for
protecting Binding Updates between any given home address and home protecting Binding Updates between any given home address and home
agent. In order to make this possible, it is necessary that the home agent. In order to make this possible, it is necessary that the home
address of the mobile node is visible in the Binding Updates and address of the mobile node is visible in the Binding Updates and
Acknowledgements. The home address is used in these packets as a Acknowledgements. The home address is used in these packets as a
source or destination, or in the Home Address Destination option or source or destination, or in the Home Address Destination option or
the type 2 routing header. the type 2 routing header.
As with all IPsec security associations in this specification, manual As with all IPsec security associations in this specification, manual
configuration of security associations MUST be supported. The used configuration of security associations MUST be supported. The shared
shared secrets MUST be random and unique for different mobile nodes, secrets used MUST be random and unique for different mobile nodes,
and MUST be distributed off-line to the mobile nodes. and MUST be distributed off-line to the mobile nodes. Automatic key
management with IKEv2 [41] MAY be supported as described in [42].
Automatic key management with IKE [7] or IKEv2 [44] MAY be supported.
When IKE is used, either the security policy database entries or the
Mobile IPv6 processing MUST unequivocally identify the IKE phase 1
credentials which can be used to authorize the creation of security
associations for protecting Binding Updates for a particular home
address. How these mappings are maintained is outside the scope of
this specification, but they may be maintained, for instance, as a
locally administered table in the home agent. If the phase 1
identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS
may also be used.
Section 11.3.2 discusses how IKE connections to the home agent need a
careful treatment of the addresses used for transporting IKE. This
is necessary to ensure that a Binding Update is not needed before the
IKE exchange which is needed for securing the Binding Update.
When IKE version 1 is used with preshared secret authentication
between the mobile node and the home agent, aggressive mode MUST be
used.
The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1. Section 11.3.2 discusses how IKEv2 connections to the home agent need
a careful treatment of the addresses used for transporting IKEv2.
This is necessary to ensure that a Binding Update is not needed
before the IKEv2 exchange which is needed for securing the Binding
Update.
References [15] and [45] contain more detailed descriptions and More detailed descriptions and examples using IPsec to protect
examples on using IPsec to protect the communications between the communications between the mobile node and the home agent have been
mobile node and the home agent. published [42].
5.2. Binding Updates to Correspondent Nodes 5.2. Binding Updates to Correspondent Nodes
The protection of Binding Updates sent to correspondent nodes does The protection of Binding Updates sent to correspondent nodes does
not require the configuration of security associations or the not require the configuration of security associations or the
existence of an authentication infrastructure between the mobile existence of an authentication infrastructure between the mobile
nodes and correspondent nodes. Instead, a method called the return nodes and correspondent nodes. Instead, a method called the return
routability procedure is used to assure that the right mobile node is routability procedure is used to assure that the right mobile node is
sending the message. This method does not protect against attackers sending the message. This method does not protect against attackers
who are on the path between the home network and the correspondent who are on the path between the home network and the correspondent
node. However, attackers in such a location are capable of node. However, attackers in such a location are capable of
performing the same attacks even without Mobile IPv6. The main performing the same attacks even without Mobile IPv6. The main
advantage of the return routability procedure is that it limits the advantage of the return routability procedure is that it limits the
potential attackers to those having an access to one specific path in potential attackers to those having an access to one specific path in
the Internet, and avoids forged Binding Updates from anywhere else in the Internet, and avoids forged Binding Updates from anywhere else in
the Internet. For a more in depth explanation of the security the Internet. For a more in depth explanation of the security
properties of the return routability procedure, see Section 15. properties of the return routability procedure, see Section 15.
Also, consult [43] Also, consult [40]
The integrity and authenticity of the Binding Updates messages to The integrity and authenticity of the Binding Updates messages to
correspondent nodes is protected by using a keyed-hash algorithm. correspondent nodes is protected by using a keyed-hash algorithm.
The binding management key, Kbm, is used to key the hash algorithm The binding management key, Kbm, is used to key the hash algorithm
for this purpose. Kbm is established using data exchanged during the for this purpose. Kbm is established using data exchanged during the
return routability procedure. The data exchange is accomplished by return routability procedure. The data exchange is accomplished by
use of node keys, nonces, cookies, tokens, and certain cryptographic use of node keys, nonces, cookies, tokens, and certain cryptographic
functions. Section 5.2.5 outlines the basic return routability functions. Section 5.2.5 outlines the basic return routability
procedure. Section 5.2.6 shows how the results of this procedure are procedure. Section 5.2.6 shows how the results of this procedure are
used to authorize a Binding Update to a correspondent node. used to authorize a Binding Update to a correspondent node.
5.2.1. Node Keys 5.2.1. Node Keys
skipping to change at page 24, line 31 skipping to change at page 23, line 15
A correspondent node MAY generate a fresh node key at any time; this A correspondent node MAY generate a fresh node key at any time; this
avoids the need for secure persistent key storage. Procedures for avoids the need for secure persistent key storage. Procedures for
optionally updating the node key are discussed later in optionally updating the node key are discussed later in
Section 5.2.7. Section 5.2.7.
5.2.2. Nonces 5.2.2. Nonces
Each correspondent node also generates nonces at regular intervals. Each correspondent node also generates nonces at regular intervals.
The nonces should be generated by using a random number generator The nonces should be generated by using a random number generator
that is known to have good randomness properties [17]. A that is known to have good randomness properties [14]. A
correspondent node may use the same Kcn and nonce with all the correspondent node may use the same Kcn and nonce with all the
mobiles it is in communication with. mobiles it is in communication with.
Each nonce is identified by a nonce index. When a new nonce is Each nonce is identified by a nonce index. When a new nonce is
generated, it must be associated with a new nonce index; this may be generated, it must be associated with a new nonce index; this may be
done, for example, by incrementing the value of the previous nonce done, for example, by incrementing the value of the previous nonce
index, if the nonce index is used as an array pointer into a linear index, if the nonce index is used as an array pointer into a linear
array of nonces. However, there is no requirement that nonces be array of nonces. However, there is no requirement that nonces be
stored that way, or that the values of subsequent nonce indices have stored that way, or that the values of subsequent nonce indices have
any particular relationship to each other. The index value is any particular relationship to each other. The index value is
skipping to change at page 25, line 47 skipping to change at page 24, line 32
parties who have not seen the request cannot spoof responses. parties who have not seen the request cannot spoof responses.
Home and care-of keygen tokens are produced by the correspondent node Home and care-of keygen tokens are produced by the correspondent node
based on its currently active secret key (Kcn) and nonces, as well as based on its currently active secret key (Kcn) and nonces, as well as
the home or care-of address (respectively). A keygen token is valid the home or care-of address (respectively). A keygen token is valid
as long as both the secret key (Kcn) and the nonce used to create it as long as both the secret key (Kcn) and the nonce used to create it
are valid. are valid.
5.2.4. Cryptographic Functions 5.2.4. Cryptographic Functions
In this specification, the function used to compute hash values is By default in this specification, the function used to compute hash
SHA1 [14]. Message Authentication Codes (MACs) are computed using values is SHA1 [11]. Message Authentication Codes (MACs) are then
HMAC_SHA1 [29] [14]. HMAC_SHA1(K,m) denotes such a MAC computed on computed using HMAC_SHA1 [26] [11]. HMAC_SHA1(K,m) denotes such a
message m with key K. MAC computed on message m with key K.
5.2.5. Return Routability Procedure 5.2.5. Return Routability Procedure
The Return Routability Procedure enables the correspondent node to The Return Routability Procedure enables the correspondent node to
obtain some reasonable assurance that the mobile node is in fact obtain some reasonable assurance that the mobile node is in fact
addressable at its claimed care-of address as well as at its home addressable at its claimed care-of address as well as at its home
address. Only with this assurance is the correspondent node able to address. Only with this assurance is the correspondent node able to
accept Binding Updates from the mobile node which would then instruct accept Binding Updates from the mobile node which would then instruct
the correspondent node to direct that mobile node's data traffic to the correspondent node to direct that mobile node's data traffic to
its claimed care-of address. its claimed care-of address.
skipping to change at page 35, line 7 skipping to change at page 33, line 41
the following we define the security measures taken to protect these, the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties. and to prevent their use in attacks against other parties.
This specification limits the use of the Home Address destination This specification limits the use of the Home Address destination
option to the situation where the correspondent node already has a option to the situation where the correspondent node already has a
Binding Cache entry for the given home address. This avoids the use Binding Cache entry for the given home address. This avoids the use
of the Home Address option in attacks described in Section 15.1. of the Home Address option in attacks described in Section 15.1.
Mobile IPv6 uses a type of routing header specific to Mobile IPv6. Mobile IPv6 uses a type of routing header specific to Mobile IPv6.
This type provides the necessary functionality but does not open This type provides the necessary functionality but does not open
vulnerabilities discussed in Section 15.1 and RFC 5095 [46]. vulnerabilities discussed in Section 15.1 and RFC 5095 [43].
Tunnels between the mobile node and the home agent are protected by Tunnels between the mobile node and the home agent are protected by
ensuring proper use of source addresses, and optional cryptographic ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node verifies that the outer IP address protection. The mobile node verifies that the outer IP address
corresponds to its home agent. The home agent verifies that the corresponds to its home agent. The home agent verifies that the
outer IP address corresponds to the current location of the mobile outer IP address corresponds to the current location of the mobile
node (Binding Updates sent to the home agents are secure). The home node (Binding Updates sent to the home agents are secure). The home
agent identifies the mobile node through the source address of the agent identifies the mobile node through the source address of the
inner packet. (Typically, this is the home address of the mobile inner packet. (Typically, this is the home address of the mobile
node, but it can also be a link-local address, as discussed in node, but it can also be a link-local address, as discussed in
skipping to change at page 36, line 49 skipping to change at page 35, line 49
. . . .
. Message Data . . Message Data .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto Payload Proto
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the IPv6 following the Mobility Header. Uses the same values as the IPv6
Next Header field [8]. Next Header field [5].
This field is intended to be used by a future extension (see This field is intended to be used by a future extension (see
Appendix A.1). Appendix A.1).
Implementations conforming to this specification SHOULD set the Implementations conforming to this specification SHOULD set the
payload protocol type to IPPROTO_NONE (59 decimal). payload protocol type to IPPROTO_NONE (59 decimal).
Header Len Header Len
8-bit unsigned integer, representing the length of the Mobility 8-bit unsigned integer, representing the length of the Mobility
skipping to change at page 37, line 38 skipping to change at page 36, line 38
Checksum Checksum
16-bit unsigned integer. This field contains the checksum of the 16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated from the octet string Mobility Header. The checksum is calculated from the octet string
consisting of a "pseudo-header" followed by the entire Mobility consisting of a "pseudo-header" followed by the entire Mobility
Header starting with the Payload Proto field. The checksum is the Header starting with the Payload Proto field. The checksum is the
16-bit one's complement of the one's complement sum of this 16-bit one's complement of the one's complement sum of this
string. string.
The pseudo-header contains IPv6 header fields, as specified in The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [8]. The Next Header value used in the Section 8.1 of RFC 2460 [5]. The Next Header value used in the
pseudo-header is 135. The addresses used in the pseudo-header are pseudo-header is 135. The addresses used in the pseudo-header are
the addresses that appear in the Source and Destination Address the addresses that appear in the Source and Destination Address
fields in the IPv6 packet carrying the Mobility Header. fields in the IPv6 packet carrying the Mobility Header.
Note that the procedures of calculating upper layer checksums Note that the procedures of calculating upper layer checksums
while away from home described in Section 11.3.1 apply even for while away from home described in Section 11.3.1 apply even for
the Mobility Header. If a mobility message has a Home Address the Mobility Header. If a mobility message has a Home Address
destination option, then the checksum calculation uses the home destination option, then the checksum calculation uses the home
address in this option as the value of the IPv6 Source Address address in this option as the value of the IPv6 Source Address
field. The type 2 routing header is treated as explained in [8]. field. The type 2 routing header is treated as explained in [5].
The Mobility Header is considered as the upper layer protocol for The Mobility Header is considered as the upper layer protocol for
the purposes of calculating the pseudo-header. The Upper-Layer the purposes of calculating the pseudo-header. The Upper-Layer
Packet Length field in the pseudo-header MUST be set to the total Packet Length field in the pseudo-header MUST be set to the total
length of the Mobility Header. length of the Mobility Header.
For computing the checksum, the checksum field is set to zero. For computing the checksum, the checksum field is set to zero.
Message Data Message Data
skipping to change at page 45, line 27 skipping to change at page 44, line 27
A 16-bit unsigned integer used by the receiving node to sequence A 16-bit unsigned integer 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. Binding Acknowledgement with this Binding Update.
Lifetime Lifetime
16-bit unsigned integer. The number of time units remaining 16-bit unsigned integer. The number of time units remaining
before the binding MUST be considered expired. A value of zero before the binding MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the mobile node MUST be indicates that the Binding Cache entry for the mobile node MUST be
deleted. (In this case the specified care-of address MUST also be deleted. One time unit is 4 seconds.
set equal to the home address.) One time unit is 4 seconds.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options which it does not receiver MUST ignore and skip any options which it does not
understand. understand.
skipping to change at page 46, line 8 skipping to change at page 45, line 7
* Alternate Care-of Address option * Alternate Care-of Address option
If no options are present in this message, 4 octets of padding are If no options are present in this message, 4 octets of padding are
necessary and the Header Len field will be set to 1. necessary and the Header Len field will be set to 1.
The care-of address is specified either by the Source Address field The care-of address is specified either by the Source Address field
in the IPv6 header or by the Alternate Care-of Address option, if in the IPv6 header or by the Alternate Care-of Address option, if
present. The care-of address MUST be a unicast routable address. present. The care-of address MUST be a unicast routable address.
IPv6 Source Address MUST be a topologically correct source address. IPv6 Source Address MUST be a topologically correct source address.
Binding Updates for a care-of address which is not a unicast routable Binding Updates for a care-of address which is not a unicast routable
address MUST be silently discarded. Similarly, the Binding Update address MUST be silently discarded.
MUST be silently discarded if the care-of address appears as a home
address in an existing Binding Cache entry, with its current location
creating a circular reference back to the home address specified in
the Binding Update (possibly through additional entries).
The deletion of a binding can be indicated by setting the Lifetime The deletion of a binding MUST be indicated by setting the Lifetime
field to 0 and by setting the care-of address equal to the home field to 0. In deletion, the generation of the binding management
address. In deletion, the generation of the binding management key key depends exclusively on the home keygen token, as explained in
depends exclusively on the home keygen token, as explained in Section 5.2.5.
Section 5.2.5. (Note that while the senders are required to set both
the Lifetime field to 0 and the care-of address equal to the home
address, Section 9.5.1 rules for receivers are more liberal, and
interpret either condition as a deletion.)
Correspondent nodes SHOULD NOT delete the Binding Cache entry before Correspondent nodes SHOULD NOT delete the Binding Cache entry before
the lifetime expires, if any application hosted by the correspondent the lifetime expires, if any application hosted by the correspondent
node is still likely to require communication with the mobile node. node is still likely to require communication with the mobile node.
A Binding Cache entry that is de-allocated prematurely might cause A Binding Cache entry that is de-allocated prematurely might cause
subsequent packets to be dropped from the mobile node, if they subsequent packets to be dropped from the mobile node, if they
contain the Home Address destination option. This situation is contain the Home Address destination option. This situation is
recoverable, since a Binding Error message is sent to the mobile node recoverable, since a Binding Error message is sent to the mobile node
(see Section 6.1.9); however, it causes unnecessary delay in the (see Section 6.1.9); however, it causes unnecessary delay in the
communications. communications.
skipping to change at page 48, line 4 skipping to change at page 46, line 30
133 Not home agent for this mobile node 133 Not home agent for this mobile node
134 Duplicate Address Detection failed 134 Duplicate Address Detection failed
135 Sequence number out of window 135 Sequence number out of window
136 Expired home nonce index 136 Expired home nonce index
137 Expired care-of nonce index 137 Expired care-of nonce index
138 Expired nonces 138 Expired nonces
139 Registration type change disallowed 139 Registration type change disallowed
TBD Invalid Care-of Address
Up-to-date values of the Status field are to be specified in the Up-to-date values of the Status field are to be specified in the
IANA registry of assigned numbers [13]. IANA registry of assigned numbers [10].
Key Management Mobility Capability (K) Key Management Mobility Capability (K)
If this bit is cleared, the protocol used by the home agent for If this bit is cleared, the protocol used by the home agent for
establishing the IPsec security associations between the mobile establishing the IPsec security associations between the mobile
node and the home agent does not survive movements. It may then node and the home agent does not survive movements. It may then
have to be rerun. (Note that the IPsec security associations have to be rerun. (Note that the IPsec security associations
themselves are expected to survive movements.) themselves are expected to survive movements.)
Correspondent nodes MUST set the K bit to 0. Correspondent nodes MUST set the K bit to 0.
skipping to change at page 51, line 46 skipping to change at page 50, line 34
currently defined for use in the Mobility Header. currently defined for use in the Mobility Header.
Implementations MUST silently ignore any mobility options that they Implementations MUST silently ignore any mobility options that they
do not understand. do not understand.
Mobility options may have alignment requirements. Following the Mobility options may have alignment requirements. Following the
convention in IPv6, these options are aligned in a packet so that convention in IPv6, these options are aligned in a packet so that
multi-octet values within the Option Data field of each option fall multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at on natural boundaries (i.e., fields of width n octets are placed at
an integer multiple of n octets from the start of the header, for n = an integer multiple of n octets from the start of the header, for n =
1, 2, 4, or 8) [8]. 1, 2, 4, or 8) [5].
6.2.2. Pad1 6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format The Pad1 option does not have any alignment requirements. Its format
is as follows: is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
skipping to change at page 56, line 35 skipping to change at page 55, line 20
8-bit unsigned integer. Length of the option, in octets, 8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field excluding the Option Type and Option Length fields. This field
MUST be set to 16. MUST be set to 16.
Home Address Home Address
The home address of the mobile node sending the packet. This The home address of the mobile node sending the packet. This
address MUST be a unicast routable address. address MUST be a unicast routable address.
The alignment requirement [8] for the Home Address option is 8n+6. The alignment requirement [5] for the Home Address option is 8n+6.
The three highest-order bits of the Option Type field are encoded to The three highest-order bits of the Option Type field are encoded to
indicate specific processing of the option [8]; for the Home Address indicate specific processing of the option [5]; for the Home Address
option, these three bits are set to 110. This indicates the option, these three bits are set to 110. This indicates the
following processing requirements: following processing requirements:
o Any IPv6 node that does not recognize the Option Type must discard o Any IPv6 node that does not recognize the Option Type must discard
the packet, and if the packet's Destination Address was not a the packet, and if the packet's Destination Address was not a
multicast address, return an ICMP Parameter Problem, Code 2, multicast address, return an ICMP Parameter Problem, Code 2,
message to the packet's Source Address. The Pointer field in the message to the packet's Source Address. The Pointer field in the
ICMP message SHOULD point at the Option Type field. Otherwise, ICMP message SHOULD point at the Option Type field. Otherwise,
for multicast addresses, the ICMP message MUST NOT be sent. for multicast addresses, the ICMP message MUST NOT be sent.
skipping to change at page 57, line 15 skipping to change at page 55, line 47
The Home Address option MUST be placed as follows: The Home Address option MUST be placed as follows:
o After the routing header, if that header is present o After the routing header, if that header is present
o Before the Fragment Header, if that header is present o Before the Fragment Header, if that header is present
o Before the AH Header or ESP Header, if either one of those headers o Before the AH Header or ESP Header, if either one of those headers
are present are present
For each IPv6 packet header, the Home Address Option MUST NOT appear For each IPv6 packet header, the Home Address Option MUST NOT appear
more than once. However, an encapsulated packet [9] MAY contain a more than once. However, an encapsulated packet [6] MAY contain a
separate Home Address option associated with each encapsulating IP separate Home Address option associated with each encapsulating IP
header. header.
The inclusion of a Home Address destination option in a packet The inclusion of a Home Address destination option in a packet
affects the receiving node's processing of only this single packet. affects the receiving node's processing of only this single packet.
No state is created or modified in the receiving node as a result of No state is created or modified in the receiving node as a result of
receiving a Home Address option in a packet. In particular, the receiving a Home Address option in a packet. In particular, the
presence of a Home Address option in a received packet MUST NOT alter presence of a Home Address option in a received packet MUST NOT alter
the contents of the receiver's Binding Cache and MUST NOT cause any the contents of the receiver's Binding Cache and MUST NOT cause any
changes in the routing of subsequent packets sent by this receiving changes in the routing of subsequent packets sent by this receiving
node. node.
6.4. Type 2 Routing Header 6.4. Type 2 Routing Header
Mobile IPv6 defines a new routing header variant, the type 2 routing Mobile IPv6 defines a new routing header variant, the type 2 routing
skipping to change at page 58, line 27 skipping to change at page 57, line 9
+ Home Address + + Home Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Next Header
8-bit selector. Identifies the type of header immediately 8-bit selector. Identifies the type of header immediately
following the routing header. Uses the same values as the IPv6 following the routing header. Uses the same values as the IPv6
Next Header field [8]. Next Header field [5].
Hdr Ext Len Hdr Ext Len
2 (8-bit unsigned integer); length of the routing header in 2 (8-bit unsigned integer); length of the routing header in
8-octet units, not including the first 8 octets. 8-octet units, not including the first 8 octets.
Routing Type Routing Type
2 (8-bit unsigned integer). 2 (8-bit unsigned integer).
skipping to change at page 59, line 7 skipping to change at page 57, line 38
Home Address Home Address
The Home Address of the destination Mobile Node. The Home Address of the destination Mobile Node.
For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments
Left value describes the number of route segments remaining; i.e., Left value describes the number of route segments remaining; i.e.,
number of explicitly listed intermediate nodes still to be visited number of explicitly listed intermediate nodes still to be visited
before reaching the final destination. Segments Left MUST be 1. The before reaching the final destination. Segments Left MUST be 1. The
ordering rules for extension headers in an IPv6 packet are described ordering rules for extension headers in an IPv6 packet are described
in Section 4.1 of RFC 2460 [8]. The type 2 routing header defined in Section 4.1 of RFC 2460 [5]. The type 2 routing header defined
for Mobile IPv6 follows the same ordering as other routing headers. for Mobile IPv6 follows the same ordering as other routing headers.
If another routing header is present along with a type 2 routing If another routing header is present along with a type 2 routing
header, the type 2 routing header should follow the other routing header, the type 2 routing header should follow the other routing
header. A packet containing such nested encapsulation should be header. A packet containing such nested encapsulation should be
created as if the inner (type 2) routing header was constructed first created as if the inner (type 2) routing header was constructed first
and then treated as an original packet by header construction process and then treated as an original packet by header construction process
for the other routing header. for the other routing header.
In addition, the general procedures defined by IPv6 for routing In addition, the general procedures defined by IPv6 for routing
headers suggest that a received routing header MAY be automatically headers suggest that a received routing header MAY be automatically
skipping to change at page 59, line 29 skipping to change at page 58, line 11
packets sent by upper-layer protocols, if the received packet is packets sent by upper-layer protocols, if the received packet is
authenticated [6]. This MUST NOT be done automatically for type 2 authenticated [6]. This MUST NOT be done automatically for type 2
routing headers. routing headers.
6.5. ICMP Home Agent Address Discovery Request Message 6.5. ICMP Home Agent Address Discovery Request Message
The ICMP Home Agent Address Discovery Request message is used by a The ICMP Home Agent Address Discovery Request message is used by a
mobile node to initiate the dynamic home agent address discovery mobile node to initiate the dynamic home agent address discovery
mechanism, as described in Section 11.4.1. The mobile node sends the mechanism, as described in Section 11.4.1. The mobile node sends the
Home Agent Address Discovery Request message to the Mobile IPv6 Home- Home Agent Address Discovery Request message to the Mobile IPv6 Home-
Agents anycast address [10] for its own home subnet prefix. (Note Agents anycast address [7] for its own home subnet prefix. (Note
that the currently defined anycast addresses may not work with all that the currently defined anycast addresses may not work with all
prefix lengths other than those defined in RFC 4291 [18] [38].) prefix lengths other than those defined in RFC 4291 [15] [35].)
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
144 144
Code Code
0 0
Checksum Checksum
The ICMP checksum [19]. The ICMP checksum [16].
Identifier Identifier
An identifier to aid in matching Home Agent Address Discovery An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request Reply messages to this Home Agent Address Discovery Request
message. message.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
skipping to change at page 61, line 15 skipping to change at page 59, line 39
Type Type
145 145
Code Code
0 0
Checksum Checksum
The ICMP checksum [19]. The ICMP checksum [16].
Identifier Identifier
The identifier from the invoking Home Agent Address Discovery The identifier from the invoking Home Agent Address Discovery
Request message. Request message.
Reserved Reserved
This field is unused. It MUST be initialized to zero by the This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
skipping to change at page 62, line 41 skipping to change at page 61, line 22
Type Type
146 146
Code Code
0 0
Checksum Checksum
The ICMP checksum [19]. The ICMP checksum [16].
Identifier Identifier
An identifier to aid in matching a future Mobile Prefix An identifier to aid in matching a future Mobile Prefix
Advertisement to this Mobile Prefix Solicitation. Advertisement to this Mobile Prefix Solicitation.
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 Mobile Prefix Solicitation messages may have options. These The Mobile Prefix Solicitation messages may have options. These
options MUST use the option format defined in Neighbor Discovery (RFC options MUST use the option format defined in Neighbor Discovery (RFC
4861 [20]). This document does not define any option types for the 4861 [17]). This document does not define any option types for the
Mobile Prefix Solicitation message, but future documents may define Mobile Prefix Solicitation message, but future documents may define
new options. Home agents MUST silently ignore any options they do new options. Home agents MUST silently ignore any options they do
not recognize and continue processing the message. not recognize and continue processing the message.
6.8. ICMP Mobile Prefix Advertisement Message Format 6.8. ICMP Mobile Prefix Advertisement Message Format
A home agent will send a Mobile Prefix Advertisement to a mobile node A home agent will send a Mobile Prefix Advertisement to a mobile node
to distribute prefix information about the home link while the mobile to distribute prefix information about the home link while the mobile
node is traveling away from the home network. This will occur in node is traveling away from the home network. This will occur in
response to a Mobile Prefix Solicitation with an Advertisement, or by response to a Mobile Prefix Solicitation with an Advertisement, or by
skipping to change at page 64, line 22 skipping to change at page 62, line 51
Type Type
147 147
Code Code
0 0
Checksum Checksum
The ICMP checksum [19]. The ICMP checksum [16].
Identifier Identifier
An identifier to aid in matching this Mobile Prefix Advertisement An identifier to aid in matching this Mobile Prefix Advertisement
to a previous Mobile Prefix Solicitation. to a previous Mobile Prefix Solicitation.
M M
1-bit Managed Address Configuration flag. When set, hosts use the 1-bit Managed Address Configuration flag. When set, hosts use the
administered (stateful) protocol for address autoconfiguration in administered (stateful) protocol for address autoconfiguration in
addition to any addresses autoconfigured using stateless address addition to any addresses autoconfigured using stateless address
autoconfiguration. The use of this flag is described in [20] autoconfiguration. The use of this flag is described in [17]
[21]. [18].
O O
1-bit Other Stateful Configuration flag. When set, hosts use the 1-bit Other Stateful Configuration flag. When set, hosts use the
administered (stateful) protocol for autoconfiguration of other administered (stateful) protocol for autoconfiguration of other
(non-address) information. The use of this flag is described in (non-address) information. The use of this flag is described in
[20] [21]. [17] [18].
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 Mobile Prefix Advertisement messages may have options. These The Mobile Prefix Advertisement messages may have options. These
options MUST use the option format defined in Neighbor Discovery (RFC options MUST use the option format defined in Neighbor Discovery (RFC
4861 [20]). This document defines one option which may be carried in 4861 [17]). This document defines one option which may be carried in
a Mobile Prefix Advertisement message, but future documents may a Mobile Prefix Advertisement message, but future documents may
define new options. Mobile nodes MUST silently ignore any options define new options. Mobile nodes MUST silently ignore any options
they do not recognize and continue processing the message. they do not recognize and continue processing the message.
Prefix Information Prefix Information
Each message contains one or more Prefix Information options. Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should use Each option carries the prefix(es) that the mobile node should use
to configure its home address(es). Section 10.6 describes which to configure its home address(es). Section 10.6 describes which
prefixes should be advertised to the mobile node. prefixes should be advertised to the mobile node.
The Prefix Information option is defined in Section 4.6.2 of The Prefix Information option is defined in Section 4.6.2 of
Neighbor Discovery (RFC 4861 [20]), with modifications defined in Neighbor Discovery (RFC 4861 [17]), with modifications defined in
Section 7.2 of this specification. The home agent MUST use this Section 7.2 of this specification. The home agent MUST use this
modified Prefix Information option to send home network prefixes modified Prefix Information option to send home network prefixes
as defined in Section 10.6.1. as defined in Section 10.6.1.
If the Advertisement is sent in response to a Mobile Prefix If the Advertisement is sent in response to a Mobile Prefix
Solicitation, the home agent MUST copy the Identifier value from that Solicitation, the home agent MUST copy the Identifier value from that
message into the Identifier field of the Advertisement. message into the Identifier field of the Advertisement.
The home agent MUST NOT send more than one Mobile Prefix The home agent MUST NOT send more than one Mobile Prefix
Advertisement message per second to any mobile node. Advertisement message per second to any mobile node.
The M and O bits MUST be cleared if the Home Agent DHCPv6 support is The M and O bits MUST be cleared if the Home Agent DHCPv6 support is
not provided. If such support is provided then they are set in not provided. If such support is provided then they are set in
concert with the home network's administrative settings. concert with the home network's administrative settings.
7. Modifications to IPv6 Neighbor Discovery 7. Modifications to IPv6 Neighbor Discovery
7.1. Modified Router Advertisement Message Format 7.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement message Mobile IPv6 modifies the format of the Router Advertisement message
[20] by the addition of a single flag bit to indicate that the router [17] by the addition of a single flag bit to indicate that the router
sending the Advertisement message is serving as a home agent on this sending the Advertisement message is serving as a home agent on this
link. The format of the Router Advertisement message is as follows: link. The format of the Router Advertisement message is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime | | Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time | | Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer | | Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [20]: specified for Neighbor Discovery [17]:
Home Agent (H) Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also indicate that the router sending this Router Advertisement is also
functioning as a Mobile IPv6 home agent on this link. functioning as a Mobile IPv6 home agent on this link.
Reserved Reserved
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit. addition of the above bit.
7.2. Modified Prefix Information Option Format 7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address in Mobile IPv6 requires knowledge of a router's global address in
building a Home Agents List as part of the dynamic home agent address building a Home Agents List as part of the dynamic home agent address
discovery mechanism. discovery mechanism.
However, Neighbor Discovery [20] only advertises a router's link- However, Neighbor Discovery [17] only advertises a router's link-
local address, by requiring this address to be used as the IP Source local address, by requiring this address to be used as the IP Source
Address of each Router Advertisement. Address of each Router Advertisement.
Mobile IPv6 extends Neighbor Discovery to allow a router to advertise Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
its global address, by the addition of a single flag bit in the its global address, by the addition of a single flag bit in the
format of a Prefix Information option for use in Router Advertisement format of a Prefix Information option for use in Router Advertisement
messages. The format of the Prefix Information option is as follows: messages. The format of the Prefix Information option is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 67, line 29 skipping to change at page 66, line 29
| | | |
+ + + +
| | | |
+ Prefix + + Prefix +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally This format represents the following changes over that originally
specified for Neighbor Discovery [20]: specified for Neighbor Discovery [17]:
Router Address (R) Router Address (R)
1-bit router address flag. When set, indicates that the Prefix 1-bit router address flag. When set, indicates that the Prefix
field contains a complete IP address assigned to the sending field contains a complete IP address assigned to the sending
router. The indicated prefix is the first Prefix Length bits of router. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IP address has the same scope and the Prefix field. The router IP address has the same scope and
conforms to the same lifetime values as the advertised prefix. conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses advertising the prefix itself, since Prefix Advertisement uses
skipping to change at page 67, line 51 skipping to change at page 66, line 51
independent of the processing required for the On-Link (L) and independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits. Autonomous Address-Configuration (A) flag bits.
Reserved1 Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit. addition of the above bit.
In a Router Advertisement, a home agent MUST, and all other routers In a Router Advertisement, a home agent MUST, and all other routers
MAY, include at least one Prefix Information option with the Router MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery (RFC 4861 [20]) specifies Address (R) bit set. Neighbor Discovery (RFC 4861 [17]) specifies
that, when including all options in a Router Advertisement causes the that, when including all options in a Router Advertisement causes the
size of the Advertisement to exceed the link MTU, multiple size of the Advertisement to exceed the link MTU, multiple
Advertisements can be sent, each containing a subset of the Neighbor Advertisements can be sent, each containing a subset of the Neighbor
Discovery options. Also, when sending unsolicited multicast Router Discovery options. Also, when sending unsolicited multicast Router
Advertisements more frequently than the limit specified in RFC 4861, Advertisements more frequently than the limit specified in RFC 4861,
the sending router need not include all options in each of these the sending router need not include all options in each of these
Advertisements. However, in both of these cases the router SHOULD Advertisements. However, in both of these cases the router SHOULD
include at least one Prefix Information option with the Router include at least one Prefix Information option with the Router
Address (R) bit set in each such advertisement, if this bit is set in Address (R) bit set in each such advertisement, if this bit is set in
some advertisement sent by the router. some advertisement sent by the router.
skipping to change at page 69, line 10 skipping to change at page 68, line 10
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.
Advertisement Interval Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds, 32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent between successive unsolicited Router Advertisement messages sent
by this router on this network interface. Using the conceptual by this router on this network interface. Using the conceptual
router configuration variables defined by Neighbor Discovery [20], router configuration variables defined by Neighbor Discovery [17],
this field MUST be equal to the value MaxRtrAdvInterval, expressed this field MUST be equal to the value MaxRtrAdvInterval, expressed
in milliseconds. in milliseconds.
Routers MAY include this option in their Router Advertisements. A Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.5.1. in its movement detection algorithm, as described in Section 11.5.1.
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
skipping to change at page 71, line 13 skipping to change at page 70, line 13
This option MUST be silently ignored for other Neighbor Discovery This option MUST be silently ignored for other Neighbor Discovery
messages. messages.
If both the Home Agent Preference and Home Agent Lifetime are set to If both the Home Agent Preference and Home Agent Lifetime are set to
their default values specified above, this option SHOULD NOT be their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home included in the Router Advertisement messages sent by this home
agent. agent.
7.5. Changes to Sending Router Advertisements 7.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [20] limits routers to The Neighbor Discovery protocol specification [17] limits routers to
a minimum interval of 3 seconds between sending unsolicited multicast a minimum interval of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface Router Advertisement messages from any given network interface
(limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that: (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough that "Routers generate Router Advertisements frequently enough that
hosts will learn of their presence within a few minutes, but not hosts will learn of their presence within a few minutes, but not
frequently enough to rely on an absence of advertisements to frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability detect router failure; a separate Neighbor Unreachability
Detection algorithm provides failure detection." Detection algorithm provides failure detection."
skipping to change at page 72, line 12 skipping to change at page 71, line 12
o MinRtrAdvInterval 0.03 seconds o MinRtrAdvInterval 0.03 seconds
o MaxRtrAdvInterval 0.07 seconds o MaxRtrAdvInterval 0.07 seconds
In the case where the minimum intervals and delays are used, the mean In the case where the minimum intervals and delays are used, the mean
time between unsolicited multicast router advertisements is 50ms. time between unsolicited multicast router advertisements is 50ms.
Use of these modified limits MUST be configurable (see also the Use of these modified limits MUST be configurable (see also the
configuration variable MinDelayBetweenRas in Section 13 which may configuration variable MinDelayBetweenRas in Section 13 which may
also have to be modified accordingly). Systems where these values also have to be modified accordingly). Systems where these values
are available MUST NOT default to them, and SHOULD default to values are available MUST NOT default to them, and SHOULD default to values
specified in Neighbor Discovery (RFC 4861 [20]). Knowledge of the specified in Neighbor Discovery (RFC 4861 [17]). Knowledge of the
type of network interface and operating environment SHOULD be taken type of network interface and operating environment SHOULD be taken
into account in configuring these limits for each network interface. into account in configuring these limits for each network interface.
This is important with some wireless links, where increasing the This is important with some wireless links, where increasing the
frequency of multicast beacons can cause considerable overhead. frequency of multicast beacons can cause considerable overhead.
Routers SHOULD adhere to the intervals specified in RFC 4861 [20], if Routers SHOULD adhere to the intervals specified in RFC 4861 [17], if
this overhead is likely to cause service degradation. this overhead is likely to cause service degradation.
Additionally, the possible low values of MaxRtrAdvInterval may cause Additionally, the possible low values of MaxRtrAdvInterval may cause
some problems with movement detection in some mobile nodes. To some problems with movement detection in some mobile nodes. To
ensure that this is not a problem, Routers SHOULD add 20ms to any ensure that this is not a problem, Routers SHOULD add 20ms to any
Advertisement Intervals sent in RAs, which are below 200 ms, in order Advertisement Intervals sent in RAs, which are below 200 ms, in order
to account for scheduling granularities on both the MN and the to account for scheduling granularities on both the MN and the
Router. Router.
Note that multicast Router Advertisements are not always required in Note that multicast Router Advertisements are not always required in
skipping to change at page 72, line 40 skipping to change at page 71, line 40
layers. Router advertisements in such networks SHOULD be sent only layers. Router advertisements in such networks SHOULD be sent only
when solicited. In such networks it SHOULD be possible to disable when solicited. In such networks it SHOULD be possible to disable
unsolicited multicast Router Advertisements on specific interfaces. unsolicited multicast Router Advertisements on specific interfaces.
The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
to some high values. to some high values.
Home agents MUST include the Source Link-Layer Address option in all Home agents MUST include the Source Link-Layer Address option in all
Router Advertisements they send. This simplifies the process of Router Advertisements they send. This simplifies the process of
returning home, as discussed in Section 11.5.5. returning home, as discussed in Section 11.5.5.
Note that according to Neighbor Discovery (RFC 4861 [20]), Note that according to Neighbor Discovery (RFC 4861 [17]),
AdvDefaultLifetime is by default based on the value of AdvDefaultLifetime is by default based on the value of
MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime
field of Router Advertisements. Given that this field is expressed field of Router Advertisements. Given that this field is expressed
in seconds, a small MaxRtrAdvInterval value can result in a zero in seconds, a small MaxRtrAdvInterval value can result in a zero
value for this field. To prevent this, routers SHOULD keep value for this field. To prevent this, routers SHOULD keep
AdvDefaultLifetime in at least one second, even if the use of AdvDefaultLifetime in at least one second, even if the use of
MaxRtrAdvInterval would result in a smaller value. MaxRtrAdvInterval would result in a smaller value.
8. Requirements for Types of IPv6 Nodes 8. Requirements for Types of IPv6 Nodes
skipping to change at page 75, line 27 skipping to change at page 74, line 27
o The node SHOULD allow route optimization to be administratively o The node SHOULD allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled. enabled or disabled. The default SHOULD be enabled.
8.3. All IPv6 Routers 8.3. All IPv6 Routers
All IPv6 routers, even those not serving as a home agent for Mobile All IPv6 routers, even those not serving as a home agent for Mobile
IPv6, have an effect on how well mobile nodes can communicate: IPv6, have an effect on how well mobile nodes can communicate:
o Every IPv6 router SHOULD be able to send an Advertisement Interval o Every IPv6 router SHOULD be able to send an Advertisement Interval
option (Section 7.3) in each of its Router Advertisements [20], to option (Section 7.3) in each of its Router Advertisements [17], to
aid movement detection by mobile nodes (as in Section 11.5.1). aid movement detection by mobile nodes (as in Section 11.5.1).
The use of this option in Router Advertisements SHOULD be The use of this option in Router Advertisements SHOULD be
configurable. configurable.
o Every IPv6 router SHOULD be able to support sending unsolicited o Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in multicast Router Advertisements at the faster rate described in
Section 7.5. If the router supports a faster rate, the used rate Section 7.5. If the router supports a faster rate, the used rate
MUST be configurable. MUST be configurable.
o Each router SHOULD include at least one prefix with the Router o Each router SHOULD include at least one prefix with the Router
skipping to change at page 76, line 10 skipping to change at page 75, line 10
In order for a mobile node to operate correctly while away from home, In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function at least one IPv6 router on the mobile node's home link must function
as a home agent for the mobile node. The following additional as a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers that serve as a home agent: requirements apply to all IPv6 routers that serve as a home agent:
o Every home agent MUST be able to maintain an entry in its Binding o Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as the home Cache for each mobile node for which it is serving as the home
agent (Section 10.1 and Section 10.3.1). agent (Section 10.1 and Section 10.3.1).
o Every home agent MUST be able to intercept packets (using proxy o Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery [20]) addressed to a mobile node for which it Neighbor Discovery [17]) addressed to a mobile node for which it
is currently serving as the home agent, on that mobile node's home is currently serving as the home agent, on that mobile node's home
link, while the mobile node is away from home (Section 10.4.1). link, while the mobile node is away from home (Section 10.4.1).
o Every home agent MUST be able to encapsulate [9] such intercepted o Every home agent MUST be able to encapsulate [6] such intercepted
packets in order to tunnel them to the primary care-of address for packets in order to tunnel them to the primary care-of address for
the mobile node indicated in its binding in the home agent's the mobile node indicated in its binding in the home agent's
Binding Cache (Section 10.4.2). Binding Cache (Section 10.4.2).
o Every home agent MUST support decapsulating [9] reverse tunneled o Every home agent MUST support decapsulating [6] reverse tunneled
packets sent to it from a mobile node's home address. Every home packets sent to it from a mobile node's home address. Every home
agent MUST also check that the source address in the tunneled agent MUST also check that the source address in the tunneled
packets corresponds to the currently registered location of the packets corresponds to the currently registered location of the
mobile node (Section 10.4.5). mobile node (Section 10.4.5).
o The node MUST be able to process Mobility Headers as described in o The node MUST be able to process Mobility Headers as described in
Section 10.2. Section 10.2.
o Every home agent MUST be able to return a Binding Acknowledgement o Every home agent MUST be able to return a Binding Acknowledgement
in response to a Binding Update (Section 10.3.1). in response to a Binding Update (Section 10.3.1).
o Every home agent MUST maintain a separate Home Agents List for o Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in each link on which it is serving as a home agent, as described in
Section 10.1 and Section 10.5.1. Section 10.1 and Section 10.5.1.
o Every home agent MUST be able to accept packets addressed to the o Every home agent MUST be able to accept packets addressed to the
Mobile IPv6 Home-Agents anycast address [10] for the subnet on Mobile IPv6 Home-Agents anycast address [7] for the subnet on
which it is serving as a home agent, and MUST be able to which it is serving as a home agent, and MUST be able to
participate in dynamic home agent address discovery participate in dynamic home agent address discovery
(Section 10.5). (Section 10.5).
o Every home agent SHOULD support a configuration mechanism to allow o Every home agent SHOULD support a configuration mechanism to allow
a system administrator to manually set the value to be sent by a system administrator to manually set the value to be sent by
this home agent in the Home Agent Preference field of the Home this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends Agent Information Option in Router Advertisements that it sends
(Section 7.4). (Section 7.4).
skipping to change at page 77, line 29 skipping to change at page 76, line 29
Finally, the following requirements apply to all IPv6 nodes capable Finally, the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes: of functioning as mobile nodes:
o The node MUST maintain a Binding Update List (Section 11.1). o The node MUST maintain a Binding Update List (Section 11.1).
o The node MUST support sending packets containing a Home Address o The node MUST support sending packets containing a Home Address
option (Section 11.3.1), and follow the required IPsec interaction option (Section 11.3.1), and follow the required IPsec interaction
(Section 11.3.2). (Section 11.3.2).
o The node MUST be able to perform IPv6 encapsulation and o The node MUST be able to perform IPv6 encapsulation and
decapsulation [9]. decapsulation [6].
o The node MUST be able to process type 2 routing header as defined o The node MUST be able to process type 2 routing header as defined
in Section 6.4 and Section 11.3.3. in Section 6.4 and Section 11.3.3.
o The node MUST support receiving a Binding Error message o The node MUST support receiving a Binding Error message
(Section 11.3.6). (Section 11.3.6).
o The node MUST support receiving ICMP errors (Section 11.3.5). o The node MUST support receiving ICMP errors (Section 11.3.5).
o The node MUST support movement detection, care-of address o The node MUST support movement detection, care-of address
skipping to change at page 78, line 24 skipping to change at page 77, line 24
o The node MUST allow route optimization to be administratively o The node MUST allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled. enabled or disabled. The default SHOULD be enabled.
o The node MAY support the multicast address listener part of a o The node MAY support the multicast address listener part of a
multicast group membership protocol as described in multicast group membership protocol as described in
Section 11.3.4. If this support is provided, the mobile node MUST Section 11.3.4. If this support is provided, the mobile node MUST
be able to receive tunneled multicast packets from the home agent. be able to receive tunneled multicast packets from the home agent.
o The node MAY support stateful address autoconfiguration mechanisms o The node MAY support stateful address autoconfiguration mechanisms
such as DHCPv6 [32] on the interface represented by the tunnel to such as DHCPv6 [29] on the interface represented by the tunnel to
the home agent. the home agent.
9. Correspondent Node Operation 9. Correspondent Node Operation
9.1. Conceptual Data Structures 9.1. Conceptual Data Structures
IPv6 nodes with route optimization support maintain a Binding Cache IPv6 nodes with route optimization support maintain a Binding Cache
of bindings for other nodes. A separate Binding Cache SHOULD be of bindings for other nodes. A separate Binding Cache SHOULD be
maintained by each IPv6 node for each of its unicast routable maintained by each IPv6 node for each of its unicast routable
addresses. The Binding Cache MAY be implemented in any manner addresses. The Binding Cache MAY be implemented in any manner
consistent with the external behavior described in this document, for consistent with the external behavior described in this document, for
example by being combined with the node's Destination Cache as example by being combined with the node's Destination Cache as
maintained by Neighbor Discovery [20]. When sending a packet, the maintained by Neighbor Discovery [17]. When sending a packet, the
Binding Cache is searched before the Neighbor Discovery conceptual Binding Cache is searched before the Neighbor Discovery conceptual
Destination Cache [20]. Destination Cache [17].
Each Binding Cache entry conceptually contains the following fields: Each Binding Cache entry conceptually contains the following fields:
o The home address of the mobile node for which this is the Binding o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent. Binding Cache for the destination address of a packet being sent.
o The care-of address for the mobile node indicated by the home o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry. address field in this Binding Cache entry.
skipping to change at page 80, line 24 skipping to change at page 79, line 24
node MUST silently discard the message. node MUST silently discard the message.
o The MH Type field MUST have a known value (Section 6.1.1). o The MH Type field MUST have a known value (Section 6.1.1).
Otherwise, the node MUST discard the message and issue a Binding Otherwise, the node MUST discard the message and issue a Binding
Error message as described in Section 9.3.3, with Status field set Error message as described in Section 9.3.3, with Status field set
to 2 (unrecognized MH Type value). to 2 (unrecognized MH Type value).
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem, Code 0, directly to the Source Address of the Parameter Problem, Code 0, directly to the Source Address of the
packet as specified in RFC 4443 [19]. Thus no Binding Cache packet as specified in RFC 4443 [16]. Thus no Binding Cache
information is used in sending the ICMP message. The Pointer information is used in sending the ICMP message. The Pointer
field in the ICMP message SHOULD point at the Payload Proto field. field in the ICMP message SHOULD point at the Payload Proto field.
o The Header Len field in the Mobility Header MUST NOT be less than o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem, Code 0, directly to the Source SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
Address of the packet as specified in RFC 4443 [19]. (The Binding Address of the packet as specified in RFC 4443 [16]. (The Binding
Cache information is again not used.) The Pointer field in the Cache information is again not used.) The Pointer field in the
ICMP message SHOULD point at the Header Len field. ICMP message SHOULD point at the Header Len field.
Subsequent checks depend on the particular Mobility Header. Subsequent checks depend on the particular Mobility Header.
9.3. Packet Processing 9.3. Packet Processing
This section describes how the correspondent node sends packets to This section describes how the correspondent node sends packets to
the mobile node, and receives packets from it. the mobile node, and receives packets from it.
skipping to change at page 82, line 5 skipping to change at page 81, line 5
9.3.2. Sending Packets to a Mobile Node 9.3.2. Sending Packets to a Mobile Node
Before sending any packet, the sending node SHOULD examine its Before sending any packet, the sending node SHOULD examine its
Binding Cache for an entry for the destination address to which the Binding Cache for an entry for the destination address to which the
packet is being sent. If the sending node has a Binding Cache entry packet is being sent. If the sending node has a Binding Cache entry
for this address, the sending node SHOULD use a type 2 routing header for this address, the sending node SHOULD use a type 2 routing header
to route the packet to this mobile node (the destination node) by way to route the packet to this mobile node (the destination node) by way
of its care-of address. However, the sending node MUST NOT do this of its care-of address. However, the sending node MUST NOT do this
in the following cases: in the following cases:
o When sending an IPv6 Neighbor Discovery [20] packet. o When sending an IPv6 Neighbor Discovery [17] packet.
o Where otherwise noted in Section 6.1. o Where otherwise noted in Section 6.1.
When calculating authentication data in a packet that contains a type When calculating authentication data in a packet that contains a type
2 routing header, the correspondent node MUST calculate the AH 2 routing header, the correspondent node MUST calculate the AH
authentication data as if the following were true: The routing header authentication data as if the following were true: The routing header
contains the care-of address, the destination IPv6 address field of contains the care-of address, the destination IPv6 address field of
the IPv6 header contains the home address, and the Segments Left the IPv6 header contains the home address, and the Segments Left
field is zero. The IPsec Security Policy Database lookup MUST based field is zero. The IPsec Security Policy Database lookup MUST based
on the mobile node's home address. on the mobile node's home address.
skipping to change at page 83, line 31 skipping to change at page 82, line 31
The Home Address field in the Binding Error message MUST be copied The Home Address field in the Binding Error message MUST be copied
from the Home Address field in the Home Address destination option of from the Home Address field in the Home Address destination option of
the offending packet, or set to the unspecified address if no such the offending packet, or set to the unspecified address if no such
option appeared in the packet. option appeared in the packet.
Note that the IPv6 Source Address and Home Address field values Note that the IPv6 Source Address and Home Address field values
discussed above are the values from the wire, i.e., before any discussed above are the values from the wire, i.e., before any
modifications possibly performed as specified in Section 9.3.1. modifications possibly performed as specified in Section 9.3.1.
Binding Error messages SHOULD be subject to rate limiting in the same Binding Error messages SHOULD be subject to rate limiting in the same
manner as is done for ICMPv6 messages [19]. manner as is done for ICMPv6 messages [16].
9.3.4. Receiving ICMP Error Messages 9.3.4. Receiving ICMP Error Messages
When the correspondent node has a Binding Cache entry for a mobile When the correspondent node has a Binding Cache entry for a mobile
node, all traffic destined to the mobile node goes directly to the node, all traffic destined to the mobile node goes directly to the
current care-of address of the mobile node using a routing header. current care-of address of the mobile node using a routing header.
Any ICMP error message caused by packets on their way to the care-of Any ICMP error message caused by packets on their way to the care-of
address will be returned in the normal manner to the correspondent address will be returned in the normal manner to the correspondent
node. node.
On the other hand, if the correspondent node has no Binding Cache On the other hand, if the correspondent node has no Binding Cache
entry for the mobile node, the packet will be routed through the entry for the mobile node, the packet will be routed through the
mobile node's home link. Any ICMP error message caused by the packet mobile node's home link. Any ICMP error message caused by the packet
on its way to the mobile node while in the tunnel, will be on its way to the mobile node while in the tunnel, will be
transmitted to the mobile node's home agent. By the definition of transmitted to the mobile node's home agent. By the definition of
IPv6 encapsulation [9], the home agent MUST relay certain ICMP error IPv6 encapsulation [6], the home agent MUST relay certain ICMP error
messages back to the original sender of the packet, which in this messages back to the original sender of the packet, which in this
case is the correspondent node. case is the correspondent node.
Thus, in all cases, any meaningful ICMP error messages caused by Thus, in all cases, any meaningful ICMP error messages caused by
packets from a correspondent node to a mobile node will be returned packets from a correspondent node to a mobile node will be returned
to the correspondent node. If the correspondent node receives to the correspondent node. If the correspondent node receives
persistent ICMP Destination Unreachable messages after sending persistent ICMP Destination Unreachable messages after sending
packets to a mobile node based on an entry in its Binding Cache, the packets to a mobile node based on an entry in its Binding Cache, the
correspondent node SHOULD delete this Binding Cache entry. Note that correspondent node SHOULD delete this Binding Cache entry. Note that
if the mobile node continues to send packets with the Home Address if the mobile node continues to send packets with the Home Address
skipping to change at page 87, line 33 skipping to change at page 86, line 33
Update is stored by the receiving node in its Binding Cache entry Update is stored by the receiving node in its Binding Cache entry
for the given home address. for the given home address.
o If the Lifetime specified in the Binding Update is not zero, then o If the Lifetime specified in the Binding Update is not zero, then
this is a request to cache a binding for the home address. If the this is a request to cache a binding for the home address. If the
Home Registration (H) bit is set in the Binding Update, the Home Registration (H) bit is set in the Binding Update, the
Binding Update is processed according to the procedure specified Binding Update is processed according to the procedure specified
in Section 10.3.1; otherwise, it is processed according to the in Section 10.3.1; otherwise, it is processed according to the
procedure specified in Section 9.5.2. procedure specified in Section 9.5.2.
o If the Lifetime specified in the Binding Update is zero or the o If the Lifetime specified in the Binding Update is zero, then this
specified care-of address matches the home address for the is a request to delete the cached binding for the home address.
binding, then this is a request to delete the cached binding for In this case, the Binding Update MUST include a valid home nonce
the home address. In this case, the Binding Update MUST include a index, and the care-of nonce index MUST be ignored by the
valid home nonce index, and the care-of nonce index MUST be correspondent node. The generation of the binding management key
ignored by the correspondent node. The generation of the binding depends then exclusively on the home keygen token (Section 5.2.5).
management key depends then exclusively on the home keygen token If the Home Registration (H) bit is set in the Binding Update, the
(Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update is processed according to the procedure specified
Binding Update, the Binding Update is processed according to the in Section 10.3.2; otherwise, it is processed according to the
procedure specified in Section 10.3.2; otherwise, it is processed procedure specified in Section 9.5.3.
according to the procedure specified in Section 9.5.3.
The specified care-of address MUST be determined as follows: The specified care-of address MUST be determined as follows:
o If the Alternate Care-of Address option is present, the care-of o If the Alternate Care-of Address option is present, the care-of
address is the address in that option. address is the address in that option.
o Otherwise, the care-of address is the Source Address field in the o Otherwise, the care-of address is the Source Address field in the
packet's IPv6 header. packet's IPv6 header.
The home address for the binding MUST be determined as follows: The home address for the binding MUST be determined as follows:
skipping to change at page 89, line 37 skipping to change at page 88, line 37
index, sequence number being out of window (Section 9.5.1), or index, sequence number being out of window (Section 9.5.1), or
insufficiency of resources (Section 9.5.2), a Binding insufficiency of resources (Section 9.5.2), a Binding
Acknowledgement MUST be sent. If the node accepts the Binding Acknowledgement MUST be sent. If the node accepts the Binding
Update, the Binding Acknowledgement SHOULD NOT be sent. Update, the Binding Acknowledgement SHOULD NOT be sent.
If the node accepts the Binding Update and creates or updates an If the node accepts the Binding Update and creates or updates an
entry for this binding, the Status field in the Binding entry for this binding, the Status field in the Binding
Acknowledgement MUST be set to a value less than 128. Otherwise, the Acknowledgement MUST be set to a value less than 128. Otherwise, the
Status field MUST be set to a value greater than or equal to 128. Status field MUST be set to a value greater than or equal to 128.
Values for the Status field are described in Section 6.1.8 and in the Values for the Status field are described in Section 6.1.8 and in the
IANA registry of assigned numbers [13]. IANA registry of assigned numbers [10].
If the Status field in the Binding Acknowledgement contains the value If the Status field in the Binding Acknowledgement contains the value
136 (expired home nonce index), 137 (expired care-of nonce index), or 136 (expired home nonce index), 137 (expired care-of nonce index), or
138 (expired nonces) then the message MUST NOT include the Binding 138 (expired nonces) then the message MUST NOT include the Binding
Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option. Otherwise, the Binding
Authorization Data mobility option MUST be included, and MUST meet Authorization Data mobility option MUST be included, and MUST meet
the specific authentication requirements for Binding Acknowledgements the specific authentication requirements for Binding Acknowledgements
as defined in Section 5.2. as defined in Section 5.2.
If the Source Address field of the IPv6 header that carried the If the Source Address field of the IPv6 header that carried the
skipping to change at page 92, line 23 skipping to change at page 91, line 23
Section 9.1. Section 9.1.
The Home Agents List is maintained by each home agent, recording The Home Agents List is maintained by each home agent, recording
information about each router on the same link that is acting as a information about each router on the same link that is acting as a
home agent. This list is used by the dynamic home agent address home agent. This list is used by the dynamic home agent address
discovery mechanism. A router is known to be acting as a home agent, discovery mechanism. A router is known to be acting as a home agent,
if it sends a Router Advertisement in which the Home Agent (H) bit is if it sends a Router Advertisement in which the Home Agent (H) bit is
set. When the lifetime for a list entry (defined below) expires, set. When the lifetime for a list entry (defined below) expires,
that entry is removed from the Home Agents List. The Home Agents that entry is removed from the Home Agents List. The Home Agents
List is similar to the Default Router List conceptual data structure List is similar to the Default Router List conceptual data structure
maintained by each host for Neighbor Discovery [20]. The Home Agents maintained by each host for Neighbor Discovery [17]. The Home Agents
List MAY be implemented in any manner consistent with the external List MAY be implemented in any manner consistent with the external
behavior described in this document. behavior described in this document.
Each home agent maintains a separate Home Agents List for each link Each home agent maintains a separate Home Agents List for each link
on which it is serving as a home agent. A new entry is created or an on which it is serving as a home agent. A new entry is created or an
existing entry is updated in response to receipt of a valid Router existing entry is updated in response to receipt of a valid Router
Advertisement in which the Home Agent (H) bit is set. Each Home Advertisement in which the Home Agent (H) bit is set. Each Home
Agents List entry conceptually contains the following fields: Agents List entry conceptually contains the following fields:
o The link-local IP address of a home agent on the link. This o The link-local IP address of a home agent on the link. This
address is learned through the Source Address of the Router address is learned through the Source Address of the Router
Advertisements [20] received from the router. Advertisements [17] received from the router.
o One or more global IP addresses for this home agent. Global o One or more global IP addresses for this home agent. Global
addresses are learned through Prefix Information options with the addresses are learned through Prefix Information options with the
Router Address (R) bit set and received in Router Advertisements Router Address (R) bit set and received in Router Advertisements
from this link-local address. Global addresses for the router in from this link-local address. Global addresses for the router in
a Home Agents List entry MUST be deleted once the prefix a Home Agents List entry MUST be deleted once the prefix
associated with that address is no longer valid [20]. associated with that address is no longer valid [17].
o The remaining lifetime of this Home Agents List entry. If a Home o The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement Agent Information Option is present in a Router Advertisement
received from a home agent, the lifetime of the Home Agents List received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home entry representing that home agent is initialized from the Home
Agent Lifetime field in the option (if present); otherwise, the Agent Lifetime field in the option (if present); otherwise, the
lifetime is initialized from the Router Lifetime field in the lifetime is initialized from the Router Lifetime field in the
received Router Advertisement. If Home Agents List entry lifetime received Router Advertisement. If Home Agents List entry lifetime
reaches zero, the entry MUST be deleted from the Home Agents List. reaches zero, the entry MUST be deleted from the Home Agents List.
skipping to change at page 94, line 30 skipping to change at page 93, line 30
the home address of the mobile node. the home address of the mobile node.
The home agent MUST mark this Binding Cache entry as a home The home agent MUST mark this Binding Cache entry as a home
registration to indicate that the node is serving as a home agent for registration to indicate that the node is serving as a home agent for
this binding. Binding Cache entries marked as a home registration this binding. Binding Cache entries marked as a home registration
MUST be excluded from the normal cache replacement policy used for MUST be excluded from the normal cache replacement policy used for
the Binding Cache (Section 9.6) and MUST NOT be removed from the the Binding Cache (Section 9.6) and MUST NOT be removed from the
Binding Cache until the expiration of the Lifetime period. Binding Cache until the expiration of the Lifetime period.
Unless this home agent already has a binding for the given home Unless this home agent already has a binding for the given home
address, the home agent MUST perform Duplicate Address Detection [21] address, the home agent MUST perform Duplicate Address Detection [18]
on the mobile node's home link before returning the Binding on the mobile node's home link before returning the Binding
Acknowledgement. This ensures that no other node on the home link Acknowledgement. This ensures that no other node on the home link
was using the mobile node's home address when the Binding Update was using the mobile node's home address when the Binding Update
arrived. If this Duplicate Address Detection fails for the given arrived. If this Duplicate Address Detection fails for the given
home address or an associated link local address, then the home agent home address or an associated link local address, then the home agent
MUST reject the complete Binding Update and MUST return a Binding MUST reject the complete Binding Update and MUST return a Binding
Acknowledgement to the mobile node, in which the Status field is set Acknowledgement to the mobile node, in which the Status field is set
to 134 (Duplicate Address Detection failed). When the home agent to 134 (Duplicate Address Detection failed). When the home agent
sends a successful Binding Acknowledgement to the mobile node, the sends a successful Binding Acknowledgement to the mobile node, the
home agent assures to the mobile node that its address(es) will be home agent assures to the mobile node that its address(es) will be
skipping to change at page 95, line 20 skipping to change at page 94, line 20
The lifetime of the Binding Cache entry depends on a number of The lifetime of the Binding Cache entry depends on a number of
factors: factors:
o The lifetime for the Binding Cache entry MUST NOT be greater than o The lifetime for the Binding Cache entry MUST NOT be greater than
the Lifetime value specified in the Binding Update. the Lifetime value specified in the Binding Update.
o The lifetime for the Binding Cache entry MUST NOT be greater than o The lifetime for the Binding Cache entry MUST NOT be greater than
the remaining valid lifetime for the subnet prefix in the mobile the remaining valid lifetime for the subnet prefix in the mobile
node's home address specified with the Binding Update. The node's home address specified with the Binding Update. The
remaining valid lifetime for this prefix is determined by the home remaining valid lifetime for this prefix is determined by the home
agent based on its own Prefix List entry [20]. agent based on its own Prefix List entry [17].
The remaining preferred lifetime SHOULD NOT have any impact on the The remaining preferred lifetime SHOULD NOT have any impact on the
lifetime for the binding cache entry. lifetime for the binding cache entry.
The home agent MUST remove a binding when the valid lifetime of The home agent MUST remove a binding when the valid lifetime of
the prefix associated with it expires. the prefix associated with it expires.
o The home agent MAY further decrease the specified lifetime for the o The home agent MAY further decrease the specified lifetime for the
binding, for example based on a local policy. The resulting binding, for example based on a local policy. The resulting
lifetime is stored by the home agent in the Binding Cache entry, lifetime is stored by the home agent in the Binding Cache entry,
skipping to change at page 96, line 26 skipping to change at page 95, line 26
K = 0 K = 0
Discard key management connections, if any, to the old care-of Discard key management connections, if any, to the old care-of
address. If the mobile node did not have a binding before address. If the mobile node did not have a binding before
sending this Binding Update, discard the connections to the sending this Binding Update, discard the connections to the
home address. home address.
K = 1 K = 1
Move the peer endpoint of the key management protocol Move the peer endpoint of the key management protocol
connection, if any, to the new care-of address. For an IKE connection, if any, to the new care-of address.
phase 1 connection, this means that any IKE packets sent to the
peer are sent to this address, and packets from this address
with the original ISAKMP cookies are accepted.
Note that RFC 2408 [6] Section 2.5.3 gives specific rules that
ISAKMP cookies must satisfy: they must depend on specific
parties and can only be generated by the entity itself. Then
it recommends a particular way to do this, namely a hash of IP
addresses. With the K bit set to 1, the recommended
implementation technique does not work directly. To satisfy
the two rules, the specific parties must be treated as the
original IP addresses, not the ones in use at the specific
moment.
o The Sequence Number field MUST be copied from the Sequence Number o The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update. given in the Binding Update.
o The Lifetime field MUST be set to the remaining lifetime for the o The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the home agent in its home registration Binding binding as set by the home agent in its home registration Binding
Cache entry for the mobile node, as described above. Cache entry for the mobile node, as described above.
o If the home agent stores the Binding Cache entry in nonvolatile o If the home agent stores the Binding Cache entry in nonvolatile
storage, then the Binding Refresh Advice mobility option MUST be storage, then the Binding Refresh Advice mobility option MUST be
skipping to change at page 99, line 21 skipping to change at page 98, line 9
10.4.1. Intercepting Packets for a Mobile Node 10.4.1. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for a mobile node it MUST While a node is serving as the home agent for a mobile node it MUST
attempt to intercept packets on the mobile node's home link that are attempt to intercept packets on the mobile node's home link that are
addressed to the mobile node. addressed to the mobile node.
In order to do this, when a node begins serving as the home agent it In order to do this, when a node begins serving as the home agent it
MUST have performed Duplicate Address Detection (as specified in MUST have performed Duplicate Address Detection (as specified in
Section 10.3.1), and subsequently it MUST multicast onto the home Section 10.3.1), and subsequently it MUST multicast onto the home
link a Neighbor Advertisement message [20] on behalf of the mobile link a Neighbor Advertisement message [17] on behalf of the mobile
node. For the home address specified in the Binding Update, the home node. For the home address specified in the Binding Update, the home
agent sends a Neighbor Advertisement message [20] to the all-nodes agent sends a Neighbor Advertisement message [17] to the all-nodes
multicast address on the home link to advertise the home agent's own multicast address on the home link to advertise the home agent's own
link-layer address for this IP address on behalf of the mobile node. link-layer address for this IP address on behalf of the mobile node.
If the Link-Layer Address Compatibility (L) flag has been specified If the Link-Layer Address Compatibility (L) flag has been specified
in the Binding Update, the home agent MUST do the same for the link- in the Binding Update, the home agent MUST do the same for the link-
local address of the mobile node. local address of the mobile node.
All fields in each Neighbor Advertisement message SHOULD be set in All fields in each Neighbor Advertisement message SHOULD be set in
the same way they would be set by the mobile node if it was sending the same way they would be set by the mobile node if it was sending
this Neighbor Advertisement [20] while at home, with the following this Neighbor Advertisement [17] while at home, with the following
exceptions: exceptions:
o The Target Address in the Neighbor Advertisement MUST be set to o The Target Address in the Neighbor Advertisement MUST be set to
the specific IP address for the mobile node. the specific IP address for the mobile node.
o The Advertisement MUST include a Target Link-layer Address option o The Advertisement MUST include a Target Link-layer Address option
specifying the home agent's link-layer address. specifying the home agent's link-layer address.
o The Router (R) bit in the Advertisement MUST be set to zero. o The Router (R) bit in the Advertisement MUST be set to zero.
skipping to change at page 100, line 14 skipping to change at page 98, line 50
advertisement. advertisement.
Any node on the home link that receives one of the Neighbor Any node on the home link that receives one of the Neighbor
Advertisement messages (described above) will update its Neighbor Advertisement messages (described above) will update its Neighbor
Cache to associate the mobile node's address with the home agent's Cache to associate the mobile node's address with the home agent's
link layer address, causing it to transmit any future packets link layer address, causing it to transmit any future packets
normally destined to the mobile node to the mobile node's home agent. normally destined to the mobile node to the mobile node's home agent.
Since multicasting on the local link (such as Ethernet) is typically Since multicasting on the local link (such as Ethernet) is typically
not guaranteed to be reliable, the home agent MAY retransmit this not guaranteed to be reliable, the home agent MAY retransmit this
Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see
[20]) times to increase its reliability. It is still possible that [17]) times to increase its reliability. It is still possible that
some nodes on the home link will not receive any of the Neighbor some nodes on the home link will not receive any of the Neighbor
Advertisements, but these nodes will eventually be able to detect the Advertisements, but these nodes will eventually be able to detect the
link-layer address change for the mobile node's address through use link-layer address change for the mobile node's address through use
of Neighbor Unreachability Detection [20]. of Neighbor Unreachability Detection [17].
While a node is serving as a home agent for some mobile node, the While a node is serving as a home agent for some mobile node, the
home agent uses IPv6 Neighbor Discovery [20] to intercept unicast home agent uses IPv6 Neighbor Discovery [17] to intercept unicast
packets on the home link addressed to the mobile node. In order to packets on the home link addressed to the mobile node. In order to
intercept packets in this way, the home agent MUST act as a proxy for intercept packets in this way, the home agent MUST act as a proxy for
this mobile node and reply to any received Neighbor Solicitations for this mobile node and reply to any received Neighbor Solicitations for
it. When a home agent receives a Neighbor Solicitation, it MUST it. When a home agent receives a Neighbor Solicitation, it MUST
check if the Target Address specified in the message matches the check if the Target Address specified in the message matches the
address of any mobile node for which it has a Binding Cache entry address of any mobile node for which it has a Binding Cache entry
marked as a home registration. marked as a home registration.
If such an entry exists in the home agent's Binding Cache, the home If such an entry exists in the home agent's Binding Cache, the home
agent MUST reply to the Neighbor Solicitation with a Neighbor agent MUST reply to the Neighbor Solicitation with a Neighbor
Advertisement giving the home agent's own link-layer address as the Advertisement giving the home agent's own link-layer address as the
link-layer address for the specified Target Address. In addition, link-layer address for the specified Target Address. In addition,
the Router (R) bit in the Advertisement MUST be set to zero. Acting the Router (R) bit in the Advertisement MUST be set to zero. Acting
as a proxy in this way allows other nodes on the mobile node's home as a proxy in this way allows other nodes on the mobile node's home
link to resolve the mobile node's address and for the home agent to link to resolve the mobile node's address and for the home agent to
defend these addresses on the home link for Duplicate Address defend these addresses on the home link for Duplicate Address
Detection [20]. Detection [17].
10.4.2. Processing Intercepted Packets 10.4.2. Processing Intercepted Packets
For any packet sent to a mobile node from the mobile node's home For any packet sent to a mobile node from the mobile node's home
agent (in which the home agent is the original sender of the packet), agent (in which the home agent is the original sender of the packet),
the home agent is operating as a correspondent node of the mobile the home agent is operating as a correspondent node of the mobile
node for this packet and the procedures described in Section 9.3.2 node for this packet and the procedures described in Section 9.3.2
apply. The home agent then uses a routing header to route the packet apply. The home agent then uses a routing header to route the packet
to the mobile node by way of the primary care-of address in the home to the mobile node by way of the primary care-of address in the home
agent's Binding Cache. agent's Binding Cache.
While the mobile node is away from home, the home agent intercepts While the mobile node is away from home, the home agent intercepts
any packets on the home link addressed to the mobile node's home any packets on the home link addressed to the mobile node's home
address, as described in Section 10.4.1. In order to forward each address, as described in Section 10.4.1. In order to forward each
intercepted packet to the mobile node, the home agent MUST tunnel the intercepted packet to the mobile node, the home agent MUST tunnel the
packet to the mobile node using IPv6 encapsulation [9]. When a home packet to the mobile node using IPv6 encapsulation [6]. When a home
agent encapsulates an intercepted packet for forwarding to the mobile agent encapsulates an intercepted packet for forwarding to the mobile
node, the home agent sets the Source Address in the new tunnel IP node, the home agent sets the Source Address in the new tunnel IP
header to the home agent's own IP address and sets the Destination header to the home agent's own IP address and sets the Destination
Address in the tunnel IP header to the mobile node's primary care-of Address in the tunnel IP header to the mobile node's primary care-of
address. When received by the mobile node, normal processing of the address. When received by the mobile node, normal processing of the
tunnel header [9] will result in decapsulation and processing of the tunnel header [6] will result in decapsulation and processing of the
original packet by the mobile node. original packet by the mobile node.
However, packets addressed to the mobile node's link-local address However, packets addressed to the mobile node's link-local address
MUST NOT be tunneled to the mobile node. Instead, these packets MUST MUST NOT be tunneled to the mobile node. Instead, these packets MUST
be discarded and the home agent SHOULD return an ICMP Destination be discarded and the home agent SHOULD return an ICMP Destination
Unreachable, Code 3, message to the packet's Source Address (unless Unreachable, Code 3, message to the packet's Source Address (unless
this Source Address is a multicast address). this Source Address is a multicast address).
Interception and tunneling of the following multicast addressed Interception and tunneling of the following multicast addressed
packets on the home network are only done if the home agent supports packets on the home network are only done if the home agent supports
multicast group membership control messages from the mobile node as multicast group membership control messages from the mobile node as
described in the next section. Tunneling of multicast packets to a described in the next section. Tunneling of multicast packets to a
mobile node follows similar limitations to those defined above for mobile node follows similar limitations to those defined above for
unicast packets addressed to the mobile node's link-local address. unicast packets addressed to the mobile node's link-local address.
Multicast packets addressed to a multicast address with link-local Multicast packets addressed to a multicast address with link-local
scope [18], to which the mobile node is subscribed, MUST NOT be scope [15], to which the mobile node is subscribed, MUST NOT be
tunneled to the mobile node. These packets SHOULD be silently tunneled to the mobile node. These packets SHOULD be silently
discarded (after delivering to other local multicast recipients). discarded (after delivering to other local multicast recipients).
Multicast packets addressed to a multicast address with a scope Multicast packets addressed to a multicast address with a scope
larger than link-local, but smaller than global (e.g., site-local and larger than link-local, but smaller than global (e.g., site-local and
organization-local [18]), to which the mobile node is subscribed, organization-local [15]), to which the mobile node is subscribed,
SHOULD NOT be tunneled to the mobile node. Multicast packets SHOULD NOT be tunneled to the mobile node. Multicast packets
addressed with a global scope, to which the mobile node has addressed with a global scope, to which the mobile node has
successfully subscribed, MUST be tunneled to the mobile node. successfully subscribed, MUST be tunneled to the mobile node.
Before tunneling a packet to the mobile node, the home agent MUST Before tunneling a packet to the mobile node, the home agent MUST
perform any IPsec processing as indicated by the security policy data perform any IPsec processing as indicated by the security policy data
base. base.
10.4.3. Multicast Membership Control 10.4.3. Multicast Membership Control
This section is a prerequisite for the multicast data packet This section is a prerequisite for the multicast data packet
forwarding, described in the previous section. If this support is forwarding, described in the previous section. If this support is
not provided, multicast group membership control messages are not provided, multicast group membership control messages are
silently ignored. silently ignored.
In order to forward multicast data packets from the home network to In order to forward multicast data packets from the home network to
all the proper mobile nodes, the home agent SHOULD be capable of all the proper mobile nodes, the home agent SHOULD be capable of
receiving tunneled multicast group membership control information receiving tunneled multicast group membership control information
from the mobile node in order to determine which groups the mobile from the mobile node in order to determine which groups the mobile
node has subscribed to. These multicast group membership messages node has subscribed to. These multicast group membership messages
are Listener Report messages specified in MLD [11] or in other are Listener Report messages specified in MLD [8] or in other
protocols such as [41]. protocols such as [38].
The messages are issued by the mobile node, but sent through the The messages are issued by the mobile node, but sent through the
reverse tunnel to the home agent. These messages are issued whenever reverse tunnel to the home agent. These messages are issued whenever
the mobile node decides to enable reception of packets for a the mobile node decides to enable reception of packets for a
multicast group or in response to an MLD Query from the home agent. multicast group or in response to an MLD Query from the home agent.
The mobile node will also issue multicast group control messages to The mobile node will also issue multicast group control messages to
disable reception of multicast packets when it is no longer disable reception of multicast packets when it is no longer
interested in receiving multicasts for a particular group. interested in receiving multicasts for a particular group.
To obtain the mobile node's current multicast group membership the To obtain the mobile node's current multicast group membership the
skipping to change at page 103, line 8 skipping to change at page 101, line 42
section and the multicast forwarding in Section 10.4.2 are to be section and the multicast forwarding in Section 10.4.2 are to be
achieved. At the time of this writing it was thought that a full achieved. At the time of this writing it was thought that a full
IPv6 multicast router function would be necessary on the home agent, IPv6 multicast router function would be necessary on the home agent,
but it may be possible to achieve the same effects through a "proxy but it may be possible to achieve the same effects through a "proxy
MLD" application coupled with kernel multicast forwarding. This may MLD" application coupled with kernel multicast forwarding. This may
be the subject of future specifications. be the subject of future specifications.
10.4.4. Stateful Address Autoconfiguration 10.4.4. Stateful Address Autoconfiguration
This section describes how home agents support the use of stateful This section describes how home agents support the use of stateful
address autoconfiguration mechanisms such as DHCPv6 [32] from the address autoconfiguration mechanisms such as DHCPv6 [29] from the
mobile nodes. If this support is not provided, then the M and O bits mobile nodes. If this support is not provided, then the M and O bits
must remain cleared on the Mobile Prefix Advertisement Messages. Any must remain cleared on the Mobile Prefix Advertisement Messages. Any
mobile node which sends DHCPv6 messages to the home agent without mobile node which sends DHCPv6 messages to the home agent without
this support will not receive a response. this support will not receive a response.
If DHCPv6 is used, packets are sent with link-local source addresses If DHCPv6 is used, packets are sent with link-local source addresses
either to a link-scope multicast address or a link-local address. either to a link-scope multicast address or a link-local address.
Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel
standard DHCPv6 packets to the home agent. Since these link-scope standard DHCPv6 packets to the home agent. Since these link-scope
packets cannot be forwarded onto the home network, it is necessary packets cannot be forwarded onto the home network, it is necessary
skipping to change at page 103, line 35 skipping to change at page 102, line 20
flows. flows.
10.4.5. Handling Reverse Tunneled Packets 10.4.5. Handling Reverse Tunneled Packets
Unless a binding has been established between the mobile node and a Unless a binding has been established between the mobile node and a
correspondent node, traffic from the mobile node to the correspondent correspondent node, traffic from the mobile node to the correspondent
node goes through a reverse tunnel. Home agents MUST support reverse node goes through a reverse tunnel. Home agents MUST support reverse
tunneling as follows: tunneling as follows:
o The tunneled traffic arrives to the home agent's address using o The tunneled traffic arrives to the home agent's address using
IPv6 encapsulation [9]. IPv6 encapsulation [6].
o Depending on the security policies used by the home agent, reverse o Depending on the security policies used by the home agent, reverse
tunneled packets MAY be discarded unless accompanied by a valid tunneled packets MAY be discarded unless accompanied by a valid
ESP header. The support for authenticated reverse tunneling ESP header. The support for authenticated reverse tunneling
allows the home agent to protect the home network and allows the home agent to protect the home network and
correspondent nodes from malicious nodes masquerading as a mobile correspondent nodes from malicious nodes masquerading as a mobile
node. node.
o Otherwise, when a home agent decapsulates a tunneled packet from o Otherwise, when a home agent decapsulates a tunneled packet from
the mobile node, the home agent MUST verify that the Source the mobile node, the home agent MUST verify that the Source
skipping to change at page 104, line 23 skipping to change at page 103, line 9
and authentication algorithm MUST be available. It is not necessary and authentication algorithm MUST be available. It is not necessary
to distinguish between different kinds of packets during the return to distinguish between different kinds of packets during the return
routability procedure. routability procedure.
Security associations are needed to provide this protection. When Security associations are needed to provide this protection. When
the care-of address for the mobile node changes as a result of an the care-of address for the mobile node changes as a result of an
accepted Binding Update, special treatment is needed for the next accepted Binding Update, special treatment is needed for the next
packets sent using these security associations. The home agent MUST packets sent using these security associations. The home agent MUST
set the new care-of address as the destination address of these set the new care-of address as the destination address of these
packets, as if the outer header destination address in the security packets, as if the outer header destination address in the security
association had changed [15]. association had changed [12].
The above protection SHOULD be used with all mobile nodes. The use The above protection SHOULD be used with all mobile nodes. The use
is controlled by configuration of the IPsec security policy database is controlled by configuration of the IPsec security policy database
both at the mobile node and at the home agent. both at the mobile node and at the home agent.
As described earlier, the Binding Update and Binding Acknowledgement As described earlier, the Binding Update and Binding Acknowledgement
messages require protection between the home agent and the mobile messages require protection between the home agent and the mobile
node. The Mobility Header protocol carries both these messages as node. The Mobility Header protocol carries both these messages as
well as the return routability messages. From the point of view of well as the return routability messages. From the point of view of
the security policy database these messages are indistinguishable. the security policy database these messages are indistinguishable.
When IPsec is used to protect return routability signaling or payload When IPsec is used to protect return routability signaling or payload
packets, this protection MUST only be applied to the return packets, this protection MUST only be applied to the return
routability packets entering the IPv6 encapsulated tunnel interface routability packets entering the IPv6 encapsulated tunnel interface
between the mobile node and the home agent. This can be achieved, between the mobile node and the home agent. This can be achieved,
for instance, by defining the security policy database entries for instance, by defining the security policy database entries
specifically for the tunnel interface. That is, the policy entries specifically for the tunnel interface. That is, the policy entries
are not generally applied on all traffic on the physical interface(s) are not generally applied on all traffic on the physical interface(s)
of the nodes, but rather only on traffic that enters the tunnel. of the nodes, but rather only on traffic that enters the tunnel.
This makes use of per-interface security policy database entries [2] This makes use of per-interface security policy database entries [2]
specific to the tunnel interface (the node's attachment to the tunnel specific to the tunnel interface (the node's attachment to the tunnel
[8]). [5]).
10.5. Dynamic Home Agent Address Discovery 10.5. Dynamic Home Agent Address Discovery
This section describes an optional mechanism by which a home agent This section describes an optional mechanism by which a home agent
can help mobile nodes to discover the addresses of other home agents can help mobile nodes to discover the addresses of other home agents
on the mobile node's home network. The home agent keeps track of the on the mobile node's home network. The home agent keeps track of the
other home agents on the same link and responds to queries sent by other home agents on the same link and responds to queries sent by
the mobile node. the mobile node.
10.5.1. Receiving Router Advertisement Messages 10.5.1. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent, the For each link on which a router provides service as a home agent, the
router maintains a Home Agents List recording information about all router maintains a Home Agents List recording information about all
other home agents on that link. This list is used in the dynamic other home agents on that link. This list is used in the dynamic
home agent address discovery mechanism; the mobile node uses the list home agent address discovery mechanism; the mobile node uses the list
as described in Section 11.4.1. The information for the list is as described in Section 11.4.1. The information for the list is
learned through receipt of the periodic unsolicited multicast Router learned through receipt of the periodic unsolicited multicast Router
Advertisements, in a manner similar to the Default Router List Advertisements, in a manner similar to the Default Router List
conceptual data structure maintained by each host for Neighbor conceptual data structure maintained by each host for Neighbor
Discovery [20]. In the construction of the Home Agents List, the Discovery [17]. In the construction of the Home Agents List, the
Router Advertisements are from each (other) home agent on the link Router Advertisements are from each (other) home agent on the link
and the Home Agent (H) bit is set in them. and the Home Agent (H) bit is set in them.
On receipt of a valid Router Advertisement, as defined in the On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery [20], the home processing algorithm specified for Neighbor Discovery [17], the home
agent performs the following steps in addition to any steps already agent performs the following steps in addition to any steps already
required of it by Neighbor Discovery: required of it by Neighbor Discovery:
o If the Home Agent (H) bit in the Router Advertisement is not set, o If the Home Agent (H) bit in the Router Advertisement is not set,
delete the sending node's entry in the current Home Agents List delete the sending node's entry in the current Home Agents List
(if one exists). Skip all the following steps. (if one exists). Skip all the following steps.
o Otherwise, extract the Source Address from the IP header of the o Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [20]. link of the home agent sending this Advertisement [17].
o Determine the preference for this home agent. If the Router o Determine the preference for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the Advertisement contains a Home Agent Information Option, then the
preference is taken from the Home Agent Preference field in the preference is taken from the Home Agent Preference field in the
option; otherwise, the default preference of 0 MUST be used. option; otherwise, the default preference of 0 MUST be used.
o Determine the lifetime for this home agent. If the Router o Determine the lifetime for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the Advertisement contains a Home Agent Information Option, then the
lifetime is taken from the Home Agent Lifetime field in the lifetime is taken from the Home Agent Lifetime field in the
option; otherwise, the lifetime specified by the Router Lifetime option; otherwise, the lifetime specified by the Router Lifetime
skipping to change at page 106, line 27 skipping to change at page 105, line 14
such global addresses to the list of global addresses in this Home such global addresses to the list of global addresses in this Home
Agents List entry. Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for A home agent SHOULD maintain an entry in its Home Agents List for
each valid home agent address until that entry's lifetime expires, each valid home agent address until that entry's lifetime expires,
after which time the entry MUST be deleted. after which time the entry MUST be deleted.
As described in Section 11.4.1, a mobile node attempts dynamic home As described in Section 11.4.1, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the Mobile IPv6 Home-Agents anycast Discovery Request message to the Mobile IPv6 Home-Agents anycast
address [10] for its home IP subnet prefix. A home agent receiving a address [7] for its home IP subnet prefix. A home agent receiving a
Home Agent Address Discovery Request message that serves this subnet Home Agent Address Discovery Request message that serves this subnet
SHOULD return an ICMP Home Agent Address Discovery Reply message to SHOULD return an ICMP Home Agent Address Discovery Reply message to
the mobile node with the Source Address of the Reply packet set to the mobile node with the Source Address of the Reply packet set to
one of the global unicast addresses of the home agent. The Home one of the global unicast addresses of the home agent. The Home
Agent Addresses field in the Reply message is constructed as follows: Agent Addresses field in the Reply message is constructed as follows:
o The Home Agent Addresses field SHOULD contain all global IP o The Home Agent Addresses field SHOULD contain all global IP
addresses for each home agent currently listed in this home addresses for each home agent currently listed in this home
agent's own Home Agents List (Section 10.1). agent's own Home Agents List (Section 10.1).
skipping to change at page 107, line 6 skipping to change at page 105, line 42
o Among home agents with equal preference, their IP addresses in the o Among home agents with equal preference, their IP addresses in the
Home Agent Addresses field SHOULD be listed in an order randomized Home Agent Addresses field SHOULD be listed in an order randomized
with respect to other home agents with equal preference every time with respect to other home agents with equal preference every time
a Home Agent Address Discovery Reply message is returned by this a Home Agent Address Discovery Reply message is returned by this
home agent. home agent.
o If more than one global IP address is associated with a home o If more than one global IP address is associated with a home
agent, these addresses SHOULD be listed in a randomized order. agent, these addresses SHOULD be listed in a randomized order.
o The home agent SHOULD reduce the number of home agent IP addresses o The home agent SHOULD reduce the number of home agent IP addresses
so that the packet fits within the minimum IPv6 MTU [8]. The home so that the packet fits within the minimum IPv6 MTU [5]. The home
agent addresses selected for inclusion in the packet SHOULD be agent addresses selected for inclusion in the packet SHOULD be
those from the complete list with the highest preference. This those from the complete list with the highest preference. This
limitation avoids the danger of the Reply message packet being limitation avoids the danger of the Reply message packet being
fragmented (or rejected by an intermediate router with an ICMP fragmented (or rejected by an intermediate router with an ICMP
Packet Too Big message [19]). Packet Too Big message [16]).
10.6. Sending Prefix Information to the Mobile Node 10.6. Sending Prefix Information to the Mobile Node
10.6.1. List of Home Network Prefixes 10.6.1. List of Home Network Prefixes
Mobile IPv6 arranges to propagate relevant prefix information to the Mobile IPv6 arranges to propagate relevant prefix information to the
mobile node when it is away from home, so that it may be used in mobile node when it is away from home, so that it may be used in
mobile node home address configuration and in network renumbering. mobile node home address configuration and in network renumbering.
In this mechanism, mobile nodes away from home receive Mobile Prefix In this mechanism, mobile nodes away from home receive Mobile Prefix
Advertisements messages. These messages include Prefix Information Advertisements messages. These messages include Prefix Information
skipping to change at page 107, line 34 skipping to change at page 106, line 26
If there are multiple home agents, differences in the advertisements If there are multiple home agents, differences in the advertisements
sent by different home agents can lead to an inability to use a sent by different home agents can lead to an inability to use a
particular home address when changing to another home agent. In particular home address when changing to another home agent. In
order to ensure that the mobile nodes get the same information from order to ensure that the mobile nodes get the same information from
different home agents, it is preferred that all of the home agents on different home agents, it is preferred that all of the home agents on
the same link be configured in the same manner. the same link be configured in the same manner.
To support this, the home agent monitors prefixes advertised by To support this, the home agent monitors prefixes advertised by
itself and other home agents on the home link. In Neighbor Discovery itself and other home agents on the home link. In Neighbor Discovery
(RFC 4861 [20]) it is acceptable for two routers to advertise (RFC 4861 [17]) it is acceptable for two routers to advertise
different sets of prefixes on the same link. For home agents, the different sets of prefixes on the same link. For home agents, the
differences should be detected for a given home address because the differences should be detected for a given home address because the
mobile node communicates only with one home agent at a time and the mobile node communicates only with one home agent at a time and the
mobile node needs to know the full set of prefixes assigned to the mobile node needs to know the full set of prefixes assigned to the
home link. All other comparisons of Router Advertisements are as home link. All other comparisons of Router Advertisements are as
specified in Section 6.2.7 of RFC 4861. specified in Section 6.2.7 of RFC 4861.
10.6.2. Scheduling Prefix Deliveries 10.6.2. Scheduling Prefix Deliveries
A home agent serving a mobile node will schedule the delivery of the A home agent serving a mobile node will schedule the delivery of the
skipping to change at page 113, line 46 skipping to change at page 112, line 46
relying on Mobile IPv6. If application running on the mobile node relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile within this general type of communication, however, the mobile
node should not use its care-of address as the source of the node should not use its care-of address as the source of the
packet in this way. packet in this way.
The choice of the most efficient communications method is The choice of the most efficient communications method is
application specific, and outside the scope of this specification. application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of The APIs necessary for controlling the choice are also out of
scope. One example of such an API is described in the IPv6 Socket scope. One example of such an API is described in the IPv6 Socket
API for Source Address Selection specification [24]. API for Source Address Selection specification [21].
o While not at its home link, the mobile node MUST NOT use the Home o While not at its home link, the mobile node MUST NOT use the Home
Address destination option when communicating with link-local Address destination option when communicating with link-local
peers. peers.
Similarly, the mobile node MUST NOT use the Home Address Similarly, the mobile node MUST NOT use the Home Address
destination option for IPv6 Neighbor Discovery [20] packets. destination option for IPv6 Neighbor Discovery [17] packets.
Detailed operation of these cases is described later in this section Detailed operation of these cases is described later in this section
and also discussed in [34]. and also discussed in [31].
For packets sent by a mobile node while it is at home, no special For packets sent by a mobile node while it is at home, no special
Mobile IPv6 processing is required. Likewise, if the mobile node Mobile IPv6 processing is required. Likewise, if the mobile node
uses any address other than one of its home addresses as the source uses any address other than one of its home addresses as the source
of a packet sent while away from home, no special Mobile IPv6 of a packet sent while away from home, no special Mobile IPv6
processing is required. In either case, the packet is simply processing is required. In either case, the packet is simply
addressed and transmitted in the same way as any normal IPv6 packet. addressed and transmitted in the same way as any normal IPv6 packet.
For packets sent by the mobile node sent while away from home using For packets sent by the mobile node sent while away from home using
the mobile node's home address as the source, special Mobile IPv6 the mobile node's home address as the source, special Mobile IPv6
skipping to change at page 115, line 35 skipping to change at page 114, line 35
* Change the Source Address field in the packet's IPv6 header to * Change the Source Address field in the packet's IPv6 header to
one of the mobile node's care-of addresses. This will one of the mobile node's care-of addresses. This will
typically be the mobile node's current primary care-of address, typically be the mobile node's current primary care-of address,
but MUST be an address assigned to the interface on the link but MUST be an address assigned to the interface on the link
being used. being used.
By using the care-of address as the Source Address in the IPv6 By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through any Address option, the packet will be able to safely pass through any
router implementing ingress filtering [30]. router implementing ingress filtering [27].
Reverse Tunneling Reverse Tunneling
This is the mechanism which tunnels the packets via the home This is the mechanism which tunnels the packets via the home
agent. It is not as efficient as the above mechanism, but is agent. It is not as efficient as the above mechanism, but is
needed if there is no binding yet with the correspondent node. needed if there is no binding yet with the correspondent node.
This mechanism is used for packets that have the mobile node's This mechanism is used for packets that have the mobile node's
home address as the Source Address in the IPv6 header, or with home address as the Source Address in the IPv6 header, or with
multicast control protocol packets as described in Section 11.3.4. multicast control protocol packets as described in Section 11.3.4.
Specifically: Specifically:
* The packet is sent to the home agent using IPv6 encapsulation * The packet is sent to the home agent using IPv6 encapsulation
[9]. [6].
* The Source Address in the tunnel packet is the primary care-of * The Source Address in the tunnel packet is the primary care-of
address as registered with the home agent. address as registered with the home agent.
* The Destination Address in the tunnel packet is the home * The Destination Address in the tunnel packet is the home
agent's address. agent's address.
Then, the home agent will pass the encapsulated packet to the Then, the home agent will pass the encapsulated packet to the
correspondent node. correspondent node.
skipping to change at page 117, line 44 skipping to change at page 116, line 44
However, such an exchange is not required, as long as the result However, such an exchange is not required, as long as the result
of the authentication calculation remains the same. of the authentication calculation remains the same.
When an automated key management protocol is used to create new When an automated key management protocol is used to create new
security associations for a peer, it is important to ensure that the security associations for a peer, it is important to ensure that the
peer can send the key management protocol packets to the mobile node. peer can send the key management protocol packets to the mobile node.
This may not be possible if the peer is the home agent of the mobile This may not be possible if the peer is the home agent of the mobile
node and the purpose of the security associations would be to send a node and the purpose of the security associations would be to send a
Binding Update to the home agent. Packets addressed to the home Binding Update to the home agent. Packets addressed to the home
address of the mobile node cannot be used before the Binding Update address of the mobile node cannot be used before the Binding Update
has been processed. For the default case of using IKE [7] as the has been processed. For the default case of using IKEv2 [41] as the
automated key management protocol, such problems can be avoided by automated key management protocol, such problems can be avoided by
the following requirements when communicating with its home agent: the following requirements when communicating with its home agent:
o When the mobile node is away from home, it MUST use its care-of o When the mobile node is away from home, it MUST use its care-of
address as the Source Address of all packets it sends as part of address as the Source Address of all packets it sends as part of
the key management protocol (without use of Mobile IPv6 for these the key management protocol (without use of Mobile IPv6 for these
packets, as suggested in Section 11.3.1). packets, as suggested in Section 11.3.1).
o In addition, for all security associations bound to the mobile
node's home address established by IKE, the mobile node MUST
include an ISAKMP Identification Payload [6] in the IKE phase 2
exchange, giving the mobile node's home address as the initiator
of the Security Association [5].
The Key Management Mobility Capability (K) bit in Binding Updates and The Key Management Mobility Capability (K) bit in Binding Updates and
Acknowledgements can be used to avoid the need to rerun IKE upon Acknowledgements can be used to avoid the need to rerun IKEv2 upon
movements. movements.
11.3.3. Receiving Packets While Away from Home 11.3.3. Receiving Packets While Away from Home
While away from home, a mobile node will receive packets addressed to While away from home, a mobile node will receive packets addressed to
its home address, by one of two methods: its home address, by one of two methods:
o Packets sent by a correspondent node, that does not have a Binding o Packets sent by a correspondent node, that does not have a Binding
Cache entry for the mobile node, will be sent to the home address, Cache entry for the mobile node, will be sent to the home address,
captured by the home agent and tunneled to the mobile node. captured by the home agent and tunneled to the mobile node.
skipping to change at page 118, line 40 skipping to change at page 117, line 34
processing of this last hop of the routing header is entirely processing of this last hop of the routing header is entirely
internal to the mobile node, since the care-of address and home internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node. address are both addresses within the mobile node.
For packets received by the first method, the mobile node MUST check For packets received by the first method, the mobile node MUST check
that the IPv6 source address of the tunneled packet is the IP address that the IPv6 source address of the tunneled packet is the IP address
of its home agent. In this method, the mobile node may also send a of its home agent. In this method, the mobile node may also send a
Binding Update to the original sender of the packet as described in Binding Update to the original sender of the packet as described in
Section 11.7.2 and subject to the rate limiting defined in Section 11.7.2 and subject to the rate limiting defined in
Section 11.8. The mobile node MUST also process the received packet Section 11.8. The mobile node MUST also process the received packet
in the manner defined for IPv6 encapsulation [9], which will result in the manner defined for IPv6 encapsulation [6], which will result
in the encapsulated (inner) packet being processed normally by upper- in the encapsulated (inner) packet being processed normally by upper-
layer protocols within the mobile node as if it had been addressed layer protocols within the mobile node as if it had been addressed
(only) to the mobile node's home address. (only) to the mobile node's home address.
For packets received by the second method, the following rules will For packets received by the second method, the following rules will
result in the packet being processed normally by upper-layer result in the packet being processed normally by upper-layer
protocols within the mobile node as if it had been addressed to the protocols within the mobile node as if it had been addressed to the
mobile node's home address. mobile node's home address.
A node receiving a packet addressed to itself (i.e., one of the A node receiving a packet addressed to itself (i.e., one of the
skipping to change at page 119, line 49 skipping to change at page 118, line 44
same way as any other (stationary) node. Thus, when it is at home, a same way as any other (stationary) node. Thus, when it is at home, a
mobile node functions identically to other multicast senders and mobile node functions identically to other multicast senders and
receivers. Therefore, this section describes the behavior of a receivers. Therefore, this section describes the behavior of a
mobile node that is not on its home link. mobile node that is not on its home link.
In order to receive packets sent to some multicast group, a mobile In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method, in which a mobile node must join that multicast group. One method, in which a mobile
node MAY join the group, is via a (local) multicast router on the node MAY join the group, is via a (local) multicast router on the
foreign link being visited. In this case, the mobile node MUST use foreign link being visited. In this case, the mobile node MUST use
its care-of address and MUST NOT use the Home Address destination its care-of address and MUST NOT use the Home Address destination
option when sending MLD packets [11]. option when sending MLD packets [8].
Alternatively, a mobile node MAY join multicast groups via a bi- Alternatively, a mobile node MAY join multicast groups via a bi-
directional tunnel to its home agent. The mobile node tunnels its directional tunnel to its home agent. The mobile node tunnels its
multicast group membership control packets (such as those defined in multicast group membership control packets (such as those defined in
[11] or in [41]) to its home agent, and the home agent forwards [8] or in [38]) to its home agent, and the home agent forwards
multicast packets down the tunnel to the mobile node. A mobile node multicast packets down the tunnel to the mobile node. A mobile node
MUST NOT tunnel multicast group membership control packets until (1) MUST NOT tunnel multicast group membership control packets until (1)
the mobile node has a binding in place at the home agent, and (2) the the mobile node has a binding in place at the home agent, and (2) the
latter sends at least one multicast group membership control packet latter sends at least one multicast group membership control packet
via the tunnel. Once this condition is true, the mobile node SHOULD via the tunnel. Once this condition is true, the mobile node SHOULD
assume it does not change as long as the binding does not expire. assume it does not change as long as the binding does not expire.
A mobile node that wishes to send packets to a multicast group also A mobile node that wishes to send packets to a multicast group also
has two options: has two options:
1. Send directly on the foreign link being visited. 1. Send directly on the foreign link being visited.
To do this, the application uses the care-of address as a source To do this, the application uses the care-of address as a source
address for multicast traffic, just as it would use a stationary address for multicast traffic, just as it would use a stationary
address. This requires that the application either knows the address. This requires that the application either knows the
care-of address, or uses an API such as the IPv6 Socket API for care-of address, or uses an API such as the IPv6 Socket API for
Source Address Selection specification [24] to request that the Source Address Selection specification [21] to request that the
care-of address be used as the source address in transmitted care-of address be used as the source address in transmitted
packets. The mobile node MUST NOT use Home Address destination packets. The mobile node MUST NOT use Home Address destination
option in such traffic. option in such traffic.
2. Send via a tunnel to its home agent. 2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST use node that tunnels a multicast packet to its home agent MUST use
its home address as the IPv6 Source Address of the inner its home address as the IPv6 Source Address of the inner
skipping to change at page 122, line 44 skipping to change at page 121, line 38
in Section 11.7.1, the mobile node may not know the address of any in Section 11.7.1, the mobile node may not know the address of any
router on its home link that can serve as a home agent for it. For router on its home link that can serve as a home agent for it. For
example, some nodes on its home link may have been reconfigured while example, some nodes on its home link may have been reconfigured while
the mobile node has been away from home, such that the router that the mobile node has been away from home, such that the router that
was operating as the mobile node's home agent has been replaced by a was operating as the mobile node's home agent has been replaced by a
different router serving this role. different router serving this role.
In this case, the mobile node MAY attempt to discover the address of In this case, the mobile node MAY attempt to discover the address of
a suitable home agent on its home link. To do so, the mobile node a suitable home agent on its home link. To do so, the mobile node
sends an ICMP Home Agent Address Discovery Request message to the sends an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address [10] for its home subnet Mobile IPv6 Home-Agents anycast address [7] for its home subnet
prefix. As described in Section 10.5, the home agent on its home prefix. As described in Section 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message. This message gives the Agent Address Discovery Reply message. This message gives the
addresses for the home agents operating on the home link. addresses for the home agents operating on the home link.
The mobile node, upon receiving this Home Agent Address Discovery The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to Reply message, MAY then send its home registration Binding Update to
any of the unicast IP addresses listed in the Home Agent Addresses any of the unicast IP addresses listed in the Home Agent Addresses
field in the Reply. For example, the mobile node MAY attempt its field in the Reply. For example, the mobile node MAY attempt its
home registration to each of these addresses, in turn, until its home registration to each of these addresses, in turn, until its
skipping to change at page 124, line 32 skipping to change at page 123, line 26
11.4.3. Receiving Mobile Prefix Advertisements 11.4.3. Receiving Mobile Prefix Advertisements
Section 10.6 describes the operation of a home agent to support boot Section 10.6 describes the operation of a home agent to support boot
time configuration and renumbering a mobile node's home subnet while time configuration and renumbering a mobile node's home subnet while
the mobile node is away from home. The home agent sends Mobile the mobile node is away from home. The home agent sends Mobile
Prefix Advertisements to the mobile node while away from home, giving Prefix Advertisements to the mobile node while away from home, giving
"important" Prefix Information options that describe changes in the "important" Prefix Information options that describe changes in the
prefixes in use on the mobile node's home link. prefixes in use on the mobile node's home link.
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 [17], 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.
When a mobile node receives a Mobile Prefix Advertisement, it MUST When a mobile node receives a Mobile Prefix Advertisement, it MUST
validate it according to the following test: validate it according to the following test:
o The Source Address of the IP packet carrying the Mobile Prefix o The Source Address of the IP packet carrying the Mobile Prefix
Advertisement is the same as the home agent address to which the Advertisement is the same as the home agent address to which the
mobile node last sent an accepted home registration Binding Update mobile node last sent an accepted home registration Binding Update
to register its primary care-of address. Otherwise, if no such to register its primary care-of address. Otherwise, if no such
skipping to change at page 125, line 21 skipping to change at page 124, line 15
Otherwise, the advertisement is unsolicited, and MUST be Otherwise, the advertisement is unsolicited, and MUST be
discarded. In this case the mobile node SHOULD send a Mobile discarded. In this case the mobile node SHOULD send a Mobile
Prefix Solicitation. Prefix Solicitation.
Any received Mobile Prefix Advertisement not meeting these tests MUST Any received Mobile Prefix Advertisement not meeting these tests MUST
be silently discarded. be silently discarded.
For an accepted Mobile Prefix Advertisement, the mobile node MUST For an accepted Mobile Prefix Advertisement, the mobile node MUST
process Managed Address Configuration (M), Other Stateful process Managed Address Configuration (M), Other Stateful
Configuration (O), and the Prefix Information Options as if they Configuration (O), and the Prefix Information Options as if they
arrived in a Router Advertisement [20] on the mobile node's home arrived in a Router Advertisement [17] on the mobile node's home
link. (This specification does not, however, describe how to acquire link. (This specification does not, however, describe how to acquire
home addresses through stateful protocols.) Such processing may home addresses through stateful protocols.) Such processing may
result in the mobile node configuring a new home address, although result in the mobile node configuring a new home address, although
due to separation between preferred lifetime and valid lifetime, such due to separation between preferred lifetime and valid lifetime, such
changes should not affect most communications by the mobile node, in changes should not affect most communications by the mobile node, in
the same way as for nodes that are at home. the same way as for nodes that are at home.
This specification assumes that any security associations and This specification assumes that any security associations and
security policy entries that may be needed for new prefixes have been security policy entries that may be needed for new prefixes have been
pre-configured in the mobile node. Note that while dynamic key pre-configured in the mobile node. Note that while dynamic key
skipping to change at page 126, line 17 skipping to change at page 125, line 10
reachable, in which case the mobile node must discover a new default reachable, in which case the mobile node must discover a new default
router (usually on a new link). However, this detection only occurs router (usually on a new link). However, this detection only occurs
when the mobile node has packets to send, and in the absence of when the mobile node has packets to send, and in the absence of
frequent Router Advertisements or indications from the link-layer, frequent Router Advertisements or indications from the link-layer,
the mobile node might become unaware of an L3 handover that occurred. the mobile node might become unaware of an L3 handover that occurred.
Therefore, the mobile node should supplement this method with other Therefore, the mobile node should supplement this method with other
information whenever it is available to the mobile node (e.g., from information whenever it is available to the mobile node (e.g., from
lower protocol layers). lower protocol layers).
When the mobile node detects an L3 handover, it performs Duplicate When the mobile node detects an L3 handover, it performs Duplicate
Address Detection [21] on its link-local address, selects a new Address Detection [18] on its link-local address, selects a new
default router as a consequence of Router Discovery, and then default router as a consequence of Router Discovery, and then
performs Prefix Discovery with that new router to form new care-of performs Prefix Discovery with that new router to form new care-of
address(es) as described in Section 11.5.3. It then registers its address(es) as described in Section 11.5.3. It then registers its
new primary care-of address with its home agent as described in new primary care-of address with its home agent as described in
Section 11.7.1. After updating its home registration, the mobile Section 11.7.1. After updating its home registration, the mobile
node then updates associated mobility bindings in correspondent nodes node then updates associated mobility bindings in correspondent nodes
that it is performing route optimization with as specified in that it is performing route optimization with as specified in
Section 11.7.2. Section 11.7.2.
Due to the temporary packet flow disruption and signaling overhead Due to the temporary packet flow disruption and signaling overhead
skipping to change at page 127, line 11 skipping to change at page 126, line 5
receive Router Advertisements with the same link-local source receive Router Advertisements with the same link-local source
address. This might be common if routers use the same link-local address. This might be common if routers use the same link-local
address on multiple interfaces. This issue can be avoided when address on multiple interfaces. This issue can be avoided when
routers use the Router Address (R) bit, since that provides a routers use the Router Address (R) bit, since that provides a
global address of the router. global address of the router.
In addition, the mobile node should consider the following events as In addition, the mobile node should consider the following events as
indications that an L3 handover may have occurred. Upon receiving indications that an L3 handover may have occurred. Upon receiving
such indications, the mobile node needs to perform Router Discovery such indications, the mobile node needs to perform Router Discovery
to discover routers and prefixes on the new link, as described in to discover routers and prefixes on the new link, as described in
Section 6.3.7 of Neighbor Discovery (RFC 4861 [20]). Section 6.3.7 of Neighbor Discovery (RFC 4861 [17]).
o If Router Advertisements that the mobile node receives include an o If Router Advertisements that the mobile node receives include an
Advertisement Interval option, the mobile node may use its Advertisement Interval option, the mobile node may use its
Advertisement Interval field as an indication of the frequency Advertisement Interval field as an indication of the frequency
with which it should expect to continue to receive future with which it should expect to continue to receive future
Advertisements from that router. This field specifies the minimum Advertisements from that router. This field specifies the minimum
rate (the maximum amount of time between successive rate (the maximum amount of time between successive
Advertisements) that the mobile node should expect. If this Advertisements) that the mobile node should expect. If this
amount of time elapses without the mobile node receiving any amount of time elapses without the mobile node receiving any
Advertisement from this router, the mobile node can be sure that Advertisement from this router, the mobile node can be sure that
skipping to change at page 128, line 19 skipping to change at page 127, line 17
When an MN detects that it has arrived on a new link using the When an MN detects that it has arrived on a new link using the
movement detection algorithm in use (Section 11.5.1,) or on movement detection algorithm in use (Section 11.5.1,) or on
bootstrapping, it performs the following steps to determine if it is bootstrapping, it performs the following steps to determine if it is
on the home link. on the home link.
o The MN performs the procedure described in Section 11.5.3 and o The MN performs the procedure described in Section 11.5.3 and
configures an address. It also keeps track of all the on-link configures an address. It also keeps track of all the on-link
prefix(es) received in the RA along with their prefix lengths. prefix(es) received in the RA along with their prefix lengths.
o If the home prefix has not been statically configured the MN uses o If the home prefix has not been statically configured the MN uses
some form of bootstrapping procedure (e.g. RFC5026 [25]) to some form of bootstrapping procedure (e.g. RFC5026 [22]) to
determine the home prefix. determine the home prefix.
o Given the availability of the home prefix, the MN checks whether o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it is connected to the home RA. If it does, the MN concludes that it is connected to the home
link. link.
11.5.3. Forming New Care-of Addresses 11.5.3. Forming New Care-of Addresses
After detecting that it has moved a mobile node SHOULD generate a new After detecting that it has moved a mobile node SHOULD generate a new
skipping to change at page 128, line 50 skipping to change at page 127, line 48
registered with its home agent), but it MAY have an additional registered with its home agent), but it MAY have an additional
care-of address for any or all of the prefixes on its current link. care-of address for any or all of the prefixes on its current link.
Furthermore, since a wireless network interface may actually allow a Furthermore, since a wireless network interface may actually allow a
mobile node to be reachable on more than one link at a time (i.e., mobile node to be reachable on more than one link at a time (i.e.,
within wireless transmitter range of routers on more than one within wireless transmitter range of routers on more than one
separate link), a mobile node MAY have care-of addresses on more than separate link), a mobile node MAY have care-of addresses on more than
one link at a time. The use of more than one care-of address at a one link at a time. The use of more than one care-of address at a
time is described in Section 11.5.4. time is described in Section 11.5.4.
As described in Section 4, in order to form a new care-of address, a As described in Section 4, in order to form a new care-of address, a
mobile node MAY use either stateless [21] or stateful (e.g., DHCPv6 mobile node MAY use either stateless [18] or stateful (e.g., DHCPv6
[32]) Address Autoconfiguration. If a mobile node needs to use a [29]) Address Autoconfiguration. If a mobile node needs to use a
source address (other than the unspecified address) in packets sent source address (other than the unspecified address) in packets sent
as a part of address autoconfiguration, it MUST use an IPv6 link- as a part of address autoconfiguration, it MUST use an IPv6 link-
local address rather than its own IPv6 home address. local address rather than its own IPv6 home address.
RFC 4862 [21] specifies that in normal processing for Duplicate RFC 4862 [18] specifies that in normal processing for Duplicate
Address Detection, the node SHOULD delay sending the initial Neighbor Address Detection, the node SHOULD delay sending the initial Neighbor
Solicitation message by a random delay between 0 and Solicitation message by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY. Since delaying DAD can result in MAX_RTR_SOLICITATION_DELAY. Since delaying DAD can result in
significant delays in configuring a new care-of address when the significant delays in configuring a new care-of address when the
Mobile Node moves to a new link, the Mobile Node preferably SHOULD Mobile Node moves to a new link, the Mobile Node preferably SHOULD
NOT delay DAD when configuring a new care-of address. The Mobile NOT delay DAD when configuring a new care-of address. The Mobile
Node SHOULD delay according to the mechanisms specified in RFC 4862 Node SHOULD delay according to the mechanisms specified in RFC 4862
unless the implementation has a behavior that desynchronizes the unless the implementation has a behavior that desynchronizes the
steps that happen before the DAD in the case that multiple nodes steps that happen before the DAD in the case that multiple nodes
experience handover at the same time. Such desynchronizing behaviors experience handover at the same time. Such desynchronizing behaviors
skipping to change at page 129, line 44 skipping to change at page 128, line 41
Acknowledge (A) bits set its home agent, as described on Acknowledge (A) bits set its home agent, as described on
Section 11.7.1. Section 11.7.1.
To assist with smooth handovers, a mobile node SHOULD retain its To assist with smooth handovers, a mobile node SHOULD retain its
previous primary care-of address as a (non-primary) care-of address, previous primary care-of address as a (non-primary) care-of address,
and SHOULD still accept packets at this address, even after and SHOULD still accept packets at this address, even after
registering its new primary care-of address with its home agent. registering its new primary care-of address with its home agent.
This is reasonable, since the mobile node could only receive packets This is reasonable, since the mobile node could only receive packets
at its previous primary care-of address if it were indeed still at its previous primary care-of address if it were indeed still
connected to that link. If the previous primary care-of address was connected to that link. If the previous primary care-of address was
allocated using stateful Address Autoconfiguration [32], the mobile allocated using stateful Address Autoconfiguration [29], the mobile
node may not wish to release the address immediately upon switching node may not wish to release the address immediately upon switching
to a new primary care-of address. to a new primary care-of address.
Whenever a mobile node determines that it is no longer reachable Whenever a mobile node determines that it is no longer reachable
through a given link, it SHOULD invalidate all care-of addresses through a given link, it SHOULD invalidate all care-of addresses
associated with address prefixes that it discovered from routers on associated with address prefixes that it discovered from routers on
the unreachable link which are not in the current set of address the unreachable link which are not in the current set of address
prefixes advertised by the (possibly new) current default router. prefixes advertised by the (possibly new) current default router.
11.5.5. Returning Home 11.5.5. Returning Home
skipping to change at page 130, line 27 skipping to change at page 129, line 26
intercept all packets sent to the mobile's home address and tunnel intercept all packets sent to the mobile's home address and tunnel
them to the previously registered care-of address. them to the previously registered care-of address.
In this home registration, the mobile node MUST set the Acknowledge In this home registration, the mobile node MUST set the Acknowledge
(A) and Home Registration (H) bits, set the Lifetime field to zero, (A) and Home Registration (H) bits, set the Lifetime field to zero,
and set the care-of address for the binding to the mobile node's own and set the care-of address for the binding to the mobile node's own
home address. The mobile node MUST use its home address as the home address. The mobile node MUST use its home address as the
source address in the Binding Update. source address in the Binding Update.
When sending this Binding Update to its home agent, the mobile node When sending this Binding Update to its home agent, the mobile node
must be careful in how it uses Neighbor Solicitation [20] (if needed) must be careful in how it uses Neighbor Solicitation [17] (if needed)
to learn the home agent's link-layer address, since the home agent to learn the home agent's link-layer address, since the home agent
will be currently configured to intercept packets to the mobile will be currently configured to intercept packets to the mobile
node's home address using Proxy Neighbor Discovery (Proxy ND). In node's home address using Proxy Neighbor Discovery (Proxy ND). In
particular, the mobile node is unable to use its home address as the particular, the mobile node is unable to use its home address as the
Source Address in the Neighbor Solicitation until the home agent Source Address in the Neighbor Solicitation until the home agent
stops defending the home address. stops defending the home address.
Neighbor Solicitation by the mobile node for the home agent's address Neighbor Solicitation by the mobile node for the home agent's address
will normally not be necessary, since the mobile node has already will normally not be necessary, since the mobile node has already
learned the home agent's link-layer address from a Source Link-Layer learned the home agent's link-layer address from a Source Link-Layer
Address option in a Router Advertisement. However, if there are Address option in a Router Advertisement. However, if there are
multiple home agents it may still be necessary to send a multiple home agents it may still be necessary to send a
solicitation. In this special case of the mobile node returning solicitation. In this special case of the mobile node returning
home, the mobile node MUST multicast the packet, and in addition set home, the mobile node MUST multicast the packet, and in addition set
the Source Address of this Neighbor Solicitation to the unspecified the Source Address of this Neighbor Solicitation to the unspecified
address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation
MUST be set to the mobile node's home address. The destination IP MUST be set to the mobile node's home address. The destination IP
address MUST be set to the Solicited-Node multicast address [18]. address MUST be set to the Solicited-Node multicast address [15].
The home agent will send a multicast Neighbor Advertisement back to The home agent will send a multicast Neighbor Advertisement back to
the mobile node with the Solicited flag (S) set to zero. In any the mobile node with the Solicited flag (S) set to zero. In any
case, the mobile node SHOULD record the information from the Source case, the mobile node SHOULD record the information from the Source
Link-Layer Address option or from the advertisement, and set the Link-Layer Address option or from the advertisement, and set the
state of the Neighbor Cache entry for the home agent to REACHABLE. state of the Neighbor Cache entry for the home agent to REACHABLE.
The mobile node then sends its Binding Update to the home agent's The mobile node then sends its Binding Update to the home agent's
link-layer address, instructing its home agent to no longer serve as link-layer address, instructing its home agent to no longer serve as
a home agent for it. By processing this Binding Update, the home a home agent for it. By processing this Binding Update, the home
agent will cease defending the mobile node's home address for agent will cease defending the mobile node's home address for
skipping to change at page 131, line 37 skipping to change at page 130, line 34
the Binding Acknowledgement from the home agent may require the Binding Acknowledgement from the home agent may require
performing Neighbor Discovery, and the mobile node may not be able to performing Neighbor Discovery, and the mobile node may not be able to
distinguish Neighbor Solicitations coming from the home agent from distinguish Neighbor Solicitations coming from the home agent from
other Neighbor Solicitations. Note that a race condition exists other Neighbor Solicitations. Note that a race condition exists
where both the mobile node and the home agent respond to the same where both the mobile node and the home agent respond to the same
solicitations sent by other nodes; this will be only temporary, solicitations sent by other nodes; this will be only temporary,
however, until the Binding Update is accepted. however, until the Binding Update is accepted.
After receiving the Binding Acknowledgement for its Binding Update to After receiving the Binding Acknowledgement for its Binding Update to
its home agent, the mobile node MUST multicast onto the home link (to its home agent, the mobile node MUST multicast onto the home link (to
the all-nodes multicast address) a Neighbor Advertisement [20], to the all-nodes multicast address) a Neighbor Advertisement [17], to
advertise the mobile node's own link-layer address for its own home advertise the mobile node's own link-layer address for its own home
address. The Target Address in this Neighbor Advertisement MUST be address. The Target Address in this Neighbor Advertisement MUST be
set to the mobile node's home address, and the Advertisement MUST set to the mobile node's home address, and the Advertisement MUST
include a Target Link-layer Address option specifying the mobile include a Target Link-layer Address option specifying the mobile
node's link-layer address. The mobile node MUST multicast such a node's link-layer address. The mobile node MUST multicast such a
Neighbor Advertisement for each of its home addresses, as defined by Neighbor Advertisement for each of its home addresses, as defined by
the current on-link prefixes, including its link-local address. The the current on-link prefixes, including its link-local address. The
Solicited Flag (S) in these Advertisements MUST NOT be set, since Solicited Flag (S) in these Advertisements MUST NOT be set, since
they were not solicited by any Neighbor Solicitation. The Override they were not solicited by any Neighbor Solicitation. The Override
Flag (O) in these Advertisements MUST be set, indicating that the Flag (O) in these Advertisements MUST be set, indicating that the
Advertisements SHOULD override any existing Neighbor Cache entries at Advertisements SHOULD override any existing Neighbor Cache entries at
any node receiving them. any node receiving them.
Since multicasting on the local link (such as Ethernet) is typically Since multicasting on the local link (such as Ethernet) is typically
not guaranteed to be reliable, the mobile node MAY retransmit these not guaranteed to be reliable, the mobile node MAY retransmit these
Neighbor Advertisements [20] up to MAX_NEIGHBOR_ADVERTISEMENT times Neighbor Advertisements [17] up to MAX_NEIGHBOR_ADVERTISEMENT times
to increase their reliability. It is still possible that some nodes to increase their reliability. It is still possible that some nodes
on the home link will not receive any of these Neighbor on the home link will not receive any of these Neighbor
Advertisements, but these nodes will eventually be able to recover Advertisements, but these nodes will eventually be able to recover
through use of Neighbor Unreachability Detection [20]. through use of Neighbor Unreachability Detection [17].
Note that the tunnel via the home agent typically stops operating at Note that the tunnel via the home agent typically stops operating at
the same time that the home registration is deleted. the same time that the home registration is deleted.
11.6. Return Routability Procedure 11.6. Return Routability Procedure
This section defines the rules that the mobile node must follow when This section defines the rules that the mobile node must follow when
performing the return routability procedure. Section 11.7.2 performing the return routability procedure. Section 11.7.2
describes the rules when the return routability procedure needs to be describes the rules when the return routability procedure needs to be
initiated. initiated.
skipping to change at page 135, line 41 skipping to change at page 134, line 38
protocol will not be able to protect care-of addresses in the IPv6 protocol will not be able to protect care-of addresses in the IPv6
header. (Mobile IPv6 implementations that know they are using header. (Mobile IPv6 implementations that know they are using
IPsec AH to protect a particular message might avoid this option. IPsec AH to protect a particular message might avoid this option.
For brevity the usage of AH is not discussed in this document.) For brevity the usage of AH is not discussed in this document.)
o If the mobile node's link-local address has the same interface o If the mobile node's link-local address has the same interface
identifier as the home address for which it is supplying a new identifier as the home address for which it is supplying a new
care-of address, then the mobile node SHOULD set the Link-Local care-of address, then the mobile node SHOULD set the Link-Local
Address Compatibility (L) bit. Address Compatibility (L) bit.
o If the home address was generated using RFC 4941 [23], then the o If the home address was generated using RFC 4941 [20], then the
link local address is unlikely to have a compatible interface link local address is unlikely to have a compatible interface
identifier. In this case, the mobile node MUST clear the Link- identifier. In this case, the mobile node MUST clear the Link-
Local Address Compatibility (L) bit. Local Address Compatibility (L) bit.
o If the IPsec security associations between the mobile node and the o If the IPsec security associations between the mobile node and the
home agent have been established dynamically, and the mobile node home agent have been established dynamically, and the mobile node
has the capability to update its endpoint in the used key has the capability to update its endpoint in the used key
management protocol to the new care-of address every time it management protocol to the new care-of address every time it
moves, the mobile node SHOULD set the Key Management Mobility moves, the mobile node SHOULD set the Key Management Mobility
Capability (K) bit in the Binding Update. Otherwise, the mobile Capability (K) bit in the Binding Update. Otherwise, the mobile
skipping to change at page 137, line 32 skipping to change at page 136, line 30
address. Therefore, the mobile node MUST treat the creation of a new address. Therefore, the mobile node MUST treat the creation of a new
binding with the home agent using an existing home address, the same binding with the home agent using an existing home address, the same
as creation of a new home address. In the unlikely event that the as creation of a new home address. In the unlikely event that the
mobile node's home address is autoconfigured as the IPv6 address of mobile node's home address is autoconfigured as the IPv6 address of
another network node on the home network, the home agent will reply another network node on the home network, the home agent will reply
to the mobile node's subsequent Binding Update with a Binding to the mobile node's subsequent Binding Update with a Binding
Acknowledgement containing a Status of 134 (Duplicate Address Acknowledgement containing a Status of 134 (Duplicate Address
Detection failed). In this case, the mobile node MUST NOT attempt to Detection failed). In this case, the mobile node MUST NOT attempt to
re-use the same home address. It SHOULD continue to register the re-use the same home address. It SHOULD continue to register the
care-of addresses for its other home addresses, if any. Mechanisms care-of addresses for its other home addresses, if any. Mechanisms
outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [25] allow outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [22] allow
mobile nodes to acquire new home addresses to replace the one for mobile nodes to acquire new home addresses to replace the one for
which Status 134 was received. which Status 134 was received.
11.7.2. Correspondent Registration 11.7.2. Correspondent Registration
When the mobile node is assured that its home address is valid, it When the mobile node is assured that its home address is valid, it
can initiate a correspondent registration with the purpose of can initiate a correspondent registration with the purpose of
allowing the correspondent node to cache the mobile node's current allowing the correspondent node to cache the mobile node's current
care-of address. This procedure consists of the return routability care-of address. This procedure consists of the return routability
procedure followed by a registration. procedure followed by a registration.
skipping to change at page 142, line 44 skipping to change at page 141, line 40
If the acknowledgement came from the home agent, the mobile node If the acknowledgement came from the home agent, the mobile node
examines the value of the Key Management Mobility Capability (K) bit. examines the value of the Key Management Mobility Capability (K) bit.
If this bit is not set, the mobile node SHOULD discard key management If this bit is not set, the mobile node SHOULD discard key management
protocol connections, if any, to the home agent. The mobile node MAY protocol connections, if any, to the home agent. The mobile node MAY
also initiate a new key management connection. also initiate a new key management connection.
If this bit is set, the mobile node SHOULD move its own endpoint in If this bit is set, the mobile node SHOULD move its own endpoint in
the key management protocol connections to the home agent, if any. the key management protocol connections to the home agent, if any.
The mobile node's new endpoint should be the new care-of address. The mobile node's new endpoint should be the new care-of address.
For an IKE phase 1 connection, this means that packets sent to this
address with the original ISAKMP cookies are accepted.
11.7.4. Receiving Binding Refresh Requests 11.7.4. Receiving Binding Refresh Requests
When a mobile node receives a packet containing a Binding Refresh When a mobile node receives a packet containing a Binding Refresh
Request message, if the mobile node has a Binding Update List entry Request message, if the mobile node has a Binding Update List entry
for the source of the Binding Refresh Request, and the mobile node for the source of the Binding Refresh Request, and the mobile node
wants to retain its binding cache entry at the correspondent node, wants to retain its binding cache entry at the correspondent node,
then the mobile node should start a return routability procedure. If then the mobile node should start a return routability procedure. If
the mobile node wants to have its binding cache entry removed, it can the mobile node wants to have its binding cache entry removed, it can
either ignore the Binding Refresh Request and wait for the binding to either ignore the Binding Refresh Request and wait for the binding to
skipping to change at page 146, line 19 skipping to change at page 145, line 19
Min: 0.03 seconds Min: 0.03 seconds
MinMobPfxAdvInterval Default: 600 seconds MinMobPfxAdvInterval Default: 600 seconds
InitialBindackTimeoutFirstReg Default: 1.5 seconds InitialBindackTimeoutFirstReg Default: 1.5 seconds
Home agents MUST allow the first three variables to be configured by Home agents MUST allow the first three variables to be configured by
system management, and mobile nodes MUST allow the last variable to system management, and mobile nodes MUST allow the last variable to
be configured by system management. be configured by system management.
The default value for InitialBindackTimeoutFirstReg has been The default value for InitialBindackTimeoutFirstReg has been
calculated as 1.5 times the default value of RetransTimer, as calculated as 1.5 times the default value of RetransTimer, as
specified in Neighbor Discovery (RFC 4861 [20]) times the default specified in Neighbor Discovery (RFC 4861 [17]) times the default
value of DupAddrDetectTransmits, as specified in Stateless Address value of DupAddrDetectTransmits, as specified in Stateless Address
Autoconfiguration (RFC 4862 [21]) Autoconfiguration (RFC 4862 [18])
The value MinDelayBetweenRAs overrides the value of the protocol The value MinDelayBetweenRAs overrides the value of the protocol
constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
(RFC 4861 [20]). This variable SHOULD be set to MinRtrAdvInterval, (RFC 4861 [17]). This variable SHOULD be set to MinRtrAdvInterval,
if MinRtrAdvInterval is less than 3 seconds. if MinRtrAdvInterval is less than 3 seconds.
14. IANA Considerations 14. IANA Considerations
This document defines a new IPv6 protocol, the Mobility Header, This document defines a new IPv6 protocol, the Mobility Header,
described in Section 6.1. This protocol has been assigned protocol described in Section 6.1. This protocol has been assigned protocol
number 135. number 135.
This document also creates a new name space "Mobility Header Type", This document also creates a new name space "Mobility Header Type",
for the MH Type field in the Mobility Header. The current message for the MH Type field in the Mobility Header. The current message
skipping to change at page 147, line 33 skipping to change at page 146, line 33
4 Care-of Test 4 Care-of Test
5 Binding Update 5 Binding Update
6 Binding Acknowledgement 6 Binding Acknowledgement
7 Binding Error 7 Binding Error
Future values of the MH Type can be allocated using Standards Action Future values of the MH Type can be allocated using Standards Action
or IESG Approval [26]. or IESG Approval [23].
Furthermore, each mobility message may contain mobility options as Furthermore, each mobility message may contain mobility options as
described in Section 6.2. This document defines a new name space described in Section 6.2. This document defines a new name space
"Mobility Option" to identify these options. The current mobility "Mobility Option" to identify these options. The current mobility
options are defined starting from Section 6.2.2 and are the options are defined starting from Section 6.2.2 and are the
following: following:
0 Pad1 0 Pad1
1 PadN 1 PadN
2 Binding Refresh Advice 2 Binding Refresh Advice
3 Alternate Care-of Address 3 Alternate Care-of Address
4 Nonce Indices 4 Nonce Indices
5 Authorization Data 5 Authorization Data
Future values of the Option Type can be allocated using Standards Future values of the Option Type can be allocated using Standards
Action or IESG Approval [26]. Action or IESG Approval [23].
Finally, this document creates a third new name space "Status Code" Finally, this document creates a third new name space "Status Code"
for the Status field in the Binding Acknowledgement message. The for the Status field in the Binding Acknowledgement message. The
current values are described in Section 6.1.8, and are the following: current values are listed in Section 6.1.8 and are the following:
0 Binding Update accepted 0 Binding Update accepted
1 Accepted but prefix discovery necessary 1 Accepted but prefix discovery necessary
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Insufficient resources 130 Insufficient resources
skipping to change at page 148, line 41 skipping to change at page 147, line 41
135 Sequence number out of window 135 Sequence number out of window
136 Expired home nonce index 136 Expired home nonce index
137 Expired care-of nonce index 137 Expired care-of nonce index
138 Expired nonces 138 Expired nonces
139 Registration type change disallowed 139 Registration type change disallowed
TBD Invalid Care-of Address
Future values of the Status field can be allocated using Standards Future values of the Status field can be allocated using Standards
Action or IESG Approval [26]. Action or IESG Approval [23].
All fields labeled "Reserved" are only to be assigned through All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval. Standards Action or IESG Approval.
This document also defines a new IPv6 destination option, the Home This document also defines a new IPv6 destination option, the Home
Address option, described in Section 6.3. This option has been Address option, described in Section 6.3. This option has been
assigned the Option Type value 0xC9. assigned the Option Type value 0xC9.
This document also defines a new IPv6 type 2 routing header, This document also defines a new IPv6 type 2 routing header,
described in Section 6.4. The value 2 has been allocated by IANA. described in Section 6.4. The value 2 has been allocated by IANA.
skipping to change at page 149, line 22 skipping to change at page 148, line 24
o The Home Agent Address Discovery Request message, described in o The Home Agent Address Discovery Request message, described in
Section 6.5; Section 6.5;
o The Home Agent Address Discovery Reply message, described in o The Home Agent Address Discovery Reply message, described in
Section 6.6; Section 6.6;
o The Mobile Prefix Solicitation, described in Section 6.7; and o The Mobile Prefix Solicitation, described in Section 6.7; and
o The Mobile Prefix Advertisement, described in Section 6.8. o The Mobile Prefix Advertisement, described in Section 6.8.
This document also defines two new Neighbor Discovery [20] options, This document also defines two new Neighbor Discovery [17] options,
which have been assigned Option Type values within the option which have been assigned Option Type values within the option
numbering space for Neighbor Discovery messages: numbering space for Neighbor Discovery messages:
o The Advertisement Interval option, described in Section 7.3; and o The Advertisement Interval option, described in Section 7.3; and
o The Home Agent Information option, described in Section 7.4. o The Home Agent Information option, described in Section 7.4.
15. Security Considerations 15. Security Considerations
15.1. Threats 15.1. Threats
skipping to change at page 150, line 52 skipping to change at page 149, line 52
Service attack. For example, the correspondent node might be a Service attack. For example, the correspondent node might be a
site that will send a high-bandwidth stream of video to anyone who 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 asks for it. Note that the use of flow-control protocols such as
TCP does not necessarily defend against this type of attack, TCP does not necessarily defend against this type of attack,
because the attacker can fake the acknowledgements. Even keeping because the attacker can fake the acknowledgements. Even keeping
TCP initial sequence numbers secret does not help, because the TCP initial sequence numbers secret does not help, because the
attacker can receive the first few segments (including the ISN) at attacker can receive the first few segments (including the ISN) at
its own address, and only then redirect the stream to the victim's its own address, and only then redirect the stream to the victim's
address. These types of attacks may also be directed to networks address. These types of attacks may also be directed to networks
instead of nodes. Further variations of this threat are described instead of nodes. Further variations of this threat are described
elsewhere [31] [36]. elsewhere [28] [33].
An attacker might also attempt to disrupt a mobile node's An attacker might also attempt to disrupt a mobile node's
communications by replaying a Binding Update that the node had communications by replaying a Binding Update that the node had
sent earlier. If the old Binding Update was accepted, packets sent earlier. If the old Binding Update was accepted, packets
destined for the mobile node would be sent to its old location as destined for the mobile node would be sent to its old location as
opposed to its current location. opposed to its current location.
A malicious mobile node associated to multiple home agents could A malicious mobile node associated to multiple home agents could
create a routing loop amongst them. This can be achieved when a create a routing loop amongst them. This can be achieved when a
mobile node binds one home address located on a first home agent mobile node binds one home address located on a first home agent
skipping to change at page 151, line 25 skipping to change at page 150, line 25
binding will force the home agents to route the same packet among binding will force the home agents to route the same packet among
each other without knowledge that a routing loop has been created. each other without knowledge that a routing loop has been created.
Such looping problem is limited to cases where a mobile node has Such looping problem is limited to cases where a mobile node has
multiple home agents and is permitted to be associated with the multiple home agents and is permitted to be associated with the
multiple home agents. For the single home agent case, a policy at multiple home agents. For the single home agent case, a policy at
the home agent would prevent the binding of one home address to the home agent would prevent the binding of one home address to
another home address hosted by the same home agent. another home address hosted by the same home agent.
The potential problems caused by such routing loops in this The potential problems caused by such routing loops in this
scenario can be substantially reduced by use of the Tunnel-Limit scenario can be substantially reduced by use of the Tunnel-Limit
Option specified in RFC 2473 [9]. Option specified in RFC 2473 [6].
In conclusion, there are Denial-of-Service, Man-in-the-Middle, In conclusion, there are Denial-of-Service, Man-in-the-Middle,
Confidentiality, and Impersonation threats against the parties Confidentiality, and Impersonation threats against the parties
involved in sending legitimate Binding Updates, the threat of involved in sending legitimate Binding Updates, the threat of
routing loops when there are multiple home agents, and Denial-of- routing loops when there are multiple home agents, and Denial-of-
Service threats against any other party. Service threats against any other party.
o Threats associated with payload packets: Payload packets exchanged o Threats associated with payload packets: Payload packets exchanged
with mobile nodes are exposed to similar threats as that of with mobile nodes are exposed to similar threats as that of
regular IPv6 traffic. However, Mobile IPv6 introduces the Home regular IPv6 traffic. However, Mobile IPv6 introduces the Home
Address destination option, a new routing header type (type 2), Address destination option, a new routing header type (type 2),
and uses tunneling headers in the payload packets. The protocol and uses tunneling headers in the payload packets. The protocol
must protect against potential new threats involving the use of must protect against potential new threats involving the use of
these mechanisms. these mechanisms.
Third parties become exposed to a reflection threat via the Home Third parties become exposed to a reflection threat via the Home
Address destination option, unless appropriate security Address destination option, unless appropriate security
precautions are followed. The Home Address destination option precautions are followed. The Home Address destination option
could be used to direct response traffic toward a node whose IP could be used to direct response traffic toward a node whose IP
address appears in the option. In this case, ingress filtering address appears in the option. In this case, ingress filtering
would not catch the forged "return address" [39] [43]. would not catch the forged "return address" [36] [40].
A similar threat exists with the tunnels between the mobile node A similar threat exists with the tunnels between the mobile node
and the home agent. An attacker might forge tunnel packets and the home agent. An attacker might forge tunnel packets
between the mobile node and the home agent, making it appear that between the mobile node and the home agent, making it appear that
the traffic is coming from the mobile node when it is not. Note the traffic is coming from the mobile node when it is not. Note
that an attacker who is able to forge tunnel packets would that an attacker who is able to forge tunnel packets would
typically also be able to forge packets that appear to come typically also be able to forge packets that appear to come
directly from the mobile node. This is not a new threat as such. directly from the mobile node. This is not a new threat as such.
However, it may make it easier for attackers to escape detection However, it may make it easier for attackers to escape detection
by avoiding ingress filtering and packet tracing mechanisms. by avoiding ingress filtering and packet tracing mechanisms.
skipping to change at page 154, line 44 skipping to change at page 153, line 44
The above mechanisms do not show that the care-of address given in The above mechanisms do not show that the care-of address given in
the Binding Update is correct. This opens the possibility for the Binding Update is correct. This opens the possibility for
Denial-of-Service attacks against third parties. However, since the Denial-of-Service attacks against third parties. However, since the
mobile node and home agent have a security association, the home mobile node and home agent have a security association, the home
agent can always identify an ill-behaving mobile node. This allows agent can always identify an ill-behaving mobile node. This allows
the home agent operator to discontinue the mobile node's service, and the home agent operator to discontinue the mobile node's service, and
possibly take further actions based on the business relationship with possibly take further actions based on the business relationship with
the mobile node's owner. the mobile node's owner.
Note that the use of a single pair of manually keyed security Note that the use of a single pair of manually keyed security
associations conflicts with the generation of a new home address [23] associations conflicts with the generation of a new home address [20]
for the mobile node, or with the adoption of a new home subnet for the mobile node, or with the adoption of a new home subnet
prefix. This is because IPsec security associations are bound to the prefix. This is because IPsec security associations are bound to the
used addresses. While certificate-based automatic keying alleviates used addresses. While certificate-based automatic keying alleviates
this problem to an extent, it is still necessary to ensure that a this problem to an extent, it is still necessary to ensure that a
given mobile node cannot send Binding Updates for the address of given mobile node cannot send Binding Updates for the address of
another mobile node. In general, this leads to the inclusion of home another mobile node. In general, this leads to the inclusion of home
addresses in certificates in the Subject AltName field. This again addresses in certificates in the Subject AltName field. This again
limits the introduction of new addresses without either manual or limits the introduction of new addresses without either manual or
automatic procedures to establish new certificates. Therefore, this automatic procedures to establish new certificates. Therefore, this
specification restricts the generation of new home addresses (for any specification restricts the generation of new home addresses (for any
reason) to those situations where a security association or reason) to those situations where a security association or
certificate for the new address already exists. certificate for the new address already exists.
Support for IKE has been specified as optional. The following should Support for IKEv2 has been specified as optional. The following
be observed about the use of manual keying: should be observed about the use of manual keying:
o As discussed above, with manually keyed IPsec, only a limited form o As discussed above, with manually keyed IPsec, only a limited form
of protection exists against replay and reordering attacks. A of protection exists against replay and reordering attacks. A
vulnerability exists if either the sequence number space is cycled vulnerability exists if either the sequence number space is cycled
through, or if the home agent reboots and forgets its sequence through, or if the home agent reboots and forgets its sequence
numbers (and uses volatile memory to store the sequence numbers). numbers (and uses volatile memory to store the sequence numbers).
Assuming the mobile node moves continuously every 10 minutes, it Assuming the mobile node moves continuously every 10 minutes, it
takes roughly 455 days before the sequence number space has been takes roughly 455 days before the sequence number space has been
cycled through. Typical movement patterns rarely reach this high cycled through. Typical movement patterns rarely reach this high
frequency today. frequency today.
o A mobile node and its home agent belong to the same domain. If o A mobile node and its home agent belong to the same domain. If
this were not the case, manual keying would not be possible [42], this were not the case, manual keying would not be possible [39],
but in Mobile IPv6 only these two parties need to know the but in Mobile IPv6 only these two parties need to know the
manually configured keys. Similarly, we note that Mobile IPv6 manually configured keys. Similarly, we note that Mobile IPv6
employs standard block ciphers in IPsec, and is not vulnerable to employs standard block ciphers in IPsec, and is not vulnerable to
problems associated with stream ciphers and manual keying. problems associated with stream ciphers and manual keying.
o It is expected that the owner of the mobile node and the o It is expected that the owner of the mobile node and the
administrator of the home agent agree on the used keys and other administrator of the home agent agree on the used keys and other
parameters with some off-line mechanism. parameters with some off-line mechanism.
The use of IKEv1 with Mobile IPv6 is documented in more detail in The use of IKEv2 with Mobile IPv6 is documented in more detail in
[15]. The following should be observed from the use of IKEv1: [42]. The following should be observed regarding the use of IKEv2:
o It is necessary to prevent a mobile node from claiming another o It is necessary to prevent a mobile node from claiming another
mobile node's home address. The home agent must verify that the mobile node's home address. The home agent must verify that the
mobile node trying to negotiate the SA for a particular home mobile node trying to negotiate the SA for a particular home
address is authorized for that home address. This implies that address is authorized for that home address. This implies that
even with the use of IKE, a policy entry needs to be configured even with the use of IKEv2, a policy entry needs to be configured
for each home address served by the home agent. for each home address served by the home agent.
It may be possible to include home addresses in the Subject It may be possible to include home addresses in the Subject
AltName field of certificate to avoid this. However, AltName field of certificate to avoid this. However,
implementations are not guaranteed to support the use of a implementations are not guaranteed to support the use of a
particular IP address (care-of address) while another address particular IP address (care-of address) while another address
(home address) appears in the certificate. In any case, even this (home address) appears in the certificate. In any case, even this
approach would require user-specific tasks in the certificate approach would require user-specific tasks in the certificate
authority. authority.
o If preshared secret authentication is used, IKEv1 main mode cannot o Due to the problems outlined in Section 11.3.2, the IKEv2 SA
be used. Aggressive mode or group preshared secrets need to be
used with corresponding security implications instead.
Note that, like many other issues, this is a general IKEv1 issue
related to the ability to use different IP addresses, and not
specifically related to Mobile IPv6. For further information, see
Section 4.4 in [15].
o Due to the problems outlined in Section 11.3.2, IKE phase 1
between the mobile node and its home agent is established using between the mobile node and its home agent is established using
the mobile node's current care-of address. This implies that when the mobile node's current care-of address. This implies that when
the mobile node moves to a new location, it may have to re- the mobile node moves to a new location, it may have to re-
establish phase 1. A Key Management Mobility Capability (K) flag establish an IKEv2 Security Association. A Key Management
is provided for implementations that can update the IKE phase 1 Mobility Capability (K) flag is provided for implementations that
endpoints without re-establishing phase 1, but the support for can update the IKEv2 endpoints without re-establishing an IKEv2
this behavior is optional. Security Association, but the support for this behavior is
optional.
o When certificates are used, IKE fragmentation can occur as
discussed in Section 7 in [15].
o Nevertheless, even if per-mobile node configuration is required o Nevertheless, even if per-mobile node configuration is required
with IKE, an important benefit of IKE is that it automates the with IKEv2, an important benefit of IKEv2 is that it automates the
negotiation of cryptographic parameters, including the SPIs, negotiation of cryptographic parameters, including the SPIs,
cryptographic algorithms, and so on. Thus, less configuration cryptographic algorithms, and so on. Thus, less configuration
information is needed. information is needed.
o The frequency of movements in some link layers or deployment o The frequency of movements in some link layers or deployment
scenarios may be high enough to make replay and reordering attacks scenarios may be high enough to make replay and reordering attacks
possible, if only manual keying is used. IKE SHOULD be used in possible, if only manual keying is used. IKEv2 SHOULD be used in
such cases. Potentially vulnerable scenarios involve continuous such cases. Potentially vulnerable scenarios involve continuous
movement through small cells, or uncontrolled alternation between movement through small cells, or uncontrolled alternation between
available network attachment points. available network attachment points.
o Similarly, in some deployment scenarios the number of mobile nodes o Similarly, in some deployment scenarios the number of mobile nodes
may be very large. In these cases, it can be necessary to use may be very large. In these cases, it can be necessary to use
automatic mechanisms to reduce the management effort in the automatic mechanisms to reduce the management effort in the
administration of cryptographic parameters, even if some per- administration of cryptographic parameters, even if some per-
mobile node configuration is always needed. IKE SHOULD also be mobile node configuration is always needed. IKEv2 SHOULD also be
used in such cases. used in such cases.
o Other automatic key management mechanisms exist beyond IKEv1, but
this document does not address the issues related to them. We
note, however, that most of the above discussion applies to IKEv2
[44] as well, at least as it is currently specified.
15.4. Binding Updates to Correspondent Nodes 15.4. Binding Updates to Correspondent Nodes
The motivation for designing the return routability procedure was to The motivation for designing the return routability procedure was to
have sufficient support for Mobile IPv6, without creating significant have sufficient support for Mobile IPv6, without creating significant
new security problems. The goal for this procedure was not to new security problems. The goal for this procedure was not to
protect against attacks that were already possible before the protect against attacks that were already possible before the
introduction of Mobile IPv6. introduction of Mobile IPv6.
The next sections will describe the security properties of the used The next sections will describe the security properties of the used
method, both from the point of view of possible on-path attackers who method, both from the point of view of possible on-path attackers who
skipping to change at page 158, line 7 skipping to change at page 156, line 37
available. available.
The resulting level of security is in theory the same even without The resulting level of security is in theory the same even without
this additional protection: the return routability tokens are this additional protection: the return routability tokens are
still exposed only to one path within the whole Internet. still exposed only to one path within the whole Internet.
However, the mobile nodes are often found on an insecure link, However, the mobile nodes are often found on an insecure link,
such as a public access Wireless LAN. Thus, in many cases, this such as a public access Wireless LAN. Thus, in many cases, this
addition makes a practical difference. addition makes a practical difference.
For further information about the design rationale of the return For further information about the design rationale of the return
routability procedure, see [31] [36] [35] [43]. The mechanisms used routability procedure, see [28] [33] [32] [40]. The mechanisms used
have been adopted from these documents. have been adopted from these documents.
15.4.2. Achieved Security Properties 15.4.2. Achieved Security Properties
The return routability procedure protects Binding Updates against all The return routability procedure protects Binding Updates against all
attackers who are unable to monitor the path between the home agent attackers who are unable to monitor the path between the home agent
and the correspondent node. The procedure does not defend against and the correspondent node. The procedure does not defend against
attackers who can monitor this path. Note that such attackers are in attackers who can monitor this path. Note that such attackers are in
any case able to mount an active attack against the mobile node when any case able to mount an active attack against the mobile node when
it is at its home location. The possibility of such attacks is not it is at its home location. The possibility of such attacks is not
skipping to change at page 160, line 24 skipping to change at page 159, line 4
limitations, attackers cannot take any practical advantages of limitations, attackers cannot take any practical advantages of
this vulnerability. this vulnerability.
o There are some other minor differences, such as an effect to the o There are some other minor differences, such as an effect to the
Denial-of-Service vulnerabilities. These can be considered to be Denial-of-Service vulnerabilities. These can be considered to be
insignificant. insignificant.
o The path between the home agent and a correspondent node is o The path between the home agent and a correspondent node is
typically easiest to attack on the links at either end, in typically easiest to attack on the links at either end, in
particular if these links are publicly accessible wireless LANs. particular if these links are publicly accessible wireless LANs.
Attacks against the routers or switches on the path are typically Attacks against the routers or switches on the path are typically
harder to accomplish. The security on layer 2 of the links plays harder to accomplish. The security on layer 2 of the links plays
then a major role in the resulting overall network security. then a major role in the resulting overall network security.
Similarly, security of IPv6 Neighbor and Router Discovery on these Similarly, security of IPv6 Neighbor and Router Discovery on these
links has a large impact. If these were secured using some new links has a large impact. If these were secured using some new
technology in the future, this could change the situation technology in the future, this could change the situation
regarding the easiest point of attack. regarding the easiest point of attack.
For a more in-depth discussion of these issues, see [43]. For a more in-depth discussion of these issues, see [40].
15.4.4. Replay Attacks 15.4.4. Replay Attacks
The return routability procedure also protects the participants The return routability procedure also protects the participants
against replayed Binding Updates. The attacker is unable replay the against replayed Binding Updates. The attacker is unable replay the
same message due to the sequence number which is a part of the same message due to the sequence number which is a part of the
Binding Update. It is also unable to modify the Binding Update since Binding Update. It is also unable to modify the Binding Update since
the MAC verification would fail after such a modification. the MAC verification would fail after such a modification.
Care must be taken when removing bindings at the correspondent node, Care must be taken when removing bindings at the correspondent node,
skipping to change at page 161, line 14 skipping to change at page 159, line 44
Binding Update arrives. This is achieved through the construct of Binding Update arrives. This is achieved through the construct of
keygen tokens from the nonces and node keys that are not specific to keygen tokens from the nonces and node keys that are not specific to
individual mobile nodes. The keygen tokens can be reconstructed by individual mobile nodes. The keygen tokens can be reconstructed by
the correspondent node, based on the home and care-of address the correspondent node, based on the home and care-of address
information that arrives with the Binding Update. This means that information that arrives with the Binding Update. This means that
the correspondent nodes are safe against memory exhaustion attacks the correspondent nodes are safe against memory exhaustion attacks
except where on-path attackers are concerned. Due to the use of except where on-path attackers are concerned. Due to the use of
symmetric cryptography, the correspondent nodes are relatively safe symmetric cryptography, the correspondent nodes are relatively safe
against CPU resource exhaustion attacks as well. against CPU resource exhaustion attacks as well.
Nevertheless, as [31] describes, there are situations in which it is Nevertheless, as [28] describes, there are situations in which it is
impossible for the mobile and correspondent nodes to determine if impossible for the mobile and correspondent nodes to determine if
they actually need a binding or whether they just have been fooled they actually need a binding or whether they just have been fooled
into believing so by an attacker. Therefore, it is necessary to into believing so by an attacker. Therefore, it is necessary to
consider situations where such attacks are being made. consider situations where such attacks are being made.
Even if route optimization is a very important optimization, it is Even if route optimization is a very important optimization, it is
still only an optimization. A mobile node can communicate with a still only an optimization. A mobile node can communicate with a
correspondent node even if the correspondent refuses to accept any correspondent node even if the correspondent refuses to accept any
Binding Updates. However, performance will suffer because packets Binding Updates. However, performance will suffer because packets
from the correspondent node to the mobile node will be routed via the from the correspondent node to the mobile node will be routed via the
skipping to change at page 163, line 17 skipping to change at page 161, line 46
dynamic home agent address discovery messages. Therefore the home dynamic home agent address discovery messages. Therefore the home
agent cannot verify the home address of the mobile node that agent cannot verify the home address of the mobile node that
requested the list of home agents. requested the list of home agents.
Apart from discovering the address(es) of home agents, attackers will Apart from discovering the address(es) of home agents, attackers will
not be able to learn much from this information, and mobile nodes not be able to learn much from this information, and mobile nodes
cannot be tricked into using wrong home agents, as all other cannot be tricked into using wrong home agents, as all other
communication with the home agents is secure. communication with the home agents is secure.
In cases where additional security is needed, one may consider In cases where additional security is needed, one may consider
instead the use of MIPv6 bootstrapping [25], (based on DNS SRV instead the use of MIPv6 bootstrapping [22], (based on DNS SRV
Resource Records [12]) in conjunction with security mechanisms Resource Records [9]) in conjunction with security mechanisms
suggested in these specifications. In that solution, security is suggested in these specifications. In that solution, security is
provided by the DNSSEC [16] framework. The needed pre-configured provided by the DNSSEC [13] framework. The needed pre-configured
data on the mobile node for this mechanism is the domain name of the data on the mobile node for this mechanism is the domain name of the
mobile service provider, which is marginally better than the home mobile service provider, which is marginally better than the home
subnet prefix. For the security, a trust anchor which dominates the subnet prefix. For the security, a trust anchor which dominates the
domain is needed. domain is needed.
15.6. Mobile Prefix Discovery 15.6. Mobile Prefix Discovery
The mobile prefix discovery function may leak interesting information The mobile prefix discovery function may leak interesting information
about network topology and prefix lifetimes to eavesdroppers; for about network topology and prefix lifetimes to eavesdroppers; for
this reason, requests for this information have to be authenticated. this reason, requests for this information have to be authenticated.
skipping to change at page 164, line 23 skipping to change at page 163, line 5
does not work if the final destination of the packet is in the home does not work if the final destination of the packet is in the home
network, and some form of perimeter defense is being applied for network, and some form of perimeter defense is being applied for
packets sent to those destinations. In such cases it is recommended packets sent to those destinations. In such cases it is recommended
that either end-to-end security or additional tunnel protection be that either end-to-end security or additional tunnel protection be
applied, as is usual in remote access situations. applied, as is usual in remote access situations.
Home agents and mobile nodes may use IPsec ESP to protect payload Home agents and mobile nodes may use IPsec ESP to protect payload
packets tunneled between themselves. This is useful for protecting packets tunneled between themselves. This is useful for protecting
communications against attackers on the path of the tunnel. communications against attackers on the path of the tunnel.
When a Unique-Local Address (ULA) RFC4193 [22] is used as a home When a Unique-Local Address (ULA) RFC4193 [19] is used as a home
address, reverse tunneling can be used to send local traffic from address, reverse tunneling can be used to send local traffic from
another location. Administrators should be aware of this when another location. Administrators should be aware of this when
allowing such home addresses. In particular, the outer IP address allowing such home addresses. In particular, the outer IP address
check described above is not sufficient against all attackers. The check described above is not sufficient against all attackers. The
use of encrypted tunnels is particularly useful for these kinds of use of encrypted tunnels is particularly useful for these kinds of
home addresses. home addresses.
15.8. Home Address Option 15.8. Home Address Option
When the mobile node sends packets directly to the correspondent When the mobile node sends packets directly to the correspondent
node, the Source Address field of the packet's IPv6 header is the node, the Source Address field of the packet's IPv6 header is the
care-of address. Therefore, ingress filtering [30] works in the care-of address. Therefore, ingress filtering [27] works in the
usual manner even for mobile nodes, as the Source Address is usual manner even for mobile nodes, as the Source Address is
topologically correct. The Home Address option is used to inform the topologically correct. The Home Address option is used to inform the
correspondent node of the mobile node's home address. correspondent node of the mobile node's home address.
However, the care-of address in the Source Address field does not However, the care-of address in the Source Address field does not
survive in replies sent by the correspondent node unless it has a survive in replies sent by the correspondent node unless it has a
binding for this mobile node. Also, not all attacker tracing binding for this mobile node. Also, not all attacker tracing
mechanisms work when packets are being reflected through mechanisms work when packets are being reflected through
correspondent nodes using the Home Address option. For these correspondent nodes using the Home Address option. For these
reasons, this specification restricts the use of the Home Address reasons, this specification restricts the use of the Home Address
skipping to change at page 166, line 9 skipping to change at page 165, line 9
This implies that a device which implements the filtering of packets This implies that a device which implements the filtering of packets
should be able to distinguish between a type 2 routing header and should be able to distinguish between a type 2 routing header and
other routing headers, as required in Section 8.3. This is necessary other routing headers, as required in Section 8.3. This is necessary
in order to allow Mobile IPv6 traffic while still having the option in order to allow Mobile IPv6 traffic while still having the option
of filtering out other uses of routing headers. of filtering out other uses of routing headers.
16. Contributors 16. Contributors
Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik
Nordmark, and Michael Thomas shaped the return routability protocols Nordmark, and Michael Thomas shaped the return routability protocols
described in [36]. described in [33].
Significant contributions were made by members of the Mobile IPv6 Significant contributions were made by members of the Mobile IPv6
Security Design Team, including (in alphabetical order) Gabriel Security Design Team, including (in alphabetical order) Gabriel
Montenegro, Erik Nordmark and Pekka Nikander. Montenegro, Erik Nordmark and Pekka Nikander.
17. Acknowledgements 17. Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working We would like to thank the members of the Mobile IP, Mobility
Groups for their comments and suggestions on this work. We would Extensions for IPv6, and IPng Working Groups for their comments and
particularly like to thank (in alphabetical order) Fred Baker, Josh suggestions on this work. We would particularly like to thank (in
Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Jean-Michel alphabetical order) Fred Baker, Josh Broch, Samita Chakrabarti,
Combes, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont, Robert Chalmers, Noel Chiappa, Jean-Michel Combes, Greg Daley, Vijay
Ashutosh Dutta, Arnaud Ebalard, Wesley Eddy, Thomas Eklund, Jun- Devarapalli, Rich Draves, Francis Dupont, Ashutosh Dutta, Arnaud
Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James Ebalard, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino, Brian
Kempf, Rajeev Koodli, Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli,
Joe Lau, Aime Le Rouzic, Jiwoong Lee, Benjamin Lim, Vesa-Matti Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Aime Le
Rouzic, Julien Laganier, Jiwoong Lee, Benjamin Lim, Vesa-Matti
Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten, Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten,
Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy, Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy,
Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru
Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts, Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts,
Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind
Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon, Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon,
Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov
Vatn, Ryuji Wakikawa, Kilian Weniger, Carl E. Williams, Vladislav Vatn, Ryuji Wakikawa, Kilian Weniger, Carl E. Williams, Vladislav
Yasevich, Alper Yegin, and Xinhua Zhao, for their detailed reviews of Yasevich, Alper Yegin, and Xinhua Zhao, for their detailed reviews of
earlier versions of this document. Their suggestions have helped to earlier versions of this document. Their suggestions have helped to
skipping to change at page 168, line 21 skipping to change at page 167, line 21
[2] Kent, S. and R. Atkinson, "Security Architecture for the [2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[5] Piper, D., "The Internet IP Security Domain of Interpretation [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
for ISAKMP", RFC 2407, November 1998.
[6] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol (ISAKMP)",
RFC 2408, November 1998.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[9] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998. Specification", RFC 2473, December 1998.
[10] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast [7] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. Addresses", RFC 2526, March 1999.
[11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[12] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [10] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
[14] National Institute of Standards and Technology, "Secure Hash [11] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[15] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[17] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[18] Hinden, R. and S. Deering, "IP Version 6 Addressing [15] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[19] Conta, A., Deering, S., and M. Gupta, "Internet Control Message [16] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006. Specification", RFC 4443, March 2006.
[20] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [17] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[21] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address [18] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
Autoconfiguration", RFC 4862, September 2007. Autoconfiguration", RFC 4862, September 2007.
[22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [19] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[23] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions [20] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941, for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007. September 2007.
[24] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket [21] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket
API for Source Address Selection", RFC 5014, September 2007. API for Source Address Selection", RFC 5014, September 2007.
[25] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [22] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
18.2. Informative References 18.2. Informative References
[27] Perkins, C., "IP Encapsulation within IP", RFC 2003, [24] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[28] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [25] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[29] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [26] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[30] Ferguson, P. and D. Senie, "Network Ingress Filtering: [27] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[31] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", [28] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses",
draft-aura-mipv6-bu-attacks-01 (work in progress), March 2002. draft-aura-mipv6-bu-attacks-01 (work in progress), March 2002.
[32] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [29] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[33] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [30] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[34] Draves, R., "Default Address Selection for Internet Protocol [31] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[35] Nordmark, E., "Securing MIPv6 BUs using return routability [32] Nordmark, E., "Securing MIPv6 BUs using return routability
(BU3WAY)", draft-nordmark-mobileip-bu3way-00 (work in (BU3WAY)", draft-nordmark-mobileip-bu3way-00 (work in
progress), November 2001. progress), November 2001.
[36] Roe, M., "Authentication of Mobile IPv6 Binding Updates and [33] Roe, M., "Authentication of Mobile IPv6 Binding Updates and
Acknowledgments", draft-roe-mobileip-updateauth-02 (work in Acknowledgments", draft-roe-mobileip-updateauth-02 (work in
progress), March 2002. progress), March 2002.
[37] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the [34] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. progress), April 2008.
[38] Savola, P., "Use of /127 Prefix Length Between Routers [35] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003. Considered Harmful", RFC 3627, September 2003.
[39] Savola, P., "Security of IPv6 Routing Header and Home Address [36] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-02 (work in Options", draft-savola-ipv6-rh-ha-security-02 (work in
progress), March 2002. progress), March 2002.
[40] Manner, J. and M. Kojo, "Mobility Related Terminology", [37] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[41] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [38] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[42] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key [39] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Management", BCP 107, RFC 4107, June 2005. Management", BCP 107, RFC 4107, June 2005.
[43] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [40] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[44] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [41] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[45] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [42] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007. April 2007.
[46] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of [43] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of
Type 0 Routing Headers in IPv6", RFC 5095, December 2007. Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
Appendix A. Future Extensions Appendix A. Future Extensions
A.1. Piggybacking A.1. Piggybacking
This document does not specify how to piggyback payload packets on This document does not specify how to piggyback payload packets on
the binding related messages. However, it is envisioned that this the binding related messages. However, it is envisioned that this
can be specified in a separate document when issues such as the can be specified in a separate document when issues such as the
interaction between piggybacking and IPsec are fully resolved (see interaction between piggybacking and IPsec are fully resolved (see
skipping to change at page 172, line 38 skipping to change at page 171, line 38
While the return routability procedure provides a good level of While the return routability procedure provides a good level of
security, there exist methods that have even higher levels of security, there exist methods that have even higher levels of
security. Secondly, as discussed in Section 15.4, future security. Secondly, as discussed in Section 15.4, future
enhancements of IPv6 security may cause a need to also improve the enhancements of IPv6 security may cause a need to also improve the
security of the return routability procedure. Using IPsec as the security of the return routability procedure. Using IPsec as the
sole method for authorizing Binding Updates to correspondent nodes is sole method for authorizing Binding Updates to correspondent nodes is
also possible. The protection of the Mobility Header for this also possible. The protection of the Mobility Header for this
purpose is easy, though one must ensure that the IPsec SA was created purpose is easy, though one must ensure that the IPsec SA was created
with appropriate authorization to use the home address referenced in with appropriate authorization to use the home address referenced in
the Binding Update. For instance, a certificate used by IKE to the Binding Update. For instance, a certificate used by IKEv2 to
create the security association might contain the home address. A create the security association might contain the home address. A
future specification may specify how this is done. future specification may specify how this is done.
A.4. Neighbor Discovery Extensions A.4. Neighbor Discovery Extensions
Future specifications may improve the efficiency of Neighbor Future specifications may improve the efficiency of Neighbor
Discovery tasks, which could be helpful for fast movements. One Discovery tasks, which could be helpful for fast movements. One
factor is currently being looked at: the delays caused by the factor is currently being looked at: the delays caused by the
Duplicate Address Detection mechanism. Currently, Duplicate Address Duplicate Address Detection mechanism. Currently, Duplicate Address
Detection needs to be performed for every new care-of address as the Detection needs to be performed for every new care-of address as the
skipping to change at page 174, line 7 skipping to change at page 173, line 7
applicable and progress independently from the Mobile IPv6 applicable and progress independently from the Mobile IPv6
specification. specification.
Future functional improvements may also be relevant for Mobile IPv6 Future functional improvements may also be relevant for Mobile IPv6
and other applications. For instance, mechanisms that would allow and other applications. For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be useful recovery from a Duplicate Address Detection collision would be useful
for link-local, care-of, and home addresses. for link-local, care-of, and home addresses.
Authors' Addresses Authors' Addresses
Charles E. Perkins
Tellabs Inc.
3590 N. 1st Street, Suite 300
San Jose CA 95134
USA
Email: charliep@computer.org
David B. Johnson David B. Johnson
Rice University Rice University
Dept. of Computer Science, MS 132 Dept. of Computer Science, MS 132
6100 Main Street 6100 Main Street
Houston TX 77005-1892 Houston TX 77005-1892
USA USA
Email: dbj@cs.rice.edu Email: dbj@cs.rice.edu
Charles E. Perkins
WiChorus Inc.
3590 N. 1st Street, Suite 300
San Jose CA 95134
USA
Email: charliep@computer.org
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
 End of changes. 212 change blocks. 
522 lines changed or deleted 453 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/