draft-ietf-mext-rfc3775bis-12.txt   draft-ietf-mext-rfc3775bis-13.txt 
IETF Mobile IP Working Group C. Perkins (Ed.) IETF Mobile IP Working Group C. Perkins (Ed.)
Internet-Draft Tellabs Inc. Internet-Draft Tellabs Inc.
Obsoletes: 3775 (if approved) D. Johnson Obsoletes: 3775 (if approved) D. Johnson
Intended status: Standards Track Rice University Intended status: Standards Track Rice University
Expires: August 12, 2011 J. Arkko Expires: September 12, 2011 J. Arkko
Ericsson Ericsson
Feb 08, 2011 Mar 11, 2011
Mobility Support in IPv6 Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-12.txt draft-ietf-mext-rfc3775bis-13.txt
Abstract Abstract
This document specifies Mobile IPv6, a protocol which allows nodes to This document specifies Mobile IPv6, a protocol which allows nodes to
remain reachable while moving around in the IPv6 Internet. Each remain reachable while moving around in the IPv6 Internet. Each
mobile node is always identified by its home address, regardless of mobile node is always identified by its home address, regardless of
its current point of attachment to the Internet. While situated away its current point of attachment to the Internet. While situated away
from its home, a mobile node is also associated with a care-of from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current address, which provides information about the mobile node's current
location. IPv6 packets addressed to a mobile node's home address are location. IPv6 packets addressed to a mobile node's home address are
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2011. This Internet-Draft will expire on September 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 9 2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 10 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . 10
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . . 12 3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . . . 12
4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 16 4. Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . 16
4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 16 4.1. Basic Operation . . . . . . . . . . . . . . . . . . . . 16
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . . 18 4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . . . 18
4.3. New IPv6 Destination Option . . . . . . . . . . . . . . . 19 4.3. New IPv6 Destination Option . . . . . . . . . . . . . . 19
4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 19 4.4. New IPv6 ICMP Messages . . . . . . . . . . . . . . . . . 19
4.5. Conceptual Data Structure Terminology . . . . . . . . . . 20 4.5. Conceptual Data Structure Terminology . . . . . . . . . 20
4.6. Unique-Local Addressability . . . . . . . . . . . . . . . 20 4.6. Unique-Local Addressability . . . . . . . . . . . . . . 20
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 22 5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . . 22
5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 22 5.1. Binding Updates to Home Agents . . . . . . . . . . . . . 22
5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 23 5.2. Binding Updates to Correspondent Nodes . . . . . . . . . 23
5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. Node Keys . . . . . . . . . . . . . . . . . . . . . . 23
5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 24 5.2.3. Cookies and Tokens . . . . . . . . . . . . . . . . . 24
5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 25 5.2.4. Cryptographic Functions . . . . . . . . . . . . . . . 25
5.2.5. Return Routability Procedure . . . . . . . . . . . . 25 5.2.5. Return Routability Procedure . . . . . . . . . . . . 25
5.2.6. Authorizing Binding Management Messages . . . . . . . 30 5.2.6. Authorizing Binding Management Messages . . . . . . . 30
5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 32 5.2.7. Updating Node Keys and Nonces . . . . . . . . . . . . 32
5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 33 5.2.8. Preventing Replay Attacks . . . . . . . . . . . . . . 33
5.2.9. Handling Interruptions to Return Routability . . . . 33 5.2.9. Handling Interruptions to Return Routability . . . . 33
5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 34 5.3. Dynamic Home Agent Address Discovery . . . . . . . . . . 34
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 34 5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . . . 34
5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . . 34 5.5. Payload Packets . . . . . . . . . . . . . . . . . . . . 34
6. New IPv6 Protocol, Message Types, and Destination Option . . 36 6. New IPv6 Protocol, Message Types, and Destination Option . . 36
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 36 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Format . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.2. Binding Refresh Request Message . . . . . . . . . . . 38 6.1.2. Binding Refresh Request Message . . . . . . . . . . . 38
6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 39 6.1.3. Home Test Init Message . . . . . . . . . . . . . . . 39
6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 40 6.1.4. Care-of Test Init Message . . . . . . . . . . . . . . 40
6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 41 6.1.5. Home Test Message . . . . . . . . . . . . . . . . . . 41
6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 42 6.1.6. Care-of Test Message . . . . . . . . . . . . . . . . 42
6.1.7. Binding Update Message . . . . . . . . . . . . . . . 44 6.1.7. Binding Update Message . . . . . . . . . . . . . . . 44
6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 46 6.1.8. Binding Acknowledgement Message . . . . . . . . . . . 46
6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 49 6.1.9. Binding Error Message . . . . . . . . . . . . . . . . 49
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 50 6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . 50
6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 52 6.2.4. Binding Refresh Advice . . . . . . . . . . . . . . . 52
6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 52 6.2.5. Alternate Care-of Address . . . . . . . . . . . . . . 52
6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 53 6.2.6. Nonce Indices . . . . . . . . . . . . . . . . . . . . 53
6.2.7. Binding Authorization Data . . . . . . . . . . . . . 54 6.2.7. Binding Authorization Data . . . . . . . . . . . . . 54
6.3. Home Address Option . . . . . . . . . . . . . . . . . . . 55 6.3. Home Address Option . . . . . . . . . . . . . . . . . . 55
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 57 6.4. Type 2 Routing Header . . . . . . . . . . . . . . . . . 57
6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 57 6.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 57
6.5. ICMP Home Agent Address Discovery Request Message . . . . 59 6.5. ICMP Home Agent Address Discovery Request Message . . . 59
6.6. ICMP Home Agent Address Discovery Reply Message . . . . . 60 6.6. ICMP Home Agent Address Discovery Reply Message . . . . 60
6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 61 6.7. ICMP Mobile Prefix Solicitation Message Format . . . . . 61
6.8. ICMP Mobile Prefix Advertisement Message Format . . . . . 62 6.8. ICMP Mobile Prefix Advertisement Message Format . . . . 62
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 66 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 66
7.1. Modified Router Advertisement Message Format . . . . . . 66 7.1. Modified Router Advertisement Message Format . . . . . . 66
7.2. Modified Prefix Information Option Format . . . . . . . . 66 7.2. Modified Prefix Information Option Format . . . . . . . 66
7.3. New Advertisement Interval Option Format . . . . . . . . 68 7.3. New Advertisement Interval Option Format . . . . . . . . 68
7.4. New Home Agent Information Option Format . . . . . . . . 69 7.4. New Home Agent Information Option Format . . . . . . . . 69
7.5. Changes to Sending Router Advertisements . . . . . . . . 71 7.5. Changes to Sending Router Advertisements . . . . . . . . 71
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 73 8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . . 73
8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 73 8.1. All IPv6 Nodes . . . . . . . . . . . . . . . . . . . . . 73
8.2. IPv6 Nodes with Support for Route Optimization . . . . . 73 8.2. IPv6 Nodes with Support for Route Optimization . . . . . 73
8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 75 8.3. All IPv6 Routers . . . . . . . . . . . . . . . . . . . . 75
8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 75 8.4. IPv6 Home Agents . . . . . . . . . . . . . . . . . . . . 75
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . . 77 8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . . . 77
9. Correspondent Node Operation . . . . . . . . . . . . . . . . 79 9. Correspondent Node Operation . . . . . . . . . . . . . . . . 79
9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 79 9.1. Conceptual Data Structures . . . . . . . . . . . . . . . 79
9.2. Processing Mobility Headers . . . . . . . . . . . . . . . 80 9.2. Processing Mobility Headers . . . . . . . . . . . . . . 80
9.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 80 9.3. Packet Processing . . . . . . . . . . . . . . . . . . . 80
9.3.1. Receiving Packets with Home Address Option . . . . . 80 9.3.1. Receiving Packets with Home Address Option . . . . . 80
9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 81 9.3.2. Sending Packets to a Mobile Node . . . . . . . . . . 81
9.3.3. Sending Binding Error Messages . . . . . . . . . . . 83 9.3.3. Sending Binding Error Messages . . . . . . . . . . . 83
9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 83 9.3.4. Receiving ICMP Error Messages . . . . . . . . . . . . 83
9.4. Return Routability Procedure . . . . . . . . . . . . . . 84 9.4. Return Routability Procedure . . . . . . . . . . . . . . 84
9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 84 9.4.1. Receiving Home Test Init Messages . . . . . . . . . . 84
9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 84 9.4.2. Receiving Care-of Test Init Messages . . . . . . . . 84
9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 85 9.4.3. Sending Home Test Messages . . . . . . . . . . . . . 85
9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 85 9.4.4. Sending Care-of Test Messages . . . . . . . . . . . . 85
9.5. Processing Bindings . . . . . . . . . . . . . . . . . . . 85 9.5. Processing Bindings . . . . . . . . . . . . . . . . . . 85
9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 85 9.5.1. Receiving Binding Updates . . . . . . . . . . . . . . 85
9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 88 9.5.2. Requests to Cache a Binding . . . . . . . . . . . . . 88
9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 88 9.5.3. Requests to Delete a Binding . . . . . . . . . . . . 88
9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 89 9.5.4. Sending Binding Acknowledgements . . . . . . . . . . 89
9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 90 9.5.5. Sending Binding Refresh Requests . . . . . . . . . . 90
9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 90 9.6. Cache Replacement Policy . . . . . . . . . . . . . . . . 90
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 92 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 92
10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 92 10.1. Conceptual Data Structures . . . . . . . . . . . . . . . 92
10.2. Processing Mobility Headers . . . . . . . . . . . . . . . 93 10.2. Processing Mobility Headers . . . . . . . . . . . . . . 93
10.3. Processing Bindings . . . . . . . . . . . . . . . . . . . 93 10.3. Processing Bindings . . . . . . . . . . . . . . . . . . 93
10.3.1. Primary Care-of Address Registration . . . . . . . . 93 10.3.1. Primary Care-of Address Registration . . . . . . . . 93
10.3.2. Primary Care-of Address De-Registration . . . . . . . 97 10.3.2. Primary Care-of Address De-Registration . . . . . . . 97
10.4. Packet Processing . . . . . . . . . . . . . . . . . . . . 98 10.4. Packet Processing . . . . . . . . . . . . . . . . . . . 98
10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 98 10.4.1. Intercepting Packets for a Mobile Node . . . . . . . 98
10.4.2. Processing Intercepted Packets . . . . . . . . . . . 100 10.4.2. Processing Intercepted Packets . . . . . . . . . . . 100
10.4.3. Multicast Membership Control . . . . . . . . . . . . 101 10.4.3. Multicast Membership Control . . . . . . . . . . . . 101
10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 102 10.4.4. Stateful Address Autoconfiguration . . . . . . . . . 102
10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 103 10.4.5. Handling Reverse Tunneled Packets . . . . . . . . . . 103
10.4.6. Protecting Return Routability Packets . . . . . . . . 103 10.4.6. Protecting Return Routability Packets . . . . . . . . 103
10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 104 10.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 104
10.5.1. Receiving Router Advertisement Messages . . . . . . . 104 10.5.1. Receiving Router Advertisement Messages . . . . . . . 104
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 . . . . . . . . . . . . 107 10.6.2. Scheduling Prefix Deliveries . . . . . . . . . . . . 107
10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 109 10.6.3. Sending Advertisements . . . . . . . . . . . . . . . 109
10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 110 10.6.4. Lifetimes for Changed Prefixes . . . . . . . . . . . 110
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 111 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 111
11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 111 11.1. Conceptual Data Structures . . . . . . . . . . . . . . . 111
11.2. Processing Mobility Headers . . . . . . . . . . . . . . . 112 11.2. Processing Mobility Headers . . . . . . . . . . . . . . 112
11.3. Packet Processing . . . . . . . . . . . . . . . . . . . . 113 11.3. Packet Processing . . . . . . . . . . . . . . . . . . . 113
11.3.1. Sending Packets While Away from Home . . . . . . . . 113 11.3.1. Sending Packets While Away from Home . . . . . . . . 113
11.3.2. Interaction with Outbound IPsec Processing . . . . . 116 11.3.2. Interaction with Outbound IPsec Processing . . . . . 116
11.3.3. Receiving Packets While Away from Home . . . . . . . 118 11.3.3. Receiving Packets While Away from Home . . . . . . . 118
11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 119 11.3.4. Routing Multicast Packets . . . . . . . . . . . . . . 119
11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 121 11.3.5. Receiving ICMP Error Messages . . . . . . . . . . . . 121
11.3.6. Receiving Binding Error Messages . . . . . . . . . . 121 11.3.6. Receiving Binding Error Messages . . . . . . . . . . 121
11.4. Home Agent and Prefix Management . . . . . . . . . . . . 122 11.4. Home Agent and Prefix Management . . . . . . . . . . . . 122
11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 122 11.4.1. Dynamic Home Agent Address Discovery . . . . . . . . 122
11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 123 11.4.2. Sending Mobile Prefix Solicitations . . . . . . . . . 123
11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 124 11.4.3. Receiving Mobile Prefix Advertisements . . . . . . . 124
11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 125 11.5. Movement . . . . . . . . . . . . . . . . . . . . . . . . 125
11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 125 11.5.1. Movement Detection . . . . . . . . . . . . . . . . . 125
11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 128 11.5.2. Home Link Detection . . . . . . . . . . . . . . . . . 128
11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 128 11.5.3. Forming New Care-of Addresses . . . . . . . . . . . . 128
11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 129 11.5.4. Using Multiple Care-of Addresses . . . . . . . . . . 129
11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 130 11.5.5. Returning Home . . . . . . . . . . . . . . . . . . . 130
11.6. Return Routability Procedure . . . . . . . . . . . . . . 132 11.6. Return Routability Procedure . . . . . . . . . . . . . . 132
11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 132 11.6.1. Sending Test Init Messages . . . . . . . . . . . . . 132
11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 133 11.6.2. Receiving Test Messages . . . . . . . . . . . . . . . 133
11.6.3. Protecting Return Routability Packets . . . . . . . . 134 11.6.3. Protecting Return Routability Packets . . . . . . . . 134
11.7. Processing Bindings . . . . . . . . . . . . . . . . . . . 134 11.7. Processing Bindings . . . . . . . . . . . . . . . . . . 134
11.7.1. Sending Binding Updates to the Home Agent . . . . . . 134 11.7.1. Sending Binding Updates to the Home Agent . . . . . . 134
11.7.2. Correspondent Registration . . . . . . . . . . . . . 137 11.7.2. Correspondent Registration . . . . . . . . . . . . . 137
11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 140 11.7.3. Receiving Binding Acknowledgements . . . . . . . . . 140
11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 142 11.7.4. Receiving Binding Refresh Requests . . . . . . . . . 142
11.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 143 11.8. Retransmissions and Rate Limiting . . . . . . . . . . . 143
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 145 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 145
13. Protocol Configuration Variables . . . . . . . . . . . . . . 146 13. Protocol Configuration Variables . . . . . . . . . . . . . . 146
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147
15. Security Considerations . . . . . . . . . . . . . . . . . . . 150 15. Security Considerations . . . . . . . . . . . . . . . . . . . 150
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 150 15.1. Threats . . . . . . . . . . . . . . . . . . . . . . . . 150
15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 152 15.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 152
15.3. Binding Updates to Home Agent . . . . . . . . . . . . . . 154 15.3. Binding Updates to Home Agent . . . . . . . . . . . . . 154
15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 156 15.4. Binding Updates to Correspondent Nodes . . . . . . . . . 156
15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 156 15.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 156
15.4.2. Achieved Security Properties . . . . . . . . . . . . 157 15.4.2. Achieved Security Properties . . . . . . . . . . . . 157
15.4.3. Comparison to Regular IPv6 Communications . . . . . . 158 15.4.3. Comparison to Regular IPv6 Communications . . . . . . 158
15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 160 15.4.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 160
15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 160 15.4.5. Denial-of-Service Attacks . . . . . . . . . . . . . . 160
15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 161 15.4.6. Key Lengths . . . . . . . . . . . . . . . . . . . . . 161
15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 162 15.5. Dynamic Home Agent Address Discovery . . . . . . . . . . 162
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . . 163 15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . . . 163
15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 163 15.7. Tunneling via the Home Agent . . . . . . . . . . . . . . 163
15.8. Home Address Option . . . . . . . . . . . . . . . . . . . 164 15.8. Home Address Option . . . . . . . . . . . . . . . . . . 164
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . . 164 15.9. Type 2 Routing Header . . . . . . . . . . . . . . . . . 164
15.10. SHA-1 Secure Enough for Mobile IPv6 Control Messages . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168
18.1. Normative References . . . . . . . . . . . . . . . . . . 168 18.1. Normative References . . . . . . . . . . . . . . . . . . 168
18.2. Informative References . . . . . . . . . . . . . . . . . 169 18.2. Informative References . . . . . . . . . . . . . . . . . 169
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172 Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 172
A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172 A.1. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 172
A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172 A.2. Triangular Routing . . . . . . . . . . . . . . . . . . . 172
A.3. New Authorization Methods . . . . . . . . . . . . . . . . 172 A.3. New Authorization Methods . . . . . . . . . . . . . . . 172
A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . . 172 A.4. Neighbor Discovery Extensions . . . . . . . . . . . . . 172
Appendix B. Changes since RFC 3775 . . . . . . . . . . . . . . . 174 Appendix B. Changes since RFC 3775 . . . . . . . . . . . . . . . 174
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 177
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 [6], packets destined to a mobile node support for mobility in IPv6 [6], 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
skipping to change at page 12, line 21 skipping to change at page 12, line 21
First (size, input) First (size, input)
Some formulas in this specification use a functional form "First Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that (size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used. only the first "size" bits remain to be used.
3.2. Mobile IPv6 Terms 3.2. Mobile IPv6 Terms
These terms are intended to be compatible with the definitions given These terms are intended to be compatible with the definitions given
in RFC 3753[38]. However, if there is any conflict, the definitions in RFC 3753[39]. However, if there is any conflict, the definitions
given here should be considered to supersede those in RFC 3753. given here should be considered to supersede those in RFC 3753.
home address home address
A unicast routable address assigned to a mobile node, used as the A unicast routable address assigned to a mobile node, used as the
permanent address of the mobile node. This address is within the permanent address of the mobile node. This address is within the
mobile node's home link. Standard IP routing mechanisms will mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its deliver packets destined for a mobile node's home address to its
home link. Mobile nodes can have multiple home addresses, for home link. Mobile nodes can have multiple home addresses, for
instance when there are multiple home prefixes on the home link. instance when there are multiple home prefixes on the home link.
skipping to change at page 23, line 33 skipping to change at page 23, line 33
routability procedure is used to assure that the right mobile node is routability procedure is used to assure that the right mobile node is
sending the message. This method does not protect against attackers sending the message. This method does not protect against attackers
who are on the path between the home network and the correspondent who are on the path between the home network and the correspondent
node. However, attackers in such a location are capable of node. However, attackers in such a location are capable of
performing the same attacks even without Mobile IPv6. The main performing the same attacks even without Mobile IPv6. The main
advantage of the return routability procedure is that it limits the advantage of the return routability procedure is that it limits the
potential attackers to those having an access to one specific path in potential attackers to those having an access to one specific path in
the Internet, and avoids forged Binding Updates from anywhere else in the Internet, and avoids forged Binding Updates from anywhere else in
the Internet. For a more in depth explanation of the security the Internet. For a more in depth explanation of the security
properties of the return routability procedure, see Section 15. properties of the return routability procedure, see Section 15.
Also, consult [41] Also, consult [42]
The integrity and authenticity of the Binding Update messages to The integrity and authenticity of the Binding Update messages to
correspondent nodes is protected by using a keyed-hash algorithm. correspondent nodes is protected by using a keyed-hash algorithm.
The binding management key, Kbm, is used to key the hash algorithm The binding management key, Kbm, is used to key the hash algorithm
for this purpose. Kbm is established using data exchanged during the for this purpose. Kbm is established using data exchanged during the
return routability procedure. The data exchange is accomplished by return routability procedure. The data exchange is accomplished by
use of node keys, nonces, cookies, tokens, and certain cryptographic use of node keys, nonces, cookies, tokens, and certain cryptographic
functions. Section 5.2.5 outlines the basic return routability functions. Section 5.2.5 outlines the basic return routability
procedure. Section 5.2.6 shows how the results of this procedure are procedure. Section 5.2.6 shows how the results of this procedure are
used to authorize a Binding Update to a correspondent node. used to authorize a Binding Update to a correspondent node.
skipping to change at page 25, line 33 skipping to change at page 25, line 33
Home and care-of keygen tokens are produced by the correspondent node Home and care-of keygen tokens are produced by the correspondent node
based on its currently active secret key (Kcn) and nonces, as well as based on its currently active secret key (Kcn) and nonces, as well as
the home or care-of address (respectively). A keygen token is valid the home or care-of address (respectively). A keygen token is valid
as long as both the secret key (Kcn) and the nonce used to create it as long as both the secret key (Kcn) and the nonce used to create it
are valid. are valid.
5.2.4. Cryptographic Functions 5.2.4. Cryptographic Functions
By default in this specification, the function used to compute hash By default in this specification, the function used to compute hash
values is SHA1 [11]. Message Authentication Codes (MACs) are then values is SHA-1 [11], which is considered to offer sufficient
computed using HMAC_SHA1 [1][11]. HMAC_SHA1(K,m) denotes such a MAC protection for Mobile IPv6 control messages (see Section 15.10).
computed on message m with key K. Message Authentication Codes (MACs) are then computed using HMAC_SHA1
[1][11]. HMAC_SHA1(K,m) denotes such a MAC computed on message m
with key K.
5.2.5. Return Routability Procedure 5.2.5. Return Routability Procedure
The Return Routability Procedure enables the correspondent node to The Return Routability Procedure enables the correspondent node to
obtain some reasonable assurance that the mobile node is in fact obtain some reasonable assurance that the mobile node is in fact
addressable at its claimed care-of address as well as at its home addressable at its claimed care-of address as well as at its home
address. Only with this assurance is the correspondent node able to address. Only with this assurance is the correspondent node able to
accept Binding Updates from the mobile node which would then instruct accept Binding Updates from the mobile node which would then instruct
the correspondent node to direct that mobile node's data traffic to the correspondent node to direct that mobile node's data traffic to
its claimed care-of address. its claimed care-of address.
skipping to change at page 29, line 36 skipping to change at page 29, line 41
The care-of nonce index is provided to identify the nonce used for The care-of nonce index is provided to identify the nonce used for
the care-of keygen token. The home and care-of nonce indices MAY the care-of keygen token. The home and care-of nonce indices MAY
be the same, or different, in the Home and Care-of Test messages. be the same, or different, in the Home and Care-of Test messages.
When the mobile node has received both the Home and Care-of Test When the mobile node has received both the Home and Care-of Test
messages, the return routability procedure is complete. As a result messages, the return routability procedure is complete. As a result
of the procedure, the mobile node has the data it needs to send a of the procedure, the mobile node has the data it needs to send a
Binding Update to the correspondent node. The mobile node hashes the Binding Update to the correspondent node. The mobile node hashes the
tokens together to form a 20 octet binding key Kbm: tokens together to form a 20 octet binding key Kbm:
Kbm = SHA1 (home keygen token | care-of keygen token) Kbm = SHA-1 (home keygen token | care-of keygen token)
A Binding Update may also be used to delete a previously established A Binding Update may also be used to delete a previously established
binding (Section 6.1.7). In this case, the care-of keygen token is binding (Section 6.1.7). In this case, the care-of keygen token is
not used. Instead, the binding management key is generated as not used. Instead, the binding management key is generated as
follows: follows:
Kbm = SHA1(home keygen token) Kbm = SHA-1(home keygen token)
Note that the correspondent node does not create any state specific Note that the correspondent node does not create any state specific
to the mobile node, until it receives the Binding Update from that to the mobile node, until it receives the Binding Update from that
mobile node. The correspondent node does not maintain the value for mobile node. The correspondent node does not maintain the value for
the binding management key Kbm; it creates Kbm when given the nonce the binding management key Kbm; it creates Kbm when given the nonce
indices and the mobile node's addresses. indices and the mobile node's addresses.
5.2.6. Authorizing Binding Management Messages 5.2.6. Authorizing Binding Management Messages
After the mobile node has created the binding management key (Kbm), After the mobile node has created the binding management key (Kbm),
skipping to change at page 34, line 41 skipping to change at page 34, line 42
the following we define the security measures taken to protect these, the following we define the security measures taken to protect these,
and to prevent their use in attacks against other parties. and to prevent their use in attacks against other parties.
This specification limits the use of the Home Address destination This specification limits the use of the Home Address destination
option to the situation where the correspondent node already has a option to the situation where the correspondent node already has a
Binding Cache entry for the given home address. This avoids the use Binding Cache entry for the given home address. This avoids the use
of the Home Address option in attacks described in Section 15.1. of the Home Address option in attacks described in Section 15.1.
Mobile IPv6 uses a type of routing header specific to Mobile IPv6. Mobile IPv6 uses a type of routing header specific to Mobile IPv6.
This type provides the necessary functionality but does not open This type provides the necessary functionality but does not open
vulnerabilities discussed in Section 15.1 and RFC 5095 [43]. vulnerabilities discussed in Section 15.1 and RFC 5095 [44].
Tunnels between the mobile node and the home agent are protected by Tunnels between the mobile node and the home agent are protected by
ensuring proper use of source addresses, and optional cryptographic ensuring proper use of source addresses, and optional cryptographic
protection. The mobile node verifies that the outer IP address protection. The mobile node verifies that the outer IP address
corresponds to its home agent. The home agent verifies that the corresponds to its home agent. The home agent verifies that the
outer IP address corresponds to the current location of the mobile outer IP address corresponds to the current location of the mobile
node (Binding Updates sent to the home agents are secure). The home node (Binding Updates sent to the home agents are secure). The home
agent identifies the mobile node through the source address of the agent identifies the mobile node through the source address of the
inner packet. (Typically, this is the home address of the mobile inner packet. (Typically, this is the home address of the mobile
node, but it can also be a link-local address, as discussed in node, but it can also be a link-local address, as discussed in
skipping to change at page 101, line 43 skipping to change at page 101, line 43
forwarding, described in the previous section. If this support is forwarding, described in the previous section. If this support is
not provided, multicast group membership control messages are not provided, multicast group membership control messages are
silently ignored. silently ignored.
In order to forward multicast data packets from the home network to In order to forward multicast data packets from the home network to
all the proper mobile nodes, the home agent SHOULD be capable of all the proper mobile nodes, the home agent SHOULD be capable of
receiving tunneled multicast group membership control information receiving tunneled multicast group membership control information
from the mobile node in order to determine which groups the mobile from the mobile node in order to determine which groups the mobile
node has subscribed to. These multicast group membership messages node has subscribed to. These multicast group membership messages
are Listener Report messages specified in MLD [9] or in other are Listener Report messages specified in MLD [9] or in other
protocols such as [39]. protocols such as [40].
The messages are issued by the mobile node, but sent through the The messages are issued by the mobile node, but sent through the
reverse tunnel to the home agent. These messages are issued whenever reverse tunnel to the home agent. These messages are issued whenever
the mobile node decides to enable reception of packets for a the mobile node decides to enable reception of packets for a
multicast group or in response to an MLD Query from the home agent. multicast group or in response to an MLD Query from the home agent.
The mobile node will also issue multicast group control messages to The mobile node will also issue multicast group control messages to
disable reception of multicast packets when it is no longer disable reception of multicast packets when it is no longer
interested in receiving multicasts for a particular group. interested in receiving multicasts for a particular group.
To obtain the mobile node's current multicast group membership the To obtain the mobile node's current multicast group membership the
skipping to change at page 113, line 46 skipping to change at page 113, line 46
relying on Mobile IPv6. If application running on the mobile node relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile within this general type of communication, however, the mobile
node should not use its care-of address as the source of the node should not use its care-of address as the source of the
packet in this way. packet in this way.
The choice of the most efficient communications method is The choice of the most efficient communications method is
application specific, and outside the scope of this specification. application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of The APIs necessary for controlling the choice are also out of
scope. One example of such an API is described in the IPv6 Socket scope. One example of such an API is described in the IPv6 Socket
API for Source Address Selection specification [42]. API for Source Address Selection specification [43].
o While not at its home link, the mobile node MUST NOT use the Home o While not at its home link, the mobile node MUST NOT use the Home
Address destination option when communicating with link-local Address destination option when communicating with link-local
peers. peers.
Similarly, the mobile node MUST NOT use the Home Address Similarly, the mobile node MUST NOT use the Home Address
destination option for IPv6 Neighbor Discovery [18] packets. destination option for IPv6 Neighbor Discovery [18] packets.
Detailed operation of these cases is described later in this section Detailed operation of these cases is described later in this section
and also discussed in [32]. and also discussed in [32].
skipping to change at page 119, line 49 skipping to change at page 119, line 49
In order to receive packets sent to some multicast group, a mobile In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method, in which a mobile node must join that multicast group. One method, in which a mobile
node MAY join the group, is via a (local) multicast router on the node MAY join the group, is via a (local) multicast router on the
foreign link being visited. In this case, the mobile node MUST use foreign link being visited. In this case, the mobile node MUST use
its care-of address and MUST NOT use the Home Address destination its care-of address and MUST NOT use the Home Address destination
option when sending MLD packets [9]. option when sending MLD packets [9].
Alternatively, a mobile node MAY join multicast groups via a bi- Alternatively, a mobile node MAY join multicast groups via a bi-
directional tunnel to its home agent. The mobile node tunnels its directional tunnel to its home agent. The mobile node tunnels its
multicast group membership control packets (such as those defined in multicast group membership control packets (such as those defined in
[9] or in [39]) to its home agent, and the home agent forwards [9] or in [40]) to its home agent, and the home agent forwards
multicast packets down the tunnel to the mobile node. A mobile node multicast packets down the tunnel to the mobile node. A mobile node
MUST NOT tunnel multicast group membership control packets until (1) MUST NOT tunnel multicast group membership control packets until (1)
the mobile node has a binding in place at the home agent, and (2) the the mobile node has a binding in place at the home agent, and (2) the
latter sends at least one multicast group membership control packet latter sends at least one multicast group membership control packet
via the tunnel. Once this condition is true, the mobile node SHOULD via the tunnel. Once this condition is true, the mobile node SHOULD
assume it does not change as long as the binding does not expire. assume it does not change as long as the binding does not expire.
A mobile node that wishes to send packets to a multicast group also A mobile node that wishes to send packets to a multicast group also
has two options: has two options:
1. Send directly on the foreign link being visited. 1. Send directly on the foreign link being visited.
To do this, the application uses the care-of address as a source To do this, the application uses the care-of address as a source
address for multicast traffic, just as it would use a stationary address for multicast traffic, just as it would use a stationary
address. This requires that the application either knows the address. This requires that the application either knows the
care-of address, or uses an API such as the IPv6 Socket API for care-of address, or uses an API such as the IPv6 Socket API for
Source Address Selection specification [42] to request that the Source Address Selection specification [43] to request that the
care-of address be used as the source address in transmitted care-of address be used as the source address in transmitted
packets. The mobile node MUST NOT use Home Address destination packets. The mobile node MUST NOT use Home Address destination
option in such traffic. option in such traffic.
2. Send via a tunnel to its home agent. 2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST use node that tunnels a multicast packet to its home agent MUST use
its home address as the IPv6 Source Address of the inner its home address as the IPv6 Source Address of the inner
skipping to change at page 151, line 46 skipping to change at page 151, line 46
Address destination option, a new routing header type (type 2), Address destination option, a new routing header type (type 2),
and uses tunneling headers in the payload packets. The protocol and uses tunneling headers in the payload packets. The protocol
must protect against potential new threats involving the use of must protect against potential new threats involving the use of
these mechanisms. these mechanisms.
Third parties become exposed to a reflection threat via the Home Third parties become exposed to a reflection threat via the Home
Address destination option, unless appropriate security Address destination option, unless appropriate security
precautions are followed. The Home Address destination option precautions are followed. The Home Address destination option
could be used to direct response traffic toward a node whose IP could be used to direct response traffic toward a node whose IP
address appears in the option. In this case, ingress filtering address appears in the option. In this case, ingress filtering
would not catch the forged "return address" [37] [41]. would not catch the forged "return address" [37] [42].
A similar threat exists with the tunnels between the mobile node A similar threat exists with the tunnels between the mobile node
and the home agent. An attacker might forge tunnel packets and the home agent. An attacker might forge tunnel packets
between the mobile node and the home agent, making it appear that between the mobile node and the home agent, making it appear that
the traffic is coming from the mobile node when it is not. Note the traffic is coming from the mobile node when it is not. Note
that an attacker who is able to forge tunnel packets would that an attacker who is able to forge tunnel packets would
typically also be able to forge packets that appear to come typically also be able to forge packets that appear to come
directly from the mobile node. This is not a new threat as such. directly from the mobile node. This is not a new threat as such.
However, it may make it easier for attackers to escape detection However, it may make it easier for attackers to escape detection
by avoiding ingress filtering and packet tracing mechanisms. by avoiding ingress filtering and packet tracing mechanisms.
skipping to change at page 155, line 24 skipping to change at page 155, line 24
vulnerability exists if either the sequence number space is cycled vulnerability exists if either the sequence number space is cycled
through, or if the home agent reboots and forgets its sequence through, or if the home agent reboots and forgets its sequence
numbers (and uses volatile memory to store the sequence numbers). numbers (and uses volatile memory to store the sequence numbers).
Assuming the mobile node moves continuously every 10 minutes, it Assuming the mobile node moves continuously every 10 minutes, it
takes roughly 455 days before the sequence number space has been takes roughly 455 days before the sequence number space has been
cycled through. Typical movement patterns rarely reach this high cycled through. Typical movement patterns rarely reach this high
frequency today. frequency today.
o A mobile node and its home agent belong to the same domain. If o A mobile node and its home agent belong to the same domain. If
this were not the case, manual keying would not be possible [40], this were not the case, manual keying would not be possible [41],
but in Mobile IPv6 only these two parties need to know the but in Mobile IPv6 only these two parties need to know the
manually configured keys. Similarly, we note that Mobile IPv6 manually configured keys. Similarly, we note that Mobile IPv6
employs standard block ciphers in IPsec, and is not vulnerable to employs standard block ciphers in IPsec, and is not vulnerable to
problems associated with stream ciphers and manual keying. problems associated with stream ciphers and manual keying.
o It is expected that the owner of the mobile node and the o It is expected that the owner of the mobile node and the
administrator of the home agent agree on the used keys and other administrator of the home agent agree on the used keys and other
parameters with some off-line mechanism. parameters with some off-line mechanism.
The use of IKEv2 with Mobile IPv6 is documented in more detail in The use of IKEv2 with Mobile IPv6 is documented in more detail in
skipping to change at page 157, line 37 skipping to change at page 157, line 37
available. available.
The resulting level of security is in theory the same even without The resulting level of security is in theory the same even without
this additional protection: the return routability tokens are this additional protection: the return routability tokens are
still exposed only to one path within the whole Internet. still exposed only to one path within the whole Internet.
However, the mobile nodes are often found on an insecure link, However, the mobile nodes are often found on an insecure link,
such as a public access Wireless LAN. Thus, in many cases, this such as a public access Wireless LAN. Thus, in many cases, this
addition makes a practical difference. addition makes a practical difference.
For further information about the design rationale of the return For further information about the design rationale of the return
routability procedure, see [28] [34] [33] [41]. The mechanisms used routability procedure, see [28] [34] [33] [42]. The mechanisms used
have been adopted from these documents. have been adopted from these documents.
15.4.2. Achieved Security Properties 15.4.2. Achieved Security Properties
The return routability procedure protects Binding Updates against all The return routability procedure protects Binding Updates against all
attackers who are unable to monitor the path between the home agent attackers who are unable to monitor the path between the home agent
and the correspondent node. The procedure does not defend against and the correspondent node. The procedure does not defend against
attackers who can monitor this path. Note that such attackers are in attackers who can monitor this path. Note that such attackers are in
any case able to mount an active attack against the mobile node when any case able to mount an active attack against the mobile node when
it is at its home location. The possibility of such attacks is not it is at its home location. The possibility of such attacks is not
skipping to change at page 160, line 13 skipping to change at page 160, line 13
particular if these links are publicly accessible wireless LANs. particular if these links are publicly accessible wireless LANs.
Attacks against the routers or switches on the path are typically Attacks against the routers or switches on the path are typically
harder to accomplish. The security on layer 2 of the links plays harder to accomplish. The security on layer 2 of the links plays
then a major role in the resulting overall network security. then a major role in the resulting overall network security.
Similarly, security of IPv6 Neighbor and Router Discovery on these Similarly, security of IPv6 Neighbor and Router Discovery on these
links has a large impact. If these were secured using some new links has a large impact. If these were secured using some new
technology in the future, this could change the situation technology in the future, this could change the situation
regarding the easiest point of attack. regarding the easiest point of attack.
For a more in-depth discussion of these issues, see [41]. For a more in-depth discussion of these issues, see [42].
15.4.4. Replay Attacks 15.4.4. Replay Attacks
The return routability procedure also protects the participants The return routability procedure also protects the participants
against replayed Binding Updates. The attacker is unable replay the against replayed Binding Updates. The attacker is unable replay the
same message due to the sequence number which is a part of the same message due to the sequence number which is a part of the
Binding Update. It is also unable to modify the Binding Update since Binding Update. It is also unable to modify the Binding Update since
the MAC verification would fail after such a modification. the MAC verification would fail after such a modification.
Care must be taken when removing bindings at the correspondent node, Care must be taken when removing bindings at the correspondent node,
skipping to change at page 166, line 5 skipping to change at page 165, line 25
In essence the semantics of the type 2 routing header is the same as In essence the semantics of the type 2 routing header is the same as
a special form of IP-in-IP tunneling where the inner and outer source a special form of IP-in-IP tunneling where the inner and outer source
addresses are the same. addresses are the same.
This implies that a device which implements the filtering of packets This implies that a device which implements the filtering of packets
should be able to distinguish between a type 2 routing header and should be able to distinguish between a type 2 routing header and
other routing headers, as required in Section 8.3. This is necessary other routing headers, as required in Section 8.3. This is necessary
in order to allow Mobile IPv6 traffic while still having the option in order to allow Mobile IPv6 traffic while still having the option
of filtering out other uses of routing headers. of filtering out other uses of routing headers.
15.10. SHA-1 Secure Enough for Mobile IPv6 Control Messages
This document relies on hash-based message authentication codes
(HMAC) computed using the SHA-1 [11] hash algorithm for the home
keygen token, care-of keygen token, as well as the authentication
fields in the binding update and binding authorization data (see
Section 5.2.4). While SHA-1 has been deprecated for some
cryptographic mechanisms, SHA-1 is considered secure for the
foreseeable future when used as specified here. For additional
details, see [38].
16. Contributors 16. Contributors
Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik
Nordmark, and Michael Thomas shaped the return routability protocols Nordmark, and Michael Thomas shaped the return routability protocols
described in [34]. described in [34].
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.
skipping to change at page 170, line 38 skipping to change at page 170, line 38
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008. progress), April 2008.
[36] Savola, P., "Use of /127 Prefix Length Between Routers [36] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003. Considered Harmful", RFC 3627, September 2003.
[37] Savola, P., "Security of IPv6 Routing Header and Home Address [37] Savola, P., "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-02 (work in Options", draft-savola-ipv6-rh-ha-security-02 (work in
progress), March 2002. progress), March 2002.
[38] Manner, J. and M. Kojo, "Mobility Related Terminology", [38] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", draft-turner-sha0-sha1-seccon-05 (work in
progress), February 2011.
[39] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[39] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [40] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
[40] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key [41] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
Management", BCP 107, RFC 4107, June 2005. Management", BCP 107, RFC 4107, June 2005.
[41] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [42] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[42] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket [43] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket
API for Source Address Selection", RFC 5014, September 2007. API for Source Address Selection", RFC 5014, September 2007.
[43] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of [44] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of
Type 0 Routing Headers in IPv6", RFC 5095, December 2007. Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
Appendix A. Future Extensions Appendix A. Future Extensions
A.1. Piggybacking A.1. Piggybacking
This document does not specify how to piggyback payload packets on This document does not specify how to piggyback payload packets on
the binding related messages. However, it is envisioned that this the binding related messages. However, it is envisioned that this
can be specified in a separate document when issues such as the can be specified in a separate document when issues such as the
interaction between piggybacking and IPsec are fully resolved (see interaction between piggybacking and IPsec are fully resolved (see
skipping to change at page 174, line 8 skipping to change at page 174, line 8
specification. specification.
Future functional improvements may also be relevant for Mobile IPv6 Future functional improvements may also be relevant for Mobile IPv6
and other applications. For instance, mechanisms that would allow and other applications. For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be useful recovery from a Duplicate Address Detection collision would be useful
for link-local, care-of, and home addresses. for link-local, care-of, and home addresses.
Appendix B. Changes since RFC 3775 Appendix B. Changes since RFC 3775
The following issues were identified during the evolution of the The following issues were identified during the evolution of the
current document. Discussion about the issues can be found on the current document. Discussion about most of the issues can be found
[mext] working group page on the [mext] working group page
http://trac.tools.ietf.org/wg/mext/trac/report/6 http://trac.tools.ietf.org/wg/mext/trac/report/6
Issue #1 Last Accepted SQN [Ahmad Muhanna] Issue #1 Last Accepted SQN [Ahmad Muhanna]
Solution: specify that the mobile node update its binding sequence Solution: specify that the mobile node update its binding sequence
number to match the sequence number given in the Binding number to match the sequence number given in the Binding
Acknowledgement (if the Binding Acknowledgement correctly passes Acknowledgement (if the Binding Acknowledgement correctly passes
authentication and the status is 135 (Sequence Number out of authentication and the status is 135 (Sequence Number out of
window). See Section 11.7.3. window). See Section 11.7.3.
skipping to change at page 174, line 33 skipping to change at page 174, line 33
Fixed. Fixed.
Issue #5 Wrong protocol number (2 instead of 135) used in discussion Issue #5 Wrong protocol number (2 instead of 135) used in discussion
about checksum pseudo-header. about checksum pseudo-header.
Fixed. See Section 6.1.1. Fixed. See Section 6.1.1.
Issue #8 Application using the care-of address [Julien Laganier] Issue #8 Application using the care-of address [Julien Laganier]
Cite IPv6 Socket API for Source Address Selection specification Cite IPv6 Socket API for Source Address Selection specification
[42]. See Section 11.3.4. [43]. See Section 11.3.4.
Issue #10 The usage of "HA lifetime" [Ryuji Wakikawa] Issue #10 The usage of "HA lifetime" [Ryuji Wakikawa]
The mobile node SHOULD store the list of home agents for later use The mobile node SHOULD store the list of home agents for later use
in case the home agent currently managing the mobile node's in case the home agent currently managing the mobile node's
care-of address forwarding should become unavailable. See care-of address forwarding should become unavailable. See
Section 11.4.1. Section 11.4.1.
Issue #11 De-registration when returning home [Vijay Devarapalli] Issue #11 De-registration when returning home [Vijay Devarapalli]
skipping to change at page 177, line 5 skipping to change at page 176, line 10
Solution: Home Agent defers BCE removal after sending the Binding Solution: Home Agent defers BCE removal after sending the Binding
Acknowledgement. See Section 10.3.2. Acknowledgement. See Section 10.3.2.
Issue #6 Minor editorial corrections and updates. Issue #6 Minor editorial corrections and updates.
Update IPsec and IKE references to the revised IPsec architecture Update IPsec and IKE references to the revised IPsec architecture
and IKEv2. and IKEv2.
Update HMAC_SHA1 [1] to Normative instead of Informational. Update HMAC_SHA1 [1] to Normative instead of Informational.
Include discussion (see Section 15.10) to inform implementers that
HMAC_SHA1 is considered to offer sufficient protection for control
messages as required by Mobile IPv6.
Authors' Addresses Authors' Addresses
Charles E. Perkins Charles E. Perkins
Tellabs Inc. Tellabs Inc.
4555 Great America Parkway, Suite 150 4555 Great America Parkway, Suite 150
Santa Clara CA 95054 Santa Clara CA 95054
USA USA
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 56 change blocks. 
95 lines changed or deleted 119 lines changed or added

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