draft-ietf-mext-rfc3775bis-03.txt   draft-ietf-mext-rfc3775bis-04.txt 
IETF Mobile IP Working Group D. Johnson IETF Mobile IP Working Group D. Johnson
Internet-Draft Rice University Internet-Draft Rice University
Obsoletes: 3775 (if approved) C. Perkins (Ed.) Obsoletes: 3775 (if approved) C. Perkins (Ed.)
Expires: September 10, 2009 WiChorus Inc. Expires: January 14, 2010 WiChorus Inc.
J. Arkko J. Arkko
Ericsson Ericsson
March 9, 2009 July 13, 2009
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-03.txt draft-ietf-mext-rfc3775bis-04.txt
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. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 7 skipping to change at page 3, line 7
routed to its care-of address. The protocol enables IPv6 nodes to 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 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 address, and to then send any packets destined for the mobile node
directly to it at this care-of address. To support this operation, directly to it at this care-of address. To support this operation,
Mobile IPv6 defines a new IPv6 protocol and a new destination option. Mobile IPv6 defines a new IPv6 protocol and a new destination option.
All IPv6 nodes, whether mobile or stationary, can communicate with All IPv6 nodes, whether mobile or stationary, can communicate with
mobile nodes. mobile nodes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 10 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 11 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 13 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 12
4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 17 4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 16
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 17 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 16
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 19 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 18
4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 20 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 19
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 20 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 19
4.5. Conceptual Data Structure Terminology . . . . . . . . . . 21 4.5. Conceptual Data Structure Terminology . . . . . . . . . . 20
4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 21 4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 20
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 23 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 22
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 23 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 22
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 24 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 23
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 25 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 26 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 25
5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 26 5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 25
5.2.5. Return Routability Procedure . . . . . . . . . . . . 27 5.2.5. Return Routability Procedure . . . . . . . . . . . . 26
5.2.6. Authorizing Binding Management Messages . . . . . . . 31 5.2.6. Authorizing Binding Management Messages . . . . . . . 30
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 33 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 32
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 34 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 33
5.2.9. Handling Interruptions to Return Routability . . . . 34 5.2.9. Handling Interruptions to Return Routability . . . . 33
5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 35 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 34
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 35 5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 34
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 35 5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 34
6. New IPv6 Protocol, Message Types, and Destination Option . . 37 6. New IPv6 Protocol, Message Types, and Destination Option . . 36
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 37 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 37 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.2. Binding Refresh Request Message . . . . . . . . . . . 39 6.1.2. Binding Refresh Request Message . . . . . . . . . . . 38
6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 40 6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 39
6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 41 6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 40
6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 42 6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 41
6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 43 6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 42
6.1.7. Binding Update Message . . . . . . . . . . . . . . . 45 6.1.7. Binding Update Message . . . . . . . . . . . . . . . 44
6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 47 6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 46
6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 50 6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 49
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 51 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 50
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 53 6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 52
6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 54 6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 53
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 54 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 53
6.2.7. Binding Authorization Data . . . . . . . . . . . . . 55 6.2.7. Binding Authorization Data . . . . . . . . . . . . . 54
6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 56 6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 58 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 57
6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 59 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 58
6.5. ICMP Home Agent Address Discovery Request Message . . . . 60 6.5. ICMP Home Agent Address Discovery Request Message . . . . 59
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 61 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 60
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 62 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 61
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 64 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 63
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 67 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 66
7.1. Modified Router Advertisement Message Format . . . . . . 67 7.1. Modified Router Advertisement Message Format . . . . . . 66
7.2. Modified Prefix Information Option Format . . . . . . . . 67 7.2. Modified Prefix Information Option Format . . . . . . . . 66
7.3. New Advertisement Interval Option Format . . . . . . . . 69 7.3. New Advertisement Interval Option Format . . . . . . . . 68
7.4. New Home Agent Information Option Format . . . . . . . . 70 7.4. New Home Agent Information Option Format . . . . . . . . 69
7.5. Changes to Sending Router Advertisements . . . . . . . . 72 7.5. Changes to Sending Router Advertisements . . . . . . . . 71
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 74 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 73
8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 74 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 73
8.2. IPv6 Nodes with Support for Route Optimization . . . . . 74 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 73
8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 76 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 75
8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 76 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 75
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 78 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 77
9. Correspondent Node Operation . . . . . . . . . . . . . . . . 80 9. Correspondent Node Operation . . . . . . . . . . . . . . . . 79
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 80 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 79
9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 81 9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 80
9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 81 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 80
9.3.1. Receiving Packets with Home Address Option . . . . . 81 9.3.1. Receiving Packets with Home Address Option . . . . . 80
9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 82 9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 81
9.3.3. Sending Binding Error Messages . . . . . . . . . . . 84 9.3.3. Sending Binding Error Messages . . . . . . . . . . . 83
9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 84 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 83
9.4. Return Routability Procedure . . . . . . . . . . . . . . 85 9.4. Return Routability Procedure . . . . . . . . . . . . . . 84
9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 85 9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 84
9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 85 9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 84
9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 86 9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 85
9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 86 9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 85
9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 86 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 85
9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 86 9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 85
9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 89 9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 88
9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 89 9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 88
9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 90 9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 89
9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 91 9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 90
9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 91 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 90
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 93 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 92
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 93 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 92
10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 94 10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 93
10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 94 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 93
10.3.1. Primary Care-of Address Registration . . . . . . . . 94 10.3.1. Primary Care-of Address Registration . . . . . . . . 93
10.3.2. Primary Care-of Address De-Registration . . . . . . . 98 10.3.2. Primary Care-of Address De-Registration . . . . . . . 97
10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 99 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 99
10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 99 10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 99
10.4.2. Processing Intercepted Packets . . . . . . . . . . . 101 10.4.2. Processing Intercepted Packets . . . . . . . . . . . 100
10.4.3. Multicast Membership Control . . . . . . . . . . . . 102 10.4.3. Multicast Membership Control . . . . . . . . . . . . 101
10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 103 10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 103
10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 104 10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 103
10.4.6. Protecting Return Routability Packets . . . . . . . . 104 10.4.6. Protecting Return Routability Packets . . . . . . . . 104
10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 105 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 104
10.5.1. Receiving Router Advertisement Messages . . . . . . . 105 10.5.1. Receiving Router Advertisement Messages . . . . . . . 105
10.6. Sending Prefix Information to the Mobile Node . . . . . . 107 10.6. Sending Prefix Information to the Mobile Node . . . . . . 107
10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 107 10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 107
10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 108 10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 107
10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 110 10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 109
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 111 10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 110
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 112 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 111
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 112 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 111
11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 113 11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 112
11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 114 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 113
11.3.1. Sending Packets While Away from Home . . . . . . . . 114 11.3.1. Sending Packets While Away from Home . . . . . . . . 113
11.3.2. Interaction with Outbound IPsec Processing . . . . . 117 11.3.2. Interaction with Outbound IPsec Processing . . . . . 116
11.3.3. Receiving Packets While Away from Home . . . . . . . 119 11.3.3. Receiving Packets While Away from Home . . . . . . . 118
11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 120 11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 119
11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 122 11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 121
11.3.6. Receiving Binding Error Messages . . . . . . . . . . 122 11.3.6. Receiving Binding Error Messages . . . . . . . . . . 121
11.4. Home Agent and Prefix Management . . . . . . . . . . . . 123 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 122
11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 123 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 122
11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 124 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 123
11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 125 11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 124
11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 126 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 125
11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 126 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 125
11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 129 11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 128
11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 129 11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 128
11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 130 11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 129
11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 131 11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 130
11.6. Return Routability Procedure . . . . . . . . . . . . . . 133 11.6. Return Routability Procedure . . . . . . . . . . . . . . 132
11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 133 11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 132
11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 134 11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 133
11.6.3. Protecting Return Routability Packets . . . . . . . . 135 11.6.3. Protecting Return Routability Packets . . . . . . . . 134
11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 135 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 134
11.7.1. Sending Binding Updates to the Home Agent . . . . . . 135 11.7.1. Sending Binding Updates to the Home Agent . . . . . . 134
11.7.2. Correspondent Registration . . . . . . . . . . . . . 138 11.7.2. Correspondent Registration . . . . . . . . . . . . . 137
11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 141 11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 140
11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 143 11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 142
11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 144 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 143
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 146 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 145
13. Protocol Configuration Variables . . . . . . . . . . . . . . 147 13. Protocol Configuration Variables . . . . . . . . . . . . . . 146
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147
15. Security Considerations . . . . . . . . . . . . . . . . . . . 151 15. Security Considerations . . . . . . . . . . . . . . . . . . . 150
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 151 15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 150
15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 153 15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 152
15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 155 15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 154
15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 158 15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 157
15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 158 15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 157
15.4.2. Achieved Security Properties . . . . . . . . . . . . 159 15.4.2. Achieved Security Properties . . . . . . . . . . . . 158
15.4.3. Comparison to Regular IPv6 Communications . . . . . . 159 15.4.3. Comparison to Regular IPv6 Communications . . . . . . 158
15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 161 15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 160
15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 161 15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 160
15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 162 15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 161
15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 163 15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 162
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 164 15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 163
15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 164 15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 163
15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 165 15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 164
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 166 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 167 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 168 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168
18.1. Normative References . . . . . . . . . . . . . . . . . . 169 18.1. Normative References . . . . . . . . . . . . . . . . . . 168
18.2. Informative References . . . . . . . . . . . . . . . . . 170 18.2. Informative References . . . . . . . . . . . . . . . . . 169
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 173 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 173 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 173 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 173 A.3. New Authorization Methods . . . . . . . . . . . . . . . . 172
A.4. Dynamically Generated Home Addresses . . . . . . . . . . 173 A.4. Dynamically Generated Home Addresses . . . . . . . . . . 172
A.5. Remote Home Address Configuration . . . . . . . . . . . . 173 A.5. Remote Home Address Configuration . . . . . . . . . . . . 172
A.6. Neighbor Discovery Extensions . . . . . . . . . . . . . . 174 A.6. Neighbor Discovery Extensions . . . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175
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 [8], 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
skipping to change at page 81, line 48 skipping to change at page 80, line 48
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.
9.3.1. Receiving Packets with Home Address Option 9.3.1. Receiving Packets with Home Address Option
Packets containing a Home Address option MUST be dropped if the given Packets containing a Home Address option MUST be dropped if the given
home address is not a unicast routable address. home address is not a unicast routable address.
Mobile nodes can include a Home Address destination option in a Mobile nodes can include a Home Address destination option in a
packet if they believe the correspondent node has a Binding Cache packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. Packets containing a entry for the home address of a mobile node. If the Next Header
Home Address option MUST be dropped if there is no corresponding value of the Destination Option is one of the following: {50 (ESP),
Binding Cache entry. A corresponding Binding Cache entry MUST have 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
the same home address as appears in the Home Address destination normally. Otherwise, the packet MUST be dropped if there is no
option, and the currently registered care-of address MUST be equal to corresponding Binding Cache entry. A corresponding Binding Cache
the source address of the packet. These tests MUST NOT be done for entry MUST have the same home address as appears in the Home Address
packets that contain a Home Address option and a Binding Update. destination option, and the currently registered care-of address MUST
be equal to the source address of the packet.
If the packet is dropped due the above tests, the correspondent node If the packet is dropped due the above tests, the correspondent node
MUST send the Binding Error message as described in Section 9.3.3. MUST send the Binding Error message as described in Section 9.3.3.
The Status field in this message should be set to 1 (unknown binding The Status field in this message should be set to 1 (unknown binding
for Home Address destination option). for Home Address destination option).
The correspondent node MUST process the option in a manner consistent The correspondent node MUST process the option in a manner consistent
with exchanging the Home Address field from the Home Address option with exchanging the Home Address field from the Home Address option
into the IPv6 header and replacing the original value of the Source into the IPv6 header and replacing the original value of the Source
Address field there. After all IPv6 options have been processed, it Address field there. After all IPv6 options have been processed, it
skipping to change at page 83, line 44 skipping to change at page 82, line 46
on the packet in the form it will have on the receiver after on the packet in the form it will have on the receiver after
advancing the routing header. advancing the routing header.
Following the definition of a type 2 routing header in Section 6.4, Following the definition of a type 2 routing header in Section 6.4,
this packet will be routed to the mobile node's care-of address, this packet will be routed to the mobile node's care-of address,
where it will be delivered to the mobile node (the mobile node has where it will be delivered to the mobile node (the mobile node has
associated the care-of address with its network interface). associated the care-of address with its network interface).
Note that following the above conceptual model in an implementation Note that following the above conceptual model in an implementation
creates some additional requirements for path MTU discovery since the creates some additional requirements for path MTU discovery since the
layer that decides the packet size (e.g., TCP and applications using layer that determines the packet size (e.g., TCP and applications
UDP) needs to be aware of the size of the headers added by the IP using UDP) needs to be aware of the size of the headers added by the
layer on the sending node. IP layer on the sending node.
If, instead, the sending node has no Binding Cache entry for the If, instead, the sending node has no Binding Cache entry for the
destination address to which the packet is being sent, the sending destination address to which the packet is being sent, the sending
node simply sends the packet normally, with no routing header. If node simply sends the packet normally, with no routing header. If
the destination node is not a mobile node (or is a mobile node that the destination node is not a mobile node (or is a mobile node that
is currently at home), the packet will be delivered directly to this is currently at home), the packet will be delivered directly to this
node and processed normally by it. If, however, the destination node node and processed normally by it. If, however, the destination node
is a mobile node that is currently away from home, the packet will be is a mobile node that is currently away from home, the packet will be
intercepted by the mobile node's home agent and tunneled to the intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address. mobile node's current primary care-of address.
skipping to change at page 98, line 36 skipping to change at page 97, line 36
described in Section 10.6. described in Section 10.6.
10.3.2. Primary Care-of Address De-Registration 10.3.2. Primary Care-of Address De-Registration
A binding may need to be de-registered when the mobile node returns A binding may need to be de-registered when the mobile node returns
home or when the mobile node knows that it will not have any care-of home or when the mobile node knows that it will not have any care-of
addresses in the visited network. addresses in the visited network.
A Binding Update is validated and authorized in the manner described A Binding Update is validated and authorized in the manner described
in the previous section; note that when the mobile node de-registers in the previous section; note that when the mobile node de-registers
when it is at home, it may not include the Home Address destination when it is at home, it MAY choose to omit the Home Address
option, in which case the mobile node's home address is the source IP destination option, in which case the mobile node's home address is
address of the de-registration Binding Update. This section the source IP address of the de-registration Binding Update. This
describes the processing of a valid Binding Update that requests the section describes the processing of a valid Binding Update that
receiving node to no longer serve as its home agent, de-registering requests the receiving node to no longer serve as its home agent, de-
its primary care-of address. registering its primary care-of address.
To begin processing the Binding Update, the home agent MUST perform To begin processing the Binding Update, the home agent MUST perform
the following test: the following test:
o If the receiving node has no entry marked as a home registration o If the receiving node has no entry marked as a home registration
in its Binding Cache for this mobile node, then this node MUST in its Binding Cache for this mobile node, then this node MUST
reject the Binding Update and SHOULD return a Binding reject the Binding Update and SHOULD return a Binding
Acknowledgement to the mobile node, in which the Status field is Acknowledgement to the mobile node, in which the Status field is
set to 133 (not home agent for this mobile node). set to 133 (not home agent for this mobile node).
If the home agent does not reject the Binding Update as described If the home agent does not reject the Binding Update as described
above, then it MUST delete any existing entry in its Binding Cache above, then the home agent MUST return a Binding Acknowledgement to
for this mobile node. Then, the home agent MUST return a Binding the mobile node, constructed as follows:
Acknowledgement to the mobile node, constructed as follows:
o The Status field MUST be set to a value 0, indicating success. o The Status field MUST be set to a value 0, indicating success.
o The Key Management Mobility Capability (K) bit is set or cleared o The Key Management Mobility Capability (K) bit is set or cleared
and actions based on its value are performed as described in the and actions based on its value are performed as described in the
previous section. The mobile node's home address is used as its previous section. The mobile node's home address is used as its
new care-of address for the purposes of moving the key management new care-of address for the purposes of moving the key management
connection to a new endpoint. connection to a new endpoint.
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 zero. o The Lifetime field MUST be set to zero.
o The Binding Refresh Advice mobility option MUST be omitted. o The Binding Refresh Advice mobility option MUST be omitted.
In addition, the home agent MUST stop intercepting packets on the
mobile node's home link that are addressed to the mobile node
(Section 10.4.1).
The rules for selecting the Destination IP address (and, if required, The rules for selecting the Destination IP address (and, if required,
routing header construction) for the Binding Acknowledgement to the routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in the previous section. When the Status mobile node are the same as in the previous section. When the Status
field in the Binding Acknowledgement is greater than or equal to 128 field in the Binding Acknowledgement is greater than or equal to 128
and the Source Address of the Binding Update is on the home link, the and the Source Address of the Binding Update is on the home link, the
home agent MUST send it to the mobile node's link layer address home agent MUST send it to the mobile node's link layer address
(retrieved either from the Binding Update or through Neighbor (retrieved either from the Binding Update or through Neighbor
Solicitation). Solicitation).
When a mobile node sends a binding update to refresh the binding from
the visited link and soon after moves to the home link and sends a
de-registration binding update, a race condition can happen if the
first binding update gets delayed. The delayed binding update can
cause the home agent to create a new binding cache entry for a mobile
node that had just attached to the home link and successfully deleted
the binding. This would prevent the mobile node from using its home
address from the home link.
In order to prevent this, the home agent SHOULD NOT remove the
binding cache entry immediately after receiving the deregistration
binding update from the mobile node. It SHOULD mark the binding
cache entry as invalid, and MUST stop intercepting packets on the
mobile node's home link that are addressed to the mobile node
(Section Section 10.4.1). The home agent should wait for
MAX_DELETE_BCE_TIMEOUT (Section Section 12) seconds before removing
the binding cache entry completely. In the scenario described above,
if the home agent receives the delayed binding update that the mobile
node sent from the visited link, it would reject the message since
the sequence number would be less than the last received
deregistration binding update from the home link. The home agent
would then send a Binding Acknowledgment with status '135' (Sequence
number out of window) to the care of address on the visited link.
The mobile node can continue using the home address from the home
link.
10.4. Packet Processing 10.4. Packet Processing
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 mobile node it MUST While a node is serving as the home agent for mobile node it MUST
attempt to intercept packets on the mobile node's home link that are 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 multicast onto the home link a Neighbor Advertisement message MUST multicast onto the home link a Neighbor Advertisement message
skipping to change at page 122, line 48 skipping to change at page 121, line 48
When a mobile node receives a packet containing a Binding Error When a mobile node receives a packet containing a Binding Error
message, it should first check if the mobile node has a Binding message, it should first check if the mobile node has a Binding
Update List entry for the source of the Binding Error message. If Update List entry for the source of the Binding Error message. If
the mobile node does not have such an entry, it MUST ignore the the mobile node does not have such an entry, it MUST ignore the
message. This is necessary to prevent a waste of resources on, e.g., message. This is necessary to prevent a waste of resources on, e.g.,
return routability procedure due to spoofed Binding Error messages. return routability procedure due to spoofed Binding Error messages.
Otherwise, if the message Status field was 1 (unknown binding for Otherwise, if the message Status field was 1 (unknown binding for
Home Address destination option), the mobile node should perform one Home Address destination option), the mobile node should perform one
of the following two actions: of the following three actions:
o If the Binding Error Message was sent by the Home Agent, the
Mobile Node SHOULD send a Binding Update to the Home Agent
according to Section Section 11.7.1.
o If the mobile node has recent upper layer progress information, o If the mobile node has recent upper layer progress information,
which indicates that communications with the correspondent node which indicates that communications with the correspondent node
are progressing, it MAY ignore the message. This can be done in are progressing, it MAY ignore the message. This can be done in
order to limit the damage that spoofed Binding Error messages can order to limit the damage that spoofed Binding Error messages can
cause to ongoing communications. cause to ongoing communications.
o If the mobile node has no upper layer progress information, it o If the mobile node has no upper layer progress information, it
MUST remove the entry and route further communications through the MUST remove the entry and route further communications through the
home agent. It MAY also optionally start a return routability home agent. It MAY also optionally start a return routability
skipping to change at page 135, line 44 skipping to change at page 134, line 44
packets, the mobile node MUST set the source address it uses for the packets, the mobile node MUST set the source address it uses for the
outgoing tunnel packets to the current primary care-of address. The outgoing tunnel packets to the current primary care-of address. The
mobile node starts to use a new primary care-of address immediately mobile node starts to use a new primary care-of address immediately
after sending a Binding Update to the home agent to register this new after sending a Binding Update to the home agent to register this new
address. address.
11.7. Processing Bindings 11.7. Processing Bindings
11.7.1. Sending Binding Updates to the Home Agent 11.7.1. Sending Binding Updates to the Home Agent
After deciding to change its primary care-of address as described in In order to change its primary care-of address as described in
Section 11.5.1 and Section 11.5.3, a mobile node MUST register this Section 11.5.1 and Section 11.5.3, a mobile node MUST register this
care-of address with its home agent in order to make this its primary care-of address with its home agent in order to make this its primary
care-of address. care-of address.
Also, if the mobile node wants the services of the home agent beyond Also, if the mobile node wants the services of the home agent beyond
the current registration period, the mobile node should send a new the current registration period, the mobile node should send a new
Binding Update to it well before the expiration of this period, even Binding Update to it well before the expiration of this period, even
if it is not changing its primary care-of address. However, if the if it is not changing its primary care-of address. However, if the
home agent returned a Binding Acknowledgement for the current home agent returned a Binding Acknowledgement for the current
registration with Status field set to 1 (accepted but prefix registration with Status field set to 1 (accepted but prefix
skipping to change at page 146, line 12 skipping to change at page 145, line 12
Update. Retransmitted Home Test Init and Care-of Test Init messages Update. Retransmitted Home Test Init and Care-of Test Init messages
MUST use new cookie values. MUST use new cookie values.
12. Protocol Constants 12. Protocol Constants
DHAAD_RETRIES 4 retransmissions DHAAD_RETRIES 4 retransmissions
INITIAL_BINDACK_TIMEOUT 1 second INITIAL_BINDACK_TIMEOUT 1 second
INITIAL_DHAAD_TIMEOUT 3 seconds INITIAL_DHAAD_TIMEOUT 3 seconds
INITIAL_SOLICIT_TIMER 3 seconds INITIAL_SOLICIT_TIMER 3 seconds
MAX_BINDACK_TIMEOUT 32 seconds MAX_BINDACK_TIMEOUT 32 seconds
MAX_DELETE_BCE_TIMEOUT 10 seconds
MAX_NONCE_LIFETIME 240 seconds MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds MAX_TOKEN_LIFETIME 210 seconds
MAX_RO_FAILURE 3 retries MAX_RO_FAILURE 3 retries
MAX_RR_BINDING_LIFETIME 420 seconds MAX_RR_BINDING_LIFETIME 420 seconds
MAX_UPDATE_RATE 3 times MAX_UPDATE_RATE 3 times
PREFIX_ADV_RETRIES 3 retransmissions PREFIX_ADV_RETRIES 3 retransmissions
PREFIX_ADV_TIMEOUT 3 seconds PREFIX_ADV_TIMEOUT 3 seconds
13. Protocol Configuration Variables 13. Protocol Configuration Variables
skipping to change at page 162, line 36 skipping to change at page 161, line 36
node can protect itself against some of these resource exhaustion node can protect itself against some of these resource exhaustion
attacks as follows. If the correspondent node is flooded with a attacks as follows. If the correspondent node is flooded with a
large number of Binding Updates that fail the cryptographic integrity large number of Binding Updates that fail the cryptographic integrity
checks, it can stop processing Binding Updates. If a correspondent checks, it can stop processing Binding Updates. If a correspondent
node finds that it is spending more resources on checking bogus node finds that it is spending more resources on checking bogus
Binding Updates than it is likely to save by accepting genuine Binding Updates than it is likely to save by accepting genuine
Binding Updates, then it may silently discard some or all Binding Binding Updates, then it may silently discard some or all Binding
Updates without performing any cryptographic operations. Updates without performing any cryptographic operations.
Layers above IP can usually provide additional information to help Layers above IP can usually provide additional information to help
decide if there is a need to establish a binding with a specific determine whether there is a need to establish a binding with a
peer. For example, TCP knows if the node has a queue of data that it specific peer. For example, TCP knows if the node has a queue of
is trying to send to a peer. An implementation of this specification data that it is trying to send to a peer. An implementation of this
is not required to make use of information from higher protocol specification is not required to make use of information from higher
layers, but some implementations are likely to be able to manage protocol layers, but some implementations are likely to be able to
resources more effectively by making use of such information. manage resources more effectively by making use of such information.
We also require that all implementations be capable of We also require that all implementations be capable of
administratively disabling route optimization. administratively disabling route optimization.
15.4.6. Key Lengths 15.4.6. Key Lengths
Attackers can try to break the return routability procedure in many Attackers can try to break the return routability procedure in many
ways. Section 15.4.2 discusses the situation where the attacker can ways. Section 15.4.2 discusses the situation where the attacker can
see the cryptographic values sent in the clear, and Section 15.4.3 see the cryptographic values sent in the clear, and Section 15.4.3
discusses the impact this has on IPv6 communications. This section discusses the impact this has on IPv6 communications. This section
skipping to change at page 168, line 10 skipping to change at page 167, line 10
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 and IPng Working
Groups for their comments and suggestions on this work. We would Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) Fred Baker, Josh particularly like to thank (in alphabetical order) Fred Baker, Josh
Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Greg Daley, Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Jean-Michel
Vijay Devarapalli, Rich Draves, Francis Dupont, Wesley Eddy, Thomas Combes, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont,
Eklund, Jun-Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ashutosh Dutta, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino,
Ioannidis, James Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton, Brian Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli,
Joe Lau, Jiwoong Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Jiwoong Lee,
Miles, Glenn Morrow, Thomas Narten, Karen Nielsen, Simon Nybroe, Benjamin Lim, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn
Morrow, Ahmad Muhanna, Thomas Narten, Karen Nielsen, Simon Nybroe,
David Oran, Brett Pentland, Lars Henrik Petander, Basavaraj Patil, David Oran, Brett Pentland, Lars Henrik Petander, Basavaraj Patil,
Mohan Parthasarathy, Alexandru Petrescu, Mattias Petterson, Ken Mohan Parthasarathy, Alexandru Petrescu, Mattias Petterson, Ken
Powell, Phil Roberts, Ed Remmell, Patrice Romand, Luis A. Sanchez, Powell, Phil Roberts, Ed Remmell, Patrice Romand, Luis A. Sanchez,
Jeff Schiller, Pekka Savola, Arvind Sevalkar, Keiichi Shima, Tom Jeff Schiller, Pekka Savola, Arvind Sevalkar, Keiichi Shima, Tom
Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler,
Benny Van Houdt, Jon-Olov Vatn, Carl E. Williams, Vladislav Yasevich, Pascal Thubert, Benny Van Houdt, Jon-Olov Vatn, Ryuji Wakikawa,
Alper Yegin, and Xinhua Zhao, for their detailed reviews of earlier Kilian Weniger, Carl E. Williams, Vladislav Yasevich, Alper Yegin,
versions of this document. Their suggestions have helped to improve and Xinhua Zhao, for their detailed reviews of earlier versions of
both the design and presentation of the protocol. this document. Their suggestions have helped to improve both the
design and presentation of the protocol.
We would also like to thank the participants of the Mobile IPv6 We would also like to thank the participants of the Mobile IPv6
testing event (1999), implementors who participated in Mobile IPv6 testing event (1999), implementors who participated in Mobile IPv6
interoperability testing at Connectathons (2000, 2001, 2002, and interoperability testing at Connectathons (2000, 2001, 2002, and
2003), and the participants at the ETSI interoperability testing 2003), and the participants at the ETSI interoperability testing
(2000, 2002). Finally, we would like to thank the TAHI project who (2000, 2002). Finally, we would like to thank the TAHI project who
has provided test suites for Mobile IPv6. has provided test suites for Mobile IPv6.
18. References 18. References
 End of changes. 22 change blocks. 
216 lines changed or deleted 235 lines changed or added

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