draft-ietf-mext-rfc3775bis-02.txt   draft-ietf-mext-rfc3775bis-03.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: April 4, 2009 WiChorus Inc. Expires: September 10, 2009 WiChorus Inc.
J. Arkko J. Arkko
Ericsson Ericsson
October 1, 2008 March 9, 2009
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-02.txt draft-ietf-mext-rfc3775bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 4, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
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. Each mobile node reachable while moving around in the IPv6 Internet. Each mobile node
is always identified by its home address, regardless of its current is always identified by its home address, regardless of its current
point of attachment to the Internet. While situated away from its point of attachment to the Internet. While situated away from its
home, a mobile node is also associated with a care-of address, which home, a mobile node is also associated with a care-of address, which
provides information about the mobile node's current location. IPv6 provides information about the mobile node's current location. IPv6
packets addressed to a mobile node's home address are transparently packets addressed to a mobile node's home address are transparently
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 . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 9 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 10
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 10 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 12 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 13
4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 16 4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 17
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 16 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 17
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 18 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 19
4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 19 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 20
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 19 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 20
4.5. Conceptual Data Structure Terminology . . . . . . . . . . 19 4.5. Conceptual Data Structure Terminology . . . . . . . . . . 21
4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 20 4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 21
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 21 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 23
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 21 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 23
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 22 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 24
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 24 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 26
5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 24 5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 26
5.2.5. Return Routability Procedure . . . . . . . . . . . . 25 5.2.5. Return Routability Procedure . . . . . . . . . . . . 27
5.2.6. Authorizing Binding Management Messages . . . . . . . 29 5.2.6. Authorizing Binding Management Messages . . . . . . . 31
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 31 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 33
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 32 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 34
5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 32 5.2.9. Handling Interruptions to Return Routability . . . . 34
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 32 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 35
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 33 5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 35
6. New IPv6 Protocol, Message Types, and Destination Option . . 34 5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 35
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 34 6. New IPv6 Protocol, Message Types, and Destination Option . . 37
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 37
6.1.2. Binding Refresh Request Message . . . . . . . . . . . 36 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 37 6.1.2. Binding Refresh Request Message . . . . . . . . . . . 39
6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 38 6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 40
6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 39 6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 41
6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 40 6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 42
6.1.7. Binding Update Message . . . . . . . . . . . . . . . 42 6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 43
6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 44 6.1.7. Binding Update Message . . . . . . . . . . . . . . . 45
6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 47 6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 47
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 48 6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 50
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 49 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 51
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 50 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 51 6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 53
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 51 6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 54
6.2.7. Binding Authorization Data . . . . . . . . . . . . . 52 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 54
6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 53 6.2.7. Binding Authorization Data . . . . . . . . . . . . . 55
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 55 6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 56
6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 56 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 58
6.5. ICMP Home Agent Address Discovery Request Message . . . . 57 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 59
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 58 6.5. ICMP Home Agent Address Discovery Request Message . . . . 60
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 59 6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 61
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 61 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 62
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 64 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 64
7.1. Modified Router Advertisement Message Format . . . . . . 64 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 67
7.2. Modified Prefix Information Option Format . . . . . . . . 64 7.1. Modified Router Advertisement Message Format . . . . . . 67
7.3. New Advertisement Interval Option Format . . . . . . . . 66 7.2. Modified Prefix Information Option Format . . . . . . . . 67
7.4. New Home Agent Information Option Format . . . . . . . . 67 7.3. New Advertisement Interval Option Format . . . . . . . . 69
7.5. Changes to Sending Router Advertisements . . . . . . . . 69 7.4. New Home Agent Information Option Format . . . . . . . . 70
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 71 7.5. Changes to Sending Router Advertisements . . . . . . . . 72
8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 71 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 74
8.2. IPv6 Nodes with Support for Route Optimization . . . . . 71 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 74
8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 73 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 74
8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 73 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 76
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 75 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 76
9. Correspondent Node Operation . . . . . . . . . . . . . . . . 77 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 78
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 77 9. Correspondent Node Operation . . . . . . . . . . . . . . . . 80
9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 78 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 80
9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 78 9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 81
9.3.1. Receiving Packets with Home Address Option . . . . . 78 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 81
9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 79 9.3.1. Receiving Packets with Home Address Option . . . . . 81
9.3.3. Sending Binding Error Messages . . . . . . . . . . . 81 9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 82
9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 81 9.3.3. Sending Binding Error Messages . . . . . . . . . . . 84
9.4. Return Routability Procedure . . . . . . . . . . . . . . 82 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 84
9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 82 9.4. Return Routability Procedure . . . . . . . . . . . . . . 85
9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 82 9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 85
9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 83 9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 85
9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 83 9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 86
9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 83 9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 86
9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 83 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 86
9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 86 9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 86
9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 86 9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 89
9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 87 9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 89
9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 88 9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 90
9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 88 9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 91
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 90 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 91
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 90 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 93
10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 91 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 93
10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 91 10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 94
10.3.1. Primary Care-of Address Registration . . . . . . . . 91 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 94
10.3.2. Primary Care-of Address De-Registration . . . . . . . 95 10.3.1. Primary Care-of Address Registration . . . . . . . . 94
10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 96 10.3.2. Primary Care-of Address De-Registration . . . . . . . 98
10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 96 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 99
10.4.2. Processing Intercepted Packets . . . . . . . . . . . 98 10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 99
10.4.3. Multicast Membership Control . . . . . . . . . . . . 99 10.4.2. Processing Intercepted Packets . . . . . . . . . . . 101
10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 100 10.4.3. Multicast Membership Control . . . . . . . . . . . . 102
10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 101 10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 103
10.4.6. Protecting Return Routability Packets . . . . . . . . 101 10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 104
10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 102 10.4.6. Protecting Return Routability Packets . . . . . . . . 104
10.5.1. Receiving Router Advertisement Messages . . . . . . . 102 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 105
10.6. Sending Prefix Information to the Mobile Node . . . . . . 104 10.5.1. Receiving Router Advertisement Messages . . . . . . . 105
10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 104 10.6. Sending Prefix Information to the Mobile Node . . . . . . 107
10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 105 10.6.1. List of Home Network Prefixes . . . . . . . . . . . . 107
10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 107 10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 108
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 108 10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 110
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 109 10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 111
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 109 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 112
11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 110 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 112
11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 111 11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 113
11.3.1. Sending Packets While Away from Home . . . . . . . . 111 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 114
11.3.2. Interaction with Outbound IPsec Processing . . . . . 114 11.3.1. Sending Packets While Away from Home . . . . . . . . 114
11.3.3. Receiving Packets While Away from Home . . . . . . . 116 11.3.2. Interaction with Outbound IPsec Processing . . . . . 117
11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 117 11.3.3. Receiving Packets While Away from Home . . . . . . . 119
11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 119 11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 120
11.3.6. Receiving Binding Error Messages . . . . . . . . . . 119 11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 122
11.4. Home Agent and Prefix Management . . . . . . . . . . . . 120 11.3.6. Receiving Binding Error Messages . . . . . . . . . . 122
11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 120 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 123
11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 121 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 123
11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 122 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 124
11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 123 11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 125
11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 123 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 126
11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 125 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 126
11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 126 11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 129
11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 127 11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 129
11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 127 11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 130
11.6. Return Routability Procedure . . . . . . . . . . . . . . 129 11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 131
11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 129 11.6. Return Routability Procedure . . . . . . . . . . . . . . 133
11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 130 11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 133
11.6.3. Protecting Return Routability Packets . . . . . . . . 132 11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 134
11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 132 11.6.3. Protecting Return Routability Packets . . . . . . . . 135
11.7.1. Sending Binding Updates to the Home Agent . . . . . . 132 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 135
11.7.2. Correspondent Registration . . . . . . . . . . . . . 135 11.7.1. Sending Binding Updates to the Home Agent . . . . . . 135
11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 138 11.7.2. Correspondent Registration . . . . . . . . . . . . . 138
11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 140 11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 141
11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 141 11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 143
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 143 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 144
13. Protocol Configuration Variables . . . . . . . . . . . . . . 144 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 146
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 13. Protocol Configuration Variables . . . . . . . . . . . . . . 147
15. Security Considerations . . . . . . . . . . . . . . . . . . . 148 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 148 15. Security Considerations . . . . . . . . . . . . . . . . . . . 151
15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 150 15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 151
15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 151 15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 153
15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 154 15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 155
15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 154 15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 158
15.4.2. Achieved Security Properties . . . . . . . . . . . . 155 15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 158
15.4.3. Comparison to Regular IPv6 Communications . . . . . . 156 15.4.2. Achieved Security Properties . . . . . . . . . . . . 159
15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 158 15.4.3. Comparison to Regular IPv6 Communications . . . . . . 159
15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 158 15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 161
15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 159 15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 161
15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 160 15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 162
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 161 15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 163
15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 161 15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 164
15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 162 15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 164
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 162 15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 164 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 166
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 165 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 167
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 168
18.1. Normative References . . . . . . . . . . . . . . . . . . 166 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 169
18.2. Informative References . . . . . . . . . . . . . . . . . 167 18.1. Normative References . . . . . . . . . . . . . . . . . . 169
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 170 18.2. Informative References . . . . . . . . . . . . . . . . . 170
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 170 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 173
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 170 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 173
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 170 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 173
A.4. Dynamically Generated Home Addresses . . . . . . . . . . 170 A.3. New Authorization Methods . . . . . . . . . . . . . . . . 173
A.5. Remote Home Address Configuration . . . . . . . . . . . . 170 A.4. Dynamically Generated Home Addresses . . . . . . . . . . 173
A.6. Neighbor Discovery Extensions . . . . . . . . . . . . . . 171 A.5. Remote Home Address Configuration . . . . . . . . . . . . 173
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173 A.6. Neighbor Discovery Extensions . . . . . . . . . . . . . . 174
Intellectual Property and Copyright Statements . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 176
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 18, line 5 skipping to change at page 19, line 5
limited support for the reconfiguration of the home network. In limited support for the reconfiguration of the home network. In
these cases, the mobile node may not know the IP address of its own these cases, the mobile node may not know the IP address of its own
home agent, and even the home subnet prefixes may change over time. home agent, and even the home subnet prefixes may change over time.
A mechanism, known as "dynamic home agent address discovery" allows a A mechanism, known as "dynamic home agent address discovery" allows a
mobile node to dynamically discover the IP address of a home agent on mobile node to dynamically discover the IP address of a home agent on
its home link, even when the mobile node is away from home. Mobile its home link, even when the mobile node is away from home. Mobile
nodes can also learn new information about home subnet prefixes nodes can also learn new information about home subnet prefixes
through the "mobile prefix discovery" mechanism. These mechanisms through the "mobile prefix discovery" mechanism. These mechanisms
are described starting from Section 6.5. are described starting from Section 6.5.
This document assumes that the mobile node is configured with the This document is written under the assumption that the mobile node is
home prefix for the mobile node to be able to discover a home agent configured with the home prefix for the mobile node to be able to
and configure a home address. This might be limiting in deployments discover a home agent and configure a home address. This might be
where the home agent and the home address for the mobile node needs limiting in deployments where the home agent and the home address for
to be assigned dynamically. Additional mechanisms have been the mobile node needs to be assigned dynamically. Additional
specified for the mobile node to dynamically configure a home agent, mechanisms have been specified for the mobile node to dynamically
a home address and the home prefix. These mechanisms are described configure a home agent, a home address and the home prefix. These
in "Mobile IPv6 Bootstrapping in Split Scenario" [25] and "MIP6 mechanisms are described in "Mobile IPv6 Bootstrapping in Split
bootstrapping for the Integrated Scenario" [37]. Scenario" [25] and "MIP6 bootstrapping for the Integrated Scenario"
[37].
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 32, line 42 skipping to change at page 34, line 42
correspondent node, however. Correspondent nodes must retain correspondent node, however. Correspondent nodes must retain
bindings and the associated sequence number information at least as bindings and the associated sequence number information at least as
long as the nonces used in the authorization of the binding are still long as the nonces used in the authorization of the binding are still
valid. Alternatively, if memory is very constrained, the valid. Alternatively, if memory is very constrained, the
correspondent node MAY invalidate the nonces that were used for the correspondent node MAY invalidate the nonces that were used for the
binding being deleted (or some larger group of nonces that they binding being deleted (or some larger group of nonces that they
belong to). This may, however, impact the ability to accept Binding belong to). This may, however, impact the ability to accept Binding
Updates from mobile nodes that have recently received keygen tokens. Updates from mobile nodes that have recently received keygen tokens.
This alternative is therefore recommended only as a last measure. This alternative is therefore recommended only as a last measure.
5.2.9. Handling Interruptions to Return Routability
In some scenarios, such as simultaneous mobility, where both
correspondent host and mobile host move at the same time, or in the
case where the correspondent node reboots and loses data, route
optimization may not complete, or relevant data in the binding cache
might be lost.
o Return Routability signalling MUST be sent to the correspondent
node's home address if it has one (i.e. not to the correspondent
nodes care-of address if the correspondent node is also mobile).
o If Return Routability signalling timed out after MAX_RO_FAILURE
attempts, the mobile node MUST revert to sending packets to the
correspondent node's home address through its home agent.
The mobile node may run the bidirectional tunnelling in parallel with
the return routability procedure until it is successful. Exponential
backoff SHOULD be used for retransmission of return routability
messages.
The return routability procedure may be triggered by movement of the
mobile node or by sustained loss of end-to-end communication with a
correspondent node (e.g. based on indications from upper-layers) that
has been using a route optimised connection to the mobile node. If
such indications are received, the mobile node MAY revert to bi-
directional tunnelling while re-starting the return routability
procedure.
5.3. Dynamic Home Agent Address Discovery 5.3. Dynamic Home Agent Address Discovery
No security is required for dynamic home agent address discovery. No security is required for dynamic home agent address discovery.
5.4. Mobile Prefix Discovery 5.4. Mobile Prefix Discovery
The mobile node and the home agent SHOULD use an IPsec security The mobile node and the home agent SHOULD use an IPsec security
association to protect the integrity and authenticity of the Mobile association to protect the integrity and authenticity of the Mobile
Prefix Solicitations and Advertisements. Both the mobile nodes and Prefix Solicitations and Advertisements. Both the mobile nodes and
the home agents MUST support and SHOULD use the Encapsulating the home agents MUST support and SHOULD use the Encapsulating
skipping to change at page 85, line 24 skipping to change at page 88, line 24
registration type change, or expired nonce index values, MUST be registration type change, or expired nonce index values, MUST be
silently discarded. silently discarded.
If the Binding Update is valid according to the tests above, then the If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows: Binding Update is processed further as follows:
o The Sequence Number value received from a mobile node in a Binding o The Sequence Number value received from a mobile node in a Binding
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 nonzero and the o If the Lifetime specified in the Binding Update is zero, then this
specified care-of address is not equal to the home address for the is a request to delete the cached binding for the home address.
binding, then this is a request to cache a binding for the home If the Home Registration (H) bit is set in the Binding Update, the
address. If the Home Registration (H) bit is set in the Binding Binding Update is processed according to the procedure specified
Update, the Binding Update is processed according to the procedure in Section 10.3.1; otherwise, it is processed according to the
specified in Section 10.3.1; otherwise, it is processed according procedure specified in Section 9.5.2.
to the 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 or the
specified care-of address matches the home address for the specified care-of address matches the home address for the
binding, then this is a request to delete the cached binding for binding, then this is a request to delete the cached binding for
the home address. In this case, the Binding Update MUST include a the home address. In this case, the Binding Update MUST include a
valid home nonce index, and the care-of nonce index MUST be valid home nonce index, and the care-of nonce index MUST be
ignored by the correspondent node. The generation of the binding ignored by the correspondent node. The generation of the binding
management key depends then exclusively on the home keygen token management key depends then exclusively on the home keygen token
(Section 5.2.5). If the Home Registration (H) bit is set in the (Section 5.2.5). If the Home Registration (H) bit is set in the
Binding Update, the Binding Update is processed according to the Binding Update, the Binding Update is processed according to the
skipping to change at page 102, line 26 skipping to change at page 105, line 26
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]). [8]).
10.5. Dynamic Home Agent Address Discovery 10.5. Dynamic Home Agent Address Discovery
This section describes how a home agent can help mobile nodes to This section describes an optional mechanism by which a home agent
discover the addresses of the home agents. The home agent keeps can help mobile nodes to discover the addresses of other home agents
track of the other home agents on the same link and responds to on the mobile node's home network. The home agent keeps track of the
queries sent by the mobile node. other home agents on the same link and responds to queries sent by
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, described in Section 10.5. home agent address discovery mechanism; the mobile node uses the list
The information for the list is learned through receipt of the as described in Section 11.4.1. The information for the list is
periodic unsolicited multicast Router Advertisements, in a manner learned through receipt of the periodic unsolicited multicast Router
similar to the Default Router List conceptual data structure Advertisements, in a manner similar to the Default Router List
maintained by each host for Neighbor Discovery [20]. In the conceptual data structure maintained by each host for Neighbor
construction of the Home Agents List, the Router Advertisements are Discovery [20]. In the construction of the Home Agents List, the
from each (other) home agent on the link and the Home Agent (H) bit Router Advertisements are from each (other) home agent on the link
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 [20], 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.
skipping to change at page 121, line 11 skipping to change at page 124, line 11
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
registration is accepted. The mobile node sends a Binding Update to registration is accepted. The mobile node sends a Binding Update to
an address and waits for the matching Binding Acknowledgement, moving an address and waits for the matching Binding Acknowledgement, moving
on to the next address if there is no response. The mobile node on to the next address if there is no response. The mobile node
MUST, however, wait at least InitialBindackTimeoutFirstReg seconds MUST, however, wait at least InitialBindackTimeoutFirstReg seconds
(see Section 13) before sending a Binding Update to the next home (see Section 13) before sending a Binding Update to the next home
agent. In trying each of the returned home agent addresses, the agent. In trying each of the returned home agent addresses, the
mobile node SHOULD try each of them in the order they appear in the mobile node SHOULD try each of them in the order they appear in the
Home Agent Addresses field in the received Home Agent Address Home Agent Addresses field in the received Home Agent Address
Discovery Reply message. Discovery Reply message. In order to do this, the mobile node SHOULD
store the list of home agents for later use in case the home agent
currently managing the mobile node's care-of address forwarding
should become unavailable. The list MAY be stored, along with any
available lifetime information for the home agent addresses, in
nonvolatile memory to survive reboots by the mobile node.
If the mobile node has a current registration with some home agent If the mobile node has a current registration with some home agent
(the Lifetime for that registration has not yet expired), then the (the Lifetime for that registration has not yet expired), then the
mobile node MUST attempt any new registration first with that home mobile node MUST attempt any new registration first with that home
agent. If that registration attempt fails (e.g., timed out or agent. If that registration attempt fails (e.g., timed out or
rejected), the mobile node SHOULD then reattempt this registration rejected), the mobile node SHOULD then reattempt this registration
with another home agent. If the mobile node knows of no other with another home agent. If the mobile node knows of no other
suitable home agent, then it MAY attempt the dynamic home agent suitable home agent, then it MAY attempt the dynamic home agent
address discovery mechanism described above. address discovery mechanism described above.
skipping to change at page 127, line 44 skipping to change at page 131, line 8
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
A mobile node detects that it has returned to its home link through A mobile node detects that it has returned to its home link through
the movement detection algorithm in use (Section 11.5.2). The mobile the movement detection algorithm in use (Section 11.5.2), when the
node SHOULD then send a Binding Update to its home agent, to instruct mobile node detects that its home subnet prefix is again on-link. To
its home agent to no longer intercept or tunnel packets for it. In be able to send and receive packets using its home address from the
this home registration, the mobile node MUST set the Acknowledge (A) home link, the mobile node MUST send a Binding Update to its home
and Home Registration (H) bits, set the Lifetime field to zero, and agent to instruct its home agent to no longer intercept or tunnel
set the care-of address for the binding to the mobile node's own home packets for it. Until the mobile node sends such a de-registration
address. The mobile node MUST use its home address as the source Binding Update, it MUST NOT attempt to send and receive packets using
address in the Binding Update. its home address from the home link. The home agent will continue to
intercept all packets sent to the mobile's home address and tunnel to
the previously registered care-of address.
In this home registration, the mobile node MUST set the Acknowledge
(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
home address. The mobile node MUST use its home address as the
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 [20] (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 Duplicate Address Detection (DAD). In node's home address using Duplicate Address Detection (DAD). 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.
skipping to change at page 143, line 14 skipping to change at page 146, line 14
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_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_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
MaxMobPfxAdvInterval Default: 86,400 seconds MaxMobPfxAdvInterval Default: 86,400 seconds
MinDelayBetweenRAs Default: 3 seconds, MinDelayBetweenRAs Default: 3 seconds,
Min: 0.03 seconds Min: 0.03 seconds
skipping to change at page 149, line 11 skipping to change at page 152, line 11
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 [31] [36].
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
create a routing loop amongst them. This can be achieved when a
mobile node binds one home address located on a first home agent
to another home address on a second home agent. This type of
binding will force the home agents to route the same packet among
each other without knowledge that a routing loop has been created.
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. For the single home agent case, a policy at
the home agent would prevent the binding of one home address to
another home address hosted by the same home agent.
The potential problems caused by such routing loops in this
scenario can be substantially reduced by use of the Tunnel-Limit
Option specified in RFC 2473 [9].
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, and Denial-of- involved in sending legitimate Binding Updates, the threat 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.
skipping to change at page 165, line 11 skipping to change at page 168, line 11
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, Greg Daley,
Vijay Devarapalli, Rich Draves, Francis Dupont, Thomas Eklund, Jun- Vijay Devarapalli, Rich Draves, Francis Dupont, Wesley Eddy, Thomas
Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James Eklund, Jun-Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John
Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton, Joe Lau, Jiwoong Ioannidis, James Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton,
Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn Morrow, Joe Lau, Jiwoong Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin
Thomas Narten, Karen Nielsen, Simon Nybroe, David Oran, Brett Miles, Glenn Morrow, Thomas Narten, Karen Nielsen, Simon Nybroe,
Pentland, Lars Henrik Petander, Basavaraj Patil, Mohan Parthasarathy, David Oran, Brett Pentland, Lars Henrik Petander, Basavaraj Patil,
Alexandru Petrescu, Mattias Petterson, Ken Powell, Phil Roberts, Ed Mohan Parthasarathy, Alexandru Petrescu, Mattias Petterson, Ken
Remmell, Patrice Romand, Luis A. Sanchez, Jeff Schiller, Pekka Powell, Phil Roberts, Ed Remmell, Patrice Romand, Luis A. Sanchez,
Savola, Arvind Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Jeff Schiller, Pekka Savola, Arvind Sevalkar, Keiichi Shima, Tom
Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Benny Van Houdt, Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler,
Jon-Olov Vatn, Carl E. Williams, Vladislav Yasevich, Alper Yegin, and Benny Van Houdt, Jon-Olov Vatn, Carl E. Williams, Vladislav Yasevich,
Xinhua Zhao, for their detailed reviews of earlier versions of this Alper Yegin, and Xinhua Zhao, for their detailed reviews of earlier
document. Their suggestions have helped to improve both the design versions of this document. Their suggestions have helped to improve
and presentation of the protocol. 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
skipping to change at page 174, line 4 skipping to change at line 7760
USA USA
Email: charliep@computer.org 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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 18 change blocks. 
227 lines changed or deleted 307 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/