summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6275.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6275.txt')
-rw-r--r--doc/rfc/rfc6275.txt9467
1 files changed, 9467 insertions, 0 deletions
diff --git a/doc/rfc/rfc6275.txt b/doc/rfc/rfc6275.txt
new file mode 100644
index 0000000..87301d2
--- /dev/null
+++ b/doc/rfc/rfc6275.txt
@@ -0,0 +1,9467 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Perkins, Ed.
+Request for Comments: 6275 Tellabs, Inc.
+Obsoletes: 3775 D. Johnson
+Category: Standards Track Rice University
+ISSN: 2070-1721 J. Arkko
+ Ericsson
+ July 2011
+
+
+ Mobility Support in IPv6
+
+Abstract
+
+ This document specifies Mobile IPv6, a protocol that allows nodes to
+ remain reachable while moving around in the IPv6 Internet. Each
+ mobile node is always identified by its home address, regardless of
+ its current point of attachment to the Internet. While situated away
+ from its home, a mobile node is also associated with a care-of
+ address, which provides information about the mobile node's current
+ location. IPv6 packets addressed to a mobile node's home address are
+ transparently routed to its care-of address. The protocol enables
+ IPv6 nodes to cache the binding of a mobile node's home address with
+ its care-of address, and to then send any packets destined for the
+ mobile node directly to it at this care-of address. To support this
+ operation, Mobile IPv6 defines a new IPv6 protocol and a new
+ destination option. All IPv6 nodes, whether mobile or stationary,
+ can communicate with mobile nodes. This document obsoletes RFC 3775.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6275.
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 1]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 2]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................7
+ 2. Comparison with Mobile IP for IPv4 ..............................8
+ 3. Terminology .....................................................9
+ 3.1. General Terms ..............................................9
+ 3.2. Mobile IPv6 Terms .........................................11
+ 4. Overview of Mobile IPv6 ........................................15
+ 4.1. Basic Operation ...........................................15
+ 4.2. New IPv6 Protocol .........................................17
+ 4.3. New IPv6 Destination Option ...............................18
+ 4.4. New IPv6 ICMP Messages ....................................19
+ 4.5. Conceptual Data Structure Terminology .....................19
+ 4.6. Unique-Local Addressability ...............................20
+ 5. Overview of Mobile IPv6 Security ...............................20
+ 5.1. Binding Updates to Home Agents ............................21
+ 5.2. Binding Updates to Correspondent Nodes ....................22
+ 5.2.1. Node Keys ..........................................22
+ 5.2.2. Nonces .............................................23
+ 5.2.3. Cookies and Tokens .................................23
+ 5.2.4. Cryptographic Functions ............................24
+ 5.2.5. Return Routability Procedure .......................24
+ 5.2.6. Authorizing Binding Management Messages ............28
+ 5.2.7. Updating Node Keys and Nonces ......................30
+ 5.2.8. Preventing Replay Attacks ..........................32
+ 5.2.9. Handling Interruptions to Return Routability .......32
+ 5.3. Dynamic Home Agent Address Discovery ......................33
+ 5.4. Mobile Prefix Discovery ...................................33
+ 5.5. Payload Packets ...........................................33
+ 6. New IPv6 Protocol, Message Types, and Destination Option .......34
+ 6.1. Mobility Header ...........................................34
+ 6.1.1. Format .............................................34
+ 6.1.2. Binding Refresh Request Message ....................36
+ 6.1.3. Home Test Init Message .............................37
+ 6.1.4. Care-of Test Init Message ..........................38
+ 6.1.5. Home Test Message ..................................39
+ 6.1.6. Care-of Test Message ...............................41
+ 6.1.7. Binding Update Message .............................42
+ 6.1.8. Binding Acknowledgement Message ....................44
+ 6.1.9. Binding Error Message ..............................47
+ 6.2. Mobility Options ..........................................48
+ 6.2.1. Format .............................................49
+ 6.2.2. Pad1 ...............................................49
+ 6.2.3. PadN ...............................................50
+ 6.2.4. Binding Refresh Advice .............................50
+ 6.2.5. Alternate Care-of Address ..........................51
+ 6.2.6. Nonce Indices ......................................52
+ 6.2.7. Binding Authorization Data .........................52
+
+
+
+Perkins, et al. Standards Track [Page 3]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 6.3. Home Address Option .......................................54
+ 6.4. Type 2 Routing Header .....................................55
+ 6.4.1. Format .............................................56
+ 6.5. ICMP Home Agent Address Discovery Request Message .........57
+ 6.6. ICMP Home Agent Address Discovery Reply Message ...........58
+ 6.7. ICMP Mobile Prefix Solicitation Message Format ............60
+ 6.8. ICMP Mobile Prefix Advertisement Message Format ...........61
+ 7. Modifications to IPv6 Neighbor Discovery .......................64
+ 7.1. Modified Router Advertisement Message Format ..............64
+ 7.2. Modified Prefix Information Option Format .................65
+ 7.3. New Advertisement Interval Option Format ..................66
+ 7.4. New Home Agent Information Option Format ..................67
+ 7.5. Changes to Sending Router Advertisements ..................69
+ 8. Requirements for Types of IPv6 Nodes ...........................71
+ 8.1. All IPv6 Nodes ............................................71
+ 8.2. IPv6 Nodes with Support for Route Optimization ............72
+ 8.3. All IPv6 Routers ..........................................73
+ 8.4. IPv6 Home Agents ..........................................74
+ 8.5. IPv6 Mobile Nodes .........................................75
+ 9. Correspondent Node Operation ...................................76
+ 9.1. Conceptual Data Structures ................................76
+ 9.2. Processing Mobility Headers ...............................78
+ 9.3. Packet Processing .........................................78
+ 9.3.1. Receiving Packets with Home Address Option .........78
+ 9.3.2. Sending Packets to a Mobile Node ...................79
+ 9.3.3. Sending Binding Error Messages .....................81
+ 9.3.4. Receiving ICMP Error Messages ......................81
+ 9.4. Return Routability Procedure ..............................82
+ 9.4.1. Receiving Home Test Init Messages ..................82
+ 9.4.2. Receiving Care-of Test Init Messages ...............82
+ 9.4.3. Sending Home Test Messages .........................83
+ 9.4.4. Sending Care-of Test Messages ......................83
+ 9.5. Processing Bindings .......................................83
+ 9.5.1. Receiving Binding Updates ..........................83
+ 9.5.2. Requests to Cache a Binding ........................86
+ 9.5.3. Requests to Delete a Binding .......................86
+ 9.5.4. Sending Binding Acknowledgements ...................87
+ 9.5.5. Sending Binding Refresh Requests ...................88
+ 9.6. Cache Replacement Policy ..................................88
+ 10. Home Agent Operation ..........................................89
+ 10.1. Conceptual Data Structures ...............................89
+ 10.2. Processing Mobility Headers ..............................90
+ 10.3. Processing Bindings ......................................90
+ 10.3.1. Primary Care-of Address Registration ..............90
+ 10.3.2. Primary Care-of Address De-Registration ...........94
+ 10.4. Packet Processing ........................................96
+ 10.4.1. Intercepting Packets for a Mobile Node ............96
+ 10.4.2. Processing Intercepted Packets ....................98
+
+
+
+Perkins, et al. Standards Track [Page 4]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 10.4.3. Multicast Membership Control ......................99
+ 10.4.4. Stateful Address Autoconfiguration ...............100
+ 10.4.5. Handling Reverse-Tunneled Packets ................100
+ 10.4.6. Protecting Return Routability Packets ............101
+ 10.5. Dynamic Home Agent Address Discovery ....................102
+ 10.5.1. Receiving Router Advertisement Messages ..........102
+ 10.6. Sending Prefix Information to the Mobile Node ...........104
+ 10.6.1. List of Home Network Prefixes ....................104
+ 10.6.2. Scheduling Prefix Deliveries .....................105
+ 10.6.3. Sending Advertisements ...........................107
+ 10.6.4. Lifetimes for Changed Prefixes ...................108
+ 11. Mobile Node Operation ........................................108
+ 11.1. Conceptual Data Structures ..............................108
+ 11.2. Processing Mobility Headers .............................110
+ 11.3. Packet Processing .......................................110
+ 11.3.1. Sending Packets While Away from Home .............110
+ 11.3.2. Interaction with Outbound IPsec Processing .......113
+ 11.3.3. Receiving Packets While Away from Home ...........115
+ 11.3.4. Routing Multicast Packets ........................117
+ 11.3.5. Receiving ICMP Error Messages ....................118
+ 11.3.6. Receiving Binding Error Messages .................119
+ 11.4. Home Agent and Prefix Management ........................120
+ 11.4.1. Dynamic Home Agent Address Discovery .............120
+ 11.4.2. Sending Mobile Prefix Solicitations ..............121
+ 11.4.3. Receiving Mobile Prefix Advertisements ...........121
+ 11.5. Movement ................................................123
+ 11.5.1. Movement Detection ...............................123
+ 11.5.2. Home Link Detection ..............................125
+ 11.5.3. Forming New Care-of Addresses ....................126
+ 11.5.4. Using Multiple Care-of Addresses .................127
+ 11.5.5. Returning Home ...................................127
+ 11.6. Return Routability Procedure ............................130
+ 11.6.1. Sending Test Init Messages .......................130
+ 11.6.2. Receiving Test Messages ..........................131
+ 11.6.3. Protecting Return Routability Packets ............132
+ 11.7. Processing Bindings .....................................132
+ 11.7.1. Sending Binding Updates to the Home Agent ........132
+ 11.7.2. Correspondent Registration .......................135
+ 11.7.3. Receiving Binding Acknowledgements ...............138
+ 11.7.4. Receiving Binding Refresh Requests ...............140
+ 11.8. Retransmissions and Rate Limiting .......................141
+ 12. Protocol Constants ...........................................142
+ 13. Protocol Configuration Variables .............................142
+ 14. IANA Considerations ..........................................143
+ 15. Security Considerations ......................................146
+ 15.1. Threats .................................................146
+ 15.2. Features ................................................148
+ 15.3. Binding Updates to Home Agent ...........................150
+
+
+
+Perkins, et al. Standards Track [Page 5]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 15.4. Binding Updates to Correspondent Nodes ..................152
+ 15.4.1. Overview .........................................153
+ 15.4.2. Achieved Security Properties .....................153
+ 15.4.3. Comparison to Regular IPv6 Communications ........154
+ 15.4.4. Replay Attacks ...................................156
+ 15.4.5. Denial-of-Service Attacks ........................156
+ 15.4.6. Key Lengths ......................................157
+ 15.5. Dynamic Home Agent Address Discovery ....................158
+ 15.6. Mobile Prefix Discovery .................................159
+ 15.7. Tunneling via the Home Agent ............................159
+ 15.8. Home Address Option .....................................160
+ 15.9. Type 2 Routing Header ...................................161
+ 15.10. SHA-1 Secure Enough for Mobile IPv6 Control Messages ...161
+ 16. Contributors .................................................162
+ 17. Acknowledgements .............................................162
+ 18. References ...................................................162
+ 18.1. Normative References ....................................162
+ 18.2. Informative References ..................................164
+ Appendix A. Future Extensions ....................................166
+ A.1. Piggybacking .............................................166
+ A.2. Triangular Routing .......................................166
+ A.3. New Authorization Methods ................................166
+ A.4. Neighbor Discovery Extensions ............................166
+ Appendix B. Changes since RFC 3775 ...............................167
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 6]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+1. Introduction
+
+ This document specifies a protocol that allows nodes to remain
+ reachable while moving around in the IPv6 Internet. Without specific
+ 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
+ home link. In order to continue communication in spite of its
+ movement, a mobile node could change its IP address each time it
+ moves to a new link, but the mobile node would then not be able to
+ maintain transport and higher-layer connections when it changes
+ location. Mobility support in IPv6 is particularly important, as
+ mobile computers are likely to account for a majority or at least a
+ substantial fraction of the population of the Internet during the
+ lifetime of IPv6.
+
+ The protocol defined in this document, known as Mobile IPv6, allows a
+ mobile node to move from one link to another without changing the
+ mobile node's "home address". Packets may be routed to the mobile
+ node using this address regardless of the mobile node's current point
+ of attachment to the Internet. The mobile node may also continue to
+ communicate with other nodes (stationary or mobile) after moving to a
+ new link. The movement of a mobile node away from its home link is
+ thus transparent to transport and higher-layer protocols and
+ applications.
+
+ The Mobile IPv6 protocol is just as suitable for mobility across
+ homogeneous media as for mobility across heterogeneous media. For
+ example, Mobile IPv6 facilitates node movement from one Ethernet
+ segment to another as well as it facilitates node movement from an
+ Ethernet segment to a wireless LAN cell, with the mobile node's IP
+ address remaining unchanged in spite of such movement.
+
+ One can think of the Mobile IPv6 protocol as solving the network-
+ layer mobility management problem. Some mobility management
+ applications -- for example, handover among wireless transceivers,
+ each of which covers only a very small geographic area -- have been
+ solved using link-layer techniques. For example, in many current
+ wireless LAN products, link-layer mobility mechanisms allow a
+ "handover" of a mobile node from one cell to another, re-establishing
+ link-layer connectivity to the node in each new location.
+
+ Mobile IPv6 does not attempt to solve all general problems related to
+ the use of mobile computers or wireless networks. In particular,
+ this protocol does not attempt to solve:
+
+ o Handling links with unidirectional connectivity or partial
+ reachability, such as the hidden terminal problem where a host is
+ hidden from only some of the routers on the link.
+
+
+
+Perkins, et al. Standards Track [Page 7]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Access control on a link being visited by a mobile node.
+
+ o Local or hierarchical forms of mobility management (similar to
+ many current link-layer mobility management solutions).
+
+ o Assistance for adaptive applications.
+
+ o Mobile routers.
+
+ o Service discovery.
+
+ o Distinguishing between packets lost due to bit errors versus
+ network congestion.
+
+ This document obsoletes RFC 3775. Issues with the original document
+ have been observed during the integration, testing, and deployment of
+ RFC 3775. A more detailed list of the changes since RFC 3775 may be
+ found in Appendix B.
+
+2. Comparison with Mobile IP for IPv4
+
+ The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both
+ from the experiences gained from the development of Mobile IP support
+ in IPv4 (Mobile IPv4) [32] [25] [26], and from the opportunities
+ provided by IPv6. Mobile IPv6 thus shares many features with Mobile
+ IPv4, but is integrated into IPv6 and offers many other improvements.
+ This section summarizes the major differences between Mobile IPv4 and
+ Mobile IPv6:
+
+ o There is no need to deploy special routers as "foreign agents", as
+ in Mobile IPv4. Mobile IPv6 operates in any location without any
+ special support required from the local router.
+
+ o Support for route optimization is a fundamental part of the
+ protocol, rather than a nonstandard set of extensions.
+
+ o Mobile IPv6 route optimization can operate securely even without
+ pre-arranged security associations. It is expected that route
+ optimization can be deployed on a global scale between all mobile
+ nodes and correspondent nodes.
+
+ o Support is also integrated into Mobile IPv6 for allowing route
+ optimization to coexist efficiently with routers that perform
+ "ingress filtering" [27].
+
+ o The IPv6 Neighbor Unreachability Detection ensures symmetric
+ reachability between the mobile node and its default router in the
+ current location.
+
+
+
+Perkins, et al. Standards Track [Page 8]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Most packets sent to a mobile node while away from home in Mobile
+ IPv6 are sent using an IPv6 routing header rather than IP
+ encapsulation, reducing the amount of resulting overhead compared
+ to Mobile IPv4.
+
+ o Mobile IPv6 is decoupled from any particular link layer, as it
+ uses IPv6 Neighbor Discovery [18] instead of the Address
+ Resolution Protocol (ARP). This also improves the robustness of
+ the protocol.
+
+ o The use of IPv6 encapsulation (and the routing header) removes the
+ need in Mobile IPv6 to manage "tunnel soft state".
+
+ o The dynamic home agent address discovery mechanism in Mobile IPv6
+ returns a single reply to the mobile node. The directed broadcast
+ approach used in IPv4 returns separate replies from each home
+ agent.
+
+3. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [2].
+
+3.1. General Terms
+
+ IP
+
+ Internet Protocol Version 6 (IPv6).
+
+ node
+
+ A device that implements IP.
+
+ router
+
+ A node that forwards IP packets not explicitly addressed to
+ itself.
+
+ unicast routable address
+
+ An identifier for a single interface such that a packet sent to it
+ from another IPv6 subnet is delivered to the interface identified
+ by that address. Accordingly, a unicast routable address must be
+ either a global IPv6 address or a unique local IPv6 address.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 9]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ host
+
+ Any node that is not a router.
+
+ link
+
+ A communication facility or medium over which nodes can
+ communicate at the link layer, such as an Ethernet (simple or
+ bridged). A link is the layer immediately below IP.
+
+ interface
+
+ A node's attachment to a link.
+
+ subnet prefix
+
+ A bit string that consists of some number of initial bits of an IP
+ address.
+
+ interface identifier
+
+ A number used to identify a node's interface on a link. The
+ interface identifier is the remaining low-order bits in the node's
+ IP address after the subnet prefix.
+
+ link-layer address
+
+ A link-layer identifier for an interface, such as IEEE 802
+ addresses on Ethernet links.
+
+ packet
+
+ An IP header plus payload.
+
+ security association
+
+ An IPsec security association is a cooperative relationship formed
+ by the sharing of cryptographic keying material and associated
+ context. Security associations are simplex. That is, two
+ security associations are needed to protect bidirectional traffic
+ between two nodes, one for each direction.
+
+ security policy database
+
+ A database that specifies what security services are to be offered
+ to IP packets and in what fashion.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 10]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ destination option
+
+ Destination options are carried by the IPv6 Destination Options
+ extension header. Destination options include optional
+ information that need be examined only by the IPv6 node given as
+ the destination address in the IPv6 header, not by routers in
+ between. Mobile IPv6 defines one new destination option, the Home
+ Address destination option (see Section 6.3).
+
+ routing header
+
+ A routing header may be present as an IPv6 header extension, and
+ indicates that the payload has to be delivered to a destination
+ IPv6 address in some way that is different from what would be
+ carried out by standard Internet routing. In this document, use
+ of the term "routing header" typically refers to use of a type 2
+ routing header, as specified in Section 6.4.
+
+ "|" (concatenation)
+
+ Some formulas in this specification use the symbol "|" to indicate
+ bytewise concatenation, as in A | B. This concatenation requires
+ that all of the octets of the datum A appear first in the result,
+ followed by all of the octets of the datum B.
+
+ First (size, input)
+
+ Some formulas in this specification use a functional form "First
+ (size, input)" to indicate truncation of the "input" data so that
+ only the first "size" bits remain to be used.
+
+3.2. Mobile IPv6 Terms
+
+ These terms are intended to be compatible with the definitions given
+ in RFC 3753 [40]. However, if there is any conflict, the definitions
+ given here should be considered to supersede those in RFC 3753.
+
+ home address
+
+ A unicast routable address assigned to a mobile node, used as the
+ permanent address of the mobile node. This address is within the
+ mobile node's home link. Standard IP routing mechanisms will
+ deliver packets destined for a mobile node's home address to its
+ home link. Mobile nodes can have multiple home addresses, for
+ instance, when there are multiple home prefixes on the home link.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 11]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ home subnet prefix
+
+ The IP subnet prefix corresponding to a mobile node's home
+ address.
+
+ home link
+
+ The link on which a mobile node's home subnet prefix is defined.
+
+ mobile node
+
+ A node that can change its point of attachment from one link to
+ another, while still being reachable via its home address.
+
+ movement
+
+ A change in a mobile node's point of attachment to the Internet
+ such that it is no longer connected to the same link as it was
+ previously. If a mobile node is not currently attached to its
+ home link, the mobile node is said to be "away from home".
+
+ Layer 2 (L2) handover
+
+ A process by which the mobile node changes from one link-layer
+ connection to another. For example, a change of wireless access
+ point is an L2 handover.
+
+ Layer 3 (L3) handover
+
+ Subsequent to an L2 handover, a mobile node detects a change in an
+ on-link subnet prefix that would require a change in the primary
+ care-of address. For example, a change of access router
+ subsequent to a change of wireless access point typically results
+ in an L3 handover.
+
+ correspondent node
+
+ A peer node with which a mobile node is communicating. The
+ correspondent node may be either mobile or stationary.
+
+ foreign subnet prefix
+
+ Any IP subnet prefix other than the mobile node's home subnet
+ prefix.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 12]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ foreign link
+
+ Any link other than the mobile node's home link.
+
+ care-of address
+
+ A unicast routable address associated with a mobile node while
+ visiting a foreign link; the subnet prefix of this IP address is a
+ foreign subnet prefix. Among the multiple care-of addresses that
+ a mobile node may have at any given time (e.g., with different
+ subnet prefixes), the one registered with the mobile node's home
+ agent for a given home address is called its "primary" care-of
+ address.
+
+ home agent
+
+ A router on a mobile node's home link with which the mobile node
+ has registered its current care-of address. While the mobile node
+ is away from home, the home agent intercepts packets on the home
+ link destined to the mobile node's home address, encapsulates
+ them, and tunnels them to the mobile node's registered care-of
+ address.
+
+ binding
+
+ The association of the home address of a mobile node with a
+ care-of address for that mobile node, along with the remaining
+ lifetime of that association.
+
+ registration
+
+ The process during which a mobile node sends a Binding Update to
+ its home agent or a correspondent node, causing a binding for the
+ mobile node to be registered.
+
+ mobility message
+
+ A message containing a Mobility Header (see Section 6.1).
+
+ binding authorization
+
+ Correspondent registration needs to be authorized to allow the
+ recipient to believe that the sender has the right to specify a
+ new binding.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 13]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ return routability procedure
+
+ The return routability procedure authorizes registrations by the
+ use of a cryptographic token exchange.
+
+ correspondent registration
+
+ A return routability procedure followed by a registration, run
+ between the mobile node and a correspondent node.
+
+ home registration
+
+ A registration between the mobile node and its home agent,
+ authorized by the use of IPsec.
+
+ nonce
+
+ Nonces are random numbers used internally by the correspondent
+ node in the creation of keygen tokens related to the return
+ routability procedure. The nonces are not specific to a mobile
+ node, and are kept secret within the correspondent node.
+
+ nonce index
+
+ A nonce index is used to indicate which nonces have been used when
+ creating keygen token values, without revealing the nonces
+ themselves.
+
+ cookie
+
+ A cookie is a random number used by a mobile node to prevent
+ spoofing by a bogus correspondent node in the return routability
+ procedure.
+
+ care-of init cookie
+
+ A cookie sent to the correspondent node in the Care-of Test Init
+ message, to be returned in the Care-of Test message.
+
+ home init cookie
+
+ A cookie sent to the correspondent node in the Home Test Init
+ message, to be returned in the Home Test message.
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 14]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ keygen token
+
+ A keygen token is a number supplied by a correspondent node in the
+ return routability procedure to enable the mobile node to compute
+ the necessary binding management key for authorizing a Binding
+ Update.
+
+ care-of keygen token
+
+ A keygen token sent by the correspondent node in the Care-of Test
+ message.
+
+ home keygen token
+
+ A keygen token sent by the correspondent node in the Home Test
+ message.
+
+ binding management key (Kbm)
+
+ A binding management key (Kbm) is a key used for authorizing a
+ binding cache management message (e.g., Binding Update or Binding
+ Acknowledgement). Return routability provides a way to create a
+ binding management key.
+
+4. Overview of Mobile IPv6
+
+4.1. Basic Operation
+
+ A mobile node is always expected to be addressable at its home
+ address, whether it is currently attached to its home link or is away
+ from home. The "home address" is an IP address assigned to the
+ mobile node within its home subnet prefix on its home link. While a
+ mobile node is at home, packets addressed to its home address are
+ routed to the mobile node's home link, using conventional Internet
+ routing mechanisms.
+
+ While a mobile node is attached to some foreign link away from home,
+ it is also addressable at one or more care-of addresses. A care-of
+ address is an IP address associated with a mobile node that has the
+ subnet prefix of a particular foreign link. The mobile node can
+ acquire its care-of address through conventional IPv6 mechanisms,
+ such as stateless or stateful auto-configuration. As long as the
+ mobile node stays in this location, packets addressed to this care-of
+ address will be routed to the mobile node. The mobile node may also
+ accept packets from several care-of addresses, such as when it is
+ moving but still reachable at the previous link.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 15]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The association between a mobile node's home address and care-of
+ address is known as a "binding" for the mobile node. While away from
+ home, a mobile node registers its primary care-of address with a
+ router on its home link, requesting this router to function as the
+ "home agent" for the mobile node. The mobile node performs this
+ binding registration by sending a "Binding Update" message to the
+ home agent. The home agent replies to the mobile node by returning a
+ "Binding Acknowledgement" message. The operation of the mobile node
+ is specified in Section 11, and the operation of the home agent is
+ specified in Section 10.
+
+ Any node communicating with a mobile node is referred to in this
+ document as a "correspondent node" of the mobile node, and may itself
+ be either a stationary node or a mobile node. Mobile nodes can
+ provide information about their current location to correspondent
+ nodes. This happens through the correspondent registration. As a
+ part of this procedure, a return routability test is performed in
+ order to authorize the establishment of the binding. The operation
+ of the correspondent node is specified in Section 9.
+
+ There are two possible modes for communications between the mobile
+ node and a correspondent node. The first mode, bidirectional
+ tunneling, does not require Mobile IPv6 support from the
+ correspondent node and is available even if the mobile node has not
+ registered its current binding with the correspondent node. Packets
+ from the correspondent node are routed to the home agent and then
+ tunneled to the mobile node. Packets to the correspondent node are
+ tunneled from the mobile node to the home agent ("reverse tunneled")
+ and then routed normally from the home network to the correspondent
+ node. In this mode, the home agent uses proxy Neighbor Discovery to
+ intercept any IPv6 packets addressed to the mobile node's home
+ address (or home addresses) on the home link. Each intercepted
+ packet is tunneled to the mobile node's primary care-of address.
+ This tunneling is performed using IPv6 encapsulation [7].
+
+ The second mode, "route optimization", requires the mobile node to
+ register its current binding at the correspondent node. Packets from
+ the correspondent node can be routed directly to the care-of address
+ of the mobile node. When sending a packet to any IPv6 destination,
+ the correspondent node checks its cached bindings for an entry for
+ the packet's destination address. If a cached binding for this
+ destination address is found, the node uses a new type of IPv6
+ routing header [6] (see Section 6.4) to route the packet to the
+ mobile node by way of the care-of address indicated in this binding.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 16]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Routing packets directly to the mobile node's care-of address allows
+ the shortest communications path to be used. It also eliminates
+ congestion at the mobile node's home agent and home link. In
+ addition, the impact of temporary failures of the home agent or
+ networks on the path to or from the home agent is reduced.
+
+ When routing packets directly to the mobile node, the correspondent
+ node sets the Destination Address in the IPv6 header to the care-of
+ address of the mobile node. A new type of IPv6 routing header (see
+ Section 6.4) is also added to the packet to carry the desired home
+ address. Similarly, the mobile node sets the Source Address in the
+ packet's IPv6 header to its current care-of addresses. The mobile
+ node adds a new IPv6 "Home Address" destination option (see
+ Section 6.3) to carry its home address. The inclusion of home
+ addresses in these packets makes the use of the care-of address
+ transparent above the network layer (e.g., at the transport layer).
+
+ Mobile IPv6 also provides support for multiple home agents, and a
+ limited support for the reconfiguration of the home network. In
+ 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.
+ A mechanism known as "dynamic home agent address discovery" allows a
+ 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
+ nodes can also learn new information about home subnet prefixes
+ through the "mobile prefix discovery" mechanism. These mechanisms
+ are described starting in Section 6.5.
+
+ This document is written under the assumption that the mobile node is
+ configured with the home prefix for the mobile node to be able to
+ discover a home agent and configure a home address. This might be
+ limiting in deployments where the home agent and the home address for
+ the mobile node need to be assigned dynamically. Additional
+ mechanisms have been specified for the mobile node to dynamically
+ configure a home agent, a home address, and the home prefix. These
+ mechanisms are described in "Mobile IPv6 Bootstrapping in Split
+ Scenario" [22] and "MIP6-bootstrapping for the Integrated Scenario"
+ [36].
+
+4.2. New IPv6 Protocol
+
+ Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header
+ (see Section 6.1). This header is used to carry the following
+ messages:
+
+ Home Test Init
+
+ Home Test
+
+
+
+Perkins, et al. Standards Track [Page 17]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Care-of Test Init
+
+ Care-of Test
+
+ These four messages are used to perform the return routability
+ procedure from the mobile node to a correspondent node. This
+ ensures authorization of subsequent Binding Updates, as described
+ in Section 5.2.5.
+
+ Binding Update
+
+ A Binding Update is used by a mobile node to notify a
+ correspondent node or the mobile node's home agent of its current
+ binding. The Binding Update sent to the mobile node's home agent
+ to register its primary care-of address is marked as a "home
+ registration".
+
+ Binding Acknowledgement
+
+ A Binding Acknowledgement is used to acknowledge receipt of a
+ Binding Update, if an acknowledgement was requested in the Binding
+ Update (e.g., the Binding Update was sent to a home agent), or an
+ error occurred.
+
+ Binding Refresh Request
+
+ A Binding Refresh Request is used by a correspondent node to
+ request that a mobile node re-establish its binding with the
+ correspondent node. This message is typically used when the
+ cached binding is in active use but the binding's lifetime is
+ close to expiration. The correspondent node may use, for
+ instance, recent traffic and open transport layer connections as
+ an indication of active use.
+
+ Binding Error
+
+ The Binding Error is used by the correspondent node to signal an
+ error related to mobility, such as an inappropriate attempt to use
+ the Home Address destination option without an existing binding.
+ The Binding Error message is also used by the home agent to signal
+ an error to the mobile node, if it receives an unrecognized
+ Mobility Header Message Type from the mobile node.
+
+4.3. New IPv6 Destination Option
+
+ Mobile IPv6 defines a new IPv6 destination option, the Home Address
+ destination option. This option is described in detail in
+ Section 6.3.
+
+
+
+Perkins, et al. Standards Track [Page 18]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+4.4. New IPv6 ICMP Messages
+
+ Mobile IPv6 also introduces four new ICMP message types, two for use
+ in the dynamic home agent address discovery mechanism, and two for
+ renumbering and mobile configuration mechanisms. As described in
+ Sections 10.5 and 11.4.1, the following two new ICMP message types
+ are used for home agent address discovery:
+
+ o Home Agent Address Discovery Request, described in Section 6.5.
+
+ o Home Agent Address Discovery Reply, described in Section 6.6.
+
+ The next two message types are used for network renumbering and
+ address configuration on the mobile node, as described in
+ Section 10.6:
+
+ o Mobile Prefix Solicitation, described in Section 6.7.
+
+ o Mobile Prefix Advertisement, described in Section 6.8.
+
+4.5. Conceptual Data Structure Terminology
+
+ This document describes the Mobile IPv6 protocol in terms of the
+ following conceptual data structures:
+
+ Binding Cache
+
+ A cache of bindings for other nodes. This cache is maintained by
+ home agents and correspondent nodes. The cache contains both
+ "correspondent registration" entries (see Section 9.1) and "home
+ registration" entries (see Section 10.1).
+
+ Binding Update List
+
+ This list is maintained by each mobile node. The list has an item
+ for every binding that the mobile node has or is trying to
+ establish with a specific other node. Both correspondent and home
+ registrations are included in this list. Entries from the list
+ are deleted as the lifetime of the binding expires. See
+ Section 11.1.
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 19]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Home Agents List
+
+ Home agents need to know which other home agents are on the same
+ link. This information is stored in the Home Agents List, as
+ described in more detail in Section 10.1. The list is used for
+ informing mobile nodes during dynamic home agent address
+ discovery.
+
+4.6. Unique-Local Addressability
+
+ This specification requires that home and care-of addresses MUST be
+ unicast routable addresses. Unique-local IPv6 unicast addresses
+ (ULAs, RFC 4193 [15]) may be usable on networks that use such non-
+ globally routable addresses, but this specification does not define
+ when such usage is safe and when it is not. Mobile nodes may not be
+ able to distinguish between their home site and the site at which
+ they are currently located. This can make it hard to prevent
+ accidental attachment to other sites, because the mobile node might
+ use the ULA at another site, which could not be used to successfully
+ send packets to the mobile node's home agent (HA). This would result
+ in unreachability between the mobile node (MN) and the HA, when
+ unique-local IPv6 routable addresses are used as care-of addresses.
+ Similarly, CNs outside the MN's own site will not be reachable when
+ ULAs are used as home addresses. Therefore, unique-local IPv6
+ unicast addresses SHOULD NOT be used as home or care-of addresses
+ when other address choices are available. If such addresses are
+ used, however, according to RFC 4193 [15], they are treated as any
+ global unicast IPv6 address so, for the remainder of this
+ specification, use of unique-local IPv6 unicast addresses is not
+ differentiated from other globally unique IPv6 addresses.
+
+5. Overview of Mobile IPv6 Security
+
+ This specification provides a number of security features. These
+ include the protection of Binding Updates both to home agents and
+ correspondent nodes, the protection of mobile prefix discovery, and
+ the protection of the mechanisms that Mobile IPv6 uses for
+ transporting data packets.
+
+ Binding Updates are protected by the use of IPsec extension headers,
+ or by the use of the Binding Authorization Data option. This option
+ employs a binding management key, Kbm, which can be established
+ through the return routability procedure. Mobile prefix discovery is
+ protected through the use of IPsec extension headers. Mechanisms
+ related to transporting payload packets -- such as the Home Address
+ destination option and type 2 routing header -- have been specified
+ in a manner that restricts their use in attacks.
+
+
+
+
+Perkins, et al. Standards Track [Page 20]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+5.1. Binding Updates to Home Agents
+
+ The mobile node and the home agent MUST use an IPsec security
+ association to protect the integrity and authenticity of the Binding
+ Updates and Acknowledgements. Both the mobile nodes and the home
+ agents MUST support and SHOULD use the Encapsulating Security Payload
+ (ESP) [5] header in transport mode and MUST use a non-NULL payload
+ authentication algorithm to provide data origin authentication,
+ connectionless integrity, and optional anti-replay protection. Note
+ that Authentication Header (AH) [4] is also possible but for brevity
+ not discussed in this specification.
+
+ In order to protect messages exchanged between the mobile node and
+ the home agent with IPsec, appropriate security policy database
+ entries must be created. A mobile node must be prevented from using
+ its security association to send a Binding Update on behalf of
+ another mobile node using the same home agent. This MUST be achieved
+ by having the home agent check that the given home address has been
+ used with the right security association. Such a check is provided
+ in the IPsec processing, by having the security policy database
+ entries unequivocally identify a single security association for
+ protecting Binding Updates between any given home address and home
+ agent. In order to make this possible, it is necessary that the home
+ address of the mobile node is visible in the Binding Updates and
+ Acknowledgements. The home address is used in these packets as a
+ source or destination, or in the Home Address destination option or
+ the type 2 routing header.
+
+ As with all IPsec security associations in this specification, manual
+ configuration of security associations MUST be supported. The shared
+ secrets used MUST be random and unique for different mobile nodes,
+ and MUST be distributed off-line to the mobile nodes. Automatic key
+ management with the Internet Key Exchange Protocol version 2 (IKEv2)
+ [24] MAY be supported as described in [20].
+
+ Section 11.3.2 discusses how IKEv2 connections to the home agent need
+ a careful treatment of the addresses used for transporting IKEv2.
+ This is necessary to ensure that a Binding Update is not needed
+ before the IKEv2 exchange that is needed for securing the Binding
+ Update.
+
+ More detailed descriptions and examples using IPsec to protect
+ communications between the mobile node and the home agent have been
+ published [12][20].
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 21]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+5.2. Binding Updates to Correspondent Nodes
+
+ The protection of Binding Updates sent to correspondent nodes does
+ not require the configuration of security associations or the
+ existence of an authentication infrastructure between the mobile
+ nodes and correspondent nodes. Instead, a method called the return
+ routability procedure is used to ensure that the right mobile node is
+ sending the message. This method does not protect against attackers
+ who are on the path between the home network and the correspondent
+ node. However, attackers in such a location are capable of
+ performing the same attacks even without Mobile IPv6. The main
+ advantage of the return routability procedure is that it limits the
+ 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. For a more in-depth explanation of the security
+ properties of the return routability procedure, see Section 15.
+ Also, consult [43].
+
+ The integrity and authenticity of the Binding Update messages to
+ correspondent nodes are protected by using a keyed-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
+ return routability procedure. The data exchange is accomplished by
+ use of node keys, nonces, cookies, tokens, and certain cryptographic
+ functions. Section 5.2.5 outlines the basic return routability
+ procedure. Section 5.2.6 shows how the results of this procedure are
+ used to authorize a Binding Update to a correspondent node.
+
+5.2.1. Node Keys
+
+ Each correspondent node has a secret key, Kcn, called the "node key",
+ which it uses to produce the keygen tokens sent to the mobile nodes.
+ The node key MUST be a random number, 20 octets in length. The node
+ key allows the correspondent node to verify that the keygen tokens
+ used by the mobile node in authorizing a Binding Update are indeed
+ its own. This key MUST NOT be shared with any other entity.
+
+ A correspondent node MAY generate a fresh node key at any time; this
+ avoids the need for secure persistent key storage. Procedures for
+ optionally updating the node key are discussed later in
+ Section 5.2.7.
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 22]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+5.2.2. Nonces
+
+ Each correspondent node also generates nonces at regular intervals.
+ The nonces should be generated by using a random number generator
+ that is known to have good randomness properties [14]. A
+ correspondent node may use the same Kcn and nonce with all the mobile
+ nodes with which it is in communication.
+
+ Each nonce is identified by a nonce index. When a new nonce is
+ generated, it must be associated with a new nonce index; this may be
+ done, for example, by incrementing the value of the previous nonce
+ index, if the nonce index is used as an array pointer into a linear
+ array of nonces. However, there is no requirement that nonces be
+ stored that way, or that the values of subsequent nonce indices have
+ any particular relationship to each other. The index value is
+ communicated in the protocol, so that if a nonce is replaced by a new
+ nonce during the run of a protocol, the correspondent node can
+ distinguish messages that should be checked against the old nonce
+ from messages that should be checked against the new nonce. Strictly
+ speaking, indices are not necessary in the authentication, but allow
+ the correspondent node to efficiently find the nonce value that it
+ used in creating a keygen token.
+
+ Correspondent nodes keep both the current nonce and a small set of
+ valid previous nonces whose lifetime has not yet expired. Expired
+ values MUST be discarded, and messages using stale or unknown indices
+ will be rejected.
+
+ The specific nonce index values cannot be used by mobile nodes to
+ determine the validity of the nonce. Expected validity times for the
+ nonces values and the procedures for updating them are discussed
+ later in Section 5.2.7.
+
+ A nonce is an octet string of any length. The recommended length is
+ 64 bits.
+
+5.2.3. Cookies and Tokens
+
+ The return routability address test procedure uses cookies and keygen
+ tokens as opaque values within the test init and test messages,
+ respectively.
+
+ o The "home init cookie" and "care-of init cookie" are 64-bit values
+ sent to the correspondent node from the mobile node, and later
+ returned to the mobile node. The home init cookie is sent in the
+ Home Test Init message, and returned in the Home Test message.
+ The care-of init cookie is sent in the Care-of Test Init message,
+ and returned in the Care-of Test message.
+
+
+
+Perkins, et al. Standards Track [Page 23]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The "home keygen token" and "care-of keygen token" are 64-bit
+ values sent by the correspondent node to the mobile node via the
+ home agent (via the Home Test message) and the care-of address (by
+ the Care-of Test message), respectively.
+
+ The mobile node should set the home init or care-of init cookie to a
+ newly generated random number in every Home or Care-of Test Init
+ message it sends. The cookies are used to verify that the Home Test
+ or Care-of Test message matches the Home Test Init or Care-of Test
+ Init message, respectively. These cookies also serve to ensure that
+ parties who have not seen the request cannot spoof responses.
+
+ 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
+ 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
+ are valid.
+
+5.2.4. Cryptographic Functions
+
+ By default in this specification, the function used to compute hash
+ values is SHA-1 [11], which is considered to offer sufficient
+ protection for Mobile IPv6 control messages (see Section 15.10).
+ 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
+
+ The return routability procedure enables the correspondent node to
+ obtain some reasonable assurance that the mobile node is in fact
+ addressable at its claimed care-of address as well as at its home
+ address. Only with this assurance is the correspondent node able to
+ accept Binding Updates from the mobile node, which would then
+ instruct the correspondent node to direct that mobile node's data
+ traffic to its claimed care-of address.
+
+ This is done by testing whether packets addressed to the two claimed
+ addresses are routed to the mobile node. The mobile node can pass
+ the test only if it is able to supply proof that it received certain
+ data (the "keygen tokens") that the correspondent node sends to those
+ addresses. These data are combined by the mobile node into a binding
+ management key, denoted Kbm.
+
+ The figure below shows the message flow for the return routability
+ procedure.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 24]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Mobile node Home agent Correspondent node
+ | |
+ | Home Test Init (HoTI) | |
+ |------------------------->|------------------------->|
+ | | |
+ | Care-of Test Init (CoTI) |
+ |---------------------------------------------------->|
+ | |
+ | | Home Test (HoT) |
+ |<-------------------------|<-------------------------|
+ | | |
+ | Care-of Test (CoT) |
+ |<----------------------------------------------------|
+ | |
+
+ The Home and Care-of Test Init messages are sent at the same time.
+ The procedure requires very little processing at the correspondent
+ node, and the Home and Care-of Test messages can be returned quickly,
+ perhaps nearly simultaneously. These four messages form the return
+ routability procedure.
+
+ Home Test Init
+
+ A mobile node sends a Home Test Init message to the correspondent
+ node (via the home agent) to acquire the home keygen token. The
+ contents of the message can be summarized as follows:
+
+ * Source Address = home address
+
+ * Destination Address = correspondent
+
+ * Parameters:
+
+ + home init cookie
+
+ The Home Test Init message conveys the mobile node's home address
+ to the correspondent node. The mobile node also sends along a
+ home init cookie that the correspondent node must return later.
+ The Home Test Init message is reverse tunneled through the home
+ agent. (The headers and addresses related to reverse tunneling
+ have been omitted from the above discussion of the message
+ contents.) The mobile node remembers these cookie values to
+ obtain some assurance that its protocol messages are being
+ processed by the desired correspondent node.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 25]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Care-of Test Init
+
+ The mobile node sends a Care-of Test Init message to the
+ correspondent node (directly, not via the home agent) to acquire
+ the care-of keygen token. The contents of this message can be
+ summarized as follows:
+
+ * Source Address = care-of address
+
+ * Destination Address = correspondent
+
+ * Parameters:
+
+ + care-of init cookie
+
+ The Care-of Test Init message conveys the mobile node's care-of
+ address to the correspondent node. The mobile node also sends
+ along a care-of init cookie that the correspondent node must
+ return later. The Care-of Test Init message is sent directly to
+ the correspondent node.
+
+ Home Test
+
+ The Home Test message is sent in response to a Home Test Init
+ message. It is sent via the home agent. The contents of the
+ message are:
+
+ * Source Address = correspondent
+
+ * Destination Address = home address
+
+ * Parameters:
+
+ + home init cookie
+
+ + home keygen token
+
+ + home nonce index
+
+ When the correspondent node receives the Home Test Init message,
+ it generates a home keygen token as follows:
+
+ home keygen token :=
+ First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
+
+ where | denotes concatenation. The final "0" inside the HMAC_SHA1
+ function is a single zero octet, used to distinguish home and care-of
+ cookies from each other.
+
+
+
+Perkins, et al. Standards Track [Page 26]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The home keygen token is formed from the first 64 bits of the MAC.
+ The home keygen token tests that the mobile node can receive messages
+ sent to its home address. Kcn is used in the production of home
+ keygen token in order to allow the correspondent node to verify that
+ it generated the home and care-of nonces, without forcing the
+ correspondent node to remember a list of all tokens it has handed
+ out.
+
+ The Home Test message is sent to the mobile node via the home
+ network, where it is presumed that the home agent will tunnel the
+ message to the mobile node. This means that the mobile node needs to
+ already have sent a Binding Update to the home agent, so that the
+ home agent will have received and authorized the new care-of address
+ for the mobile node before the return routability procedure. For
+ improved security, the data passed between the home agent and the
+ mobile node is made immune to inspection and passive attacks. Such
+ protection is gained by encrypting the home keygen token as it is
+ tunneled from the home agent to the mobile node as specified in
+ Section 10.4.6. The security properties of this additional security
+ are discussed in Section 15.4.1.
+
+ The home init cookie from the mobile node is returned in the Home
+ Test message, to ensure that the message comes from a node on the
+ route between the home agent and the correspondent node.
+
+ The home nonce index is delivered to the mobile node to later allow
+ the correspondent node to efficiently find the nonce value that it
+ used in creating the home keygen token.
+
+ Care-of Test
+
+ This message is sent in response to a Care-of Test Init message.
+ This message is not sent via the home agent; it is sent directly
+ to the mobile node. The contents of the message are:
+
+ * Source Address = correspondent
+
+ * Destination Address = care-of address
+
+ * Parameters:
+
+ + care-of init cookie
+
+ + care-of keygen token
+
+ + care-of nonce index
+
+
+
+
+
+Perkins, et al. Standards Track [Page 27]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ When the correspondent node receives the Care-of Test Init
+ message, it generates a care-of keygen token as follows:
+
+ care-of keygen token :=
+ First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))
+
+ Here, the final "1" inside the HMAC_SHA1 function is a single octet
+ containing the hex value 0x01, and is used to distinguish home and
+ care-of cookies from each other. The keygen token is formed from the
+ first 64 bits of the MAC, and sent directly to the mobile node at its
+ care-of address. The care-of init cookie from the Care-of Test Init
+ message is returned to ensure that the message comes from a node on
+ the route to the correspondent node.
+
+ 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 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
+ messages, the return routability procedure is complete. As a result
+ 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
+ tokens together to form a 20-octet binding key Kbm:
+
+ Kbm = SHA-1 (home keygen token | care-of keygen token)
+
+ 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
+ not used. Instead, the binding management key is generated as
+ follows:
+
+ Kbm = SHA-1(home keygen token)
+
+ Note that the correspondent node does not create any state specific
+ to the mobile node, until it receives the Binding Update from that
+ mobile node. The correspondent node does not maintain the value for
+ the binding management key Kbm; it creates Kbm when given the nonce
+ indices and the mobile node's addresses.
+
+5.2.6. Authorizing Binding Management Messages
+
+ After the mobile node has created the binding management key (Kbm),
+ it can supply a verifiable Binding Update to the correspondent node.
+ This section provides an overview of this registration. The figure
+ below shows the message flow.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 28]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Mobile node Correspondent node
+ | |
+ | Binding Update (BU) |
+ |---------------------------------------------->|
+ | (MAC, seq#, nonce indices, care-of address) |
+ | |
+ | |
+ | Binding Acknowledgement (BA) (if sent) |
+ |<----------------------------------------------|
+ | (MAC, seq#, status) |
+
+ Binding Update
+
+ To authorize a Binding Update, the mobile node creates a binding
+ management key Kbm from the keygen tokens as described in the
+ previous section. The contents of the Binding Update include the
+ following:
+
+ * Source Address = care-of address
+
+ * Destination Address = correspondent
+
+ * Parameters:
+
+ + home address (within the Home Address destination option if
+ different from the Source Address)
+
+ + sequence number (within the Binding Update message header)
+
+ + home nonce index (within the Nonce Indices option)
+
+ + care-of nonce index (within the Nonce Indices option)
+
+ + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
+ | BU)))
+
+ The Binding Update contains a Nonce Indices option, indicating to
+ the correspondent node which home and care-of nonces to use to
+ recompute Kbm, the binding management key. The MAC is computed as
+ described in Section 6.2.7, using the correspondent node's address
+ as the destination address and the Binding Update message itself
+ ("BU" above) as the Mobility Header (MH) Data.
+
+ Once the correspondent node has verified the MAC, it can create a
+ Binding Cache entry for the mobile.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 29]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Binding Acknowledgement
+
+ The Binding Update is in some cases acknowledged by the
+ correspondent node. The contents of the message are as follows:
+
+ * Source Address = correspondent
+
+ * Destination Address = care-of address
+
+ * Parameters:
+
+ + sequence number (within the Binding Update message header)
+
+ + First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
+ | BA)))
+
+ The Binding Acknowledgement contains the same sequence number as
+ the Binding Update. The MAC is computed as described in
+ Section 6.2.7, using the correspondent node's address as the
+ destination address and the message itself ("BA" above) as the MH
+ Data.
+
+ Bindings established with correspondent nodes using keys created by
+ way of the return routability procedure MUST NOT exceed
+ MAX_RR_BINDING_LIFETIME seconds (see Section 12).
+
+ The value in the Source Address field in the IPv6 header carrying the
+ Binding Update is normally also the care-of address that is used in
+ the binding. However, a different care-of address MAY be specified
+ by including an Alternate Care-of Address mobility option in the
+ Binding Update (see Section 6.2.5). When such a message is sent to
+ the correspondent node and the return routability procedure is used
+ as the authorization method, the Care-of Test Init and Care-of Test
+ messages MUST have been performed for the address in the Alternate
+ Care-of Address option (not the Source Address). The nonce indices
+ and MAC value MUST be based on information gained in this test.
+
+ Binding Updates may also be sent to delete a previously established
+ binding. In this case, generation of the binding management key
+ depends exclusively on the home keygen token and the care-of nonce
+ index is ignored.
+
+5.2.7. Updating Node Keys and Nonces
+
+ Correspondent nodes generate nonces at regular intervals. It is
+ recommended to keep each nonce (identified by a nonce index)
+ acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12)
+ after it has been first used in constructing a return routability
+
+
+
+Perkins, et al. Standards Track [Page 30]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ message response. However, the correspondent node MUST NOT accept
+ nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the
+ first use. As the difference between these two constants is 30
+ seconds, a convenient way to enforce the above lifetimes is to
+ generate a new nonce every 30 seconds. The node can then continue to
+ accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME
+ / 30) nonces. This results in tokens being acceptable
+ MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been
+ sent to the mobile node, depending on whether the token was sent at
+ the beginning or end of the first 30-second period. Note that the
+ correspondent node may also attempt to generate new nonces on demand,
+ or only if the old nonces have been used. This is possible, as long
+ as the correspondent node keeps track of how long a time ago the
+ nonces were used for the first time, and does not generate new nonces
+ on every return routability request.
+
+ Due to resource limitations, rapid deletion of bindings, or reboots
+ the correspondent node may not in all cases recognize the nonces that
+ the tokens were based on. If a nonce index is unrecognized, the
+ correspondent node replies with an error code in the Binding
+ Acknowledgement (either 136, 137, or 138 as discussed in
+ Section 6.1.8). The mobile node can then retry the return
+ routability procedure.
+
+ An update of Kcn SHOULD be done at the same time as an update of a
+ nonce, so that nonce indices can identify both the nonce and the key.
+ Old Kcn values have to be therefore remembered as long as old nonce
+ values.
+
+ Given that the tokens are normally expected to be usable for
+ MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a
+ single run of the return routability procedure until
+ MAX_TOKEN_LIFETIME expires. After this the mobile node SHOULD NOT
+ use the tokens. A fast moving mobile node MAY reuse a recent home
+ keygen token from a correspondent node when moving to a new location,
+ and just acquire a new care-of keygen token to show routability in
+ the new location.
+
+ While this does not save the number of round-trips due to the
+ simultaneous processing of home and care-of return routability tests,
+ there are fewer messages being exchanged, and a potentially long
+ round-trip through the home agent is avoided. Consequently, this
+ optimization is often useful. A mobile node that has multiple home
+ addresses MAY also use the same care-of keygen token for Binding
+ Updates concerning all of these addresses.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 31]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+5.2.8. Preventing Replay Attacks
+
+ The return routability procedure also protects the participants
+ against replayed Binding Updates through the use of the sequence
+ number and a MAC. Care must be taken when removing bindings at the
+ correspondent node, however. Correspondent nodes must retain
+ bindings and the associated sequence number information at least as
+ long as the nonces used in the authorization of the binding are still
+ valid. Alternatively, if memory is very constrained, the
+ correspondent node MAY invalidate the nonces that were used for the
+ binding being deleted (or some larger group of nonces that they
+ belong to). This may, however, impact the ability to accept Binding
+ Updates from mobile nodes that have recently received keygen tokens.
+ 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 signaling 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 signaling 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 tunneling 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 optimized connection to the mobile node.
+ If such indications are received, the mobile node MAY revert to
+ bidirectional tunneling while restarting the return routability
+ procedure.
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 32]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+5.3. Dynamic Home Agent Address Discovery
+
+ Dynamic home agent address discovery has been designed for use in
+ deployments where security is not needed. For this reason, no
+ security solution is provided in this document for dynamic home agent
+ address discovery.
+
+5.4. Mobile Prefix Discovery
+
+ The mobile node and the home agent SHOULD use an IPsec security
+ association to protect the integrity and authenticity of the Mobile
+ Prefix Solicitations and Advertisements. Both the mobile nodes and
+ the home agents MUST support and SHOULD use the Encapsulating
+ Security Payload (ESP) header in transport mode with a non-NULL
+ payload authentication algorithm to provide data origin
+ authentication, connectionless integrity, and optional anti-replay
+ protection.
+
+5.5. Payload Packets
+
+ Payload packets exchanged with mobile nodes can be protected in the
+ usual manner, in the same way as stationary hosts can protect them.
+ However, Mobile IPv6 introduces the Home Address destination option,
+ a routing header, and tunneling headers in the payload packets. In
+ the following we define the security measures taken to protect these,
+ and to prevent their use in attacks against other parties.
+
+ This specification limits the use of the Home Address destination
+ option to the situation where the correspondent node already has a
+ Binding Cache entry for the given home address. This avoids the use
+ of the Home Address option in attacks described in Section 15.1.
+
+ Mobile IPv6 uses a type of routing header specific to Mobile IPv6.
+ This type provides the necessary functionality but does not open
+ vulnerabilities discussed in Section 15.1 and RFC 5095 [45].
+
+ Tunnels between the mobile node and the home agent are protected by
+ ensuring proper use of source addresses, and optional cryptographic
+ protection. The mobile node verifies that the outer IP address
+ corresponds to its home agent. The home agent verifies that the
+ outer IP address corresponds to the current location of the mobile
+ node (Binding Updates sent to the home agents are secure). The home
+ agent identifies the mobile node through the source address of the
+ inner packet. (Typically, this is the home address of the mobile
+ node, but it can also be a link-local address, as discussed in
+ Section 10.4.2. To recognize the latter type of addresses, the home
+
+
+
+
+
+Perkins, et al. Standards Track [Page 33]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ agent requires that the Link-Local Address Compatibility (L) was set
+ in the Binding Update.) These measures protect the tunnels against
+ vulnerabilities discussed in Section 15.1.
+
+ For traffic tunneled via the home agent, additional IPsec ESP
+ encapsulation MAY be supported and used. If multicast group
+ membership control protocols or stateful address autoconfiguration
+ protocols are supported, payload data protection MUST be supported.
+
+6. New IPv6 Protocol, Message Types, and Destination Option
+
+6.1. Mobility Header
+
+ The Mobility Header is an extension header used by mobile nodes,
+ correspondent nodes, and home agents in all messaging related to the
+ creation and management of bindings. The subsections within this
+ section describe the message types that may be sent using the
+ Mobility Header.
+
+ Mobility Header messages MUST NOT be sent with a type 2 routing
+ header, except as described in Section 9.5.4 for Binding
+ Acknowledgement. Mobility Header messages also MUST NOT be used with
+ a Home Address destination option, except as described in Sections
+ 11.7.1 and 11.7.2 for Binding Update. Binding Update List or Binding
+ Cache information (when present) for the destination MUST NOT be used
+ in sending Mobility Header messages. That is, Mobility Header
+ messages bypass both the Binding Cache check described in
+ Section 9.3.2 and the Binding Update List check described in
+ Section 11.3.1 that are normally performed for all packets. This
+ applies even to messages sent to or from a correspondent node that is
+ itself a mobile node.
+
+6.1.1. Format
+
+ The Mobility Header is identified by a Next Header value of 135 in
+ the immediately preceding header, and has the following format:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Payload Proto | Header Len | MH Type | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ . .
+ . Message Data .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Perkins, et al. Standards Track [Page 34]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Payload Proto
+
+ 8-bit selector. Identifies the type of header immediately
+ following the Mobility Header. Uses the same values as the IPv6
+ Next Header field [6].
+
+ This field is intended to be used by a future extension (see
+ Appendix A.1).
+
+ Implementations conforming to this specification SHOULD set the
+ payload protocol type to IPPROTO_NONE (59 decimal).
+
+ Header Len
+
+ 8-bit unsigned integer, representing the length of the Mobility
+ Header in units of 8 octets, excluding the first 8 octets.
+
+ The length of the Mobility Header MUST be a multiple of 8 octets.
+
+ MH Type
+
+ 8-bit selector. Identifies the particular mobility message in
+ question. Current values are specified in Section 6.1.2 and
+ onward. An unrecognized MH Type field causes an error indication
+ to be sent.
+
+ Reserved
+
+ 8-bit field reserved for future use. The value MUST be
+ initialized to zero by the sender, and MUST be ignored by the
+ receiver.
+
+ Checksum
+
+ 16-bit unsigned integer. This field contains the checksum of the
+ Mobility Header. The checksum is calculated from the octet string
+ consisting of a "pseudo-header" followed by the entire Mobility
+ Header starting with the Payload Proto field. The checksum is the
+ 16-bit one's complement of the one's complement sum of this
+ string.
+
+ The pseudo-header contains IPv6 header fields, as specified in
+ Section 8.1 of RFC 2460 [6]. The Next Header value used in the
+ pseudo-header is 135. The addresses used in the pseudo-header are
+ the addresses that appear in the Source and Destination Address
+ fields in the IPv6 packet carrying the Mobility Header.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 35]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Note that the procedures of calculating upper-layer checksums
+ while away from home described in Section 11.3.1 apply even for
+ the Mobility Header. If a mobility message has a Home Address
+ destination option, then the checksum calculation uses the home
+ address in this option as the value of the IPv6 Source Address
+ field. The type 2 routing header is treated as explained in [6].
+
+ The Mobility Header is considered as the upper-layer protocol for
+ the purposes of calculating the pseudo-header. The Upper-Layer
+ Packet Length field in the pseudo-header MUST be set to the total
+ length of the Mobility Header.
+
+ For computing the checksum, the checksum field is set to zero.
+
+ Message Data
+
+ A variable-length field containing the data specific to the
+ indicated Mobility Header type.
+
+ Mobile IPv6 also defines a number of "mobility options" for use
+ within these messages; if included, any options MUST appear after the
+ fixed portion of the message data specified in this document. The
+ presence of such options will be indicated by the Header Len field
+ within the message. When the Header Len value is greater than the
+ length required for the message specified here, the remaining octets
+ are interpreted as mobility options. These options include padding
+ options that can be used to ensure that other options are aligned
+ properly, and that the total length of the message is divisible by 8.
+ The encoding and format of defined options are described in
+ Section 6.2.
+
+ Alignment requirements for the Mobility Header are the same as for
+ any IPv6 protocol header. That is, they MUST be aligned on an
+ 8-octet boundary.
+
+6.1.2. Binding Refresh Request Message
+
+ The Binding Refresh Request (BRR) message requests a mobile node to
+ update its mobility binding. This message is sent by correspondent
+ nodes according to the rules in Section 9.5.5. When a mobile node
+ receives a packet containing a Binding Refresh Request message it
+ processes the message according to the rules in Section 11.7.4.
+
+ The Binding Refresh Request message uses the MH Type value 0. When
+ this value is indicated in the MH Type field, the format of the
+ Message Data field in the Mobility Header is as follows:
+
+
+
+
+
+Perkins, et al. Standards Track [Page 36]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Reserved
+
+ 16-bit field reserved for future use. The value MUST be
+ initialized to zero by the sender, and MUST be ignored by the
+ receiver.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The encoding
+ and format of defined options are described in Section 6.2. The
+ receiver MUST ignore and skip any options that it does not
+ understand.
+
+ There MAY be additional information, associated with this Binding
+ Refresh Request message that need not be present in all Binding
+ Refresh Request messages sent. Mobility options allow future
+ extensions to the format of the Binding Refresh Request message to
+ be defined. This specification does not define any options valid
+ for the Binding Refresh Request message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 0.
+
+6.1.3. Home Test Init Message
+
+ A mobile node uses the Home Test Init (HoTI) message to initiate the
+ return routability procedure and request a home keygen token from a
+ correspondent node (see Section 11.6.1). The Home Test Init message
+ uses the MH Type value 1. When this value is indicated in the MH
+ Type field, the format of the Message Data field in the Mobility
+ Header is as follows:
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 37]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Home Init Cookie +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Reserved
+
+ 16-bit field reserved for future use. This value MUST be
+ initialized to zero by the sender, and MUST be ignored by the
+ receiver.
+
+ Home Init Cookie
+
+ 64-bit field that contains a random value, the home init cookie.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The receiver
+ MUST ignore and skip any options that it does not understand.
+ This specification does not define any options valid for the Home
+ Test Init message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 1.
+
+ This message is tunneled through the home agent when the mobile node
+ is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel
+ mode between the home agent and the mobile node. This protection is
+ indicated by the IPsec security policy database. The protection of
+ Home Test Init messages is unrelated to the requirement to protect
+ regular payload traffic, which MAY use such tunnels as well.
+
+6.1.4. Care-of Test Init Message
+
+ A mobile node uses the Care-of Test Init (CoTI) message to initiate
+ the return routability procedure and request a care-of keygen token
+ from a correspondent node (see Section 11.6.1). The Care-of Test
+
+
+
+Perkins, et al. Standards Track [Page 38]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Init message uses the MH Type value 2. When this value is indicated
+ in the MH Type field, the format of the Message Data field in the
+ Mobility Header is as follows:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Care-of Init Cookie +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Reserved
+
+ 16-bit field reserved for future use. The value MUST be
+ initialized to zero by the sender, and MUST be ignored by the
+ receiver.
+
+ Care-of Init Cookie
+
+ 64-bit field that contains a random value, the care-of init
+ cookie.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The receiver
+ MUST ignore and skip any options that it does not understand.
+ This specification does not define any options valid for the
+ Care-of Test Init message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 1.
+
+6.1.5. Home Test Message
+
+ The Home Test (HoT) message is a response to the Home Test Init
+ message, and is sent from the correspondent node to the mobile node
+ (see Section 5.2.5). The Home Test message uses the MH Type value 3.
+ When this value is indicated in the MH Type field, the format of the
+ Message Data field in the Mobility Header is as follows:
+
+
+
+Perkins, et al. Standards Track [Page 39]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Home Nonce Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Home Init Cookie +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Home Keygen Token +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Home Nonce Index
+
+ This field will be echoed back by the mobile node to the
+ correspondent node in a subsequent Binding Update.
+
+ Home Init Cookie
+
+ 64-bit field that contains the home init cookie.
+
+ Home Keygen Token
+
+ This field contains the 64-bit home keygen token used in the
+ return routability procedure.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The receiver
+ MUST ignore and skip any options that it does not understand.
+ This specification does not define any options valid for the Home
+ Test message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 2.
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 40]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+6.1.6. Care-of Test Message
+
+ The Care-of Test (CoT) message is a response to the Care-of Test Init
+ message, and is sent from the correspondent node to the mobile node
+ (see Section 11.6.2). The Care-of Test message uses the MH Type
+ value 4. When this value is indicated in the MH Type field, the
+ format of the Message Data field in the Mobility Header is as
+ follows:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Care-of Nonce Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Care-of Init Cookie +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Care-of Keygen Token +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Care-of Nonce Index
+
+ This value will be echoed back by the mobile node to the
+ correspondent node in a subsequent Binding Update.
+
+ Care-of Init Cookie
+
+ 64-bit field that contains the care-of init cookie.
+
+ Care-of Keygen Token
+
+ This field contains the 64-bit care-of keygen token used in the
+ return routability procedure.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The receiver
+
+
+
+
+
+Perkins, et al. Standards Track [Page 41]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ MUST ignore and skip any options that it does not understand.
+ This specification does not define any options valid for the
+ Care-of Test message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 2.
+
+6.1.7. Binding Update Message
+
+ The Binding Update (BU) message is used by a mobile node to notify
+ other nodes of a new care-of address for itself. Binding Updates are
+ sent as described in Sections 11.7.1 and 11.7.2.
+
+ The Binding Update uses the MH Type value 5. When this value is
+ indicated in the MH Type field, the format of the Message Data field
+ in the Mobility Header is as follows:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|H|L|K| Reserved | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Acknowledge (A)
+
+ The Acknowledge (A) bit is set by the sending mobile node to
+ request a Binding Acknowledgement (Section 6.1.8) be returned upon
+ receipt of the Binding Update.
+
+ Home Registration (H)
+
+ The Home Registration (H) bit is set by the sending mobile node to
+ request that the receiving node should act as this node's home
+ agent. The destination of the packet carrying this message MUST
+ be that of a router sharing the same subnet prefix as the home
+ address of the mobile node in the binding.
+
+ Link-Local Address Compatibility (L)
+
+ The Link-Local Address Compatibility (L) bit is set when the home
+ address reported by the mobile node has the same interface
+ identifier as the mobile node's link-local address.
+
+
+
+Perkins, et al. Standards Track [Page 42]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Key Management Mobility Capability (K)
+
+ If this bit is cleared, the protocol used for establishing the
+ IPsec security associations between the mobile node and the home
+ agent does not survive movements. It may then have to be rerun.
+ (Note that the IPsec security associations themselves are expected
+ to survive movements.) If manual IPsec configuration is used, the
+ bit MUST be cleared.
+
+ This bit is valid only in Binding Updates sent to the home agent,
+ and MUST be cleared in other Binding Updates. Correspondent nodes
+ MUST ignore this bit.
+
+ Reserved
+
+ These fields are unused. They MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ Sequence #
+
+ A 16-bit unsigned integer used by the receiving node to sequence
+ Binding Updates and by the sending node to match a returned
+ Binding Acknowledgement with this Binding Update.
+
+ Lifetime
+
+ 16-bit unsigned integer. The number of time units remaining
+ before the binding MUST be considered expired. A value of zero
+ indicates that the Binding Cache entry for the mobile node MUST be
+ deleted. One time unit is 4 seconds.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The encoding
+ and format of defined options are described in Section 6.2. The
+ receiver MUST ignore and skip any options that it does not
+ understand.
+
+ The following options are valid in a Binding Update:
+
+ * Binding Authorization Data option (this option is mandatory in
+ Binding Updates sent to a correspondent node)
+
+ * Nonce Indices option
+
+ * Alternate Care-of Address option
+
+
+
+Perkins, et al. Standards Track [Page 43]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ If no options are present in this message, 4 octets of padding are
+ necessary and the Header Len field will be set to 1.
+
+ The care-of address is specified either by the Source Address field
+ in the IPv6 header or by the Alternate Care-of Address option, if
+ present. The care-of address MUST be a unicast routable address.
+ IPv6 Source Address MUST be a topologically correct source address.
+ Binding Updates for a care-of address that is not a unicast routable
+ address MUST be silently discarded.
+
+ The deletion of a binding MUST be indicated by setting the Lifetime
+ field to 0. In deletion, the generation of the binding management
+ key depends exclusively on the home keygen token, as explained in
+ Section 5.2.5.
+
+ Correspondent nodes SHOULD NOT delete the Binding Cache entry before
+ the lifetime expires, if any application hosted by the correspondent
+ node is still likely to require communication with the mobile node.
+ A Binding Cache entry that is de-allocated prematurely might cause
+ subsequent packets to be dropped from the mobile node, if they
+ contain the Home Address destination option. This situation is
+ recoverable, since a Binding Error message is sent to the mobile node
+ (see Section 6.1.9); however, it causes unnecessary delay in the
+ communications.
+
+6.1.8. Binding Acknowledgement Message
+
+ The Binding Acknowledgement is used to acknowledge receipt of a
+ Binding Update (Section 6.1.7). This packet is sent as described in
+ Sections 9.5.4 and 10.3.1.
+
+ The Binding Acknowledgement has the MH Type value 6. When this value
+ is indicated in the MH Type field, the format of the Message Data
+ field in the Mobility Header is as follows:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status |K| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 44]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Status
+
+ 8-bit unsigned integer indicating the disposition of the Binding
+ Update. Values of the Status field less than 128 indicate that
+ the Binding Update was accepted by the receiving node. Values
+ greater than or equal to 128 indicate that the Binding Update was
+ rejected by the receiving node. The following Status values are
+ currently defined:
+
+ 0 Binding Update accepted
+
+ 1 Accepted but prefix discovery necessary
+
+ 128 Reason unspecified
+
+ 129 Administratively prohibited
+
+ 130 Insufficient resources
+
+ 131 Home registration not supported
+
+ 132 Not home subnet
+
+ 133 Not home agent for this mobile node
+
+ 134 Duplicate Address Detection failed
+
+ 135 Sequence number out of window
+
+ 136 Expired home nonce index
+
+ 137 Expired care-of nonce index
+
+ 138 Expired nonces
+
+ 139 Registration type change disallowed
+
+ 174 Invalid Care-of Address
+
+ Up-to-date values of the Status field are to be specified in the
+ IANA registry of assigned numbers [30].
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 45]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Key Management Mobility Capability (K)
+
+ If this bit is cleared, the protocol used by the home agent for
+ establishing the IPsec security associations between the mobile
+ node and the home agent does not survive movements. It may then
+ have to be rerun. (Note that the IPsec security associations
+ themselves are expected to survive movements.)
+
+ Correspondent nodes MUST set the K bit to 0.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ Sequence #
+
+ The Sequence Number in the Binding Acknowledgement is copied from
+ the Sequence Number field in the Binding Update. It is used by
+ the mobile node in matching this Binding Acknowledgement with an
+ outstanding Binding Update.
+
+ Lifetime
+
+ The granted lifetime, in time units of 4 seconds, for which this
+ node SHOULD retain the entry for this mobile node in its Binding
+ Cache.
+
+ The value of this field is undefined if the Status field indicates
+ that the Binding Update was rejected.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The encoding
+ and format of defined options are described in Section 6.2. The
+ receiver MUST ignore and skip any options that it does not
+ understand.
+
+ There MAY be additional information associated with this Binding
+ Acknowledgement that need not be present in all Binding
+ Acknowledgements sent. Mobility options allow future extensions
+ to the format of the Binding Acknowledgement to be defined. The
+ following options are valid for the Binding Acknowledgement:
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 46]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ * Binding Authorization Data option (this option is mandatory in
+ Binding Acknowledgements sent by a correspondent node, except
+ where otherwise noted in Section 9.5.4)
+
+ * Binding Refresh Advice option
+
+ If no options are present in this message, 4 octets of padding are
+ necessary and the Header Len field will be set to 1.
+
+6.1.9. Binding Error Message
+
+ The Binding Error (BE) message is used by the correspondent node to
+ signal an error related to mobility, such as an inappropriate attempt
+ to use the Home Address destination option without an existing
+ binding; see Section 9.3.3 for details.
+
+ The Binding Error message uses the MH Type value 7. When this value
+ is indicated in the MH Type field, the format of the Message Data
+ field in the Mobility Header is as follows:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Home Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . .
+ . Mobility Options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Status
+
+ 8-bit unsigned integer indicating the reason for this message.
+ The following values are currently defined:
+
+ 1 Unknown binding for Home Address destination option
+
+ 2 Unrecognized MH Type value
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 47]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Reserved
+
+ 8-bit field reserved for future use. The value MUST be
+ initialized to zero by the sender, and MUST be ignored by the
+ receiver.
+
+ Home Address
+
+ The home address that was contained in the Home Address
+ destination option. The mobile node uses this information to
+ determine which binding does not exist, in cases where the mobile
+ node has several home addresses.
+
+ Mobility Options
+
+ Variable-length field of such length that the complete Mobility
+ Header is an integer multiple of 8 octets long. This field
+ contains zero or more TLV-encoded mobility options. The receiver
+ MUST ignore and skip any options that it does not understand.
+ There MAY be additional information associated with this Binding
+ Error message that need not be present in all Binding Error
+ messages sent. Mobility options allow future extensions to the
+ format of the Binding Error message to be defined. The encoding
+ and format of defined options are described in Section 6.2. This
+ specification does not define any options valid for the Binding
+ Error message.
+
+ If no actual options are present in this message, no padding is
+ necessary and the Header Len field will be set to 2.
+
+6.2. Mobility Options
+
+ Mobility messages can include zero or more mobility options. This
+ allows optional fields that may not be needed in every use of a
+ particular Mobility Header, as well as future extensions to the
+ format of the messages. Such options are included in the Message
+ Data field of the message itself, after the fixed portion of the
+ message data specified in the message subsections of Section 6.1.
+
+ The presence of such options will be indicated by the Header Len of
+ the Mobility Header. If included, the Binding Authorization Data
+ option (Section 6.2.7) MUST be the last option and MUST NOT have
+ trailing padding. Otherwise, options can be placed in any order.
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 48]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+6.2.1. Format
+
+ Mobility options are encoded within the remaining space of the
+ Message Data field of a mobility message, using a type-length-value
+ (TLV) format as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option Type | Option Length | Option Data...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Option Type
+
+ 8-bit identifier of the type of mobility option. When processing
+ a Mobility Header containing an option for which the Option Type
+ value is not recognized by the receiver, the receiver MUST quietly
+ ignore and skip over the option, correctly handling any remaining
+ options in the message.
+
+ Option Length
+
+ 8-bit unsigned integer, representing the length in octets of the
+ mobility option, not including the Option Type and Option Length
+ fields.
+
+ Option Data
+
+ A variable-length field that contains data specific to the option.
+
+ The following subsections specify the Option types that are currently
+ defined for use in the Mobility Header.
+
+ Implementations MUST silently ignore any mobility options that they
+ do not understand.
+
+ Mobility options may have alignment requirements. Following the
+ convention in IPv6, these options are aligned in a packet so that
+ multi-octet values within the Option Data field of each option fall
+ on natural boundaries (i.e., fields of width n octets are placed at
+ an integer multiple of n octets from the start of the header, for n =
+ 1, 2, 4, or 8) [6].
+
+6.2.2. Pad1
+
+ The Pad1 option does not have any alignment requirements. Its format
+ is as follows:
+
+
+
+
+Perkins, et al. Standards Track [Page 49]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Type = 0 |
+ +-+-+-+-+-+-+-+-+
+
+ NOTE! the format of the Pad1 option is a special case -- it has
+ neither Option Length nor Option Data fields.
+
+ The Pad1 option is used to insert one octet of padding in the
+ Mobility Options area of a Mobility Header. If more than one octet
+ of padding is required, the PadN option, described next, should be
+ used rather than multiple Pad1 options.
+
+6.2.3. PadN
+
+ The PadN option does not have any alignment requirements. Its format
+ is as follows:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+ | Type = 1 | Option Length | Option Data
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+
+ The PadN option is used to insert two or more octets of padding in
+ the Mobility Options area of a mobility message. For N octets of
+ padding, the Option Length field contains the value N-2, and the
+ Option Data consists of N-2 zero-valued octets. PadN Option data
+ MUST be ignored by the receiver.
+
+6.2.4. Binding Refresh Advice
+
+ The Binding Refresh Advice option has an alignment requirement of 2n.
+ Its format is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 2 | Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Refresh Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Binding Refresh Advice option is only valid in the Binding
+ Acknowledgement, and only on Binding Acknowledgements sent from the
+ mobile node's home agent in reply to a home registration. The
+ Refresh Interval is measured in units of four seconds, and indicates
+
+
+
+Perkins, et al. Standards Track [Page 50]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ remaining time until the mobile node SHOULD send a new home
+ registration to the home agent. The Refresh Interval MUST be set to
+ indicate a smaller time interval than the Lifetime value of the
+ Binding Acknowledgement.
+
+6.2.5. Alternate Care-of Address
+
+ The Alternate Care-of Address option has an alignment requirement of
+ 8n + 6. Its format is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 3 | Length = 16 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Alternate Care-of Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Normally, a Binding Update specifies the desired care-of address in
+ the Source Address field of the IPv6 header. However, this is not
+ possible in some cases, such as when the mobile node wishes to
+ indicate a care-of address that it cannot use as a topologically
+ correct source address (Sections 6.1.7 and 11.7.2) or when the used
+ security mechanism does not protect the IPv6 header (Section 11.7.1).
+
+ The Alternate Care-of Address option is provided for these
+ situations. This option is valid only in Binding Update. The
+ Alternate Care-of Address field contains an address to use as the
+ care-of address for the binding, rather than using the Source Address
+ of the packet as the care-of address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 51]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+6.2.6. Nonce Indices
+
+ The Nonce Indices option has an alignment requirement of 2n. Its
+ format is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 4 | Length = 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Home Nonce Index | Care-of Nonce Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Nonce Indices option is valid only in the Binding Update message
+ sent to a correspondent node, and only when present together with a
+ Binding Authorization Data option. When the correspondent node
+ authorizes the Binding Update, it needs to produce home and care-of
+ keygen tokens from its stored random nonce values.
+
+ The Home Nonce Index field tells the correspondent node which nonce
+ value to use when producing the home keygen token.
+
+ The Care-of Nonce Index field is ignored in requests to delete a
+ binding. Otherwise, it tells the correspondent node which nonce
+ value to use when producing the care-of keygen token.
+
+6.2.7. Binding Authorization Data
+
+ The Binding Authorization Data option does not have alignment
+ requirements as such. However, since this option must be the last
+ mobility option, an implicit alignment requirement is 8n + 2. The
+ format of this option is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 5 | Option Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | Authenticator |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Binding Authorization Data option is valid in the Binding Update
+ and Binding Acknowledgement.
+
+
+
+
+Perkins, et al. Standards Track [Page 52]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The Option Length field contains the length of the authenticator in
+ octets.
+
+ The Authenticator field contains a cryptographic value that can be
+ used to determine that the message in question comes from the right
+ authority. Rules for calculating this value depends on the used
+ authorization procedure.
+
+ For the return routability procedure, this option can appear in the
+ Binding Update and Binding Acknowledgements. Rules for calculating
+ the Authenticator value are the following:
+
+ Mobility Data = care-of address | correspondent | MH Data
+ Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
+
+ Where | denotes concatenation. "Care-of address" is the care-of
+ address that will be registered for the mobile node if the Binding
+ Update succeeds, or the home address of the mobile node if this
+ option is used in de-registration. Note also that this address might
+ be different from the source address of the Binding Update message,
+ if the Alternative Care-of Address mobility option is used, or when
+ the lifetime of the binding is set to zero.
+
+ The "correspondent" is the IPv6 address of the correspondent node.
+ Note that, if the message is sent to a destination that is itself
+ mobile, the "correspondent" address may not be the address found in
+ the Destination Address field of the IPv6 header; instead, the home
+ address from the type 2 Routing header should be used.
+
+ "MH Data" is the content of the Mobility Header, excluding the
+ Authenticator field itself. The Authenticator value is calculated as
+ if the Checksum field in the Mobility Header was zero. The Checksum
+ in the transmitted packet is still calculated in the usual manner,
+ with the calculated Authenticator being a part of the packet
+ protected by the Checksum. Kbm is the binding management key, which
+ is typically created using nonces provided by the correspondent node
+ (see Section 9.4). Note that while the contents of a potential Home
+ Address destination option are not covered in this formula, the rules
+ for the calculation of the Kbm do take the home address in account.
+ This ensures that the MAC will be different for different home
+ addresses.
+
+ The first 96 bits from the MAC result are used as the Authenticator
+ field.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 53]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+6.3. Home Address Option
+
+ The Home Address option is carried by the Destination Option
+ extension header (Next Header value = 60). It is used in a packet
+ sent by a mobile node while away from home, to inform the recipient
+ of the mobile node's home address.
+
+ The Home Address option is encoded in type-length-value (TLV) format
+ as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option Type | Option Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Home Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Option Type
+
+ 201 = 0xC9
+
+ Option Length
+
+ 8-bit unsigned integer. Length of the option, in octets,
+ excluding the Option Type and Option Length fields. This field
+ MUST be set to 16.
+
+ Home Address
+
+ The home address of the mobile node sending the packet. This
+ address MUST be a unicast routable address.
+
+ The alignment requirement [6] for the Home Address option is 8n + 6.
+
+ The three highest-order bits of the Option Type field are encoded to
+ indicate specific processing of the option [6]; for the Home Address
+ option, these three bits are set to 110. This indicates the
+ following processing requirements:
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 54]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Any IPv6 node that does not recognize the Option Type must discard
+ the packet, and if the packet's Destination Address was not a
+ multicast address, return an ICMP Parameter Problem, Code 2,
+ message to the packet's Source Address. The Pointer field in the
+ ICMP message SHOULD point at the Option Type field. Otherwise,
+ for multicast addresses, the ICMP message MUST NOT be sent.
+
+ o The data within the option cannot change en route to the packet's
+ final destination.
+
+ The Home Address option MUST be placed as follows:
+
+ o After the routing header, if that header is present
+
+ o Before the Fragment Header, if that header is present
+
+ o Before the AH Header or ESP Header, if either one of those headers
+ is present
+
+ For each IPv6 packet header, the Home Address option MUST NOT appear
+ more than once. However, an encapsulated packet [7] MAY contain a
+ separate Home Address option associated with each encapsulating IP
+ header.
+
+ The inclusion of a Home Address destination option in a packet
+ affects the receiving node's processing of only this single packet.
+ No state is created or modified in the receiving node as a result of
+ receiving a Home Address option in a packet. In particular, the
+ presence of a Home Address option in a received packet MUST NOT alter
+ the contents of the receiver's Binding Cache and MUST NOT cause any
+ changes in the routing of subsequent packets sent by this receiving
+ node.
+
+6.4. Type 2 Routing Header
+
+ Mobile IPv6 defines a new routing header variant, the type 2 routing
+ header, to allow the packet to be routed directly from a
+ correspondent to the mobile node's care-of address. The mobile
+ node's care-of address is inserted into the IPv6 Destination Address
+ field. Once the packet arrives at the care-of address, the mobile
+ node retrieves its home address from the routing header, and this is
+ used as the final destination address for the packet.
+
+ The new routing header uses a different type than defined for
+ "regular" IPv6 source routing, enabling firewalls to apply different
+ rules to source routed packets than to Mobile IPv6. This routing
+ header type (type 2) is restricted to carry only one IPv6 address.
+ All IPv6 nodes that process this routing header MUST verify that the
+
+
+
+Perkins, et al. Standards Track [Page 55]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ address contained within is the node's own home address in order to
+ prevent packets from being forwarded outside the node. The IP
+ address contained in the routing header, since it is the mobile
+ node's home address, MUST be a unicast routable address.
+ Furthermore, if the scope of the home address is smaller than the
+ scope of the care-of address, the mobile node MUST discard the packet
+ (see Section 4.6).
+
+6.4.1. Format
+
+ The type 2 routing header has the following format:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Home Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Next Header
+
+ 8-bit selector. Identifies the type of header immediately
+ following the routing header. Uses the same values as the IPv6
+ Next Header field [6].
+
+ Hdr Ext Len
+
+ 2 (8-bit unsigned integer); length of the routing header in
+ 8-octet units, not including the first 8 octets.
+
+ Routing Type
+
+ 2 (8-bit unsigned integer).
+
+ Segments Left
+
+ 1 (8-bit unsigned integer).
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 56]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Reserved
+
+ 32-bit reserved field. The value MUST be initialized to zero by
+ the sender, and MUST be ignored by the receiver.
+
+ Home Address
+
+ The home address of the destination mobile node.
+
+ For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments
+ Left value describes the number of route segments remaining, i.e.,
+ number of explicitly listed intermediate nodes still to be visited
+ before reaching the final destination. Segments Left MUST be 1. The
+ ordering rules for extension headers in an IPv6 packet are described
+ in Section 4.1 of RFC 2460 [6]. The type 2 routing header defined
+ for Mobile IPv6 follows the same ordering as other routing headers.
+ If another routing header is present along with a type 2 routing
+ header, the type 2 routing header should follow the other routing
+ header. A packet containing such nested encapsulation should be
+ created as if the inner (type 2) routing header was constructed first
+ and then treated as an original packet by header construction process
+ for the other routing header.
+
+ In addition, the general procedures defined by IPv6 for routing
+ headers suggest that a received routing header MAY be automatically
+ "reversed" to construct a routing header for use in any response
+ packets sent by upper-layer protocols, if the received packet is
+ authenticated [6]. This MUST NOT be done automatically for type 2
+ routing headers.
+
+6.5. ICMP Home Agent Address Discovery Request Message
+
+ The ICMP Home Agent Address Discovery Request message is used by a
+ mobile node to initiate the dynamic home agent address discovery
+ mechanism, as described in Section 11.4.1. The mobile node sends the
+ Home Agent Address Discovery Request message to the Mobile IPv6 Home-
+ Agents anycast address [8] for its own home subnet prefix. (Note
+ that the currently defined anycast addresses may not work with all
+ prefix lengths other than those defined in RFC 4291 [16] [37].)
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Perkins, et al. Standards Track [Page 57]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Type
+
+ 144
+
+ Code
+
+ 0
+
+ Checksum
+
+ The ICMP checksum [17].
+
+ Identifier
+
+ An identifier to aid in matching Home Agent Address Discovery
+ Reply messages to this Home Agent Address Discovery Request
+ message.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ The Source Address of the Home Agent Address Discovery Request
+ message packet is typically one of the mobile node's current care-of
+ addresses. At the time of performing this dynamic home agent address
+ discovery procedure, it is likely that the mobile node is not
+ registered with any home agent. Therefore, neither the nature of the
+ address nor the identity of the mobile node can be established at
+ this time. The home agent MUST then return the Home Agent Address
+ Discovery Reply message directly to the Source Address chosen by the
+ mobile node.
+
+6.6. ICMP Home Agent Address Discovery Reply Message
+
+ The ICMP Home Agent Address Discovery Reply message is used by a home
+ agent to respond to a mobile node that uses the dynamic home agent
+ address discovery mechanism, as described in Section 10.5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 58]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ . .
+ . Home Agent Addresses .
+ . .
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 145
+
+ Code
+
+ 0
+
+ Checksum
+
+ The ICMP checksum [17].
+
+ Identifier
+
+ The identifier from the invoking Home Agent Address Discovery
+ Request message.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ Home Agent Addresses
+
+ A list of addresses of home agents on the home link for the mobile
+ node. The number of addresses presented in the list is indicated
+ by the remaining length of the IPv6 packet carrying the Home Agent
+ Address Discovery Reply message.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 59]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+6.7. ICMP Mobile Prefix Solicitation Message Format
+
+ The ICMP Mobile Prefix Solicitation message is sent by a mobile node
+ to its home agent while it is away from home. The purpose of the
+ message is to solicit a Mobile Prefix Advertisement from the home
+ agent, which will allow the mobile node to gather prefix information
+ about its home network. This information can be used to configure
+ and update home address(es) according to changes in prefix
+ information supplied by the home agent.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ IP Fields:
+
+ Source Address
+
+ The mobile node's care-of address.
+
+ Destination Address
+
+ The address of the mobile node's home agent. This home agent must
+ be on the link that the mobile node wishes to learn prefix
+ information about.
+
+ Hop Limit
+
+ Set to an initial hop limit value, similarly to any other unicast
+ packet sent by the mobile node.
+
+ Destination Option:
+
+ A Home Address destination option MUST be included.
+
+ ESP header:
+
+ IPsec headers MUST be supported and SHOULD be used as described in
+ Section 5.4.
+
+ ICMP Fields:
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 60]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Type
+
+ 146
+
+ Code
+
+ 0
+
+ Checksum
+
+ The ICMP checksum [17].
+
+ Identifier
+
+ An identifier to aid in matching a future Mobile Prefix
+ Advertisement to this Mobile Prefix Solicitation.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ The Mobile Prefix Solicitation messages may have options. These
+ options MUST use the option format defined in Neighbor Discovery (RFC
+ 4861 [18]). This document does not define any option types for the
+ Mobile Prefix Solicitation message, but future documents may define
+ new options. Home agents MUST silently ignore any options they do
+ not recognize and continue processing the message.
+
+6.8. ICMP Mobile Prefix Advertisement Message Format
+
+ A home agent will send a Mobile Prefix Advertisement to a mobile node
+ to distribute prefix information about the home link while the mobile
+ node is traveling away from the home network. This will occur in
+ response to a Mobile Prefix Solicitation with an Advertisement, or by
+ an unsolicited Advertisement sent according to the rules in
+ Section 10.6.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier |M|O| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Perkins, et al. Standards Track [Page 61]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ IP Fields:
+
+ Source Address
+
+ The home agent's address as the mobile node would expect to see it
+ (i.e., same network prefix).
+
+ Destination Address
+
+ If this message is a response to a Mobile Prefix Solicitation,
+ this field contains the Source Address field from that packet.
+ For unsolicited messages, the mobile node's care-of address SHOULD
+ be used. Note that unsolicited messages can only be sent if the
+ mobile node is currently registered with the home agent.
+
+ Routing header:
+
+ A type 2 routing header MUST be included.
+
+ ESP header:
+
+ IPsec headers MUST be supported and SHOULD be used as described in
+ Section 5.4.
+
+ ICMP Fields:
+
+ Type
+
+ 147
+
+ Code
+
+ 0
+
+ Checksum
+
+ The ICMP checksum [17].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 62]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Identifier
+
+ An identifier to aid in matching this Mobile Prefix Advertisement
+ to a previous Mobile Prefix Solicitation.
+
+ M
+
+ 1-bit Managed Address Configuration flag. When set, hosts use the
+ administered (stateful) protocol for address autoconfiguration in
+ addition to any addresses autoconfigured using stateless address
+ autoconfiguration. The use of this flag is described in [18]
+ [19].
+
+ O
+
+ 1-bit Other Stateful Configuration flag. When set, hosts use the
+ administered (stateful) protocol for autoconfiguration of other
+ (non-address) information. The use of this flag is described in
+ [18] [19].
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ The Mobile Prefix Advertisement messages may have options. These
+ options MUST use the option format defined in Neighbor Discovery (RFC
+ 4861 [18]). This document defines one option that may be carried in
+ a Mobile Prefix Advertisement message, but future documents may
+ define new options. Mobile nodes MUST silently ignore any options
+ they do not recognize and continue processing the message.
+
+ Prefix Information
+
+ Each message contains one or more Prefix Information options.
+ Each option carries the prefix(es) that the mobile node should use
+ to configure its home address(es). Section 10.6 describes which
+ prefixes should be advertised to the mobile node.
+
+ The Prefix Information option is defined in Section 4.6.2 of
+ Neighbor Discovery (RFC 4861 [18]), with modifications defined in
+ Section 7.2 of this specification. The home agent MUST use this
+ modified Prefix Information option to send home network prefixes
+ as defined in Section 10.6.1.
+
+ If the Advertisement is sent in response to a Mobile Prefix
+ Solicitation, the home agent MUST copy the Identifier value from that
+ message into the Identifier field of the Advertisement.
+
+
+
+Perkins, et al. Standards Track [Page 63]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The home agent MUST NOT send more than one Mobile Prefix
+ Advertisement message per second to any mobile node.
+
+ The M and O bits MUST be cleared if the Home Agent DHCPv6 support is
+ not provided. If such support is provided, then they are set in
+ concert with the home network's administrative settings.
+
+7. Modifications to IPv6 Neighbor Discovery
+
+7.1. Modified Router Advertisement Message Format
+
+ Mobile IPv6 modifies the format of the Router Advertisement message
+ [18] by the addition of a single flag bit to indicate that the router
+ sending the Advertisement message is serving as a home agent on this
+ link. The format of the Router Advertisement message is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reachable Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Retrans Timer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+-+-+-+-+-+-+-+-
+
+ This format represents the following changes over that originally
+ specified for Neighbor Discovery [18]:
+
+ Home Agent (H)
+
+ The Home Agent (H) bit is set in a Router Advertisement to
+ indicate that the router sending this Router Advertisement is also
+ functioning as a Mobile IPv6 home agent on this link.
+
+ Reserved
+
+ Reduced from a 6-bit field to a 5-bit field to account for the
+ addition of the above bit.
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 64]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+7.2. Modified Prefix Information Option Format
+
+ Mobile IPv6 requires knowledge of a router's global address in
+ building a Home Agents List as part of the dynamic home agent address
+ discovery mechanism.
+
+ However, Neighbor Discovery [18] only advertises a router's link-
+ local address, by requiring this address to be used as the IP Source
+ Address of each Router Advertisement.
+
+ Mobile IPv6 extends Neighbor Discovery to allow a router to advertise
+ its global address, by the addition of a single flag bit in the
+ format of a Prefix Information option for use in Router Advertisement
+ messages. The format of the Prefix Information option is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Prefix Length |L|A|R|Reserved1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preferred Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Prefix +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ This format represents the following changes over that originally
+ specified for Neighbor Discovery [18]:
+
+ Router Address (R)
+
+ 1-bit router address flag. When set, indicates that the Prefix
+ field contains a complete IP address assigned to the sending
+ router. The indicated prefix is given by the first Prefix Length
+ bits of the Prefix field. The router IP address has the same
+ scope and conforms to the same lifetime values as the advertised
+ prefix. This use of the Prefix field is compatible with its use
+ in advertising the prefix itself, since Prefix Advertisement uses
+
+
+
+
+Perkins, et al. Standards Track [Page 65]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ only the leading bits. Interpretation of this flag bit is thus
+ independent of the processing required for the On-Link (L) and
+ Autonomous Address-Configuration (A) flag bits.
+
+ Reserved1
+
+ Reduced from a 6-bit field to a 5-bit field to account for the
+ addition of the above bit.
+
+ In a Router Advertisement, a home agent MUST, and all other routers
+ MAY, include at least one Prefix Information option with the Router
+ Address (R) bit set. Neighbor Discovery (RFC 4861 [18]) specifies
+ that, when including all options in a Router Advertisement causes the
+ size of the Advertisement to exceed the link MTU, multiple
+ Advertisements can be sent, each containing a subset of the Neighbor
+ Discovery options. Also, when sending unsolicited multicast Router
+ Advertisements more frequently than the limit specified in RFC 4861,
+ the sending router need not include all options in each of these
+ Advertisements. However, in both of these cases the router SHOULD
+ include at least one Prefix Information option with the Router
+ Address (R) bit set in each such advertisement, if this bit is set in
+ some advertisement sent by the router.
+
+ In addition, the following requirement can assist mobile nodes in
+ movement detection. Barring changes in the prefixes for the link,
+ routers that send multiple Router Advertisements with the Router
+ Address (R) bit set in some of the included Prefix Information
+ options SHOULD provide at least one option and router address that
+ stays the same in all of the Advertisements.
+
+7.3. New Advertisement Interval Option Format
+
+ Mobile IPv6 defines a new Advertisement Interval option, used in
+ Router Advertisement messages to advertise the interval at which the
+ sending router sends unsolicited multicast Router Advertisements.
+ The format of the Advertisement Interval option is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Advertisement Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 66]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Type
+
+ 7
+
+ Length
+
+ 8-bit unsigned integer. The length of the option (including the
+ type and length fields) is in units of 8 octets. The value of
+ this field MUST be 1.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ Advertisement Interval
+
+ 32-bit unsigned integer. The maximum time, in milliseconds,
+ between successive unsolicited Router Advertisement messages sent
+ by this router on this network interface. Using the conceptual
+ router configuration variables defined by Neighbor Discovery [18],
+ this field MUST be equal to the value MaxRtrAdvInterval, expressed
+ in milliseconds.
+
+ Routers MAY include this option in their Router Advertisements. A
+ mobile node receiving a Router Advertisement containing this option
+ SHOULD utilize the specified Advertisement Interval for that router
+ in its movement detection algorithm, as described in Section 11.5.1.
+
+ This option MUST be silently ignored for other Neighbor Discovery
+ messages.
+
+7.4. New Home Agent Information Option Format
+
+ Mobile IPv6 defines a new Home Agent Information option, used in
+ Router Advertisements sent by a home agent to advertise information
+ specific to this router's functionality as a home agent. The format
+ of the Home Agent Information option is as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Home Agent Preference | Home Agent Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 67]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Type
+
+ 8
+
+ Length
+
+ 8-bit unsigned integer. The length of the option (including the
+ type and length fields) in units of 8 octets. The value of this
+ field MUST be 1.
+
+ Reserved
+
+ This field is unused. It MUST be initialized to zero by the
+ sender and MUST be ignored by the receiver.
+
+ Home Agent Preference
+
+ 16-bit unsigned integer. The preference for the home agent
+ sending this Router Advertisement, for use in ordering the
+ addresses returned to a mobile node in the Home Agent Addresses
+ field of a Home Agent Address Discovery Reply message. Higher
+ values mean more preferable. If this option is not included in a
+ Router Advertisement in which the Home Agent (H) bit is set, the
+ preference value for this home agent MUST be considered to be 0.
+ Greater values indicate a more preferable home agent than lower
+ values.
+
+ The manual configuration of the Home Agent Preference value is
+ described in Section 8.4. In addition, the sending home agent MAY
+ dynamically set the Home Agent Preference value, for example,
+ basing it on the number of mobile nodes it is currently serving or
+ on its remaining resources for serving additional mobile nodes;
+ such dynamic settings are beyond the scope of this document. Any
+ such dynamic setting of the Home Agent Preference, however, MUST
+ set the preference appropriately, relative to the default Home
+ Agent Preference value of 0 that may be in use by some home agents
+ on this link (i.e., a home agent not including a Home Agent
+ Information option in its Router Advertisements will be considered
+ to have a Home Agent Preference value of 0).
+
+ Home Agent Lifetime
+
+ 16-bit unsigned integer. The lifetime associated with the home
+ agent in units of seconds. The default value is the same as the
+ Router Lifetime, as specified in the main body of the Router
+ Advertisement. The maximum value corresponds to 18.2 hours. A
+
+
+
+
+
+Perkins, et al. Standards Track [Page 68]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ value of 0 MUST NOT be used. The Home Agent Lifetime applies only
+ to this router's usefulness as a home agent; it does not apply to
+ information contained in other message fields or options.
+
+ Home agents MAY include this option in their Router Advertisements.
+ This option MUST NOT be included in a Router Advertisement in which
+ the Home Agent (H) bit (see Section 7.1) is not set. If this option
+ is not included in a Router Advertisement in which the Home Agent (H)
+ bit is set, the lifetime for this home agent MUST be considered to be
+ the same as the Router Lifetime in the Router Advertisement. If
+ multiple Advertisements are being sent instead of a single larger
+ unsolicited multicast Router Advertisement, all of the multiple
+ Advertisements with the Router Address (R) bit set MUST include this
+ option with the same contents; otherwise, this option MUST be omitted
+ from all Advertisements.
+
+ This option MUST be silently ignored for other Neighbor Discovery
+ messages.
+
+ If both the Home Agent Preference and Home Agent Lifetime are set to
+ their default values specified above, this option SHOULD NOT be
+ included in the Router Advertisement messages sent by this home
+ agent.
+
+7.5. Changes to Sending Router Advertisements
+
+ The Neighbor Discovery protocol specification [18] limits routers to
+ a minimum interval of 3 seconds between sending unsolicited multicast
+ Router Advertisement messages from any given network interface
+ (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
+
+ Routers generate Router Advertisements frequently enough that
+ hosts will learn of their presence within a few minutes, but not
+ frequently enough to rely on an absence of advertisements to
+ detect router failure; a separate Neighbor Unreachability
+ Detection algorithm provides failure detection.
+
+ This limitation, however, is not suitable to providing timely
+ movement detection for mobile nodes. Mobile nodes detect their own
+ movement by learning the presence of new routers as the mobile node
+ moves into wireless transmission range of them (or physically
+ connects to a new wired network), and by learning that previous
+ routers are no longer reachable. Mobile nodes MUST be able to
+ quickly detect when they move to a link served by a new router, so
+ that they can acquire a new care-of address and send Binding Updates
+ to register this care-of address with their home agent and to notify
+ correspondent nodes as needed.
+
+
+
+
+Perkins, et al. Standards Track [Page 69]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ One method that can provide for faster movement detection is to
+ increase the rate at which unsolicited Router Advertisements are
+ sent. Mobile IPv6 relaxes this limit such that routers MAY send
+ unsolicited multicast Router Advertisements more frequently. This
+ method can be applied where the router is expecting to provide
+ service to visiting mobile nodes (e.g., wireless network interfaces),
+ or on which it is serving as a home agent to one or more mobile nodes
+ (who may return home and need to hear its Advertisements).
+
+ Routers supporting mobility SHOULD be able to be configured with a
+ smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow
+ sending of unsolicited multicast Router Advertisements more often.
+ The minimum allowed values are:
+
+ o MinRtrAdvInterval 0.03 seconds
+
+ o MaxRtrAdvInterval 0.07 seconds
+
+ In the case where the minimum intervals and delays are used, the mean
+ time between unsolicited multicast Router Advertisements is 50 ms.
+ Use of these modified limits MUST be configurable (see also the
+ configuration variable MinDelayBetweenRas in Section 13 that may also
+ have to be modified accordingly). Systems where these values are
+ available MUST NOT default to them, and SHOULD default to values
+ specified in Neighbor Discovery (RFC 4861 [18]). Knowledge of the
+ type of network interface and operating environment SHOULD be taken
+ into account in configuring these limits for each network interface.
+ This is important with some wireless links, where increasing the
+ frequency of multicast beacons can cause considerable overhead.
+ Routers SHOULD adhere to the intervals specified in RFC 4861 [18], if
+ this overhead is likely to cause service degradation.
+
+ Additionally, the possible low values of MaxRtrAdvInterval may cause
+ some problems with movement detection in some mobile nodes. To
+ ensure that this is not a problem, Routers SHOULD add 20 ms to any
+ Advertisement Intervals sent in RAs that are below 200 ms, in order
+ to account for scheduling granularities on both the MN and the
+ router.
+
+ Note that multicast Router Advertisements are not always required in
+ certain wireless networks that have limited bandwidth. Mobility
+ detection or link changes in such networks may be done at lower
+ layers. Router advertisements in such networks SHOULD be sent only
+ when solicited. In such networks it SHOULD be possible to disable
+ unsolicited multicast Router Advertisements on specific interfaces.
+ The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
+ to some high values.
+
+
+
+
+Perkins, et al. Standards Track [Page 70]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Home agents MUST include the Source Link-Layer Address option in all
+ Router Advertisements they send. This simplifies the process of
+ returning home, as discussed in Section 11.5.5.
+
+ Note that according to Neighbor Discovery (RFC 4861 [18]),
+ AdvDefaultLifetime is by default based on the value of
+ MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime
+ field of Router Advertisements. Given that this field is expressed
+ in seconds, a small MaxRtrAdvInterval value can result in a zero
+ value for this field. To prevent this, routers SHOULD keep
+ AdvDefaultLifetime in at least one second, even if the use of
+ MaxRtrAdvInterval would result in a smaller value.
+
+8. Requirements for Types of IPv6 Nodes
+
+ Mobile IPv6 places some special requirements on the functions
+ provided by different types of IPv6 nodes. This section summarizes
+ those requirements, identifying the functionality each requirement is
+ intended to support.
+
+ The requirements are set for the following groups of nodes:
+
+ o All IPv6 nodes.
+
+ o All IPv6 nodes with support for route optimization.
+
+ o All IPv6 routers.
+
+ o All Mobile IPv6 home agents.
+
+ o All Mobile IPv6 mobile nodes.
+
+ It is outside the scope of this specification to specify which of
+ these groups are mandatory in IPv6. We only describe what is
+ mandatory for a node that supports, for instance, route optimization.
+ Other specifications are expected to define the extent of IPv6.
+
+8.1. All IPv6 Nodes
+
+ Any IPv6 node may at any time be a correspondent node of a mobile
+ node, either sending a packet to a mobile node or receiving a packet
+ from a mobile node. There are no Mobile IPv6 specific MUST
+ requirements for such nodes, and basic IPv6 techniques are
+ sufficient. If a mobile node attempts to set up route optimization
+ with a node with only basic IPv6 support, an ICMP error will signal
+ that the node does not support such optimizations (Section 11.3.5),
+ and communications will flow through the home agent.
+
+
+
+
+Perkins, et al. Standards Track [Page 71]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ An IPv6 node MUST NOT support the Home Address destination option,
+ type 2 routing header, or the Mobility Header unless it fully
+ supports the requirements listed in the next sections for either
+ route optimization, mobile node, or home agent functionality.
+
+8.2. IPv6 Nodes with Support for Route Optimization
+
+ Nodes that implement route optimization are a subset of all IPv6
+ nodes on the Internet. The ability of a correspondent node to
+ participate in route optimization is essential for the efficient
+ operation of the IPv6 Internet, for the following reasons:
+
+ o Avoidance of congestion in the home network, and enabling the use
+ of lower-performance home agent equipment even for supporting
+ thousands of mobile nodes.
+
+ o Reduced network load across the entire Internet, as mobile devices
+ begin to predominate.
+
+ o Reduction of jitter and latency for the communications.
+
+ o Greater likelihood of success for Quality of Service (QoS)
+ signaling as tunneling is avoided and, again, fewer sources of
+ congestion.
+
+ o Improved robustness against network partitions, congestion, and
+ other problems, since fewer routing path segments are traversed.
+
+ These effects combine to enable much better performance and
+ robustness for communications between mobile nodes and IPv6
+ correspondent nodes. Route optimization introduces a small amount of
+ additional state for the peers, some additional messaging, and up to
+ 1.5 round-trip delays before it can be turned on. However, it is
+ believed that the benefits far outweigh the costs in most cases.
+ Section 11.3.1 discusses how mobile nodes may avoid route
+ optimization for some of the remaining cases, such as very short-term
+ communications.
+
+ The following requirements apply to all correspondent nodes that
+ support route optimization:
+
+ o The node MUST be able to validate a Home Address option using an
+ existing Binding Cache entry, as described in Section 9.3.1.
+
+ o The node MUST be able to insert a type 2 routing header into
+ packets to be sent to a mobile node, as described in
+ Section 9.3.2.
+
+
+
+
+Perkins, et al. Standards Track [Page 72]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Unless the correspondent node is also acting as a mobile node, it
+ MUST ignore type 2 routing headers and silently discard all
+ packets that it has received with such headers.
+
+ o The node SHOULD be able to interpret ICMP messages as described in
+ Section 9.3.4.
+
+ o The node MUST be able to send Binding Error messages as described
+ in Section 9.3.3.
+
+ o The node MUST be able to process Mobility Headers as described in
+ Section 9.2.
+
+ o The node MUST be able to participate in a return routability
+ procedure (Section 9.4).
+
+ o The node MUST be able to process Binding Update messages
+ (Section 9.5).
+
+ o The node MUST be able to return a Binding Acknowledgement
+ (Section 9.5.4).
+
+ o The node MUST be able to maintain a Binding Cache of the bindings
+ received in accepted Binding Updates, as described in Sections 9.1
+ and 9.6.
+
+ o The node SHOULD allow route optimization to be administratively
+ enabled or disabled. The default SHOULD be enabled.
+
+8.3. All IPv6 Routers
+
+ All IPv6 routers, even those not serving as a home agent for Mobile
+ IPv6, have an effect on how well mobile nodes can communicate:
+
+ o Every IPv6 router SHOULD be able to send an Advertisement Interval
+ option (Section 7.3) in each of its Router Advertisements [18], to
+ aid movement detection by mobile nodes (as in Section 11.5.1).
+ The use of this option in Router Advertisements SHOULD be
+ configurable.
+
+ o Every IPv6 router SHOULD be able to support sending unsolicited
+ multicast Router Advertisements at the faster rate described in
+ Section 7.5. If the router supports a faster rate, the used rate
+ MUST be configurable.
+
+ o Each router SHOULD include at least one prefix with the Router
+ Address (R) bit set and with its full IP address in its Router
+ Advertisements (as described in Section 7.2).
+
+
+
+Perkins, et al. Standards Track [Page 73]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Routers supporting filtering packets with routing headers SHOULD
+ support different rules for type 0 and type 2 routing headers (see
+ Section 6.4) so that filtering of source routed packets (type 0)
+ will not necessarily limit Mobile IPv6 traffic that is delivered
+ via type 2 routing headers.
+
+8.4. IPv6 Home Agents
+
+ In order for a mobile node to operate correctly while away from home,
+ at least one IPv6 router on the mobile node's home link must function
+ as a home agent for the mobile node. The following additional
+ requirements apply to all IPv6 routers that serve as a home agent:
+
+ o Every home agent MUST be able to maintain an entry in its Binding
+ Cache for each mobile node for which it is serving as the home
+ agent (Sections 10.1 and 10.3.1).
+
+ o Every home agent MUST be able to intercept packets (using proxy
+ Neighbor Discovery [18]) addressed to a mobile node for which it
+ is currently serving as the home agent, on that mobile node's home
+ link, while the mobile node is away from home (Section 10.4.1).
+
+ o Every home agent MUST be able to encapsulate [7] such intercepted
+ packets in order to tunnel them to the primary care-of address for
+ the mobile node indicated in its binding in the home agent's
+ Binding Cache (Section 10.4.2).
+
+ o Every home agent MUST support decapsulating [7] reverse-tunneled
+ packets sent to it from a mobile node's home address. Every home
+ agent MUST also check that the source address in the tunneled
+ packets corresponds to the currently registered location of the
+ mobile node (Section 10.4.5).
+
+ o The node MUST be able to process Mobility Headers as described in
+ Section 10.2.
+
+ o Every home agent MUST be able to return a Binding Acknowledgement
+ in response to a Binding Update (Section 10.3.1).
+
+ o Every home agent MUST maintain a separate Home Agents List for
+ each link on which it is serving as a home agent, as described in
+ Sections 10.1 and 10.5.1.
+
+ o Every home agent MUST be able to accept packets addressed to the
+ Mobile IPv6 Home-Agents anycast address [8] for the subnet on
+ which it is serving as a home agent, and MUST be able to
+ participate in dynamic home agent address discovery
+ (Section 10.5).
+
+
+
+Perkins, et al. Standards Track [Page 74]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Every home agent SHOULD support a configuration mechanism to allow
+ a system administrator to manually set the value to be sent by
+ this home agent in the Home Agent Preference field of the Home
+ Agent Information Option in Router Advertisements that it sends
+ (Section 7.4).
+
+ o Every home agent SHOULD support sending ICMP Mobile Prefix
+ Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
+ Solicitations (Section 6.7). If supported, this behavior MUST be
+ configurable, so that home agents can be configured to avoid
+ sending such Prefix Advertisements according to the needs of the
+ network administration in the home domain.
+
+ o Every home agent MUST support IPsec ESP for protection of packets
+ belonging to the return routability procedure (Section 10.4.6).
+
+ o Every home agent SHOULD support the multicast group membership
+ control protocols as described in Section 10.4.3. If this support
+ is provided, the home agent MUST be capable of using it to
+ determine which multicast data packets to forward via the tunnel
+ to the mobile node.
+
+ o Home agents MAY support stateful address autoconfiguration for
+ mobile nodes as described in Section 10.4.4.
+
+8.5. IPv6 Mobile Nodes
+
+ Finally, the following requirements apply to all IPv6 nodes capable
+ of functioning as mobile nodes:
+
+ o The node MUST maintain a Binding Update List (Section 11.1).
+
+ o The node MUST support sending packets containing a Home Address
+ option (Section 11.3.1), and follow the required IPsec interaction
+ (Section 11.3.2).
+
+ o The node MUST be able to perform IPv6 encapsulation and
+ decapsulation [7].
+
+ o The node MUST be able to process type 2 routing header as defined
+ in Sections 6.4 and 11.3.3.
+
+ o The node MUST support receiving a Binding Error message
+ (Section 11.3.6).
+
+ o The node MUST support receiving ICMP errors (Section 11.3.5).
+
+
+
+
+
+Perkins, et al. Standards Track [Page 75]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The node MUST support movement detection, care-of address
+ formation, and returning home (Section 11.5).
+
+ o The node MUST be able to process Mobility Headers as described in
+ Section 11.2.
+
+ o The node MUST support the return routability procedure
+ (Section 11.6).
+
+ o The node MUST be able to send Binding Updates, as specified in
+ Sections 11.7.1 and 11.7.2.
+
+ o The node MUST be able to receive and process Binding
+ Acknowledgements, as specified in Section 11.7.3.
+
+ o The node MUST support receiving a Binding Refresh Request
+ (Section 6.1.2), by responding with a Binding Update.
+
+ o The node MUST support receiving Mobile Prefix Advertisements
+ (Section 11.4.3) and reconfiguring its home address based on the
+ prefix information contained therein.
+
+ o The node SHOULD support use of the dynamic home agent address
+ discovery mechanism, as described in Section 11.4.1.
+
+ o The node MUST allow route optimization to be administratively
+ enabled or disabled. The default SHOULD be enabled.
+
+ o The node MAY support the multicast address listener part of a
+ multicast group membership protocol as described in
+ Section 11.3.4. If this support is provided, the mobile node MUST
+ be able to receive tunneled multicast packets from the home agent.
+
+ o The node MAY support stateful address autoconfiguration mechanisms
+ such as DHCPv6 [31] on the interface represented by the tunnel to
+ the home agent.
+
+9. Correspondent Node Operation
+
+9.1. Conceptual Data Structures
+
+ IPv6 nodes with route optimization support maintain a Binding Cache
+ of bindings for other nodes. A separate Binding Cache SHOULD be
+ maintained by each IPv6 node for each of its unicast routable
+ addresses. The Binding Cache MAY be implemented in any manner
+ consistent with the external behavior described in this document, for
+ example, by being combined with the node's Destination Cache as
+
+
+
+
+Perkins, et al. Standards Track [Page 76]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ maintained by Neighbor Discovery [18]. When sending a packet, the
+ Binding Cache is searched before the Neighbor Discovery conceptual
+ Destination Cache [18].
+
+ Each Binding Cache entry conceptually contains the following fields:
+
+ o The home address of the mobile node for which this is the Binding
+ Cache entry. This field is used as the key for searching the
+ Binding Cache for the destination address of a packet being sent.
+
+ o The care-of address for the mobile node indicated by the home
+ address field in this Binding Cache entry.
+
+ o A lifetime value, indicating the remaining lifetime for this
+ Binding Cache entry. The lifetime value is initialized from the
+ Lifetime field in the Binding Update that created or last modified
+ this Binding Cache entry. A correspondent node MAY select a
+ smaller lifetime for the Binding Cache entry, and supply that
+ value to the mobile node in the Binding Acknowledgment message.
+
+ o A flag indicating whether or not this Binding Cache entry is a
+ home registration entry (applicable only on nodes that support
+ home agent functionality).
+
+ o The maximum value of the Sequence Number field received in
+ previous Binding Updates for this home address. The Sequence
+ Number field is 16 bits long. Sequence Number values MUST be
+ compared modulo 2**16 as explained in Section 9.5.1.
+
+ o Usage information for this Binding Cache entry. This is needed to
+ implement the cache replacement policy in use in the Binding
+ Cache. Recent use of a cache entry also serves as an indication
+ that a Binding Refresh Request should be sent when the lifetime of
+ this entry nears expiration.
+
+ Binding Cache entries not marked as home registrations MAY be
+ replaced at any time by any reasonable local cache replacement policy
+ but SHOULD NOT be unnecessarily deleted. The Binding Cache for any
+ one of a node's IPv6 addresses may contain at most one entry for each
+ mobile node home address. The contents of a node's Binding Cache
+ MUST NOT be changed in response to a Home Address option in a
+ received packet.
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 77]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+9.2. Processing Mobility Headers
+
+ Mobility Header processing MUST observe the following rules:
+
+ o The checksum must be verified as per Section 6.1. If invalid, the
+ node MUST silently discard the message.
+
+ o The MH Type field MUST have a known value (Section 6.1.1).
+ Otherwise, the node MUST discard the message and issue a Binding
+ Error message as described in Section 9.3.3, with the Status field
+ set to 2 (unrecognized MH Type value).
+
+ o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
+ Otherwise, the node MUST discard the message and SHOULD send ICMP
+ Parameter Problem, Code 0, directly to the Source Address of the
+ packet as specified in RFC 4443 [17]. Thus, no Binding Cache
+ information is used in sending the ICMP message. The Pointer
+ field in the ICMP message SHOULD point at the Payload Proto field.
+
+ o The Header Len field in the Mobility Header MUST NOT be less than
+ the length specified for this particular type of message in
+ Section 6.1. Otherwise, the node MUST discard the message and
+ SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
+ Address of the packet as specified in RFC 4443 [17]. (The Binding
+ Cache information is again not used.) The Pointer field in the
+ ICMP message SHOULD point at the Header Len field.
+
+ Subsequent checks depend on the particular Mobility Header.
+
+9.3. Packet Processing
+
+ This section describes how the correspondent node sends packets to
+ the mobile node, and receives packets from it.
+
+9.3.1. Receiving Packets with Home Address Option
+
+ Packets containing a Home Address option MUST be dropped if the given
+ home address is not a unicast routable address.
+
+ Mobile nodes can include a Home Address destination option in a
+ packet if they believe the correspondent node has a Binding Cache
+ entry for the home address of a mobile node. If the Next Header
+ value of the Destination Option is one of the following: {50 (ESP),
+ 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
+ normally. Otherwise, the packet MUST be dropped if there is no
+ corresponding Binding Cache entry. A corresponding Binding Cache
+
+
+
+
+
+Perkins, et al. Standards Track [Page 78]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ entry MUST have the same home address as appears in the Home Address
+ destination option, and the currently registered care-of address MUST
+ be equal to the source address of the packet.
+
+ If the packet is dropped due to the above tests, the correspondent
+ node MUST send the Binding Error message as described in
+ Section 9.3.3. The Status field in this message should be set to 1
+ (unknown binding for Home Address destination option).
+
+ The correspondent node MUST process the option in a manner consistent
+ with exchanging the Home Address field from the Home Address option
+ into the IPv6 header and replacing the original value of the Source
+ Address field there. After all IPv6 options have been processed, it
+ MUST be possible for upper layers to process the packet without the
+ knowledge that it came originally from a care-of address or that a
+ Home Address option was used.
+
+ The use of IPsec Authentication Header (AH) for the Home Address
+ option is not required, except that if the IPv6 header of a packet is
+ covered by AH, then the authentication MUST also cover the Home
+ Address option; this coverage is achieved automatically by the
+ definition of the Option Type code for the Home Address option, since
+ it indicates that the data within the option cannot change en route
+ to the packet's final destination, and thus the option is included in
+ the AH computation. By requiring that any authentication of the IPv6
+ header also cover the Home Address option, the security of the Source
+ Address field in the IPv6 header is not compromised by the presence
+ of a Home Address option.
+
+ When attempting to verify AH authentication data in a packet that
+ contains a Home Address option, the receiving node MUST calculate the
+ AH authentication data as if the following were true: the Home
+ Address option contains the care-of address, and the source IPv6
+ address field of the IPv6 header contains the home address. This
+ conforms with the calculation specified in Section 11.3.2.
+
+9.3.2. Sending Packets to a Mobile Node
+
+ Before sending any packet, the sending node SHOULD examine its
+ Binding Cache for an entry for the destination address to which the
+ packet is being sent. If the sending node has a Binding Cache entry
+ for this address, the sending node SHOULD use a type 2 routing header
+ to route the packet to this mobile node (the destination node) by way
+ of its care-of address. However, the sending node MUST NOT do this
+ in the following cases:
+
+ o When sending an IPv6 Neighbor Discovery [18] packet.
+
+
+
+
+Perkins, et al. Standards Track [Page 79]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Where otherwise noted in Section 6.1.
+
+ When calculating authentication data in a packet that contains a type
+ 2 routing header, the correspondent node MUST calculate the AH
+ authentication data as if the following were true: the routing header
+ contains the care-of address, the destination IPv6 address field of
+ the IPv6 header contains the home address, and the Segments Left
+ field is zero. The IPsec Security Policy Database lookup MUST based
+ on the mobile node's home address.
+
+ For instance, assuming there are no additional routing headers in
+ this packet beyond those needed by Mobile IPv6, the correspondent
+ node could set the fields in the packet's IPv6 header and routing
+ header as follows:
+
+ o The Destination Address in the packet's IPv6 header is set to the
+ mobile node's home address (the original destination address to
+ which the packet was being sent).
+
+ o The routing header is initialized to contain a single route
+ segment, containing the mobile node's care-of address copied from
+ the Binding Cache entry. The Segments Left field is, however,
+ temporarily set to zero.
+
+ The IP layer will insert the routing header before performing any
+ necessary IPsec processing. Once all IPsec processing has been
+ performed, the node swaps the IPv6 destination field with the Home
+ Address field in the routing header, sets the Segments Left field to
+ one, and sends the packet. This ensures the AH calculation is done
+ on the packet in the form it will have on the receiver after
+ advancing the routing header.
+
+ Following the definition of a type 2 routing header in Section 6.4,
+ this packet will be routed to the mobile node's care-of address,
+ where it will be delivered to the mobile node (the mobile node has
+ associated the care-of address with its network interface).
+
+ Note that following the above conceptual model in an implementation
+ creates some additional requirements for path MTU discovery since the
+ layer that determines the packet size (e.g., TCP and applications
+ using UDP) needs to be aware of the size of the headers added by the
+ IP layer on the sending node.
+
+ If, instead, the sending node has no Binding Cache entry for the
+ destination address to which the packet is being sent, the sending
+ node simply sends the packet normally, with no routing header. If
+ the destination node is not a mobile node (or is a mobile node that
+ is currently at home), the packet will be delivered directly to this
+
+
+
+Perkins, et al. Standards Track [Page 80]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ node and processed normally by it. If, however, the destination node
+ is a mobile node that is currently away from home, the packet will be
+ intercepted by the mobile node's home agent and tunneled to the
+ mobile node's current primary care-of address.
+
+9.3.3. Sending Binding Error Messages
+
+ Sections 9.2 and 9.3.1 describe error conditions that lead to a need
+ to send a Binding Error message.
+
+ A Binding Error message is sent directly to the address that appeared
+ in the IPv6 Source Address field of the offending packet. If the
+ Source Address field does not contain a unicast address, the Binding
+ Error message MUST NOT be sent.
+
+ The Home Address field in the Binding Error message MUST be copied
+ from the Home Address field in the Home Address destination option of
+ the offending packet, or set to the unspecified address if no such
+ option appeared in the packet.
+
+ Note that the IPv6 Source Address and Home Address field values
+ discussed above are the values from the wire, i.e., before any
+ modifications possibly performed as specified in Section 9.3.1.
+
+ Binding Error messages SHOULD be subject to rate limiting in the same
+ manner as is done for ICMPv6 messages [17].
+
+9.3.4. Receiving ICMP Error Messages
+
+ When the correspondent node has a Binding Cache entry for a mobile
+ node, all traffic destined to the mobile node goes directly to the
+ current care-of address of the mobile node using a routing header.
+ Any ICMP error message caused by packets on their way to the care-of
+ address will be returned in the normal manner to the correspondent
+ node.
+
+ On the other hand, if the correspondent node has no Binding Cache
+ entry for the mobile node, the packet will be routed through the
+ mobile node's home link. Any ICMP error message caused by the packet
+ on its way to the mobile node while in the tunnel, will be
+ transmitted to the mobile node's home agent. By the definition of
+ IPv6 encapsulation [7], the home agent MUST relay certain ICMP error
+ messages back to the original sender of the packet, which in this
+ case is the correspondent node.
+
+ Thus, in all cases, any meaningful ICMP error messages caused by
+ packets from a correspondent node to a mobile node will be returned
+ to the correspondent node. If the correspondent node receives
+
+
+
+Perkins, et al. Standards Track [Page 81]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ persistent ICMP Destination Unreachable messages after sending
+ packets to a mobile node based on an entry in its Binding Cache, the
+ correspondent node SHOULD delete this Binding Cache entry. Note that
+ if the mobile node continues to send packets with the Home Address
+ destination option to this correspondent node, they will be dropped
+ due to the lack of a binding. For this reason it is important that
+ only persistent ICMP messages lead to the deletion of the Binding
+ Cache entry.
+
+9.4. Return Routability Procedure
+
+ This subsection specifies actions taken by a correspondent node
+ during the return routability procedure.
+
+9.4.1. Receiving Home Test Init Messages
+
+ Upon receiving a Home Test Init message, the correspondent node
+ verifies the following:
+
+ o The packet MUST NOT include a Home Address destination option.
+
+ Any packet carrying a Home Test Init message that fails to satisfy
+ this test MUST be silently ignored.
+
+ Otherwise, in preparation for sending the corresponding Home Test
+ Message, the correspondent node checks that it has the necessary
+ material to engage in a return routability procedure, as specified in
+ Section 5.2. The correspondent node MUST have a secret Kcn and a
+ nonce. If it does not have this material yet, it MUST produce it
+ before continuing with the return routability procedure.
+
+ Section 9.4.3 specifies further processing.
+
+9.4.2. Receiving Care-of Test Init Messages
+
+ Upon receiving a Care-of Test Init message, the correspondent node
+ verifies the following:
+
+ o The packet MUST NOT include a Home Address destination option.
+
+ Any packet carrying a Care-of Test Init message that fails to satisfy
+ this test MUST be silently ignored.
+
+ Otherwise, in preparation for sending the corresponding Care-of Test
+ Message, the correspondent node checks that it has the necessary
+ material to engage in a return routability procedure in the manner
+ described in Section 9.4.1.
+
+
+
+
+Perkins, et al. Standards Track [Page 82]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Section 9.4.4 specifies further processing.
+
+9.4.3. Sending Home Test Messages
+
+ The correspondent node creates a home keygen token and uses the
+ current nonce index as the Home Nonce Index. It then creates a Home
+ Test message (Section 6.1.5) and sends it to the mobile node at the
+ latter's home address.
+
+9.4.4. Sending Care-of Test Messages
+
+ The correspondent node creates a care-of keygen token and uses the
+ current nonce index as the Care-of Nonce Index. It then creates a
+ Care-of Test message (Section 6.1.6) and sends it to the mobile node
+ at the latter's care-of address.
+
+9.5. Processing Bindings
+
+ This section explains how the correspondent node processes messages
+ related to bindings. These messages are:
+
+ o Binding Update
+
+ o Binding Refresh Request
+
+ o Binding Acknowledgement
+
+ o Binding Error
+
+9.5.1. Receiving Binding Updates
+
+ Before accepting a Binding Update, the receiving node MUST validate
+ the Binding Update according to the following tests:
+
+ o The packet MUST contain a unicast routable home address, either in
+ the Home Address option or in the Source Address, if the Home
+ Address option is not present.
+
+ o The Sequence Number field in the Binding Update is greater than
+ the Sequence Number received in the previous valid Binding Update
+ for this home address, if any.
+
+ If the receiving node has no Binding Cache entry for the indicated
+ home address, it MUST accept any Sequence Number value in a
+ received Binding Update from this mobile node.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 83]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ This Sequence Number comparison MUST be performed modulo 2**16,
+ i.e., the number is a free running counter represented modulo
+ 65536. A Sequence Number in a received Binding Update is
+ considered less than or equal to the last received number if its
+ value lies in the range of the last received number and the
+ preceding 32768 values, inclusive. For example, if the last
+ received sequence number was 15, then messages with sequence
+ numbers 0 through 15, as well as 32783 through 65535, would be
+ considered less than or equal.
+
+ When the Home Registration (H) bit is not set, the following are also
+ required:
+
+ o A Nonce Indices mobility option MUST be present, and the Home and
+ Care-of Nonce Index values in this option MUST be recent enough to
+ be recognized by the correspondent node. (Care-of Nonce Index
+ values are not inspected for requests to delete a binding.)
+
+ o The correspondent node MUST re-generate the home keygen token and
+ the care-of keygen token from the information contained in the
+ packet. It then generates the binding management key Kbm and uses
+ it to verify the authenticator field in the Binding Update as
+ specified in Section 6.1.7.
+
+ o The Binding Authorization Data mobility option MUST be present,
+ and its contents MUST satisfy rules presented in Section 5.2.6.
+ Note that a care-of address different from the Source Address MAY
+ have been specified by including an Alternate Care-of Address
+ mobility option in the Binding Update. When such a message is
+ received and the return routability procedure is used as an
+ authorization method, the correspondent node MUST verify the
+ authenticator by using the address within the Alternate Care-of
+ Address in the calculations.
+
+ o The Binding Authorization Data mobility option MUST be the last
+ option and MUST NOT have trailing padding.
+
+ If the Home Registration (H) bit is set, the Nonce Indices mobility
+ option MUST NOT be present.
+
+ If the mobile node sends a sequence number that is not greater than
+ the sequence number from the last valid Binding Update for this home
+ address, then the receiving node MUST send back a Binding
+ Acknowledgement with status code 135, and the last accepted sequence
+ number in the Sequence Number field of the Binding Acknowledgement.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 84]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ If a binding already exists for the given home address and the home
+ registration flag has a different value than the Home Registration
+ (H) bit in the Binding Update, then the receiving node MUST send back
+ a Binding Acknowledgement with status code 139 (registration type
+ change disallowed). The home registration flag stored in the Binding
+ Cache entry MUST NOT be changed.
+
+ If the receiving node no longer recognizes the Home Nonce Index
+ value, Care-of Nonce Index value, or both values from the Binding
+ Update, then the receiving node MUST send back a Binding
+ Acknowledgement with status code 136, 137, or 138, respectively.
+
+ Packets carrying Binding Updates that fail to satisfy all of these
+ tests for any reason other than insufficiency of the Sequence Number,
+ registration type change, or expired nonce index values, MUST be
+ silently discarded.
+
+ If the Binding Update is valid according to the tests above, then the
+ Binding Update is processed further as follows:
+
+ 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
+ for the given home address.
+
+ o If the Lifetime specified in the Binding Update is not zero, then
+ this is a request to cache a binding for the home address. If the
+ Home Registration (H) bit is set in the Binding Update, the
+ Binding Update is processed according to the procedure specified
+ in Section 10.3.1; otherwise, it is processed according to the
+ procedure specified in Section 9.5.2.
+
+ o If the Lifetime specified in the Binding Update is zero, then this
+ is a request to delete the cached binding for the home address.
+ In this case, the Binding Update MUST include a valid home nonce
+ index, and the care-of nonce index MUST be ignored by the
+ correspondent node. The generation of the binding management key
+ depends then exclusively on the home keygen token (Section 5.2.5).
+ If the Home Registration (H) bit is set in the Binding Update, the
+ Binding Update is processed according to the procedure specified
+ in Section 10.3.2; otherwise, it is processed according to the
+ procedure specified in Section 9.5.3.
+
+ The specified care-of address MUST be determined as follows:
+
+ o If the Alternate Care-of Address option is present, the care-of
+ address is the address in that option.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 85]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Otherwise, the care-of address is the Source Address field in the
+ packet's IPv6 header.
+
+ The home address for the binding MUST be determined as follows:
+
+ o If the Home Address destination option is present, the home
+ address is the address in that option.
+
+ o Otherwise, the home address is the Source Address field in the
+ packet's IPv6 header.
+
+9.5.2. Requests to Cache a Binding
+
+ This section describes the processing of a valid Binding Update that
+ requests a node to cache a binding, for which the Home Registration
+ (H) bit is not set in the Binding Update.
+
+ In this case, the receiving node SHOULD create a new entry in its
+ Binding Cache for this home address, or update its existing Binding
+ Cache entry for this home address, if such an entry already exists.
+ The lifetime for the Binding Cache entry is initialized from the
+ Lifetime field specified in the Binding Update, although this
+ lifetime MAY be reduced by the node caching the binding; the lifetime
+ for the Binding Cache entry MUST NOT be greater than the Lifetime
+ value specified in the Binding Update. Any Binding Cache entry MUST
+ be deleted after the expiration of its lifetime.
+
+ Note that if the mobile node did not request a Binding
+ Acknowledgement, then it is not aware of the selected shorter
+ lifetime. The mobile node may thus use route optimization and send
+ packets with the Home Address destination option. As discussed in
+ Section 9.3.1, such packets will be dropped if there is no binding.
+ This situation is recoverable, but can cause temporary packet loss.
+
+ The correspondent node MAY refuse to accept a new Binding Cache entry
+ if it does not have sufficient resources. A new entry MAY also be
+ refused if the correspondent node believes its resources are utilized
+ more efficiently in some other purpose, such as serving another
+ mobile node with higher amount of traffic. In both cases the
+ correspondent node SHOULD return a Binding Acknowledgement with
+ status value 130.
+
+9.5.3. Requests to Delete a Binding
+
+ This section describes the processing of a valid Binding Update that
+ requests a node to delete a binding when the Home Registration (H)
+ bit is not set in the Binding Update.
+
+
+
+
+Perkins, et al. Standards Track [Page 86]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Any existing binding for the given home address MUST be deleted. A
+ Binding Cache entry for the home address MUST NOT be created in
+ response to receiving the Binding Update.
+
+ If the Binding Cache entry was created by use of return routability
+ nonces, the correspondent node MUST ensure that the same nonces are
+ not used again with the particular home and care-of address. If both
+ nonces are still valid, the correspondent node has to remember the
+ particular combination of nonce indices, addresses, and sequence
+ number as illegal until at least one of the nonces has become too
+ old.
+
+9.5.4. Sending Binding Acknowledgements
+
+ A Binding Acknowledgement may be sent to indicate receipt of a
+ Binding Update as follows:
+
+ o If the Binding Update was discarded as described in Sections 9.2
+ or 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise,
+ the treatment depends on the following rules.
+
+ o If the Acknowledge (A) bit is set in the Binding Update, a Binding
+ Acknowledgement MUST be sent. Otherwise, the treatment depends on
+ the next rule.
+
+ o If the node rejects the Binding Update due to an expired nonce
+ index, sequence number being out of window (Section 9.5.1), or
+ insufficiency of resources (Section 9.5.2), a Binding
+ Acknowledgement MUST be sent. If the node accepts the Binding
+ Update, the Binding Acknowledgement SHOULD NOT be sent.
+
+ If the node accepts the Binding Update and creates or updates an
+ entry for this binding, the Status field in the Binding
+ Acknowledgement MUST be set to a value less than 128. Otherwise, the
+ Status field MUST be set to a value greater than or equal to 128.
+ Values for the Status field are described in Section 6.1.8 and in the
+ IANA registry of assigned numbers [30].
+
+ If the Status field in the Binding Acknowledgement contains the value
+ 136 (expired home nonce index), 137 (expired care-of nonce index), or
+ 138 (expired nonces), then the message MUST NOT include the Binding
+ Authorization Data mobility option. Otherwise, the Binding
+ Authorization Data mobility option MUST be included, and MUST meet
+ the specific authentication requirements for Binding Acknowledgements
+ as defined in Section 5.2.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 87]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ If the Source Address field of the IPv6 header that carried the
+ Binding Update does not contain a unicast address, the Binding
+ Acknowledgement MUST NOT be sent and the Binding Update packet MUST
+ be silently discarded. Otherwise, the acknowledgement MUST be sent
+ to the Source Address. Unlike the treatment of regular packets, this
+ addressing procedure does not use information from the Binding Cache.
+ However, a routing header is needed in some cases. If the Source
+ Address is the home address of the mobile node, i.e., the Binding
+ Update did not contain a Home Address destination option, then the
+ Binding Acknowledgement MUST be sent to that address and the routing
+ header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST
+ be sent using a type 2 routing header that contains the mobile node's
+ home address.
+
+9.5.5. Sending Binding Refresh Requests
+
+ If a Binding Cache entry being deleted is still in active use when
+ sending packets to a mobile node, then the next packet sent to the
+ mobile node will be routed normally to the mobile node's home link.
+ Communication with the mobile node continues, but the tunneling from
+ the home network creates additional overhead and latency in
+ delivering packets to the mobile node.
+
+ If the sender knows that the Binding Cache entry is still in active
+ use, it MAY send a Binding Refresh Request message to the mobile node
+ in an attempt to avoid this overhead and latency due to deleting and
+ recreating the Binding Cache entry. This message is always sent to
+ the home address of the mobile node.
+
+ The correspondent node MAY retransmit Binding Refresh Request
+ messages as long as the rate limitation is applied. The
+ correspondent node MUST stop retransmitting when it receives a
+ Binding Update.
+
+9.6. Cache Replacement Policy
+
+ Conceptually, a node maintains a separate timer for each entry in its
+ Binding Cache. When creating or updating a Binding Cache entry in
+ response to a received and accepted Binding Update, the node sets the
+ timer for this entry to the specified Lifetime period. Any entry in
+ a node's Binding Cache MUST be deleted after the expiration of the
+ Lifetime specified in the Binding Update from which the entry was
+ created or last updated.
+
+ Each node's Binding Cache will, by necessity, have a finite size. A
+ node MAY use any reasonable local policy for managing the space
+ within its Binding Cache.
+
+
+
+
+Perkins, et al. Standards Track [Page 88]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ A node MAY choose to drop any entry already in its Binding Cache in
+ order to make space for a new entry. For example, a "least-recently
+ used" (LRU) strategy for cache entry replacement among entries should
+ work well, unless the size of the Binding Cache is substantially
+ insufficient. When entries are deleted, the correspondent node MUST
+ follow the rules in Section 5.2.8 in order to guard the return
+ routability procedure against replay attacks.
+
+ If the node sends a packet to a destination for which it has dropped
+ the entry from its Binding Cache, the packet will be routed through
+ the mobile node's home link. The mobile node can detect this and
+ establish a new binding if necessary.
+
+ However, if the mobile node believes that the binding still exists,
+ it may use route optimization and send packets with the Home Address
+ destination option. This can create temporary packet loss, as
+ discussed earlier, in the context of binding lifetime reductions
+ performed by the correspondent node (Section 9.5.2).
+
+10. Home Agent Operation
+
+10.1. Conceptual Data Structures
+
+ Each home agent MUST maintain a Binding Cache and Home Agents List.
+
+ The rules for maintaining a Binding Cache are the same for home
+ agents and correspondent nodes and have already been described in
+ Section 9.1.
+
+ The Home Agents List is maintained by each home agent, recording
+ information about each router on the same link that is acting as a
+ home agent. This list is used by the dynamic home agent address
+ discovery mechanism. A router is known to be acting as a home agent,
+ if it sends a Router Advertisement in which the Home Agent (H) bit is
+ set. When the lifetime for a list entry (defined below) expires,
+ that entry is removed from the Home Agents List. The Home Agents
+ List is similar to the Default Router List conceptual data structure
+ maintained by each host for Neighbor Discovery [18]. The Home Agents
+ List MAY be implemented in any manner consistent with the external
+ behavior described in this document.
+
+ Each home agent maintains a separate Home Agents List for each link
+ on which it is serving as a home agent. A new entry is created or an
+ existing entry is updated in response to receipt of a valid Router
+ Advertisement in which the Home Agent (H) bit is set. Each Home
+ Agents List entry conceptually contains the following fields:
+
+
+
+
+
+Perkins, et al. Standards Track [Page 89]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The link-local IP address of a home agent on the link. This
+ address is learned through the Source Address of the Router
+ Advertisements [18] received from the router.
+
+ o One or more global IP addresses for this home agent. Global
+ addresses are learned through Prefix Information options with the
+ Router Address (R) bit set and received in Router Advertisements
+ from this link-local address. Global addresses for the router in
+ a Home Agents List entry MUST be deleted once the prefix
+ associated with that address is no longer valid [18].
+
+ o The remaining lifetime of this Home Agents List entry. If a Home
+ Agent Information Option is present in a Router Advertisement
+ received from a home agent, the lifetime of the Home Agents List
+ entry representing that home agent is initialized from the Home
+ Agent Lifetime field in the option (if present); otherwise, the
+ lifetime is initialized from the Router Lifetime field in the
+ received Router Advertisement. If Home Agents List entry lifetime
+ reaches zero, the entry MUST be deleted from the Home Agents List.
+
+ o The preference for this home agent; higher values indicate a more
+ preferable home agent. The preference value is taken from the
+ Home Agent Preference field in the received Router Advertisement,
+ if the Router Advertisement contains a Home Agent Information
+ Option and is otherwise set to the default value of 0. A home
+ agent uses this preference in ordering the Home Agents List when
+ it sends an ICMP Home Agent Address Discovery message.
+
+10.2. Processing Mobility Headers
+
+ All IPv6 home agents MUST observe the rules described in Section 9.2
+ when processing Mobility Headers.
+
+10.3. Processing Bindings
+
+10.3.1. Primary Care-of Address Registration
+
+ When a node receives a Binding Update, it MUST validate it and
+ determine the type of Binding Update according to the steps described
+ in Section 9.5.1. Furthermore, it MUST authenticate the Binding
+ Update as described in Section 5.1. An authorization step specific
+ for the home agent is also needed to ensure that only the right node
+ can control a particular home address. This is provided through the
+ home address unequivocally identifying the security association that
+ must be used.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 90]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ This section describes the processing of a valid and authorized
+ Binding Update when it requests the registration of the mobile node's
+ primary care-of address.
+
+ To begin processing the Binding Update, the home agent MUST perform
+ the following sequence of tests:
+
+ o If the node implements only correspondent node functionality, or
+ has not been configured to act as a home agent, then the node MUST
+ reject the Binding Update. The node MUST also return a Binding
+ Acknowledgement to the mobile node, in which the Status field is
+ set to 131 (home registration not supported).
+
+ o Else, if the home address for the binding (the Home Address field
+ in the packet's Home Address option) is not an on-link IPv6
+ address with respect to the home agent's current Prefix List, then
+ the home agent MUST reject the Binding Update and SHOULD return a
+ Binding Acknowledgement to the mobile node, in which the Status
+ field is set to 132 (not home subnet).
+
+ o Else, if the home agent chooses to reject the Binding Update for
+ any other reason (e.g., insufficient resources to serve another
+ mobile node as a home agent), then the home agent SHOULD return a
+ Binding Acknowledgement to the mobile node, in which the Status
+ field is set to an appropriate value to indicate the reason for
+ the rejection.
+
+ o A Home Address destination option MUST be present in the message.
+ It MUST be validated as described in Section 9.3.1 with the
+ following additional rule. The Binding Cache entry existence test
+ MUST NOT be done for IPsec packets when the Home Address option
+ contains an address for which the receiving node could act as a
+ home agent.
+
+ If home agent accepts the Binding Update, it MUST then create a new
+ entry in its Binding Cache for this mobile node or update its
+ existing Binding Cache entry, if such an entry already exists. The
+ Home Address field as received in the Home Address option provides
+ the home address of the mobile node.
+
+ The home agent MUST mark this Binding Cache entry as a home
+ registration to indicate that the node is serving as a home agent for
+ this binding. Binding Cache entries marked as a home registration
+ MUST be excluded from the normal cache replacement policy used for
+ the Binding Cache (Section 9.6) and MUST NOT be removed from the
+ Binding Cache until the expiration of the Lifetime period.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 91]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Unless this home agent already has a binding for the given home
+ address, the home agent MUST perform Duplicate Address Detection [19]
+ on the mobile node's home link before returning the Binding
+ Acknowledgement. This ensures that no other node on the home link
+ was using the mobile node's home address when the Binding Update
+ arrived. If this Duplicate Address Detection fails for the given
+ home address or an associated link local address, then the home agent
+ MUST reject the complete Binding Update and MUST return a Binding
+ Acknowledgement to the mobile node, in which the Status field is set
+ to 134 (Duplicate Address Detection failed). When the home agent
+ sends a successful Binding Acknowledgement to the mobile node, the
+ home agent assures to the mobile node that its address(es) will be
+ kept unique by the home agent for as long as the lifetime was granted
+ for the binding.
+
+ The specific addresses, which are to be tested before accepting the
+ Binding Update and later to be defended by performing Duplicate
+ Address Detection, depend on the setting of the Link-Local Address
+ Compatibility (L) bit, as follows:
+
+ o L=0: Defend only the given address. Do not derive a link-local
+ address.
+
+ o L=1: Defend both the given non link-local unicast (home) address
+ and the derived link-local. The link-local address is derived by
+ replacing the subnet prefix in the mobile node's home address with
+ the link-local prefix.
+
+ The lifetime of the Binding Cache entry depends on a number of
+ factors:
+
+ o The lifetime for the Binding Cache entry MUST NOT be greater than
+ the Lifetime value specified in the Binding Update.
+
+ o The lifetime for the Binding Cache entry MUST NOT be greater than
+ the remaining valid lifetime for the subnet prefix in the mobile
+ node's home address specified with the Binding Update. The
+ remaining valid lifetime for this prefix is determined by the home
+ agent based on its own Prefix List entry [18].
+
+ The remaining preferred lifetime SHOULD NOT have any impact on the
+ lifetime for the Binding Cache entry.
+
+ The home agent MUST remove a binding when the valid lifetime of
+ the prefix associated with it expires.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 92]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The home agent MAY further decrease the specified lifetime for the
+ binding, for example, based on a local policy. The resulting
+ lifetime is stored by the home agent in the Binding Cache entry,
+ and this Binding Cache entry MUST be deleted by the home agent
+ after the expiration of this lifetime.
+
+ Regardless of the setting of the Acknowledge (A) bit in the Binding
+ Update, the home agent MUST return a Binding Acknowledgement to the
+ mobile node constructed as follows:
+
+ o The Status field MUST be set to a value indicating success. The
+ value 1 (accepted but prefix discovery necessary) MUST be used if
+ the subnet prefix of the specified home address is deprecated, or
+ becomes deprecated during the lifetime of the binding, or becomes
+ invalid at the end of the lifetime. The value 0 MUST be used
+ otherwise. For the purposes of comparing the binding and prefix
+ lifetimes, the prefix lifetimes are first converted into units of
+ four seconds by ignoring the two least significant bits.
+
+ o The Key Management Mobility Capability (K) bit is set if the
+ following conditions are all fulfilled, and cleared otherwise:
+
+ * The Key Management Mobility Capability (K) bit was set in the
+ Binding Update.
+
+ * The IPsec security associations between the mobile node and the
+ home agent have been established dynamically.
+
+ * The home agent has the capability to update its endpoint in the
+ used key management protocol to the new care-of address every
+ time it moves.
+
+ Depending on the final value of the bit in the Binding
+ Acknowledgement, the home agent SHOULD perform the following
+ actions:
+
+ K = 0
+
+ Discard key management connections, if any, to the old care-of
+ address. If the mobile node did not have a binding before
+ sending this Binding Update, discard the connections to the
+ home address.
+
+ K = 1
+
+ Move the peer endpoint of the key management protocol
+ connection, if any, to the new care-of address.
+
+
+
+
+Perkins, et al. Standards Track [Page 93]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The Sequence Number field MUST be copied from the Sequence Number
+ given in the Binding Update.
+
+ o The Lifetime field MUST be set to the remaining lifetime for the
+ binding as set by the home agent in its home registration Binding
+ Cache entry for the mobile node, as described above.
+
+ o If the home agent stores the Binding Cache entry in nonvolatile
+ storage, then the Binding Refresh Advice mobility option MUST be
+ omitted. Otherwise, the home agent MAY include this option to
+ suggest that the mobile node refreshes its binding before the
+ actual lifetime of the binding ends.
+
+ If the Binding Refresh Advice mobility option is present, the
+ Refresh Interval field in the option MUST be set to a value less
+ than the Lifetime value being returned in the Binding
+ Acknowledgement. This indicates that the mobile node SHOULD
+ attempt to refresh its home registration at the indicated shorter
+ interval. The home agent MUST still retain the registration for
+ the Lifetime period, even if the mobile node does not refresh its
+ registration within the Refresh period.
+
+ The rules for selecting the Destination IP address (and possibly
+ routing header construction) for the Binding Acknowledgement to the
+ mobile node are the same as in Section 9.5.4.
+
+ In addition, the home agent MUST follow the procedure defined in
+ Section 10.4.1 to intercept packets on the mobile node's home link
+ addressed to the mobile node, while the home agent is serving as the
+ home agent for this mobile node. The home agent MUST also be
+ prepared to accept reverse-tunneled packets from the new care-of
+ address of the mobile node, as described in Section 10.4.5. Finally,
+ the home agent MUST also propagate new home network prefixes, as
+ described in Section 10.6.
+
+10.3.2. Primary Care-of Address De-Registration
+
+ A binding may need to be de-registered when the mobile node returns
+ home or when the mobile node knows that it will not have any care-of
+ addresses in the visited network.
+
+ A Binding Update is validated and authorized in the manner described
+ in the previous section; note that when the mobile node de-registers
+ when it is at home, it MAY choose to omit the Home Address
+ destination option, in which case the mobile node's home address is
+ the source IP address of the de-registration Binding Update. This
+
+
+
+
+
+Perkins, et al. Standards Track [Page 94]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ section describes the processing of a valid Binding Update that
+ requests the receiving node to no longer serve as its home agent, de-
+ registering its primary care-of address.
+
+ To begin processing the Binding Update, the home agent MUST perform
+ the following test:
+
+ o If the receiving node has no entry marked as a home registration
+ in its Binding Cache for this mobile node, then this node MUST
+ reject the Binding Update and SHOULD return a Binding
+ Acknowledgement to the mobile node, in which the Status field is
+ set to 133 (not home agent for this mobile node).
+
+ If the home agent does not reject the Binding Update as described
+ above, then the home agent MUST return a Binding Acknowledgement to
+ the mobile node, constructed as follows:
+
+ o The Status field MUST be set to a value 0, indicating success.
+
+ o The Key Management Mobility Capability (K) bit is set or cleared
+ and actions based on its value are performed as described in the
+ previous section. The mobile node's home address is used as its
+ new care-of address for the purposes of moving the key management
+ connection to a new endpoint.
+
+ o The Sequence Number field MUST be copied from the Sequence Number
+ given in the Binding Update.
+
+ o The Lifetime field MUST be set to zero.
+
+ o The Binding Refresh Advice mobility option MUST be omitted.
+
+ The rules for selecting the Destination IP address (and, if required,
+ routing header construction) for the Binding Acknowledgement to the
+ mobile node are the same as in the previous section. When the Status
+ field in the Binding Acknowledgement is greater than or equal to 128
+ and the Source Address of the Binding Update is on the home link, and
+ the Binding Update came from a mobile node on the same link, the home
+ agent MUST send it to the mobile node's link-layer address (retrieved
+ either from the Binding Update or through Neighbor Solicitation).
+
+ When a mobile node sends a Binding Update to refresh the binding from
+ the visited link and soon after moves to the home link and sends a
+ de-registration Binding Update, a race condition can happen if the
+ first Binding Update gets delayed. The delayed Binding Update can
+ cause the home agent to create a new Binding Cache entry for a mobile
+
+
+
+
+
+Perkins, et al. Standards Track [Page 95]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ node that had just attached to the home link and successfully deleted
+ the binding. This would prevent the mobile node from using its home
+ address from the home link.
+
+ In order to prevent this, the home agent SHOULD NOT remove the
+ Binding Cache entry immediately after receiving the de-registration
+ Binding Update from the mobile node. It SHOULD mark the Binding
+ Cache entry as invalid, and MUST stop intercepting packets on the
+ mobile node's home link that are addressed to the mobile node
+ (Section 10.4.1). The home agent should wait for
+ MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the
+ Binding Cache entry completely. In the scenario described above, if
+ the home agent receives the delayed Binding Update that the mobile
+ node sent from the visited link, it would reject the message since
+ the sequence number would be less than the last received de-
+ registration Binding Update from the home link. The home agent would
+ then send a Binding Acknowledgment with status '135' (Sequence number
+ out of window) to the care-of address on the visited link. The
+ mobile node can continue using the home address from the home link.
+
+10.4. Packet Processing
+
+10.4.1. Intercepting Packets for a Mobile Node
+
+ While a node is serving as the home agent for a mobile node it MUST
+ attempt to intercept packets on the mobile node's home link that are
+ addressed to the mobile node.
+
+ In order to do this, when a node begins serving as the home agent it
+ MUST have performed Duplicate Address Detection (as specified in
+ Section 10.3.1), and subsequently it MUST multicast onto the home
+ link a Neighbor Advertisement message [18] on behalf of the mobile
+ node. For the home address specified in the Binding Update, the home
+ agent sends a Neighbor Advertisement message [18] to the all-nodes
+ multicast address on the home link to advertise the home agent's own
+ link-layer address for this IP address on behalf of the mobile node.
+ If the Link-Layer Address Compatibility (L) flag has been specified
+ in the Binding Update, the home agent MUST do the same for the link-
+ local address of the mobile node.
+
+ All fields in each Neighbor Advertisement message SHOULD be set in
+ the same way they would be set by the mobile node if it was sending
+ this Neighbor Advertisement [18] while at home, with the following
+ exceptions:
+
+ o The Target Address in the Neighbor Advertisement MUST be set to
+ the specific IP address for the mobile node.
+
+
+
+
+Perkins, et al. Standards Track [Page 96]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The Advertisement MUST include a Target Link-layer Address option
+ specifying the home agent's link-layer address.
+
+ o The Router (R) bit in the Advertisement MUST be set to zero.
+
+ o The Solicited (S) flag in the Advertisement MUST NOT be set, since
+ it was not solicited by any Neighbor Solicitation.
+
+ o The Override (O) flag in the Advertisement MUST be set, indicating
+ that the Advertisement SHOULD override any existing Neighbor Cache
+ entry at any node receiving it.
+
+ o The Source Address in the IPv6 header MUST be set to the home
+ agent's IP address on the interface used to send the
+ advertisement.
+
+ Any node on the home link that receives one of the Neighbor
+ Advertisement messages (described above) will update its Neighbor
+ Cache to associate the mobile node's address with the home agent's
+ link-layer address, causing it to transmit any future packets
+ normally destined to the mobile node to the mobile node's home agent.
+ Since multicasting on the local link (such as Ethernet) is typically
+ not guaranteed to be reliable, the home agent MAY retransmit this
+ Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see
+ [18]) times to increase its reliability. It is still possible that
+ some nodes on the home link will not receive any of the Neighbor
+ Advertisements, but these nodes will eventually be able to detect the
+ link-layer address change for the mobile node's address through use
+ of Neighbor Unreachability Detection [18].
+
+ While a node is serving as a home agent for some mobile node, the
+ home agent uses IPv6 Neighbor Discovery [18] to intercept unicast
+ packets on the home link addressed to the mobile node. In order to
+ intercept packets in this way, the home agent MUST act as a proxy for
+ this mobile node and reply to any received Neighbor Solicitations for
+ it. When a home agent receives a Neighbor Solicitation, it MUST
+ check if the Target Address specified in the message matches the
+ address of any mobile node for which it has a Binding Cache entry
+ marked as a home registration.
+
+ If such an entry exists in the home agent's Binding Cache, the home
+ agent MUST reply to the Neighbor Solicitation with a Neighbor
+ Advertisement giving the home agent's own link-layer address as the
+ link-layer address for the specified Target Address. In addition,
+ the Router (R) bit in the Advertisement MUST be set to zero. Acting
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 97]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ as a proxy in this way allows other nodes on the mobile node's home
+ link to resolve the mobile node's address and for the home agent to
+ defend these addresses on the home link for Duplicate Address
+ Detection [18].
+
+10.4.2. Processing Intercepted Packets
+
+ For any packet sent to a mobile node from the mobile node's home
+ agent (in which the home agent is the original sender of the packet),
+ the home agent is operating as a correspondent node of the mobile
+ node for this packet and the procedures described in Section 9.3.2
+ apply. The home agent then uses a routing header to route the packet
+ to the mobile node by way of the primary care-of address in the home
+ agent's Binding Cache.
+
+ While the mobile node is away from home, the home agent intercepts
+ any packets on the home link addressed to the mobile node's home
+ address, as described in Section 10.4.1. In order to forward each
+ intercepted packet to the mobile node, the home agent MUST tunnel the
+ packet to the mobile node using IPv6 encapsulation [7]. When a home
+ agent encapsulates an intercepted packet for forwarding to the mobile
+ node, the home agent sets the Source Address in the new tunnel IP
+ header to the home agent's own IP address and sets the Destination
+ Address in the tunnel IP header to the mobile node's primary care-of
+ address. When received by the mobile node, normal processing of the
+ tunnel header [7] will result in decapsulation and processing of the
+ original packet by the mobile node.
+
+ However, packets addressed to the mobile node's link-local address
+ MUST NOT be tunneled to the mobile node. Instead, these packets MUST
+ be discarded and the home agent SHOULD return an ICMP Destination
+ Unreachable, Code 3, message to the packet's Source Address (unless
+ this Source Address is a multicast address).
+
+ Interception and tunneling of the following multicast addressed
+ packets on the home network are only done if the home agent supports
+ multicast group membership control messages from the mobile node as
+ described in the next section. Tunneling of multicast packets to a
+ mobile node follows similar limitations to those defined above for
+ unicast packets addressed to the mobile node's link-local address.
+ Multicast packets addressed to a multicast address with link-local
+ scope [16], to which the mobile node is subscribed, MUST NOT be
+ tunneled to the mobile node. These packets SHOULD be silently
+ discarded (after delivering to other local multicast recipients).
+ Multicast packets addressed to a multicast address with a scope
+ larger than link-local, but smaller than global (e.g., site-local and
+ organization-local [16]), to which the mobile node is subscribed,
+
+
+
+
+Perkins, et al. Standards Track [Page 98]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ SHOULD NOT be tunneled to the mobile node. Multicast packets
+ addressed with a global scope, to which the mobile node has
+ successfully subscribed, MUST be tunneled to the mobile node.
+
+ Before tunneling a packet to the mobile node, the home agent MUST
+ perform any IPsec processing as indicated by the security policy data
+ base.
+
+10.4.3. Multicast Membership Control
+
+ This section is a prerequisite for the multicast data packet
+ forwarding, described in the previous section. If this support is
+ not provided, multicast group membership control messages are
+ silently ignored.
+
+ In order to forward multicast data packets from the home network to
+ all the proper mobile nodes, the home agent SHOULD be capable of
+ receiving tunneled multicast group membership control information
+ from the mobile node in order to determine which groups the mobile
+ node has subscribed to. These multicast group membership messages
+ are Listener Report messages specified in Multicast Listener
+ Discovery (MLD) [9] or in other protocols such as [41].
+
+ The messages are issued by the mobile node, but sent through the
+ reverse tunnel to the home agent. These messages are issued whenever
+ the mobile node decides to enable reception of packets for a
+ multicast group or in response to an MLD Query from the home agent.
+ The mobile node will also issue multicast group control messages to
+ disable reception of multicast packets when it is no longer
+ interested in receiving multicasts for a particular group.
+
+ To obtain the mobile node's current multicast group membership the
+ home agent must periodically transmit MLD Query messages through the
+ tunnel to the mobile node. These MLD periodic transmissions will
+ ensure the home agent has an accurate record of the groups in which
+ the mobile node is interested despite packet losses of the mobile
+ node's MLD group membership messages.
+
+ All MLD packets are sent directly between the mobile node and the
+ home agent. Since all of these packets are destined to a link-scope
+ multicast address and have a hop limit of 1, there is no direct
+ forwarding of such packets between the home network and the mobile
+ node. The MLD packets between the mobile node and the home agent are
+ encapsulated within the same tunnel header used for other packet
+ flows between the mobile node and home agent.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 99]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Note that at this time, even though a link-local source is used on
+ MLD packets, no functionality depends on these addresses being
+ unique, nor do they elicit direct responses. All MLD messages are
+ sent to multicast destinations. To avoid ambiguity on the home
+ agent, due to mobile nodes that may choose identical link-local
+ source addresses for their MLD function, it is necessary for the home
+ agent to identify which mobile node was actually the issuer of a
+ particular MLD message. This may be accomplished by noting which
+ tunnel such an MLD arrived by, which IPsec security association (SA)
+ was used, or by other distinguishing means.
+
+ This specification puts no requirement on how the functions in this
+ section and the multicast forwarding in Section 10.4.2 are to be
+ achieved. At the time of this writing, it was thought that a full
+ IPv6 multicast router function would be necessary on the home agent,
+ but it may be possible to achieve the same effects through a "proxy
+ MLD" application coupled with kernel multicast forwarding. This may
+ be the subject of future specifications.
+
+10.4.4. Stateful Address Autoconfiguration
+
+ This section describes how home agents support the use of stateful
+ address autoconfiguration mechanisms such as DHCPv6 [31] from the
+ mobile nodes. If this support is not provided, then the M and O bits
+ must remain cleared on the Mobile Prefix Advertisement Messages. Any
+ mobile node that sends DHCPv6 messages to the home agent without this
+ support will not receive a response.
+
+ If DHCPv6 is used, packets are sent with link-local source addresses
+ either to a link-scope multicast address or a link-local address.
+ Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel
+ standard DHCPv6 packets to the home agent. Since these link-scope
+ packets cannot be forwarded onto the home network, it is necessary
+ for the home agent to implement either a DHCPv6 relay agent or a
+ DHCPv6 server function itself. The arriving tunnel or IPsec SA of
+ DHCPv6 link-scope messages from the mobile node must be noted so that
+ DHCPv6 responses may be sent back to the appropriate mobile node.
+ DHCPv6 messages sent to the mobile node with a link-local destination
+ must be tunneled within the same tunnel header used for other packet
+ flows.
+
+10.4.5. Handling Reverse-Tunneled Packets
+
+ Unless a binding has been established between the mobile node and a
+ correspondent node, traffic from the mobile node to the correspondent
+ node goes through a reverse tunnel. Home agents MUST support reverse
+ tunneling as follows:
+
+
+
+
+Perkins, et al. Standards Track [Page 100]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The tunneled traffic arrives to the home agent's address using
+ IPv6 encapsulation [7].
+
+ o Depending on the security policies used by the home agent,
+ reverse-tunneled packets MAY be discarded unless accompanied by a
+ valid ESP header. The support for authenticated reverse tunneling
+ allows the home agent to protect the home network and
+ correspondent nodes from malicious nodes masquerading as a mobile
+ node.
+
+ o Otherwise, when a home agent decapsulates a tunneled packet from
+ the mobile node, the home agent MUST verify that the Source
+ Address in the tunnel IP header is the mobile node's primary
+ care-of address. Otherwise, any node in the Internet could send
+ traffic through the home agent and escape ingress filtering
+ limitations. This simple check forces the attacker to know the
+ current location of the real mobile node and be able to defeat
+ ingress filtering. This check is not necessary if the reverse-
+ tunneled packet is protected by ESP in tunnel mode.
+
+10.4.6. Protecting Return Routability Packets
+
+ The return routability procedure, described in Section 5.2.5, assumes
+ that the confidentiality of the Home Test Init and Home Test messages
+ is protected as they are tunneled between the home agent and the
+ mobile node. Therefore, the home agent MUST support tunnel mode
+ IPsec ESP for the protection of packets belonging to the return
+ routability procedure. Support for a non-null encryption transform
+ and authentication algorithm MUST be available. It is not necessary
+ to distinguish between different kinds of packets during the return
+ routability procedure.
+
+ Security associations are needed to provide this protection. When
+ the care-of address for the mobile node changes as a result of an
+ accepted Binding Update, special treatment is needed for the next
+ packets sent using these security associations. The home agent MUST
+ set the new care-of address as the destination address of these
+ packets, as if the outer header destination address in the security
+ association had changed.
+
+ The above protection SHOULD be used with all mobile nodes. The use
+ is controlled by configuration of the IPsec security policy database
+ both at the mobile node and at the home agent.
+
+ As described earlier, the Binding Update and Binding Acknowledgement
+ messages require protection between the home agent and the mobile
+ node. The Mobility Header protocol carries both these messages as
+ well as the return routability messages. From the point of view of
+
+
+
+Perkins, et al. Standards Track [Page 101]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ the security policy database these messages are indistinguishable.
+ When IPsec is used to protect return routability signaling or payload
+ packets, this protection MUST only be applied to the return
+ routability packets entering the IPv6 encapsulated tunnel interface
+ between the mobile node and the home agent. This can be achieved,
+ for instance, by defining the security policy database entries
+ specifically for the tunnel interface. That is, the policy entries
+ are not generally applied on all traffic on the physical interface(s)
+ of the nodes, but rather only on traffic that enters the tunnel.
+ This makes use of per-interface security policy database entries [3]
+ specific to the tunnel interface (the node's attachment to the tunnel
+ [6]).
+
+10.5. Dynamic Home Agent Address Discovery
+
+ This section describes an optional mechanism by which a home agent
+ can help mobile nodes to discover the addresses of other home agents
+ on the mobile node's home network. The home agent keeps track of the
+ other home agents on the same link and responds to queries sent by
+ the mobile node.
+
+10.5.1. Receiving Router Advertisement Messages
+
+ For each link on which a router provides service as a home agent, the
+ router maintains a Home Agents List recording information about all
+ other home agents on that link. This list is used in the dynamic
+ home agent address discovery mechanism; the mobile node uses the list
+ as described in Section 11.4.1. The information for the list is
+ learned through receipt of the periodic unsolicited multicast Router
+ Advertisements, in a manner similar to the Default Router List
+ conceptual data structure maintained by each host for Neighbor
+ Discovery [18]. In the construction of the Home Agents List, the
+ Router Advertisements are from each (other) home agent on the link
+ and the Home Agent (H) bit is set in them.
+
+ On receipt of a valid Router Advertisement, as defined in the
+ processing algorithm specified for Neighbor Discovery [18], the home
+ agent performs the following steps in addition to any steps already
+ required of it by Neighbor Discovery:
+
+ 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
+ (if one exists). Skip all the following steps.
+
+ o Otherwise, extract the Source Address from the IP header of the
+ Router Advertisement. This is the link-local IP address on this
+ link of the home agent sending this Advertisement [18].
+
+
+
+
+Perkins, et al. Standards Track [Page 102]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Determine the preference for this home agent. If the Router
+ Advertisement contains a Home Agent Information Option, then the
+ preference is taken from the Home Agent Preference field in the
+ option; otherwise, the default preference of 0 MUST be used.
+
+ o Determine the lifetime for this home agent. If the Router
+ Advertisement contains a Home Agent Information Option, then the
+ lifetime is taken from the Home Agent Lifetime field in the
+ option; otherwise, the lifetime specified by the Router Lifetime
+ field in the Router Advertisement SHOULD be used.
+
+ o If the link-local address of the home agent sending this
+ Advertisement is already present in this home agent's Home Agents
+ List and the received home agent lifetime value is zero,
+ immediately delete this entry in the Home Agents List.
+
+ o Otherwise, if the link-local address of the home agent sending
+ this Advertisement is already present in the receiving home
+ agent's Home Agents List, reset its lifetime and preference to the
+ values determined above.
+
+ o If the link-local address of the home agent sending this
+ Advertisement is not already present in the Home Agents List
+ maintained by the receiving home agent, and the lifetime for the
+ sending home agent is non-zero, create a new entry in the list,
+ and initialize its lifetime and preference to the values
+ determined above.
+
+ o If the Home Agents List entry for the link-local address of the
+ home agent sending this Advertisement was not deleted as described
+ above, determine any global address(es) of the home agent based on
+ each Prefix Information option received in this Advertisement in
+ which the Router Address (R) bit is set (Section 7.2). Add all
+ such global addresses to the list of global addresses in this Home
+ Agents List entry.
+
+ A home agent SHOULD maintain an entry in its Home Agents List for
+ each valid home agent address until that entry's lifetime expires,
+ after which time the entry MUST be deleted.
+
+ As described in Section 11.4.1, a mobile node attempts dynamic home
+ agent address discovery by sending an ICMP Home Agent Address
+ Discovery Request message to the Mobile IPv6 Home-Agents anycast
+ address [8] for its home IP subnet prefix. A home agent receiving a
+ Home Agent Address Discovery Request message that serves this subnet
+ SHOULD return an ICMP Home Agent Address Discovery Reply message to
+
+
+
+
+
+Perkins, et al. Standards Track [Page 103]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ the mobile node with the Source Address of the Reply packet set to
+ one of the global unicast addresses of the home agent. The Home
+ Agent Addresses field in the Reply message is constructed as follows:
+
+ o The Home Agent Addresses field SHOULD contain all global IP
+ addresses for each home agent currently listed in this home
+ agent's own Home Agents List (Section 10.1).
+
+ o The IP addresses in the Home Agent Addresses field SHOULD be
+ listed in order of decreasing preference values, based either on
+ the respective advertised preference from a Home Agent Information
+ option or on the default preference of 0 if no preference is
+ advertised (or on the configured home agent preference for this
+ home agent itself).
+
+ o Among home agents with equal preference, their IP addresses in the
+ Home Agent Addresses field SHOULD be listed in an order randomized
+ with respect to other home agents with equal preference every time
+ a Home Agent Address Discovery Reply message is returned by this
+ home agent.
+
+ o If more than one global IP address is associated with a home
+ agent, these addresses SHOULD be listed in a randomized order.
+
+ o The home agent SHOULD reduce the number of home agent IP addresses
+ so that the packet fits within the minimum IPv6 MTU [6]. The home
+ agent addresses selected for inclusion in the packet SHOULD be
+ those from the complete list with the highest preference. This
+ limitation avoids the danger of the Reply message packet being
+ fragmented (or rejected by an intermediate router with an ICMP
+ Packet Too Big message [17]).
+
+10.6. Sending Prefix Information to the Mobile Node
+
+10.6.1. List of Home Network Prefixes
+
+ Mobile IPv6 arranges to propagate relevant prefix information to the
+ mobile node when it is away from home, so that it may be used in
+ mobile node home address configuration and in network renumbering.
+ In this mechanism, mobile nodes away from home receive Mobile Prefix
+ Advertisement messages. These messages include Prefix Information
+ Options for the prefixes configured on the home subnet interface(s)
+ of the home agent.
+
+ If there are multiple home agents, differences in the advertisements
+ sent by different home agents can lead to an inability to use a
+ particular home address when changing to another home agent. In
+
+
+
+
+Perkins, et al. Standards Track [Page 104]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ order to ensure that the mobile nodes get the same information from
+ different home agents, it is preferred that all of the home agents on
+ the same link be configured in the same manner.
+
+ To support this, the home agent monitors prefixes advertised by
+ itself and other home agents on the home link. In Neighbor Discovery
+ (RFC 4861 [18]) it is acceptable for two routers to advertise
+ different sets of prefixes on the same link. For home agents, the
+ differences should be detected for a given home address because the
+ mobile node communicates only with one home agent at a time and the
+ mobile node needs to know the full set of prefixes assigned to the
+ home link. All other comparisons of Router Advertisements are as
+ specified in Section 6.2.7 of RFC 4861.
+
+10.6.2. Scheduling Prefix Deliveries
+
+ A home agent serving a mobile node will schedule the delivery of the
+ new prefix information to that mobile node when any of the following
+ conditions occur:
+
+ MUST:
+
+ o The state of the flags changes for the prefix of the mobile node's
+ registered home address.
+
+ o The valid or preferred lifetime is reconfigured or changes for any
+ reason other than advancing real time.
+
+ o The mobile node requests the information with a Mobile Prefix
+ Solicitation (see Section 11.4.2).
+
+ SHOULD:
+
+ o A new prefix is added to the home subnet interface(s) of the home
+ agent.
+
+ MAY:
+
+ o The valid or preferred lifetime or the state of the flags changes
+ for a prefix that is not used in any Binding Cache entry for this
+ mobile node.
+
+ The home agent uses the following algorithm to determine when to send
+ prefix information to the mobile node.
+
+ o If a mobile node sends a solicitation, answer right away.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 105]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o If no Mobile Prefix Advertisement has been sent to the mobile node
+ in the last MaxMobPfxAdvInterval seconds (see Section 13), then
+ ensure that a transmission is scheduled. The actual transmission
+ time is randomized as described below.
+
+ o If a prefix matching the mobile node's home registration is added
+ on the home subnet interface or if its information changes in any
+ way that does not deprecate the mobile node's address, ensure that
+ a transmission is scheduled. The actual transmission time is
+ randomized as described below.
+
+ o If a home registration expires, cancel any scheduled
+ advertisements to the mobile node.
+
+ The list of prefixes is sent in its entirety in all cases.
+
+ If the home agent has already scheduled the transmission of a Mobile
+ Prefix Advertisement to the mobile node, then the home agent will
+ replace the advertisement with a new one to be sent at the scheduled
+ time.
+
+ Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY
+ that offsets from the current time for the scheduled transmission.
+ First, calculate the maximum delay for the scheduled Advertisement:
+
+
+ MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
+
+ where MaxMobPfxAdvInterval is as defined in Section 12. Then,
+ compute the final delay for the advertisement:
+
+
+ RAND_ADV_DELAY = MinMobPfxAdvInterval +
+ (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
+
+ Here rand() returns a random integer value in the range of 0 to the
+ maximum possible integer value. This computation is expected to
+ alleviate bursts of advertisements when prefix information changes.
+ In addition, a home agent MAY further reduce the rate of packet
+ transmission by further delaying individual advertisements, when
+ necessary to avoid overwhelming local network resources. The home
+ agent SHOULD periodically continue to retransmit an unsolicited
+ Advertisement to the mobile node, until it is acknowledged by the
+ receipt of a Mobile Prefix Solicitation from the mobile node.
+
+ The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before
+ the first retransmission and double the retransmission wait time for
+ every succeeding retransmission until a maximum number of
+
+
+
+Perkins, et al. Standards Track [Page 106]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ PREFIX_ADV_RETRIES attempts (see Section 12) has been tried. If the
+ mobile node's bindings expire before the matching Binding Update has
+ been received, then the home agent MUST NOT attempt any more
+ retransmissions, even if not all PREFIX_ADV_RETRIES have been
+ retransmitted. In the meantime, if the mobile node sends another
+ Binding Update without returning home, then the home agent SHOULD
+ begin transmitting the unsolicited Advertisement again.
+
+ If some condition, as described above, occurs on the home link and
+ causes another Prefix Advertisement to be sent to the mobile node,
+ before the mobile node acknowledges a previous transmission, the home
+ agent SHOULD combine any Prefix Information options in the
+ unacknowledged Mobile Prefix Advertisement into a new Advertisement.
+ The home agent then discards the old Advertisement.
+
+10.6.3. Sending Advertisements
+
+ When sending a Mobile Prefix Advertisement to the mobile node, the
+ home agent MUST construct the packet as follows:
+
+ o The Source Address in the packet's IPv6 header MUST be set to the
+ home agent's IP address to which the mobile node addressed its
+ current home registration or its default global home agent address
+ if no binding exists.
+
+ o If the advertisement was solicited, it MUST be destined to the
+ source address of the solicitation. If it was triggered by prefix
+ changes or renumbering, the advertisement's destination will be
+ the mobile node's home address in the binding that triggered the
+ rule.
+
+ o A type 2 routing header MUST be included with the mobile node's
+ home address.
+
+ o IPsec headers MUST be supported and SHOULD be used.
+
+ o The home agent MUST send the packet as it would any other unicast
+ IPv6 packet that it originates.
+
+ o Set the Managed Address Configuration (M) flag if the
+ corresponding flag has been set in any of the Router
+ Advertisements from which the prefix information has been learned
+ (including the ones sent by this home agent).
+
+ o Set the Other Stateful Configuration (O) flag if the corresponding
+ flag has been set in any of the Router Advertisements from which
+ the prefix information has been learned (including the ones sent
+ by this home agent).
+
+
+
+Perkins, et al. Standards Track [Page 107]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+10.6.4. Lifetimes for Changed Prefixes
+
+ As described in Section 10.3.1, the lifetime returned by the home
+ agent in a Binding Acknowledgement MUST NOT be greater than the
+ remaining valid lifetime for the subnet prefix in the mobile node's
+ home address. This limit on the binding lifetime serves to prohibit
+ use of a mobile node's home address after it becomes invalid.
+
+11. Mobile Node Operation
+
+11.1. Conceptual Data Structures
+
+ Each mobile node MUST maintain a Binding Update List.
+
+ The Binding Update List records information for each Binding Update
+ sent by this mobile node, in which the lifetime of the binding has
+ not yet expired. The Binding Update List includes all bindings sent
+ by the mobile node to either its home agent or correspondent nodes.
+ It also contains Binding Updates that are waiting for the completion
+ of the return routability procedure before they can be sent.
+ However, for multiple Binding Updates sent to the same destination
+ address, the Binding Update List contains only the most recent
+ Binding Update (i.e., with the greatest Sequence Number value) sent
+ to that destination. The Binding Update List MAY be implemented in
+ any manner consistent with the external behavior described in this
+ document.
+
+ Each Binding Update List entry conceptually contains the following
+ fields:
+
+ o The IP address of the node to which a Binding Update was sent.
+
+ o The home address for which that Binding Update was sent.
+
+ o The care-of address sent in that Binding Update. This value is
+ necessary for the mobile node to determine if it has sent a
+ Binding Update while giving its new care-of address to this
+ destination after changing its care-of address.
+
+ o The initial value of the Lifetime field sent in that Binding
+ Update.
+
+ o The remaining lifetime of that binding. This lifetime is
+ initialized from the Lifetime value sent in the Binding Update and
+ is decremented until it reaches zero, at which time this entry
+ MUST be deleted from the Binding Update List.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 108]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The maximum value of the Sequence Number field sent in previous
+ Binding Updates to this destination. The Sequence Number field is
+ 16 bits long and all comparisons between Sequence Number values
+ MUST be performed modulo 2**16 (see Section 9.5.1).
+
+ o The time at which a Binding Update was last sent to this
+ destination, as needed to implement the rate limiting restriction
+ for sending Binding Updates.
+
+ o The state of any retransmissions needed for this Binding Update.
+ This state includes the time remaining until the next
+ retransmission attempt for the Binding Update and the current
+ state of the exponential back-off mechanism for retransmissions.
+
+ o A flag specifying whether or not future Binding Updates should be
+ sent to this destination. The mobile node sets this flag in the
+ Binding Update List entry when it receives an ICMP Parameter
+ Problem, Code 1, error message in response to a return routability
+ message or Binding Update sent to that destination, as described
+ in Section 11.3.5.
+
+ The Binding Update List is used to determine whether a particular
+ packet is sent directly to the correspondent node or tunneled via the
+ home agent (see Section 11.3.1).
+
+ The Binding Update list also conceptually contains the following data
+ related to running the return routability procedure. This data is
+ relevant only for Binding Updates sent to correspondent nodes.
+
+ o The time at which a Home Test Init or Care-of Test Init message
+ was last sent to this destination, as needed to implement the rate
+ limiting restriction for the return routability procedure.
+
+ o The state of any retransmissions needed for this return
+ routability procedure. This state includes the time remaining
+ until the next retransmission attempt and the current state of the
+ exponential back-off mechanism for retransmissions.
+
+ o Cookie values used in the Home Test Init and Care-of Test Init
+ messages.
+
+ o Home and care-of keygen tokens received from the correspondent
+ node.
+
+ o Home and care-of nonce indices received from the correspondent
+ node.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 109]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The time at which each of the tokens and nonces were received from
+ the correspondent node, as needed to implement reuse while moving.
+
+11.2. Processing Mobility Headers
+
+ All IPv6 mobile nodes MUST observe the rules described in Section 9.2
+ when processing Mobility Headers.
+
+11.3. Packet Processing
+
+11.3.1. Sending Packets While Away from Home
+
+ While a mobile node is away from home, it continues to use its home
+ address, as well as also using one or more care-of addresses. When
+ sending a packet while away from home, a mobile node MAY choose among
+ these in selecting the address that it will use as the source of the
+ packet, as follows:
+
+ o Protocols layered over IP will generally treat the mobile node's
+ home address as its IP source address for most packets. For
+ packets sent that are part of transport-level connections
+ established while the mobile node was at home, the mobile node
+ MUST use its home address. Likewise, for packets sent that are
+ part of transport-level connections that the mobile node may still
+ be using after moving to a new location, the mobile node SHOULD
+ use its home address in this way. If a binding exists, the mobile
+ node SHOULD send the packets directly to the correspondent node.
+ Otherwise, if a binding does not exist, the mobile node MUST use
+ reverse tunneling.
+
+ o The mobile node MAY choose to directly use one of its care-of
+ addresses as the source of the packet, not requiring the use of a
+ Home Address option in the packet. This is particularly useful
+ for short-term communication that may easily be retried if it
+ fails. Using the mobile node's care-of address as the source for
+ such queries will generally have a lower overhead than using the
+ mobile node's home address, since no extra options need to be used
+ in either the query or its reply. Such packets can be routed
+ normally, directly between their source and destination without
+ relying on Mobile IPv6. If application running on the mobile node
+ has no particular knowledge that the communication being sent fits
+ within this general type of communication, however, the mobile
+ node should not use its care-of address as the source of the
+ packet in this way.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 110]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The choice of the most efficient communications method is
+ application specific, and outside the scope of this specification.
+ The APIs necessary for controlling the choice are also out of
+ scope. One example of such an API is described in the IPv6 Socket
+ API for Source Address Selection specification [44].
+
+ o While not at its home link, the mobile node MUST NOT use the Home
+ Address destination option when communicating with link-local
+ peers.
+
+ Similarly, the mobile node MUST NOT use the Home Address
+ destination option for IPv6 Neighbor Discovery [18] packets.
+
+ Detailed operation of these cases is described later in this section
+ and also discussed in [33].
+
+ For packets sent by a mobile node while it is at home, no special
+ Mobile IPv6 processing is required. Likewise, if the mobile node
+ uses any address other than one of its home addresses as the source
+ of a packet sent while away from home, no special Mobile IPv6
+ processing is required. In either case, the packet is simply
+ addressed and transmitted in the same way as any normal IPv6 packet.
+
+ For packets sent by the mobile node sent while away from home using
+ the mobile node's home address as the source, special Mobile IPv6
+ processing of the packet is required. This can be done in the
+ following two ways:
+
+ Route Optimization
+
+ This manner of delivering packets does not require going through
+ the home network, and typically will enable faster and more
+ reliable transmission.
+
+ The mobile node needs to ensure that a Binding Cache entry exists
+ for its home address so that the correspondent node can process
+ the packet (Section 9.3.1 specifies the rules for Home Address
+ Destination Option Processing at a correspondent node). The
+ mobile node SHOULD examine its Binding Update List for an entry
+ that fulfills the following conditions:
+
+ * The Source Address field of the packet being sent is equal to
+ the home address in the entry.
+
+ * The Destination Address field of the packet being sent is equal
+ to the address of the correspondent node in the entry.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 111]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ * One of the current care-of addresses of the mobile node appears
+ as the care-of address in the entry.
+
+ * The entry indicates that a binding has been successfully
+ created.
+
+ * The remaining lifetime of the binding is greater than zero.
+
+
+ When these conditions are met, the mobile node knows that the
+ correspondent node has a suitable Binding Cache entry.
+
+ A mobile node SHOULD arrange to supply the home address in a Home
+ Address option, and MUST set the IPv6 header's Source Address
+ field to the care-of address that the mobile node has registered
+ to be used with this correspondent node. The correspondent node
+ will then use the address supplied in the Home Address option to
+ serve the function traditionally done by the Source IP address in
+ the IPv6 header. The mobile node's home address is then supplied
+ to higher protocol layers and applications.
+
+ Specifically:
+
+ * Construct the packet using the mobile node's home address as
+ the packet's Source Address, in the same way as if the mobile
+ node were at home. This includes the calculation of upper-
+ layer checksums using the home address as the value of the
+ source.
+
+ * Insert a Home Address option into the packet with the Home
+ Address field copied from the original value of the Source
+ Address field in the packet.
+
+ * Change the Source Address field in the packet's IPv6 header to
+ one of the mobile node's care-of addresses. This will
+ typically be the mobile node's current primary care-of address,
+ but MUST be an address assigned to the interface on the link
+ being used.
+
+ By using the care-of address as the Source Address in the IPv6
+ header, with the mobile node's home address instead in the Home
+ Address option, the packet will be able to safely pass through any
+ router implementing ingress filtering [27].
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 112]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Reverse Tunneling
+
+ This is the mechanism that tunnels the packets via the home agent.
+ It is not as efficient as the above mechanism, but is needed if
+ there is no binding yet with the correspondent node.
+
+ This mechanism is used for packets that have the mobile node's
+ home address as the Source Address in the IPv6 header, or with
+ multicast control protocol packets as described in Section 11.3.4.
+ Specifically:
+
+ * The packet is sent to the home agent using IPv6 encapsulation
+ [7].
+
+ * The Source Address in the tunnel packet is the primary care-of
+ address as registered with the home agent.
+
+ * The Destination Address in the tunnel packet is the home
+ agent's address.
+
+ Then, the home agent will pass the encapsulated packet to the
+ correspondent node.
+
+11.3.2. Interaction with Outbound IPsec Processing
+
+ This section sketches the interaction between outbound Mobile IPv6
+ processing and outbound IP Security (IPsec) processing for packets
+ sent by a mobile node while away from home. Any specific
+ implementation MAY use algorithms and data structures other than
+ those suggested here, but its processing MUST be consistent with the
+ effect of the operation described here and with the relevant IPsec
+ specifications. In the steps described below, it is assumed that
+ IPsec is being used in transport mode [3] and that the mobile node is
+ using its home address as the source for the packet (from the point
+ of view of higher protocol layers or applications, as described in
+ Section 11.3.1):
+
+ o The packet is created by higher-layer protocols and applications
+ (e.g., by TCP) as if the mobile node were at home and Mobile IPv6
+ were not being used.
+
+ o Determine the outgoing interface for the packet. (Note that the
+ selection between reverse tunneling and route optimization may
+ imply different interfaces, particularly if tunnels are considered
+ interfaces as well.)
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 113]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o As part of outbound packet processing in IP, the packet is
+ compared against the IPsec security policy database to determine
+ what processing is required for the packet [3].
+
+ o If IPsec processing is required, the packet is either mapped to an
+ existing security association (or SA bundle), or a new SA (or SA
+ bundle) is created for the packet, according to the procedures
+ defined for IPsec.
+
+ o Since the mobile node is away from home, the mobile is using
+ either reverse tunneling or route optimization to reach the
+ correspondent node.
+
+ If reverse tunneling is used, the packet is constructed in the
+ normal manner and then tunneled through the home agent.
+
+ If route optimization is in use, the mobile node inserts a Home
+ Address destination option into the packet, replacing the Source
+ Address in the packet's IP header with the care-of address used
+ with this correspondent node, as described in Section 11.3.1. The
+ Destination Options header in which the Home Address destination
+ option is inserted MUST appear in the packet after the routing
+ header, if present, and before the IPsec (AH [4] or ESP [5])
+ header, so that the Home Address destination option is processed
+ by the destination node before the IPsec header is processed.
+
+ Finally, once the packet is fully assembled, the necessary IPsec
+ authentication (and encryption, if required) processing is
+ performed on the packet, initializing the Authentication Data in
+ the IPsec header.
+
+ The treatment of destination options described in RFC 4302 is
+ extended as follows. The AH authentication data MUST be
+ calculated as if the following were true:
+
+ * the IPv6 source address in the IPv6 header contains the mobile
+ node's home address, and
+
+ * the Home Address field of the Home Address destination option
+ (Section 6.3) contains the new care-of address.
+
+ o This allows, but does not require, the receiver of the packet
+ containing a Home Address destination option to exchange the two
+ fields of the incoming packet to reach the above situation,
+ simplifying processing for all subsequent packet headers.
+ However, such an exchange is not required, as long as the result
+ of the authentication calculation remains the same.
+
+
+
+
+Perkins, et al. Standards Track [Page 114]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ When an automated key management protocol is used to create new
+ security associations for a peer, it is important to ensure that the
+ peer can send the key management protocol packets to the mobile node.
+ This may not be possible if the peer is the home agent of the mobile
+ node and the purpose of the security associations would be to send a
+ Binding Update to the home agent. Packets addressed to the home
+ address of the mobile node cannot be used before the Binding Update
+ has been processed. For the default case of using IKEv2 [24] as the
+ automated key management protocol, such problems can be avoided by
+ the following requirements when communicating with its home agent:
+
+ o When the mobile node is away from home, it MUST use its care-of
+ address as the Source Address of all packets it sends as part of
+ the key management protocol (without use of Mobile IPv6 for these
+ packets, as suggested in Section 11.3.1).
+
+ The Key Management Mobility Capability (K) bit in Binding Updates and
+ Acknowledgements can be used to avoid the need to rerun IKEv2 upon
+ movements.
+
+11.3.3. Receiving Packets While Away from Home
+
+ While away from home, a mobile node will receive packets addressed to
+ its home address, by one of two methods:
+
+ o Packets sent by a correspondent node that does not have a Binding
+ Cache entry for the mobile node will be sent to the home address,
+ captured by the home agent and tunneled to the mobile node.
+
+ o Packets sent by a correspondent node that has a Binding Cache
+ entry for the mobile node that contains the mobile node's current
+ care-of address will be sent by the correspondent node using a
+ type 2 routing header. The packet will be addressed to the mobile
+ node's care-of address, with the final hop in the routing header
+ directing the packet to the mobile node's home address; the
+ processing of this last hop of the routing header is entirely
+ internal to the mobile node, since the care-of address and home
+ address are both addresses within the mobile node.
+
+ For packets received by the first method, the mobile node MUST check
+ that the IPv6 source address of the tunneled packet is the IP address
+ of its home agent. In this method, the mobile node may also send a
+ Binding Update to the original sender of the packet as described in
+ Section 11.7.2 and subject to the rate limiting defined in
+ Section 11.8. The mobile node MUST also process the received packet
+ in the manner defined for IPv6 encapsulation [7], which will result
+
+
+
+
+
+Perkins, et al. Standards Track [Page 115]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ in the encapsulated (inner) packet being processed normally by upper-
+ layer protocols within the mobile node as if it had been addressed
+ (only) to the mobile node's home address.
+
+ For packets received by the second method, the following rules will
+ result in the packet being processed normally by upper-layer
+ protocols within the mobile node as if it had been addressed to the
+ mobile node's home address.
+
+ A node receiving a packet addressed to itself (i.e., one of the
+ node's addresses is in the IPv6 destination field) follows the next
+ header chain of headers and processes them. When it encounters a
+ type 2 routing header during this processing, it performs the
+ following checks. If any of these checks fail, the node MUST
+ silently discard the packet.
+
+ o The length field in the routing header is exactly 2.
+
+ o The segments left field in the routing header is 1 on the wire.
+ (But implementations may process the routing header so that the
+ value may become 0 after the routing header has been processed,
+ but before the rest of the packet is processed.)
+
+ o The Home Address field in the routing header is one of the node's
+ home addresses, if the segments left field was 1. Thus, in
+ particular the address field is required to be a unicast routable
+ address.
+
+ Once the above checks have been performed, the node swaps the IPv6
+ destination field with the Home Address field in the routing header,
+ decrements segments left by one from the value it had on the wire,
+ and resubmits the packet to IP for processing the next header.
+ Conceptually, this follows the same model as in RFC 2460. However,
+ in the case of the type 2 routing header, this can be simplified
+ since it is known that the packet will not be forwarded to a
+ different node.
+
+ The definition of AH requires the sender to calculate the AH
+ integrity check value of a routing header in the same way it appears
+ in the receiver after it has processed the header. Since IPsec
+ headers follow the routing header, any IPsec processing will operate
+ on the packet with the home address in the IP destination field and
+ segments left being zero. Thus, the AH calculations at the sender
+ and receiver will have an identical view of the packet.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 116]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+11.3.4. Routing Multicast Packets
+
+ A mobile node that is connected to its home link functions in the
+ same way as any other (stationary) node. Thus, when it is at home, a
+ mobile node functions identically to other multicast senders and
+ receivers. Therefore, this section describes the behavior of a
+ mobile node that is not on its home link.
+
+ 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 MAY join the group, is via a (local) multicast router on the
+ foreign link being visited. In this case, the mobile node MUST use
+ its care-of address and MUST NOT use the Home Address destination
+ option when sending MLD packets [9].
+
+ Alternatively, a mobile node MAY join multicast groups via a
+ bidirectional tunnel to its home agent. The mobile node tunnels its
+ multicast group membership control packets (such as those defined in
+ [9] or in [41]) to its home agent, and the home agent forwards
+ multicast packets down the tunnel to the mobile node. A mobile node
+ 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
+ latter sends at least one multicast group membership control packet
+ 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.
+
+ A mobile node that wishes to send packets to a multicast group also
+ has two options:
+
+ 1. Send directly on the foreign link being visited.
+
+ 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. This requires that the application either knows the
+ care-of address, or uses an API such as the IPv6 Socket API for
+ Source Address Selection specification [44] to request that the
+ care-of address be used as the source address in transmitted
+ packets. The mobile node MUST NOT use the Home Address
+ destination option in such traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 117]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 2. Send via a tunnel to its home agent.
+
+ Because multicast routing in general depends upon the Source
+ Address used in the IPv6 header of the multicast packet, a mobile
+ node that tunnels a multicast packet to its home agent MUST use
+ its home address as the IPv6 Source Address of the inner
+ multicast packet.
+
+ Note that direct sending from the foreign link is only applicable
+ while the mobile node is at that foreign link. This is because the
+ associated multicast tree is specific to that source location and any
+ change of location and source address will invalidate the source-
+ specific tree or branch and the application context of the other
+ multicast group members.
+
+ This specification does not provide mechanisms to enable such local
+ multicast session to survive hand-off and to seamlessly continue from
+ a new care-of address on each new foreign link. Any such mechanism,
+ developed as an extension to this specification, needs to take into
+ account the impact of fast moving mobile nodes on the Internet
+ multicast routing protocols and their ability to maintain the
+ integrity of source specific multicast trees and branches.
+
+ While the use of bidirectional tunneling can ensure that multicast
+ trees are independent of the mobile nodes movement, in some case such
+ tunneling can have adverse effects. The latency of specific types of
+ multicast applications (such as multicast-based discovery protocols)
+ will be affected when the round-trip time between the foreign subnet
+ and the home agent is significant compared to that of the topology to
+ be discovered. In addition, the delivery tree from the home agent in
+ such circumstances relies on unicast encapsulation from the agent to
+ the mobile node. Therefore, bandwidth usage is inefficient compared
+ to the native multicast forwarding in the foreign multicast system.
+
+11.3.5. Receiving ICMP Error Messages
+
+ Any node that does not recognize the Mobility header will return an
+ ICMP Parameter Problem, Code 1, message to the sender of the packet.
+ If the mobile node receives such an ICMP error message in response to
+ a return routability procedure or Binding Update, it SHOULD record in
+ its Binding Update List that future Binding Updates SHOULD NOT be
+ sent to this destination. Such Binding Update List entries SHOULD be
+ removed after a period of time in order to allow for retrying route
+ optimization.
+
+ New Binding Update List entries MUST NOT be created as a result of
+ receiving ICMP error messages.
+
+
+
+
+Perkins, et al. Standards Track [Page 118]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Correspondent nodes that have participated in the return routability
+ procedure MUST implement the ability to correctly process received
+ packets containing a Home Address destination option. Therefore,
+ correctly implemented correspondent nodes should always be able to
+ recognize Home Address options. If a mobile node receives an ICMP
+ Parameter Problem, Code 2, message from some node indicating that it
+ does not support the Home Address option, the mobile node SHOULD log
+ the error and then discard the ICMP message.
+
+11.3.6. Receiving Binding Error Messages
+
+ When a mobile node receives a packet containing a Binding Error
+ message, it should first check if the mobile node has a Binding
+ Update List entry for the source of the Binding Error message. If
+ the mobile node does not have such an entry, it MUST ignore the
+ message. This is necessary to prevent a waste of resources, e.g., on
+ return routability procedure due to spoofed Binding Error messages.
+
+ Otherwise, if the message Status field was 1 (unknown binding for
+ Home Address destination option), the mobile node should perform one
+ of the following three actions:
+
+ o If the Binding Error Message was sent by the home agent, the
+ mobile node SHOULD send a Binding Update to the home agent
+ according to Section 11.7.1.
+
+ o If the mobile node has recent upper-layer progress information,
+ which indicates that communications with the correspondent node
+ are progressing, it MAY ignore the message. This can be done in
+ order to limit the damage that spoofed Binding Error messages can
+ cause to ongoing communications.
+
+ o If the mobile node has no upper-layer progress information, it
+ MUST remove the entry and route further communications through the
+ home agent. It MAY also optionally start a return routability
+ procedure (see Section 5.2).
+
+ If the message Status field was 2 (unrecognized MH Type value), the
+ mobile node should perform one of the following two actions:
+
+ o If the mobile node is not expecting an acknowledgement or response
+ from the correspondent node, the mobile node SHOULD ignore this
+ message.
+
+ o Otherwise, the mobile node SHOULD cease the use of any extensions
+ to this specification. If no extensions had been used, the mobile
+ node should cease the attempt to use route optimization.
+
+
+
+
+Perkins, et al. Standards Track [Page 119]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+11.4. Home Agent and Prefix Management
+
+11.4.1. Dynamic Home Agent Address Discovery
+
+ Sometimes when the mobile node needs to send a Binding Update to its
+ home agent to register its new primary care-of address, as described
+ in Section 11.7.1, the mobile node may not know the address of any
+ router on its home link that can serve as a home agent for it. For
+ example, some nodes on its home link may have been reconfigured while
+ the mobile node has been away from home, such that the router that
+ was operating as the mobile node's home agent has been replaced by a
+ different router serving this role.
+
+ In this case, the mobile node MAY attempt to discover the address of
+ a suitable home agent on its home link. To do so, the mobile node
+ sends an ICMP Home Agent Address Discovery Request message to the
+ Mobile IPv6 Home-Agents anycast address [8] for its home subnet
+ prefix. As described in Section 10.5, the home agent on its home
+ link that receives this Request message will return an ICMP Home
+ Agent Address Discovery Reply message. This message gives the
+ addresses for the home agents operating on the home link.
+
+ The mobile node, upon receiving this Home Agent Address Discovery
+ Reply message, MAY then send its home registration Binding Update to
+ any of the unicast IP addresses listed in the Home Agent Addresses
+ field in the Reply. For example, the mobile node MAY attempt its
+ home registration to each of these addresses, in turn, until its
+ registration is accepted. The mobile node sends a Binding Update to
+ an address and waits for the matching Binding Acknowledgement, moving
+ on to the next address if there is no response. The mobile node
+ MUST, however, wait at least InitialBindackTimeoutFirstReg seconds
+ (see Section 13) before sending a Binding Update to the next home
+ 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
+ Home Agent Addresses field in the received Home Agent Address
+ 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
+ (the Lifetime for that registration has not yet expired), then the
+ mobile node MUST attempt any new registration first with that home
+ agent. If that registration attempt fails (e.g., timed out or
+ rejected), the mobile node SHOULD then reattempt this registration
+
+
+
+
+Perkins, et al. Standards Track [Page 120]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ with another home agent. If the mobile node knows of no other
+ suitable home agent, then it MAY attempt the dynamic home agent
+ address discovery mechanism described above.
+
+ If, after a mobile node transmits a Home Agent Address Discovery
+ Request message to the Home Agents Anycast address, it does not
+ receive a corresponding Home Agent Address Discovery Reply message
+ within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
+ node MAY retransmit the same Request message to the same anycast
+ address. This retransmission MAY be repeated up to a maximum of
+ DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be
+ delayed by twice the time interval of the previous retransmission.
+
+11.4.2. Sending Mobile Prefix Solicitations
+
+ When a mobile node has a home address that is about to become
+ invalid, it SHOULD send a Mobile Prefix Solicitation to its home
+ agent in an attempt to acquire fresh routing prefix information. The
+ new information also enables the mobile node to participate in
+ renumbering operations affecting the home network, as described in
+ Section 10.6.
+
+ The mobile node MUST use the Home Address destination option to carry
+ its home address. The mobile node MUST support and SHOULD use IPsec
+ to protect the solicitation. The mobile node MUST set the Identifier
+ field in the ICMP header to a random value.
+
+ As described in Section 11.7.2, Binding Updates sent by the mobile
+ node to other nodes MUST use a lifetime no greater than the remaining
+ lifetime of its home registration of its primary care-of address.
+ The mobile node SHOULD further limit the lifetimes that it sends on
+ any Binding Updates to be within the remaining valid lifetime (see
+ Section 10.6.2) for the prefix in its home address.
+
+ When the lifetime for a changed prefix decreases, and the change
+ would cause cached bindings at correspondent nodes in the Binding
+ Update List to be stored past the newly shortened lifetime, the
+ mobile node MUST issue a Binding Update to all such correspondent
+ nodes.
+
+ These limits on the binding lifetime serve to prohibit use of a
+ mobile node's home address after it becomes invalid.
+
+11.4.3. Receiving Mobile Prefix Advertisements
+
+ Section 10.6 describes the operation of a home agent to support boot
+ time configuration and renumbering a mobile node's home subnet while
+ the mobile node is away from home. The home agent sends Mobile
+
+
+
+Perkins, et al. Standards Track [Page 121]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Prefix Advertisements to the mobile node while away from home, giving
+ "important" Prefix Information options that describe changes in the
+ prefixes in use on the mobile node's home link.
+
+ The Mobile Prefix Solicitation is similar to the Router Solicitation
+ used in Neighbor Discovery [18], except it is routed from the mobile
+ node on the visited network to the home agent on the home network by
+ usual unicast routing rules.
+
+ When a mobile node receives a Mobile Prefix Advertisement, it MUST
+ validate it according to the following test:
+
+ o The Source Address of the IP packet carrying the Mobile Prefix
+ Advertisement is the same as the home agent address to which the
+ mobile node last sent an accepted home registration Binding Update
+ to register its primary care-of address. Otherwise, if no such
+ registrations have been made, it SHOULD be the mobile node's
+ stored home agent address, if one exists. Otherwise, if the
+ mobile node has not yet discovered its home agent's address, it
+ MUST NOT accept Mobile Prefix Advertisements.
+
+ o The packet MUST have a type 2 routing header and SHOULD be
+ protected by an IPsec header as described in Sections 5.4 and 6.8.
+
+ o If the ICMP Identifier value matches the ICMP Identifier value of
+ the most recently sent Mobile Prefix Solicitation and no other
+ advertisement has yet been received for this value, then the
+ advertisement is considered to be solicited and will be processed
+ further.
+
+ Otherwise, the advertisement is unsolicited, and MUST be
+ discarded. In this case the mobile node SHOULD send a Mobile
+ Prefix Solicitation.
+
+ Any received Mobile Prefix Advertisement not meeting these tests MUST
+ be silently discarded.
+
+ For an accepted Mobile Prefix Advertisement, the mobile node MUST
+ process Managed Address Configuration (M), Other Stateful
+ Configuration (O), and the Prefix Information Options as if they
+ arrived in a Router Advertisement [18] on the mobile node's home
+ link. (This specification does not, however, describe how to acquire
+ home addresses through stateful protocols.) Such processing may
+ result in the mobile node configuring a new home address, although
+ due to separation between preferred lifetime and valid lifetime, such
+ changes should not affect most communications by the mobile node, in
+ the same way as for nodes that are at home.
+
+
+
+
+Perkins, et al. Standards Track [Page 122]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ This specification assumes that any security associations and
+ security policy entries that may be needed for new prefixes have been
+ pre-configured in the mobile node. Note that while dynamic key
+ management avoids the need to configure new security associations, it
+ is still necessary to add policy entries to protect the
+ communications involving the home address(es). Mechanisms for
+ setting up these entries are outside the scope of this specification.
+
+11.5. Movement
+
+11.5.1. Movement Detection
+
+ The primary goal of movement detection is to detect L3 handovers.
+ This section does not attempt to specify a fast movement detection
+ algorithm that will function optimally for all types of applications,
+ link layers, and deployment scenarios; instead, it describes a
+ generic method that uses the facilities of IPv6 Neighbor Discovery,
+ including Router Discovery and Neighbor Unreachability Detection. At
+ the time of this writing, this method is considered well enough
+ understood to recommend for standardization; however, it is expected
+ that future versions of this specification or other specifications
+ may contain updated versions of the movement detection algorithm that
+ have better performance.
+
+ Generic movement detection uses Neighbor Unreachability Detection to
+ detect when the default router is no longer bidirectionally
+ reachable, in which case the mobile node must discover a new default
+ router (usually on a new link). However, this detection only occurs
+ when the mobile node has packets to send, and in the absence of
+ frequent Router Advertisements or indications from the link-layer,
+ the mobile node might become unaware of an L3 handover that occurred.
+ Therefore, the mobile node should supplement this method with other
+ information whenever it is available to the mobile node (e.g., from
+ lower protocol layers).
+
+ When the mobile node detects an L3 handover, it performs Duplicate
+ Address Detection [19] on its link-local address, selects a new
+ default router as a consequence of Router Discovery, and then
+ performs prefix discovery with that new router to form new care-of
+ address(es) as described in Section 11.5.3. It then registers its
+ new primary care-of address with its home agent as described in
+ Section 11.7.1. After updating its home registration, the mobile
+ node then updates associated mobility bindings in correspondent nodes
+ that it is performing route optimization with as specified in
+ Section 11.7.2.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 123]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Due to the temporary packet flow disruption and signaling overhead
+ involved in updating mobility bindings, the mobile node should avoid
+ performing an L3 handover until it is strictly necessary.
+
+ Specifically, when the mobile node receives a Router Advertisement
+ from a new router that contains a different set of on-link prefixes,
+ if the mobile node detects that the currently selected default router
+ on the old link is still bidirectionally reachable, it should
+ generally continue to use the old router on the old link rather than
+ switch away from it to use a new default router.
+
+ Mobile nodes can use the information in received Router
+ Advertisements to detect L3 handovers. In doing so the mobile node
+ needs to consider the following issues:
+
+ o There might be multiple routers on the same link. Thus, hearing a
+ new router does not necessarily constitute an L3 handover.
+
+ o When there are multiple routers on the same link they might
+ advertise different prefixes. Thus, even hearing a new router
+ with a new prefix might not be a reliable indication of an L3
+ handover.
+
+ o The link-local addresses of routers are not globally unique, hence
+ after completing an L3 handover the mobile node might continue to
+ receive Router Advertisements with the same link-local source
+ address. This might be common if routers use the same link-local
+ address on multiple interfaces. This issue can be avoided when
+ routers use the Router Address (R) bit, since that provides a
+ global address of the router.
+
+ In addition, the mobile node should consider the following events as
+ indications that an L3 handover may have occurred. Upon receiving
+ such indications, the mobile node needs to perform Router Discovery
+ to discover routers and prefixes on the new link, as described in
+ Section 6.3.7 of Neighbor Discovery (RFC 4861 [18]).
+
+ o If Router Advertisements that the mobile node receives include an
+ Advertisement Interval option, the mobile node may use its
+ Advertisement Interval field as an indication of the frequency
+ with which it should expect to continue to receive future
+ Advertisements from that router. This field specifies the minimum
+ rate (the maximum amount of time between successive
+ Advertisements) that the mobile node should expect. If this
+ amount of time elapses without the mobile node receiving any
+ Advertisement from this router, the mobile node can be sure that
+ at least one Advertisement sent by the router has been lost. The
+
+
+
+
+Perkins, et al. Standards Track [Page 124]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ mobile node can then implement its own policy to determine how
+ many lost Advertisements from its current default router
+ constitute an L3 handover indication.
+
+ o Neighbor Unreachability Detection determines that the default
+ router is no longer reachable.
+
+ o With some types of networks, notification that an L2 handover has
+ occurred might be obtained from lower-layer protocols or device
+ driver software within the mobile node. While further details
+ around handling L2 indications as movement hints is an item for
+ further study, at the time of writing this specification the
+ following is considered reasonable:
+
+ An L2 handover indication may or may not imply L2 movement and L2
+ movement may or may not imply L3 movement; the correlations might
+ be a function of the type of L2 but might also be a function of
+ actual deployment of the wireless topology.
+
+ Unless it is well-known that an L2 handover indication is likely
+ to imply L3 movement, instead of immediately multicasting a router
+ solicitation it may be better to attempt to verify whether the
+ default router is still bidirectionally reachable. This can be
+ accomplished by sending a unicast Neighbor Solicitation and
+ waiting for a Neighbor Advertisement with the Solicited flag set.
+ Note that this is similar to Neighbor Unreachability detection,
+ but it does not have the same state machine, such as the STALE
+ state.
+
+ If the default router does not respond to the Neighbor
+ Solicitation it makes sense to proceed to multicasting a Router
+ Solicitation.
+
+11.5.2. Home Link Detection
+
+ When an MN detects that it has arrived on a new link using the
+ movement detection algorithm in use (Section 11.5.1) or on
+ bootstrapping, it performs the following steps to determine if it is
+ on the home link.
+
+ o The MN performs the procedure described in Section 11.5.3 and
+ configures an address. It also keeps track of all the on-link
+ prefix(es) received in the RA along with their prefix lengths.
+
+ o If the home prefix has not been statically configured the MN uses
+ some form of bootstrapping procedure (e.g., RFC 5026 [22]) to
+ determine the home prefix.
+
+
+
+
+Perkins, et al. Standards Track [Page 125]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Given the availability of the home prefix, the MN checks whether
+ or not the home prefix matches one of the prefixes received in the
+ RA. If it does, the MN concludes that it is connected to the home
+ link.
+
+11.5.3. Forming New Care-of Addresses
+
+ After detecting that it has moved a mobile node SHOULD generate a new
+ primary care-of address using normal IPv6 mechanisms. This SHOULD
+ also be done when the current primary care-of address becomes
+ deprecated. A mobile node MAY form a new primary care-of address at
+ any time, but a mobile node MUST NOT send a Binding Update about a
+ new care-of address to its home agent more than MAX_UPDATE_RATE times
+ within a second.
+
+ In addition, a mobile node MAY form new non-primary care-of addresses
+ even when it has not switched to a new default router. A mobile node
+ can have only one primary care-of address at a time (which is
+ registered with its home agent), but it MAY have an additional
+ care-of address for any or all of the prefixes on its current link.
+ Furthermore, since a wireless network interface may actually allow a
+ mobile node to be reachable on more than one link at a time (i.e.,
+ within wireless transmitter range of routers on more than one
+ separate link), a mobile node MAY have care-of addresses on more than
+ one link at a time. The use of more than one care-of address at a
+ time is described in Section 11.5.4.
+
+ As described in Section 4, in order to form a new care-of address, a
+ mobile node MAY use either stateless [19] or stateful (e.g., DHCPv6
+ [31]) Address Autoconfiguration. If a mobile node needs to use a
+ source address (other than the unspecified address) in packets sent
+ as a part of address autoconfiguration, it MUST use an IPv6 link-
+ local address rather than its own IPv6 home address.
+
+ RFC 4862 [19] specifies that in normal processing for Duplicate
+ Address Detection, the node SHOULD delay sending the initial Neighbor
+ Solicitation message by a random delay between 0 and
+ MAX_RTR_SOLICITATION_DELAY. Since delaying Duplicate Address
+ Detection (DAD) can result in significant delays in configuring a new
+ care-of address when the mobile node moves to a new link, the mobile
+ node preferably SHOULD NOT delay DAD when configuring a new care-of
+ address. The mobile node SHOULD delay according to the mechanisms
+ specified in RFC 4862 unless the implementation has a behavior that
+ desynchronizes the steps that happen before the DAD in the case that
+ multiple nodes experience handover at the same time. Such
+ desynchronizing behaviors might be due to random delays in the L2
+ protocols or device drivers, or due to the movement detection
+ mechanism that is used.
+
+
+
+Perkins, et al. Standards Track [Page 126]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+11.5.4. Using Multiple Care-of Addresses
+
+ As described in Section 11.5.3, a mobile node MAY use more than one
+ care-of address at a time. Particularly in the case of many wireless
+ networks, a mobile node effectively might be reachable through
+ multiple links at the same time (e.g., with overlapping wireless
+ cells), on which different on-link subnet prefixes may exist. The
+ mobile node MUST ensure that its primary care-of address always has a
+ prefix that is advertised by its current default router. After
+ selecting a new primary care-of address, the mobile node MUST send a
+ Binding Update containing that care-of address to its home agent.
+ The Binding Update MUST have the Home Registration (H) and
+ Acknowledge (A) bits set its home agent, as described on
+ Section 11.7.1.
+
+ To assist with smooth handovers, a mobile node SHOULD retain its
+ previous primary care-of address as a (non-primary) care-of address,
+ and SHOULD still accept packets at this address, even after
+ registering its new primary care-of address with its home agent.
+ This is reasonable, since the mobile node could only receive packets
+ at its previous primary care-of address if it were indeed still
+ connected to that link. If the previous primary care-of address was
+ allocated using stateful Address Autoconfiguration [31], the mobile
+ node may not wish to release the address immediately upon switching
+ to a new primary care-of address.
+
+ Whenever a mobile node determines that it is no longer reachable
+ through a given link, it SHOULD invalidate all care-of addresses
+ associated with address prefixes that it discovered from routers on
+ the unreachable link that are not in the current set of address
+ prefixes advertised by the (possibly new) current default router.
+
+11.5.5. Returning Home
+
+ A mobile node detects that it has returned to its home link through
+ the movement detection algorithm in use (Section 11.5.2), when the
+ mobile node detects that its home subnet prefix is again on-link. To
+ be able to send and receive packets using its home address from the
+ home link, the mobile node MUST send a Binding Update to its home
+ agent to instruct its home agent to no longer intercept or tunnel
+ packets for it. Until the mobile node sends such a de-registration
+ Binding Update, it MUST NOT attempt to send and receive packets using
+ 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
+ them to the previously registered care-of address.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 127]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 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
+ must be careful in how it uses Neighbor Solicitation [18] (if needed)
+ to learn the home agent's link-layer address, since the home agent
+ will be currently configured to intercept packets to the mobile
+ node's home address using Proxy Neighbor Discovery (Proxy ND). In
+ particular, the mobile node is unable to use its home address as the
+ Source Address in the Neighbor Solicitation until the home agent
+ stops defending the home address.
+
+ Neighbor Solicitation by the mobile node for the home agent's address
+ will normally not be necessary, since the mobile node has already
+ learned the home agent's link-layer address from a Source Link-Layer
+ Address option in a Router Advertisement. However, if there are
+ multiple home agents it may still be necessary to send a
+ solicitation. In this special case of the mobile node returning
+ home, the mobile node MUST multicast the packet, and in addition set
+ the Source Address of this Neighbor Solicitation to the unspecified
+ address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation
+ MUST be set to the mobile node's home address. The destination IP
+ address MUST be set to the Solicited-Node multicast address [16].
+ The home agent will send a multicast Neighbor Advertisement back to
+ the mobile node with the Solicited (S) flag set to zero. In any
+ case, the mobile node SHOULD record the information from the Source
+ Link-Layer Address option or from the advertisement, and set the
+ state of the Neighbor Cache entry for the home agent to REACHABLE.
+
+ The mobile node then sends its Binding Update to the home agent's
+ link-layer address, instructing its home agent to no longer serve as
+ a home agent for it. By processing this Binding Update, the home
+ agent will cease defending the mobile node's home address for
+ Duplicate Address Detection and will no longer respond to Neighbor
+ Solicitations for the mobile node's home address. The mobile node is
+ then the only node on the link receiving packets at the mobile node's
+ home address. In addition, when returning home prior to the
+ expiration of a current binding for its home address, and configuring
+ its home address on its network interface on its home link, the
+ mobile node MUST NOT perform Duplicate Address Detection on its own
+ home address, in order to avoid confusion or conflict with its home
+ agent's use of the same address. This rule also applies to the
+ derived link-local address of the mobile node, if the Link Local
+
+
+
+
+
+Perkins, et al. Standards Track [Page 128]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Address Compatibility (L) bit was set when the binding was created.
+ If the mobile node returns home after the bindings for all of its
+ care-of addresses have expired, then it SHOULD perform DAD.
+
+ After the mobile node sends the Binding Update, it MUST be prepared
+ to reply to Neighbor Solicitations for its home address. Such
+ replies MUST be sent using a unicast Neighbor Advertisement to the
+ sender's link-layer address. It is necessary to reply, since sending
+ the Binding Acknowledgement from the home agent may require
+ performing Neighbor Discovery, and the mobile node may not be able to
+ distinguish Neighbor Solicitations coming from the home agent from
+ other Neighbor Solicitations. Note that a race condition exists
+ where both the mobile node and the home agent respond to the same
+ solicitations sent by other nodes; this will be only temporary,
+ however, until the Binding Update is accepted.
+
+ After receiving the Binding Acknowledgement for its Binding Update to
+ its home agent, the mobile node MUST multicast onto the home link (to
+ the all-nodes multicast address) a Neighbor Advertisement [18], to
+ advertise the mobile node's own link-layer address for its own home
+ address. The Target Address in this Neighbor Advertisement MUST be
+ set to the mobile node's home address, and the Advertisement MUST
+ include a Target Link-layer Address option specifying the mobile
+ node's link-layer address. The mobile node MUST multicast such a
+ Neighbor Advertisement for each of its home addresses, as defined by
+ the current on-link prefixes, including its link-local address. The
+ Solicited (S) flag in these Advertisements MUST NOT be set, since
+ they were not solicited by any Neighbor Solicitation. The Override
+ (O) flag in these Advertisements MUST be set, indicating that the
+ Advertisements SHOULD override any existing Neighbor Cache entries at
+ any node receiving them.
+
+ Since multicasting on the local link (such as Ethernet) is typically
+ not guaranteed to be reliable, the mobile node MAY retransmit these
+ Neighbor Advertisements [18] up to MAX_NEIGHBOR_ADVERTISEMENT times
+ to increase their reliability. It is still possible that some nodes
+ on the home link will not receive any of these Neighbor
+ Advertisements, but these nodes will eventually be able to recover
+ through use of Neighbor Unreachability Detection [18].
+
+ Note that the tunnel via the home agent typically stops operating at
+ the same time that the home registration is deleted.
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 129]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+11.6. Return Routability Procedure
+
+ This section defines the rules that the mobile node must follow when
+ performing the return routability procedure. Section 11.7.2
+ describes the rules when the return routability procedure needs to be
+ initiated.
+
+11.6.1. Sending Test Init Messages
+
+ A mobile node that initiates a return routability procedure MUST send
+ (in parallel) a Home Test Init message and a Care-of Test Init
+ message. However, if the mobile node has recently received (see
+ Section 5.2.7) one or both home or care-of keygen tokens, and
+ associated nonce indices for the desired addresses, it MAY reuse
+ them. Therefore, the return routability procedure may in some cases
+ be completed with only one message pair. It may even be completed
+ without any messages at all, if the mobile node has a recent home
+ keygen token and has previously visited the same care-of address so
+ that it also has a recent care-of keygen token. If the mobile node
+ intends to send a Binding Update with the Lifetime set to zero and
+ the care-of address equal to its home address -- such as when
+ returning home -- sending a Home Test Init message is sufficient. In
+ this case, generation of the binding management key depends
+ exclusively on the home keygen token (Section 5.2.5).
+
+ A Home Test Init message MUST be created as described in
+ Section 6.1.3.
+
+ A Care-of Test Init message MUST be created as described in
+ Section 6.1.4. When sending a Home Test Init or Care-of Test Init
+ message, the mobile node MUST record in its Binding Update List the
+ following fields from the messages:
+
+ o The IP address of the node to which the message was sent.
+
+ o The home address of the mobile node. This value will appear in
+ the Source Address field of the Home Test Init message. When
+ sending the Care-of Test Init message, this address does not
+ appear in the message, but represents the home address for which
+ the binding is desired.
+
+ o The time at which each of these messages was sent.
+
+ o The cookies used in the messages.
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 130]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Note that a single Care-of Test Init message may be sufficient even
+ when there are multiple home addresses. In this case the mobile node
+ MAY record the same information in multiple Binding Update List
+ entries.
+
+11.6.2. Receiving Test Messages
+
+ Upon receiving a packet carrying a Home Test message, a mobile node
+ MUST validate the packet according to the following tests:
+
+ o The Source Address of the packet belongs to a correspondent node
+ for which the mobile node has a Binding Update List entry with a
+ state indicating that return routability procedure is in progress.
+ Note that there may be multiple such entries.
+
+ o The Binding Update List indicates that no home keygen token has
+ been received yet.
+
+ o The Destination Address of the packet has the home address of the
+ mobile node, and the packet has been received in a tunnel from the
+ home agent.
+
+ o The Home Init Cookie field in the message matches the value stored
+ in the Binding Update List.
+
+ Any Home Test message not satisfying all of these tests MUST be
+ silently ignored. Otherwise, the mobile node MUST record the Home
+ Nonce Index and home keygen token in the Binding Update List. If the
+ Binding Update List entry does not have a care-of keygen token, the
+ mobile node SHOULD continue waiting for the Care-of Test message.
+
+ Upon receiving a packet carrying a Care-of Test message, a mobile
+ node MUST validate the packet according to the following tests:
+
+ o The Source Address of the packet belongs to a correspondent node
+ for which the mobile node has a Binding Update List entry with a
+ state indicating that return routability procedure is in progress.
+ Note that there may be multiple such entries.
+
+ o The Binding Update List indicates that no care-of keygen token has
+ been received yet.
+
+ o The Destination Address of the packet is the current care-of
+ address of the mobile node.
+
+ o The Care-of Init Cookie field in the message matches the value
+ stored in the Binding Update List.
+
+
+
+
+Perkins, et al. Standards Track [Page 131]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Any Care-of Test message not satisfying all of these tests MUST be
+ silently ignored. Otherwise, the mobile node MUST record the Care-of
+ Nonce Index and care-of keygen token in the Binding Update List. If
+ the Binding Update List entry does not have a home keygen token, the
+ mobile node SHOULD continue waiting for the Home Test message.
+
+ If after receiving either the Home Test or the Care-of Test message
+ and performing the above actions, the Binding Update List entry has
+ both the home and the care-of keygen tokens, the return routability
+ procedure is complete. The mobile node SHOULD then proceed with
+ sending a Binding Update as described in Section 11.7.2.
+
+ Correspondent nodes from the time before this specification was
+ published may not support the Mobility Header protocol. These nodes
+ will respond to Home Test Init and Care-of Test Init messages with an
+ ICMP Parameter Problem code 1. The mobile node SHOULD take such
+ messages as an indication that the correspondent node cannot provide
+ route optimization, and revert back to the use of bidirectional
+ tunneling.
+
+11.6.3. Protecting Return Routability Packets
+
+ The mobile node MUST support the protection of Home Test and Home
+ Test Init messages as described in Section 10.4.6.
+
+ When IPsec is used to protect return routability signaling or payload
+ packets, the mobile node MUST set the source address it uses for the
+ outgoing tunnel packets to the current primary care-of address. The
+ mobile node starts to use a new primary care-of address immediately
+ after sending a Binding Update to the home agent to register this new
+ address.
+
+11.7. Processing Bindings
+
+11.7.1. Sending Binding Updates to the Home Agent
+
+ In order to change its primary care-of address as described in
+ Sections 11.5.1 and 11.5.3, a mobile node MUST register this care-of
+ address with its home agent in order to make this its primary care-of
+ address.
+
+ Also, if the mobile node wants the services of the home agent beyond
+ the current registration period, the mobile node should send a new
+ Binding Update to it well before the expiration of this period, even
+ if it is not changing its primary care-of address. However, if the
+ home agent returned a Binding Acknowledgement for the current
+ registration with the Status field set to 1 (accepted but prefix
+ discovery necessary), the mobile node should not try to register
+
+
+
+Perkins, et al. Standards Track [Page 132]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ again before it has learned the validity of its home prefixes through
+ mobile prefix discovery. This is typically necessary every time this
+ Status value is received, because information learned earlier may
+ have changed.
+
+ To register a care-of address or to extend the lifetime of an
+ existing registration, the mobile node sends a packet to its home
+ agent containing a Binding Update, with the packet constructed as
+ follows:
+
+ o The Home Registration (H) bit MUST be set in the Binding Update.
+
+ o The Acknowledge (A) bit MUST be set in the Binding Update.
+
+ o The packet MUST contain a Home Address destination option, giving
+ the mobile node's home address for the binding.
+
+ o The care-of address for the binding MUST be used as the Source
+ Address in the packet's IPv6 header, unless an Alternate Care-of
+ Address mobility option is included in the Binding Update. This
+ option MUST be included in all home registrations, as the ESP
+ protocol will not be able to protect care-of addresses in the IPv6
+ header. (Mobile IPv6 implementations that know they are using
+ IPsec AH to protect a particular message might avoid this option.
+ For brevity the usage of AH is not discussed in this document.)
+
+ o If the mobile node's link-local address has the same interface
+ identifier as the home address for which it is supplying a new
+ care-of address, then the mobile node SHOULD set the Link-Local
+ Address Compatibility (L) bit.
+
+ o If the home address was generated using RFC 4941 [21], then the
+ link local address is unlikely to have a compatible interface
+ identifier. In this case, the mobile node MUST clear the Link-
+ Local Address Compatibility (L) bit.
+
+ o If the IPsec security associations between the mobile node and the
+ home agent have been established dynamically, and the mobile node
+ has the capability to update its endpoint in the used key
+ management protocol to the new care-of address every time it
+ moves, the mobile node SHOULD set the Key Management Mobility
+ Capability (K) bit in the Binding Update. Otherwise, the mobile
+ node MUST clear the bit.
+
+ o The value specified in the Lifetime field MUST be non-zero and
+ SHOULD be less than or equal to the remaining valid lifetime of
+ the home address and the care-of address specified for the
+ binding.
+
+
+
+Perkins, et al. Standards Track [Page 133]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Mobile nodes that use dynamic home agent address discovery should
+ be careful with long lifetimes. If the mobile node loses the
+ knowledge of its binding with a specific home agent, registering a
+ new binding with another home agent may be impossible as the
+ previous home agent is still defending the existing binding.
+ Therefore, to ensure that mobile nodes using home agent address
+ discovery do not lose information about their binding, they SHOULD
+ de-register before losing this information, or use small
+ lifetimes.
+
+ The Acknowledge (A) bit in the Binding Update requests the home agent
+ to return a Binding Acknowledgement in response to this Binding
+ Update. As described in Section 6.1.8, the mobile node SHOULD
+ retransmit this Binding Update to its home agent until it receives a
+ matching Binding Acknowledgement. Once reaching a retransmission
+ timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
+ the process of delivering the Binding Update, but trying instead the
+ next home agent returned during dynamic home agent address discovery
+ (see Section 11.4.1). If there was only one home agent, the mobile
+ node instead SHOULD continue to periodically retransmit the Binding
+ Update at this rate until acknowledged (or until it begins attempting
+ to register a different primary care-of address). See Section 11.8
+ for information about retransmitting Binding Updates.
+
+ With the Binding Update, the mobile node requests the home agent to
+ serve as the home agent for the given home address. Until the
+ lifetime of this registration expires, the home agent considers
+ itself the home agent for this home address.
+
+ Each Binding Update MUST be authenticated as coming from the right
+ mobile node, as defined in Section 5.1. The mobile node MUST use its
+ home address -- either in the Home Address destination option or in
+ the Source Address field of the IPv6 header -- in Binding Updates
+ sent to the home agent. This is necessary in order to allow the
+ IPsec policies to be matched with the correct home address.
+
+ When sending a Binding Update to its home agent, the mobile node MUST
+ also create or update the corresponding Binding Update List entry, as
+ specified in Section 11.7.2.
+
+ The last Sequence Number value sent to the home agent in a Binding
+ Update is stored by the mobile node. If the sending mobile node has
+ no knowledge of the correct Sequence Number value, it may start at
+ any value. If the home agent rejects the value, it sends back a
+ Binding Acknowledgement with a status code 135, and the last accepted
+ sequence number in the Sequence Number field of the Binding
+ Acknowledgement. The mobile node MUST store this information and use
+ the next Sequence Number value for the next Binding Update it sends.
+
+
+
+Perkins, et al. Standards Track [Page 134]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ If the mobile node has additional home addresses, then the mobile
+ node SHOULD send an additional packet containing a Binding Update to
+ its home agent to register the care-of address for each such other
+ home address.
+
+ The home agent will only perform DAD for the mobile node's home
+ address when the mobile node has supplied a valid binding between its
+ home address and a care-of address. If some time elapses during
+ which the mobile node has no binding at the home agent, it might be
+ possible for another node to autoconfigure the mobile node's home
+ address. Therefore, the mobile node MUST treat the creation of a new
+ binding with the home agent using an existing home address, the same
+ as creation of a new home address. In the unlikely event that the
+ mobile node's home address is autoconfigured as the IPv6 address of
+ another network node on the home network, the home agent will reply
+ to the mobile node's subsequent Binding Update with a Binding
+ Acknowledgement containing a Status of 134 (Duplicate Address
+ Detection failed). In this case, the mobile node MUST NOT attempt to
+ re-use the same home address. It SHOULD continue to register the
+ care-of addresses for its other home addresses, if any. Mechanisms
+ outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [22] allow
+ mobile nodes to acquire new home addresses to replace the one for
+ which Status 134 was received.
+
+11.7.2. Correspondent Registration
+
+ When the mobile node is assured that its home address is valid, it
+ can initiate a correspondent registration with the purpose of
+ allowing the correspondent node to cache the mobile node's current
+ care-of address. This procedure consists of the return routability
+ procedure followed by a registration.
+
+ This section defines when the correspondent registration is to be
+ initiated and the rules to follow while it is being performed.
+
+ After the mobile node has sent a Binding Update to its home agent,
+ registering a new primary care-of address (as described in
+ Section 11.7.1), the mobile node SHOULD initiate a correspondent
+ registration for each node that already appears in the mobile node's
+ Binding Update List. The initiated procedures can be used to either
+ update or delete binding information in the correspondent node.
+
+ For nodes that do not appear in the mobile node's Binding Update
+ List, the mobile node MAY initiate a correspondent registration at
+ any time after sending the Binding Update to its home agent.
+ Considerations regarding when (and if) to initiate the procedure
+ depend on the specific movement and traffic patterns of the mobile
+ node and are outside the scope of this document.
+
+
+
+Perkins, et al. Standards Track [Page 135]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ In addition, the mobile node MAY initiate the correspondent
+ registration in response to receiving a packet that meets all of the
+ following tests:
+
+ o The packet was tunneled using IPv6 encapsulation.
+
+ o The Destination Address in the tunnel (outer) IPv6 header is equal
+ to any of the mobile node's care-of addresses.
+
+ o The Destination Address in the original (inner) IPv6 header is
+ equal to one of the mobile node's home addresses.
+
+ o The Source Address in the tunnel (outer) IPv6 header differs from
+ the Source Address in the original (inner) IPv6 header.
+
+ o The packet does not contain a Home Test, Home Test Init, Care-of
+ Test, or Care-of Test Init message.
+
+ If a mobile node has multiple home addresses, it becomes important to
+ select the right home address to use in the correspondent
+ registration. The used home address MUST be the Destination Address
+ of the original (inner) packet.
+
+ The peer address used in the procedure MUST be determined as follows:
+
+ o If a Home Address destination option is present in the original
+ (inner) packet, the address from this option is used.
+
+ o Otherwise, the Source Address in the original (inner) IPv6 header
+ of the packet is used.
+
+ Note that the validity of the original packet is checked before
+ attempting to initiate a correspondent registration. For instance,
+ if a Home Address destination option appeared in the original packet,
+ then rules in Section 9.3.1 are followed.
+
+ A mobile node MAY also choose to keep its topological location
+ private from certain correspondent nodes, and thus need not initiate
+ the correspondent registration.
+
+ Upon successfully completing the return routability procedure, and
+ after receiving a successful Binding Acknowledgement from the home
+ agent, a Binding Update MAY be sent to the correspondent node.
+
+ In any Binding Update sent by a mobile node, the care-of address
+ (either the Source Address in the packet's IPv6 header or the Care-of
+ Address in the Alternate Care-of Address mobility option of the
+ Binding Update) MUST be set to one of the care-of addresses currently
+
+
+
+Perkins, et al. Standards Track [Page 136]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ in use by the mobile node or to the mobile node's home address. A
+ mobile node MAY set the care-of address differently for sending
+ Binding Updates to different correspondent nodes.
+
+ A mobile node MAY also send a Binding Update to such a correspondent
+ node, instructing it to delete any existing binding for the mobile
+ node from its Binding Cache, as described in Section 6.1.7. Even in
+ this case a successful completion of the return routability procedure
+ is required first.
+
+ If the care-of address is not set to the mobile node's home address,
+ the Binding Update requests that the correspondent node create or
+ update an entry for the mobile node in the correspondent node's
+ Binding Cache. This is done in order to record a care-of address for
+ use in sending future packets to the mobile node. In this case, the
+ value specified in the Lifetime field sent in the Binding Update
+ SHOULD be less than or equal to the remaining lifetime of the home
+ registration and the care-of address specified for the binding. The
+ care-of address given in the Binding Update MAY differ from the
+ mobile node's primary care-of address.
+
+ If the Binding Update is sent to the correspondent node, requesting
+ the deletion of any existing Binding Cache entry it has for the
+ mobile node, the care-of address is set to the mobile node's home
+ address and the Lifetime field set to zero. In this case, generation
+ of the binding management key depends exclusively on the home keygen
+ token (Section 5.2.5). The care-of nonce index SHOULD be set to zero
+ in this case. In keeping with the Binding Update creation rules
+ below, the care-of address MUST be set to the home address if the
+ mobile node is at home, or to the current care-of address if it is
+ away from home.
+
+ If the mobile node wants to ensure that its new care-of address has
+ been entered into a correspondent node's Binding Cache, the mobile
+ node needs to request an acknowledgement by setting the Acknowledge
+ (A) bit in the Binding Update.
+
+ A Binding Update is created as follows:
+
+ o The current care-of address of the mobile node MUST be sent either
+ in the Source Address of the IPv6 header or in the Alternate
+ Care-of Address mobility option.
+
+ o The Destination Address of the IPv6 header MUST contain the
+ address of the correspondent node.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 137]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o The Mobility Header is constructed according to rules in Sections
+ 6.1.7 and 5.2.6, including the Binding Authorization Data
+ (calculated as defined in Section 6.2.7) and possibly the Nonce
+ Indices mobility options.
+
+ o The home address of the mobile node MUST be added to the packet in
+ a Home Address destination option, unless the Source Address is
+ the home address.
+
+ Each Binding Update MUST have a Sequence Number greater than the
+ Sequence Number value sent in the previous Binding Update to the same
+ destination address (if any). The sequence numbers are compared
+ modulo 2**16, as described in Section 9.5.1. There is no
+ requirement, however, that the Sequence Number value strictly
+ increase by 1 with each new Binding Update sent or received, as long
+ as the value stays within the window. The last Sequence Number value
+ sent to a destination in a Binding Update is stored by the mobile
+ node in its Binding Update List entry for that destination. If the
+ sending mobile node has no Binding Update List entry, the Sequence
+ Number SHOULD start at a random value. The mobile node MUST NOT use
+ the same Sequence Number in two different Binding Updates to the same
+ correspondent node, even if the Binding Updates provide different
+ care-of addresses.
+
+ The mobile node is responsible for the completion of the
+ correspondent registration, as well as any retransmissions that may
+ be needed (subject to the rate limitation defined in Section 11.8).
+
+11.7.3. Receiving Binding Acknowledgements
+
+ Upon receiving a packet carrying a Binding Acknowledgement, a mobile
+ node MUST validate the packet according to the following tests:
+
+ o The packet meets the authentication requirements for Binding
+ Acknowledgements defined in Sections 6.1.8 and 5. That is, if the
+ Binding Update was sent to the home agent, the underlying IPsec
+ protection is used. If the Binding Update was sent to the
+ correspondent node, the Binding Authorization Data mobility option
+ MUST be present and have a valid value.
+
+ o The Binding Authorization Data mobility option, if present, MUST
+ be the last option and MUST NOT have trailing padding.
+
+ o The Sequence Number field matches the Sequence Number sent by the
+ mobile node to this destination address in an outstanding Binding
+ Update, and the Status field is not 135.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 138]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Any Binding Acknowledgement not satisfying all of these tests MUST be
+ silently ignored.
+
+ When a mobile node receives a packet carrying a valid Binding
+ Acknowledgement, the mobile node MUST examine the Status field as
+ follows:
+
+ o If the Status field indicates that the Binding Update was accepted
+ (the Status field is less than 128), then the mobile node MUST
+ update the corresponding entry in its Binding Update List to
+ indicate that the Binding Update has been acknowledged; the mobile
+ node MUST then stop retransmitting the Binding Update. In
+ addition, if the value specified in the Lifetime field in the
+ Binding Acknowledgement is less than the Lifetime value sent in
+ the Binding Update being acknowledged, the mobile node MUST
+ subtract the difference between these two Lifetime values from the
+ remaining lifetime for the binding as maintained in the
+ corresponding Binding Update List entry (with a minimum value for
+ the Binding Update List entry lifetime of 0). That is, if the
+ Lifetime value sent in the Binding Update was L_update, the
+ Lifetime value received in the Binding Acknowledgement was L_ack,
+ and the current remaining lifetime of the Binding Update List
+ entry is L_remain, then the new value for the remaining lifetime
+ of the Binding Update List entry should be
+
+ max((L_remain - (L_update - L_ack)), 0)
+
+ where max(X, Y) is the maximum of X and Y. The effect of this
+ step is to correctly manage the mobile node's view of the
+ binding's remaining lifetime (as maintained in the corresponding
+ Binding Update List entry) so that it correctly counts down from
+ the Lifetime value given in the Binding Acknowledgement, but with
+ the timer countdown beginning at the time that the Binding Update
+ was sent.
+
+ Mobile nodes SHOULD send a new Binding Update well before the
+ expiration of this period in order to extend the lifetime. This
+ helps to avoid disruptions in communications that might otherwise
+ be caused by network delays or clock drift.
+
+ o If the Binding Acknowledgement correctly passes authentication and
+ the Status field value is 135 (Sequence Number out of window),
+ then the mobile node MUST update its binding sequence number
+ appropriately to match the sequence number given in the Binding
+ Acknowledgement. Otherwise, if the Status field value is 135 but
+ the Binding Acknowledgement does not pass authentication, the
+ message MUST be silently ignored.
+
+
+
+
+Perkins, et al. Standards Track [Page 139]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o If the Status field value is 1 (accepted but prefix discovery
+ necessary), the mobile node SHOULD send a Mobile Prefix
+ Solicitation message to update its information about the available
+ prefixes.
+
+ o If the Status field indicates that the Binding Update was rejected
+ (the Status field is greater than or equal to 128), then the
+ mobile node can take steps to correct the cause of the error and
+ retransmit the Binding Update (with a new Sequence Number value),
+ subject to the rate limiting restriction specified in
+ Section 11.8. If this is not done or it fails, then the mobile
+ node SHOULD record in its Binding Update List that future Binding
+ Updates SHOULD NOT be sent to this destination.
+
+ The treatment of a Binding Refresh Advice mobility option within the
+ Binding Acknowledgement depends on where the acknowledgement came
+ from. This option MUST be ignored if the acknowledgement came from a
+ correspondent node. If it came from the home agent, the mobile node
+ uses the Refresh Interval field in the option as a suggestion that it
+ SHOULD attempt to refresh its home registration at the indicated
+ shorter interval.
+
+ If the acknowledgement came from the home agent, the mobile node
+ examines the value of the Key Management Mobility Capability (K) bit.
+ If this bit is not set, the mobile node SHOULD discard key management
+ protocol connections, if any, to the home agent. The mobile node MAY
+ also initiate a new key management connection.
+
+ If this bit is set, the mobile node SHOULD move its own endpoint in
+ the key management protocol connections to the home agent, if any.
+ The mobile node's new endpoint should be the new care-of address.
+
+11.7.4. Receiving Binding Refresh Requests
+
+ When a mobile node receives a packet containing a Binding Refresh
+ Request message, if the mobile node has a Binding Update List entry
+ for the source of the Binding Refresh Request, and the mobile node
+ wants to retain its Binding Cache entry at the correspondent node,
+ then the mobile node should start a return routability procedure. If
+ the mobile node wants to have its Binding Cache entry removed, it can
+ either ignore the Binding Refresh Request and wait for the binding to
+ time out, or at any time, it can delete its binding from a
+ correspondent node with an explicit Binding Update with a zero
+ lifetime and the care-of address set to the home address. If the
+ mobile node does not know if it needs the Binding Cache entry, it can
+ make the decision in an implementation-dependent manner, such as
+ based on available resources.
+
+
+
+
+Perkins, et al. Standards Track [Page 140]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Note that the mobile node should be careful not to respond to Binding
+ Refresh Requests for addresses not in the Binding Update List to
+ avoid being subjected to a denial of service attack.
+
+ If the return routability procedure completes successfully, a Binding
+ Update message SHOULD be sent, as described in Section 11.7.2. The
+ Lifetime field in this Binding Update SHOULD be set to a new
+ lifetime, extending any current lifetime remaining from a previous
+ Binding Update sent to this node (as indicated in any existing
+ Binding Update List entry for this node), and the lifetime SHOULD
+ again be less than or equal to the remaining lifetime of the home
+ registration and the care-of address specified for the binding. When
+ sending this Binding Update, the mobile node MUST update its Binding
+ Update List in the same way as for any other Binding Update sent by
+ the mobile node.
+
+11.8. Retransmissions and Rate Limiting
+
+ The mobile node is responsible for retransmissions and rate limiting
+ in the return routability procedure, in registrations, and in
+ solicited prefix discovery.
+
+ When the mobile node sends a Mobile Prefix Solicitation, Home Test
+ Init, Care-of Test Init, or Binding Update for which it expects a
+ response, the mobile node has to determine a value for the initial
+ retransmission timer:
+
+ o If the mobile node is sending a Mobile Prefix Solicitation, it
+ SHOULD use an initial retransmission interval of
+ INITIAL_SOLICIT_TIMER (see Section 12).
+
+ o If the mobile node is sending a Binding Update and does not have
+ an existing binding at the home agent, it SHOULD use
+ InitialBindackTimeoutFirstReg (see Section 13) as a value for the
+ initial retransmission timer. This long retransmission interval
+ will allow the home agent to complete the Duplicate Address
+ Detection procedure mandated in this case, as detailed in
+ Section 11.7.1.
+
+ o Otherwise, the mobile node should use the specified value of
+ INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.
+
+ If the mobile node fails to receive a valid matching response within
+ the selected initial retransmission interval, the mobile node SHOULD
+ retransmit the message until a response is received.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 141]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The retransmissions by the mobile node MUST use an exponential back-
+ off process in which the timeout period is doubled upon each
+ retransmission, until either the node receives a response or the
+ timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile
+ node MAY continue to send these messages at this slower rate
+ indefinitely.
+
+ The mobile node SHOULD start a separate back-off process for
+ different message types, different home addresses, and different
+ care-of addresses. However, in addition an overall rate limitation
+ applies for messages sent to a particular correspondent node. This
+ ensures that the correspondent node has a sufficient amount of time
+ to respond when bindings for multiple home addresses are registered,
+ for instance. The mobile node MUST NOT send Mobility Header messages
+ of a particular type to a particular correspondent node more than
+ MAX_UPDATE_RATE times within a second.
+
+ Retransmitted Binding Updates MUST use a Sequence Number value
+ greater than that used for the previous transmission of this Binding
+ Update. Retransmitted Home Test Init and Care-of Test Init messages
+ MUST use new cookie values.
+
+12. Protocol Constants
+
+ DHAAD_RETRIES 4 retransmissions
+ INITIAL_BINDACK_TIMEOUT 1 second
+ INITIAL_DHAAD_TIMEOUT 3 seconds
+ INITIAL_SOLICIT_TIMER 3 seconds
+ MAX_BINDACK_TIMEOUT 32 seconds
+ MAX_DELETE_BCE_TIMEOUT 10 seconds
+ MAX_NONCE_LIFETIME 240 seconds
+ MAX_TOKEN_LIFETIME 210 seconds
+ MAX_RO_FAILURE 3 retries
+ MAX_RR_BINDING_LIFETIME 420 seconds
+ MAX_UPDATE_RATE 3 times
+ PREFIX_ADV_RETRIES 3 retransmissions
+ PREFIX_ADV_TIMEOUT 3 seconds
+
+13. Protocol Configuration Variables
+
+ MaxMobPfxAdvInterval Default: 86,400 seconds
+ MinDelayBetweenRAs Default: 3 seconds,
+ Min: 0.03 seconds
+ MinMobPfxAdvInterval Default: 600 seconds
+ InitialBindackTimeoutFirstReg Default: 1.5 seconds
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 142]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Home agents MUST allow the first three variables to be configured by
+ system management, and mobile nodes MUST allow the last variable to
+ be configured by system management.
+
+ The default value for InitialBindackTimeoutFirstReg has been
+ calculated as 1.5 times the default value of RetransTimer, as
+ specified in Neighbor Discovery (RFC 4861 [18]) times the default
+ value of DupAddrDetectTransmits, as specified in Stateless Address
+ Autoconfiguration (RFC 4862 [19]).
+
+ The value MinDelayBetweenRAs overrides the value of the protocol
+ constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
+ (RFC 4861 [18]). This variable SHOULD be set to MinRtrAdvInterval,
+ if MinRtrAdvInterval is less than 3 seconds.
+
+14. IANA Considerations
+
+ This document defines a new IPv6 protocol, the Mobility Header,
+ described in Section 6.1. This protocol has been assigned protocol
+ number 135.
+
+ This document also creates a new name space "Mobility Header Type",
+ for the MH Type field in the Mobility Header. The current message
+ types are described starting from Section 6.1.2, and are the
+ following:
+
+ 0 Binding Refresh Request
+
+ 1 Home Test Init
+
+ 2 Care-of Test Init
+
+ 3 Home Test
+
+ 4 Care-of Test
+
+ 5 Binding Update
+
+ 6 Binding Acknowledgement
+
+ 7 Binding Error
+
+ Future values of the MH Type can be allocated using Standards Action
+ or IESG Approval [23].
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 143]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Furthermore, each mobility message may contain mobility options as
+ described in Section 6.2. This document defines a new name space
+ "Mobility Option" to identify these options. The current mobility
+ options are defined starting from Section 6.2.2 and are the
+ following:
+
+ 0 Pad1
+
+ 1 PadN
+
+ 2 Binding Refresh Advice
+
+ 3 Alternate Care-of Address
+
+ 4 Nonce Indices
+
+ 5 Authorization Data
+
+ Future values of the Option Type can be allocated using Standards
+ Action or IESG Approval [23].
+
+ Finally, this document creates a third new name space "Status Code"
+ for the Status field in the Binding Acknowledgement message. The
+ current values are listed in Section 6.1.8 and are the following:
+
+ 0 Binding Update accepted
+
+ 1 Accepted but prefix discovery necessary
+
+ 128 Reason unspecified
+
+ 129 Administratively prohibited
+
+ 130 Insufficient resources
+
+ 131 Home registration not supported
+
+ 132 Not home subnet
+
+ 133 Not home agent for this mobile node
+
+ 134 Duplicate Address Detection failed
+
+ 135 Sequence number out of window
+
+ 136 Expired home nonce index
+
+ 137 Expired care-of nonce index
+
+
+
+Perkins, et al. Standards Track [Page 144]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ 138 Expired nonces
+
+ 139 Registration type change disallowed
+
+ 174 Invalid Care-of Address
+
+ Future values of the Status field can be allocated using Standards
+ Action or IESG Approval [23].
+
+ All fields labeled "Reserved" are only to be assigned through
+ Standards Action or IESG Approval.
+
+ This document also defines a new IPv6 destination option, the Home
+ Address option, described in Section 6.3. This option has been
+ assigned the Option Type value 0xC9.
+
+ This document also defines a new IPv6 type 2 routing header,
+ described in Section 6.4. The value 2 has been allocated by IANA.
+
+ In addition, this document defines four ICMP message types, two used
+ as part of the dynamic home agent address discovery mechanism, and
+ two used in lieu of Router Solicitations and Advertisements when the
+ mobile node is away from the home link. These messages have been
+ assigned ICMPv6 type numbers from the informational message range:
+
+ o The Home Agent Address Discovery Request message, described in
+ Section 6.5;
+
+ o The Home Agent Address Discovery Reply message, described in
+ Section 6.6;
+
+ o The Mobile Prefix Solicitation, described in Section 6.7; and
+
+ o The Mobile Prefix Advertisement, described in Section 6.8.
+
+ This document also defines two new Neighbor Discovery [18] options,
+ which have been assigned Option Type values within the option
+ numbering space for Neighbor Discovery messages:
+
+ o The Advertisement Interval option, described in Section 7.3; and
+
+ o The Home Agent Information option, described in Section 7.4.
+
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 145]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+15. Security Considerations
+
+15.1. Threats
+
+ Any mobility solution must protect itself against misuses of the
+ mobility features and mechanisms. In Mobile IPv6, most of the
+ potential threats are concerned with false bindings, usually
+ resulting in denial-of-service attacks. Some of the threats also
+ pose potential for man-in-the-middle, hijacking, confidentiality, and
+ impersonation attacks. The main threats this protocol protects
+ against are the following:
+
+ o Threats involving Binding Updates sent to home agents and
+ correspondent nodes. For instance, an attacker might claim that a
+ certain mobile node is currently at a different location than it
+ really is. If a home agent accepts such spoofed information sent
+ to it, the mobile node might not get traffic destined to it.
+ Similarly, a malicious (mobile) node might use the home address of
+ a victim node in a forged Binding Update sent to a correspondent
+ node.
+
+ These pose threats against confidentiality, integrity, and
+ availability. That is, an attacker might learn the contents of
+ packets destined to another node by redirecting the traffic to
+ itself. Furthermore, an attacker might use the redirected packets
+ in an attempt to set itself as a man in the middle between a
+ mobile and a correspondent node. This would allow the attacker to
+ impersonate the mobile node, leading to integrity and availability
+ problems.
+
+ A malicious (mobile) node might also send Binding Updates in which
+ the care-of address is set to the address of a victim node. If
+ such Binding Updates were accepted, the malicious node could lure
+ the correspondent node into sending potentially large amounts of
+ data to the victim; the correspondent node's replies to messages
+ sent by the malicious mobile node will be sent to the victim host
+ or network. This could be used to cause a distributed denial-of-
+ service attack. For example, the correspondent node might be a
+ site that will send a high-bandwidth stream of video to anyone who
+ asks for it. Note that the use of flow-control protocols such as
+ TCP does not necessarily defend against this type of attack,
+ because the attacker can fake the acknowledgements. Even keeping
+ TCP initial sequence numbers secret does not help, because the
+ attacker can receive the first few segments (including the ISN) at
+ its own address, and only then redirect the stream to the victim's
+ address. These types of attacks may also be directed to networks
+ instead of nodes. Further variations of this threat are described
+ elsewhere [28] [35].
+
+
+
+Perkins, et al. Standards Track [Page 146]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ An attacker might also attempt to disrupt a mobile node's
+ communications by replaying a Binding Update that the node had
+ sent earlier. If the old Binding Update was accepted, packets
+ destined for the mobile node would be sent to its old location as
+ 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 [7].
+
+ In conclusion, there are denial-of-service, man-in-the-middle,
+ confidentiality, and impersonation threats against the parties
+ 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.
+
+ o Threats associated with payload packets: Payload packets exchanged
+ with mobile nodes are exposed to similar threats as that of
+ regular IPv6 traffic. However, Mobile IPv6 introduces the Home
+ Address destination option and a new routing header type (type 2),
+ and uses tunneling headers in the payload packets. The protocol
+ must protect against potential new threats involving the use of
+ these mechanisms.
+
+ Third parties become exposed to a reflection threat via the Home
+ Address destination option, unless appropriate security
+ precautions are followed. The Home Address destination option
+ could be used to direct response traffic toward a node whose IP
+ address appears in the option. In this case, ingress filtering
+ would not catch the forged "return address" [38] [43].
+
+ A similar threat exists with the tunnels between the mobile node
+ and the home agent. An attacker might forge tunnel packets
+ 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
+ that an attacker who is able to forge tunnel packets would
+
+
+
+Perkins, et al. Standards Track [Page 147]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ typically also be able to forge packets that appear to come
+ directly from the mobile node. This is not a new threat as such.
+ However, it may make it easier for attackers to escape detection
+ by avoiding ingress filtering and packet tracing mechanisms.
+ Furthermore, spoofed tunnel packets might be used to gain access
+ to the home network.
+
+ Finally, a routing header could also be used in reflection
+ attacks, and in attacks designed to bypass firewalls. The
+ generality of the regular routing header would allow circumvention
+ of IP-address based rules in firewalls. It would also allow
+ reflection of traffic to other nodes. These threats exist with
+ routing headers in general, even if the usage that Mobile IPv6
+ requires is safe.
+
+ o Threats associated with dynamic home agent and mobile prefix
+ discovery.
+
+ o Threats against the Mobile IPv6 security mechanisms themselves: An
+ attacker might, for instance, lure the participants into executing
+ expensive cryptographic operations or allocating memory for the
+ purpose of keeping state. The victim node would have no resources
+ left to handle other tasks.
+
+ As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to
+ be deployed in most nodes of the IPv6 Internet. The above threats
+ should therefore be considered as being applicable to the whole
+ Internet.
+
+ It should also be noted that some additional threats result from
+ movements as such, even without the involvement of mobility
+ protocols. Mobile nodes must be capable to defend themselves in the
+ networks that they visit, as typical perimeter defenses applied in
+ the home network no longer protect them.
+
+15.2. Features
+
+ This specification provides a series of features designed to mitigate
+ the risk introduced by the threats listed above. The main security
+ features are the following:
+
+ o Reverse tunneling as a mandatory feature.
+
+ o Protection of Binding Updates sent to home agents.
+
+ o Protection of Binding Updates sent to correspondent nodes.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 148]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Protection against reflection attacks that use the Home Address
+ destination option.
+
+ o Protection of tunnels between the mobile node and the home agent.
+
+ o Closing routing header vulnerabilities.
+
+ o Mitigating denial-of-service threats to the Mobile IPv6 security
+ mechanisms themselves.
+
+ The support for encrypted reverse tunneling (see Section 11.3.1)
+ allows mobile nodes to defeat certain kinds of traffic analysis.
+
+ Protecting those Binding Updates that are sent to home agents and
+ those that are sent to arbitrary correspondent nodes requires very
+ different security solutions due to the different situations. Mobile
+ nodes and home agents are naturally expected to be subject to the
+ network administration of the home domain.
+
+ Thus, they can and are supposed to have a security association that
+ can be used to reliably authenticate the exchanged messages. See
+ Section 5.1 for the description of the protocol mechanisms, and
+ Section 15.3 below for a discussion of the resulting level of
+ security.
+
+ It is expected that Mobile IPv6 route optimization will be used on a
+ global basis between nodes belonging to different administrative
+ domains. It would be a very demanding task to build an
+ authentication infrastructure on this scale. Furthermore, a
+ traditional authentication infrastructure cannot be easily used to
+ authenticate IP addresses because IP addresses can change often. It
+ is not sufficient to just authenticate the mobile nodes;
+ authorization to claim the right to use an address is needed as well.
+ Thus, an "infrastructureless" approach is necessary. The chosen
+ infrastructureless method is described in Section 5.2, and
+ Section 15.4 discusses the resulting security level and the design
+ rationale of this approach.
+
+ Specific rules guide the use of the Home Address destination option,
+ the routing header, and the tunneling headers in the payload packets.
+ These rules are necessary to remove the vulnerabilities associated
+ with their unrestricted use. The effect of the rules is discussed in
+ Sections 15.7, 15.8, and 15.9.
+
+ Denial-of-service threats against Mobile IPv6 security mechanisms
+ themselves concern mainly the Binding Update procedures with
+ correspondent nodes. The protocol has been designed to limit the
+ effects of such attacks, as will be described in Section 15.4.5.
+
+
+
+Perkins, et al. Standards Track [Page 149]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+15.3. Binding Updates to Home Agent
+
+ Signaling between the mobile node and the home agent requires message
+ integrity. This is necessary to assure the home agent that a Binding
+ Update is from a legitimate mobile node. In addition, correct
+ ordering and anti-replay protection are optionally needed.
+
+ IPsec ESP protects the integrity of the Binding Updates and Binding
+ Acknowledgements by securing mobility messages between the mobile
+ node and the home agent.
+
+ IPsec can provide anti-replay protection only if dynamic keying is
+ used (which may not always be the case). IPsec does not guarantee
+ correct ordering of packets, only that they have not been replayed.
+ Because of this, sequence numbers within the Mobile IPv6 messages are
+ used to ensure correct ordering (see Section 5.1). However, if the
+ 16-bit Mobile IPv6 sequence number space is cycled through, or the
+ home agent reboots and loses its state regarding the sequence
+ numbers, replay and reordering attacks become possible. The use of
+ dynamic keying, IPsec anti-replay protection, and the Mobile IPv6
+ sequence numbers can together prevent such attacks. It is also
+ recommended that use of non-volatile storage be considered for home
+ agents, to avoid losing their state.
+
+ A sliding window scheme is used for the sequence numbers. The
+ protection against replays and reordering attacks without a key
+ management mechanism works when the attacker remembers up to a
+ maximum of 2**15 Binding Updates.
+
+ The above mechanisms do not show that the care-of address given in
+ the Binding Update is correct. This opens the possibility for
+ denial-of-service attacks against third parties. However, since the
+ mobile node and home agent have a security association, the home
+ agent can always identify an ill-behaving mobile node. This allows
+ the home agent operator to discontinue the mobile node's service, and
+ possibly take further actions based on the business relationship with
+ the mobile node's owner.
+
+ Note that the use of a single pair of manually keyed security
+ associations conflicts with the generation of a new home address [21]
+ for the mobile node, or with the adoption of a new home subnet
+ prefix. This is because IPsec security associations are bound to the
+ used addresses. While certificate-based automatic keying alleviates
+ this problem to an extent, it is still necessary to ensure that a
+ given mobile node cannot send Binding Updates for the address of
+ another mobile node. In general, this leads to the inclusion of home
+ addresses in certificates in the Subject AltName field. This again
+ limits the introduction of new addresses without either manual or
+
+
+
+Perkins, et al. Standards Track [Page 150]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ automatic procedures to establish new certificates. Therefore, this
+ specification restricts the generation of new home addresses (for any
+ reason) to those situations where a security association or
+ certificate for the new address already exists.
+
+ Support for IKEv2 has been specified as optional. The following
+ should be observed about the use of manual keying:
+
+ o As discussed above, with manually keyed IPsec, only a limited form
+ of protection exists against replay and reordering attacks. A
+ vulnerability exists if either the sequence number space is cycled
+ through or the home agent reboots and forgets its sequence numbers
+ (and uses volatile memory to store the sequence numbers).
+
+ Assuming the mobile node moves continuously every 10 minutes, it
+ takes roughly 455 days before the sequence number space has been
+ cycled through. Typical movement patterns rarely reach this high
+ frequency today.
+
+ o A mobile node and its home agent belong to the same domain. If
+ this were not the case, manual keying would not be possible [42],
+ but in Mobile IPv6 only these two parties need to know the
+ manually configured keys. Similarly, we note that Mobile IPv6
+ employs standard block ciphers in IPsec, and is not vulnerable to
+ problems associated with stream ciphers and manual keying.
+
+ 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
+ parameters with some off-line mechanism.
+
+ The use of IKEv2 with Mobile IPv6 is documented in more detail in
+ [20]. The following should be observed regarding the use of IKEv2:
+
+ o It is necessary to prevent a mobile node from claiming another
+ mobile node's home address. The home agent must verify that the
+ mobile node trying to negotiate the SA for a particular home
+ address is authorized for that home address. This implies that
+ even with the use of IKEv2, a policy entry needs to be configured
+ for each home address served by the home agent.
+
+ It may be possible to include home addresses in the Subject
+ AltName field of certificate to avoid this. However,
+ implementations are not guaranteed to support the use of a
+ particular IP address (care-of address) while another address
+ (home address) appears in the certificate. In any case, even this
+ approach would require user-specific tasks in the certificate
+ authority.
+
+
+
+
+Perkins, et al. Standards Track [Page 151]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o Due to the problems outlined in Section 11.3.2, the IKEv2 SA
+ between the mobile node and its home agent is established using
+ the mobile node's current care-of address. This implies that when
+ the mobile node moves to a new location, it may have to
+ re-establish an IKEv2 security association. A Key Management
+ Mobility Capability (K) flag is provided for implementations that
+ can update the IKEv2 endpoints without re-establishing an IKEv2
+ security association, but the support for this behavior is
+ optional.
+
+ o Nevertheless, even if per-mobile node configuration is required
+ with IKEv2, an important benefit of IKEv2 is that it automates the
+ negotiation of cryptographic parameters, including the Security
+ Parameter Indices (SPIs), cryptographic algorithms, and so on.
+ Thus, less configuration information is needed.
+
+ o The frequency of movements in some link layers or deployment
+ scenarios may be high enough to make replay and reordering attacks
+ possible, if only manual keying is used. IKEv2 SHOULD be used in
+ such cases. Potentially vulnerable scenarios involve continuous
+ movement through small cells, or uncontrolled alternation between
+ available network attachment points.
+
+ o Similarly, in some deployment scenarios the number of mobile nodes
+ may be very large. In these cases, it can be necessary to use
+ automatic mechanisms to reduce the management effort in the
+ administration of cryptographic parameters, even if some per-
+ mobile node configuration is always needed. IKEv2 SHOULD also be
+ used in such cases.
+
+15.4. Binding Updates to Correspondent Nodes
+
+ The motivation for designing the return routability procedure was to
+ have sufficient support for Mobile IPv6, without creating significant
+ new security problems. The goal for this procedure was not to
+ protect against attacks that were already possible before the
+ introduction of Mobile IPv6.
+
+ The next sections will describe the security properties of the used
+ method, both from the point of view of possible on-path attackers who
+ can see those cryptographic values that have been sent in the clear
+ (Sections 15.4.2 and 15.4.3) and from the point of view of other
+ attackers (Section 15.4.6).
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 152]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+15.4.1. Overview
+
+ The chosen infrastructureless method verifies that the mobile node is
+ "live" (that is, it responds to probes) at its home and care-of
+ addresses. Section 5.2 describes the return routability procedure in
+ detail. The procedure uses the following principles:
+
+ o A message exchange verifies that the mobile node is reachable at
+ its addresses, i.e., is at least able to transmit and receive
+ traffic at both the home and care-of addresses.
+
+ o The eventual Binding Update is cryptographically bound to the
+ tokens supplied in the exchanged messages.
+
+ o Symmetric exchanges are employed to avoid the use of this protocol
+ in reflection attacks. In a symmetric exchange, the responses are
+ always sent to the same address from which the request was sent.
+
+ o The correspondent node operates in a stateless manner until it
+ receives a fully authorized Binding Update.
+
+ o Some additional protection is provided by encrypting the tunnels
+ between the mobile node and home agent with IPsec ESP. As the
+ tunnel also transports the nonce exchanges, the ability of
+ attackers to see these nonces is limited. For instance, this
+ prevents attacks from being launched from the mobile node's
+ current foreign link, even when no link-layer confidentiality is
+ available.
+
+ The resulting level of security is in theory the same even without
+ this additional protection: the return routability tokens are
+ still exposed only to one path within the whole Internet.
+ However, the mobile nodes are often found on an insecure link,
+ such as a public access Wireless LAN. Thus, in many cases, this
+ addition makes a practical difference.
+
+ For further information about the design rationale of the return
+ routability procedure, see [28] [35] [34] [43]. The mechanisms used
+ have been adopted from these documents.
+
+15.4.2. Achieved Security Properties
+
+ The return routability procedure protects Binding Updates against all
+ attackers who are unable to monitor the path between the home agent
+ and the correspondent node. The procedure does not defend against
+ 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
+
+
+
+
+Perkins, et al. Standards Track [Page 153]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ it is at its home location. The possibility of such attacks is not
+ an impediment to the deployment of Mobile IPv6 because these attacks
+ are possible regardless of whether or not Mobile IPv6 is in use.
+
+ This procedure also protects against denial-of-service attacks in
+ which the attacker pretends to be mobile, but uses the victim's
+ address as the care-of address. This would cause the correspondent
+ node to send the victim some unexpected traffic. This procedure
+ defends against these attacks by requiring at least the passive
+ presence of the attacker at the care-of address or on the path from
+ the correspondent to the care-of address. Normally, this will be the
+ mobile node.
+
+15.4.3. Comparison to Regular IPv6 Communications
+
+ This section discusses the protection offered by the return
+ routability method by comparing it to the security of regular IPv6
+ communications. We will divide vulnerabilities into three classes:
+ (1) those related to attackers on the local network of the mobile
+ node, home agent, or the correspondent node, (2) those related to
+ attackers on the path between the home network and the correspondent
+ node, and (3) off-path attackers, i.e., the rest of the Internet.
+
+ We will now discuss the vulnerabilities of regular IPv6
+ communications. The on-link vulnerabilities of IPv6 communications
+ include denial-of-service, masquerading, man-in-the-middle,
+ eavesdropping, and other attacks. These attacks can be launched
+ through spoofing Router Discovery, Neighbor Discovery, and other IPv6
+ mechanisms. Some of these attacks can be prevented with the use of
+ cryptographic protection in the packets.
+
+ A similar situation exists with on-path attackers. That is, without
+ cryptographic protection, the traffic is completely vulnerable.
+
+ Assuming that attackers have not penetrated the security of the
+ Internet routing protocols, attacks are much harder to launch from
+ off-path locations. Attacks that can be launched from these
+ locations are mainly denial-of-service attacks, such as flooding
+ and/or reflection attacks. It is not possible for an off-path
+ attacker to become a man in the middle.
+
+ Next, we will consider the vulnerabilities that exist when IPv6 is
+ used together with Mobile IPv6 and the return routability procedure.
+ On the local link, the vulnerabilities are the same as those in IPv6,
+ but masquerade and man-in-the-middle attacks can now also be launched
+ against future communications, and not just against current
+ communications. If a Binding Update was sent while the attacker was
+ present on the link, its effects remain for the lifetime of the
+
+
+
+Perkins, et al. Standards Track [Page 154]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ binding. This happens even if the attacker moves away from the link.
+ In contrast, an attacker who uses only plain IPv6 generally has to
+ stay on the link in order to continue the attack. Note that in order
+ to launch these new attacks, the IP address of the victim must be
+ known. This makes this attack feasible, mainly in the context of
+ well-known interface IDs, such as those already appearing in the
+ traffic on the link or registered in the DNS.
+
+ On-path attackers can exploit similar vulnerabilities as in regular
+ IPv6. There are some minor differences, however. Masquerade, man-
+ in-the-middle, and denial-of-service attacks can be launched with
+ just the interception of a few packets, whereas in regular IPv6 it is
+ necessary to intercept every packet. The effect of the attacks is
+ the same regardless of the method, however. In any case, the most
+ difficult task an attacker faces in these attacks is getting on the
+ right path.
+
+ The vulnerabilities for off-path attackers are the same as in regular
+ IPv6. Those nodes that are not on the path between the home agent
+ and the correspondent node will not be able to receive the home
+ address probe messages.
+
+ In conclusion, we can state the following main results from this
+ comparison:
+
+ o Return routability prevents any off-path attacks beyond those that
+ are already possible in regular IPv6. This is the most important
+ result, preventing attackers on the Internet from exploiting any
+ vulnerabilities.
+
+ o Vulnerabilities to attackers on the home agent link, the
+ correspondent node link, and the path between them are roughly the
+ same as in regular IPv6.
+
+ o However, one difference is that in basic IPv6 an on-path attacker
+ must be constantly present on the link or the path, whereas with
+ Mobile IPv6, an attacker can leave a binding behind after moving
+ away.
+
+ For this reason, this specification limits the creation of
+ bindings to at most MAX_TOKEN_LIFETIME seconds after the last
+ routability check has been performed, and limits the duration of a
+ binding to at most MAX_RR_BINDING_LIFETIME seconds. With these
+ limitations, attackers cannot take any practical advantages of
+ this vulnerability.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 155]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ o There are some other minor differences, such as an effect to the
+ denial-of-service vulnerabilities. These can be considered to be
+ insignificant.
+
+ o The path between the home agent and a correspondent node is
+ typically easiest to attack on the links at either end, in
+ particular if these links are publicly accessible wireless LANs.
+ Attacks against the routers or switches on the path are typically
+ harder to accomplish. The security on layer 2 of the links plays
+ then a major role in the resulting overall network security.
+ Similarly, security of IPv6 Neighbor and Router Discovery on these
+ links has a large impact. If these were secured using some new
+ technology in the future, this could change the situation
+ regarding the easiest point of attack.
+
+ For a more in-depth discussion of these issues, see [43].
+
+15.4.4. Replay Attacks
+
+ The return routability procedure also protects the participants
+ against replayed Binding Updates. The attacker is unable replay the
+ same message due to the sequence number that is a part of the Binding
+ Update. It is also unable to modify the Binding Update since the MAC
+ verification would fail after such a modification.
+
+ Care must be taken when removing bindings at the correspondent node,
+ however. If a binding is removed while the nonce used in its
+ creation is still valid, an attacker could replay the old Binding
+ Update. Rules outlined in Section 5.2.8 ensure that this cannot
+ happen.
+
+15.4.5. Denial-of-Service Attacks
+
+ The return routability procedure has protection against resource
+ exhaustion denial-of-service attacks. The correspondent nodes do not
+ retain any state about individual mobile nodes until an authentic
+ Binding Update arrives. This is achieved through the construct of
+ keygen tokens from the nonces and node keys that are not specific to
+ individual mobile nodes. The keygen tokens can be reconstructed by
+ the correspondent node, based on the home and care-of address
+ information that arrives with the Binding Update. This means that
+ the correspondent nodes are safe against memory exhaustion attacks
+ except where on-path attackers are concerned. Due to the use of
+ symmetric cryptography, the correspondent nodes are relatively safe
+ against CPU resource exhaustion attacks as well.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 156]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Nevertheless, as [28] describes, there are situations in which it is
+ impossible for the mobile and correspondent nodes to determine if
+ they actually need a binding or whether they just have been fooled
+ into believing so by an attacker. Therefore, it is necessary to
+ consider situations where such attacks are being made.
+
+ Even if route optimization is a very important optimization, it is
+ still only an optimization. A mobile node can communicate with a
+ correspondent node even if the correspondent refuses to accept any
+ Binding Updates. However, performance will suffer because packets
+ from the correspondent node to the mobile node will be routed via the
+ mobile's home agent rather than a more direct route. A correspondent
+ node can protect itself against some of these resource exhaustion
+ attacks as follows. If the correspondent node is flooded with a
+ large number of Binding Updates that fail the cryptographic integrity
+ checks, it can stop processing Binding Updates. If a correspondent
+ node finds that it is spending more resources on checking bogus
+ Binding Updates than it is likely to save by accepting genuine
+ Binding Updates, then it may silently discard some or all Binding
+ Updates without performing any cryptographic operations.
+
+ Layers above IP can usually provide additional information to help
+ determine whether there is a need to establish a binding with a
+ specific peer. For example, TCP knows if the node has a queue of
+ data that it is trying to send to a peer. An implementation of this
+ specification is not required to make use of information from higher
+ protocol layers, but some implementations are likely to be able to
+ manage resources more effectively by making use of such information.
+
+ We also require that all implementations be capable of
+ administratively disabling route optimization.
+
+15.4.6. Key Lengths
+
+ Attackers can try to break the return routability procedure in many
+ ways. Section 15.4.2 discusses the situation where the attacker can
+ see the cryptographic values sent in the clear, and Section 15.4.3
+ discusses the impact this has on IPv6 communications. This section
+ discusses whether attackers can guess the correct values without
+ seeing them.
+
+ While the return routability procedure is in progress, 64-bit cookies
+ are used to protect spoofed responses. This is believed to be
+ sufficient, given that to blindly spoof a response a very large
+ number of messages would have to be sent before success would be
+ probable.
+
+
+
+
+
+Perkins, et al. Standards Track [Page 157]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ The tokens used in the return routability procedure provide together
+ 128 bits of information. This information is used internally as
+ input to a hash function to produce a 160-bit quantity suitable for
+ producing the keyed hash in the Binding Update using the HMAC_SHA1
+ algorithm. The final keyed hash length is 96 bits. The limiting
+ factors in this case are the input token lengths and the final keyed
+ hash length. The internal hash function application does not reduce
+ the entropy.
+
+ The 96-bit final keyed hash is of typical size and is believed to be
+ secure. The 128-bit input from the tokens is broken in two pieces,
+ the home keygen token and the care-of keygen token. An attacker can
+ try to guess the correct cookie value, but again this would require a
+ large number of messages (an the average 2**63 messages for one or
+ 2**127 for two). Furthermore, given that the cookies are valid only
+ for a short period of time, the attack has to keep a high constant
+ message rate to achieve a lasting effect. This does not appear
+ practical.
+
+ When the mobile node is returning home, it is allowed to use just the
+ home keygen token of 64 bits. This is less than 128 bits, but
+ attacking it blindly would still require a large number of messages
+ to be sent. If the attacker is on the path and capable of seeing the
+ Binding Update, it could conceivably break the keyed hash with brute
+ force. However, in this case the attacker has to be on the path,
+ which appears to offer easier ways for denial of service than
+ preventing route optimization.
+
+15.5. Dynamic Home Agent Address Discovery
+
+ The dynamic home agent address discovery function could be used to
+ learn the addresses of home agents in the home network.
+
+ The ability to learn addresses of nodes may be useful to attackers
+ because brute-force scanning of the address space is not practical
+ with IPv6. Thus, they could benefit from any means that make mapping
+ the networks easier. For example, if a security threat targeted at
+ routers or even home agents is discovered, having a simple ICMP
+ mechanism to easily find out possible targets may prove to be an
+ additional (though minor) security risk.
+
+ This document does not define any authentication mechanism for
+ dynamic home agent address discovery messages. Therefore, the home
+ agent cannot verify the home address of the mobile node that
+ requested the list of home agents.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 158]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Apart from discovering the address(es) of home agents, attackers will
+ not be able to learn much from this information, and mobile nodes
+ cannot be tricked into using wrong home agents, as all other
+ communication with the home agents is secure.
+
+ In cases where additional security is needed, one may consider
+ instead the use of MIPv6 bootstrapping [22], (based on DNS SRV
+ Resource Records [10]) in conjunction with security mechanisms
+ suggested in these specifications. In that solution, security is
+ provided by the DNS Security (DNSSEC) [13] framework. The needed
+ pre-configured data on the mobile node for this mechanism is the
+ domain name of the mobile service provider, which is marginally
+ better than the home subnet prefix. For the security, a trust anchor
+ that dominates the domain is needed.
+
+15.6. Mobile Prefix Discovery
+
+ The mobile prefix discovery function may leak interesting information
+ about network topology and prefix lifetimes to eavesdroppers; for
+ this reason, requests for this information have to be authenticated.
+ Responses and unsolicited prefix information needs to be
+ authenticated to prevent the mobile nodes from being tricked into
+ believing false information about the prefixes and possibly
+ preventing communications with the existing addresses. Optionally,
+ encryption may be applied to prevent leakage of the prefix
+ information.
+
+15.7. Tunneling via the Home Agent
+
+ Tunnels between the mobile node and the home agent can be protected
+ by ensuring proper use of source addresses, and optional
+ cryptographic protection. These procedures are discussed in
+ Section 5.5.
+
+ Binding Updates to the home agents are secure. When receiving
+ tunneled traffic, the home agent verifies that the outer IP address
+ corresponds to the current location of the mobile node. This acts as
+ a weak form of protection against spoofing packets that appear to
+ come from the mobile node. This is particularly useful, if no end-
+ to-end security is being applied between the mobile and correspondent
+ nodes. The outer IP address check prevents attacks where the
+ attacker is controlled by ingress filtering. It also prevents
+ attacks when the attacker does not know the current care-of address
+ of the mobile node. Attackers who know the care-of address and are
+ not controlled by ingress filtering could still send traffic through
+ the home agent. This includes attackers on the same local link as
+ the mobile node is currently on. But such attackers could send
+ packets that appear to come from the mobile node without attacking
+
+
+
+Perkins, et al. Standards Track [Page 159]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ the tunnel; the attacker could simply send packets with the source
+ address set to the mobile node's home address. However, this attack
+ does not work if the final destination of the packet is in the home
+ network, and some form of perimeter defense is being applied for
+ packets sent to those destinations. In such cases it is recommended
+ that either end-to-end security or additional tunnel protection be
+ applied, as is usual in remote access situations.
+
+ Home agents and mobile nodes may use IPsec ESP to protect payload
+ packets tunneled between themselves. This is useful for protecting
+ communications against attackers on the path of the tunnel.
+
+ When a unique-local address (ULA, RFC 4193 [15]) is used as a home
+ address, reverse tunneling can be used to send local traffic from
+ another location. Administrators should be aware of this when
+ allowing such home addresses. In particular, the outer IP address
+ check described above is not sufficient against all attackers. The
+ use of encrypted tunnels is particularly useful for these kinds of
+ home addresses.
+
+15.8. Home Address Option
+
+ When the mobile node sends packets directly to the correspondent
+ node, the Source Address field of the packet's IPv6 header is the
+ care-of address. Therefore, ingress filtering [27] works in the
+ usual manner even for mobile nodes, as the Source Address is
+ topologically correct. The Home Address option is used to inform the
+ correspondent node of the mobile node's home address.
+
+ However, the care-of address in the Source Address field does not
+ survive in replies sent by the correspondent node unless it has a
+ binding for this mobile node. Also, not all attacker tracing
+ mechanisms work when packets are being reflected through
+ correspondent nodes using the Home Address option. For these
+ reasons, this specification restricts the use of the Home Address
+ option. It may only be used when a binding has already been
+ established with the participation of the node at the home address,
+ as described in Sections 5.5 and 6.3. This prevents reflection
+ attacks through the use of the Home Address option. It also ensures
+ that the correspondent nodes reply to the same address that the
+ mobile node sends traffic from.
+
+ No special authentication of the Home Address option is required
+ beyond the above, but note that if the IPv6 header of a packet is
+ covered by IPsec Authentication Header, then that authentication
+ covers the Home Address option as well. Thus, even when
+ authentication is used in the IPv6 header, the security of the Source
+ Address field in the IPv6 header is not compromised by the presence
+
+
+
+Perkins, et al. Standards Track [Page 160]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ of a Home Address option. Without authentication of the packet, any
+ field in the IPv6 header including the Source Address field or any
+ other part of the packet and the Home Address option can be forged or
+ modified in transit. In this case, the contents of the Home Address
+ option is no more suspect than any other part of the packet.
+
+15.9. Type 2 Routing Header
+
+ The definition of the type 2 routing header is described in
+ Section 6.4. This definition and the associated processing rules
+ have been chosen so that the header cannot be used for what is
+ traditionally viewed as source routing. In particular, the home
+ address in the routing header will always have to be assigned to the
+ home address of the receiving node; otherwise, the packet will be
+ dropped.
+
+ Generally, source routing has a number of security concerns. These
+ include the automatic reversal of unauthenticated source routes
+ (which is an issue for IPv4, but not for IPv6). Another concern is
+ the ability to use source routing to "jump" between nodes inside, as
+ well as outside, a firewall. These security concerns are not issues
+ in Mobile IPv6, due to the rules mentioned above.
+
+ 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
+ addresses are the same.
+
+ This implies that a device that implements the filtering of packets
+ should be able to distinguish between a type 2 routing header and
+ other routing headers, as required in Section 8.3. This is necessary
+ in order to allow Mobile IPv6 traffic while still having the option
+ 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 and 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 [39].
+
+
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 161]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+16. Contributors
+
+ Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik
+ Nordmark, and Michael Thomas shaped the return routability protocols
+ described in [35].
+
+ Significant contributions were made by members of the Mobile IPv6
+ Security Design Team, including (in alphabetical order) Gabriel
+ Montenegro, Pekka Nikander, and Erik Nordmark.
+
+17. Acknowledgements
+
+ We would like to thank the members of the Mobile IP, Mobility
+ Extensions for IPv6, and IPng Working Groups for their comments and
+ suggestions on this work. We would particularly like to thank (in
+ alphabetical order) Fred Baker, Josh Broch, Samita Chakrabarti,
+ Robert Chalmers, Noel Chiappa, Jean-Michel Combes, Greg Daley, Vijay
+ Devarapalli, Rich Draves, Francis Dupont, Ashutosh Dutta, Arnaud
+ Ebalard, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino, Brian
+ Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli,
+ Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Aime Le
+ Rouzic, Julien Laganier, Jiwoong Lee, Benjamin Lim, Vesa-Matti
+ Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten,
+ Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy,
+ Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru
+ Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts,
+ Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind
+ Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon,
+ Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov
+ Vatn, Ryuji Wakikawa, Kilian Weniger, Carl E. Williams, Vladislav
+ Yasevich, Alper Yegin, and Xinhua Zhao, for their detailed reviews of
+ earlier versions of this document. Their suggestions have helped to
+ improve both the design and presentation of the protocol.
+
+ We would also like to thank the participants of the Mobile IPv6
+ testing event (1999), implementers who participated in Mobile IPv6
+ interoperability testing at Connectathons (2000, 2001, 2002, and
+ 2003), and the participants at the ETSI interoperability testing
+ (2000, 2002). Finally, we would like to thank the TAHI project that
+ has provided test suites for Mobile IPv6.
+
+18. References
+
+18.1. Normative References
+
+ [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
+ for Message Authentication", RFC 2104, February 1997.
+
+
+
+
+Perkins, et al. Standards Track [Page 162]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Kent, S. and K. Seo, "Security Architecture for the Internet
+ Protocol", RFC 4301, December 2005.
+
+ [4] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
+
+ [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
+ December 2005.
+
+ [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
+ Specification", RFC 2473, December 1998.
+
+ [8] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
+ Addresses", RFC 2526, March 1999.
+
+ [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
+ Discovery (MLD) for IPv6", RFC 2710, October 1999.
+
+ [10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [11] National Institute of Standards and Technology, "Secure Hash
+ Standard", FIPS PUB 180-1, April 1995,
+ <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
+
+ [12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
+ Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
+ Agents", RFC 3776, June 2004.
+
+ [13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [15] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+ [16] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+
+
+
+Perkins, et al. Standards Track [Page 163]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ [17] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
+ Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
+ Specification", RFC 4443, March 2006.
+
+ [18] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ September 2007.
+
+ [19] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
+ Autoconfiguration", RFC 4862, September 2007.
+
+ [20] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
+ IKEv2 and the Revised IPsec Architecture", RFC 4877,
+ April 2007.
+
+ [21] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
+ for Stateless Address Autoconfiguration in IPv6", RFC 4941,
+ September 2007.
+
+ [22] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
+ Bootstrapping in Split Scenario", RFC 5026, October 2007.
+
+ [23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+ [24] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
+ Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
+
+18.2. Informative References
+
+ [25] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [26] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+ October 1996.
+
+ [27] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [28] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work
+ in Progress, March 2002.
+
+ [29] Krishnan, S. and G. Tsirtsis, "MIPv6 Home Link Detection", Work
+ in Progress, March 2008.
+
+ [30] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
+ line Database", RFC 3232, January 2002.
+
+
+
+Perkins, et al. Standards Track [Page 164]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ [31] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [32] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944,
+ November 2010.
+
+ [33] Draves, R., "Default Address Selection for Internet Protocol
+ version 6 (IPv6)", RFC 3484, February 2003.
+
+ [34] Nordmark, E., "Securing MIPv6 BUs using return routability
+ (BU3WAY)", Work in Progress, November 2001.
+
+ [35] Roe, M., "Authentication of Mobile IPv6 Binding Updates and
+ Acknowledgments", Work in Progress, March 2002.
+
+ [36] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
+ Integrated Scenario", Work in Progress, April 2008.
+
+ [37] Savola, P., "Use of /127 Prefix Length Between Routers
+ Considered Harmful", RFC 3627, September 2003.
+
+ [38] Savola, P., "Security of IPv6 Routing Header and Home Address
+ Options", Work in Progress, March 2002.
+
+ [39] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
+ Considerations for the SHA-0 and SHA-1 Message-Digest
+ Algorithms", RFC 6194, March 2011.
+
+ [40] Manner, J. and M. Kojo, "Mobility Related Terminology",
+ RFC 3753, June 2004.
+
+ [41] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
+ (MLDv2) for IPv6", RFC 3810, June 2004.
+
+ [42] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
+ Management", BCP 107, RFC 4107, June 2005.
+
+ [43] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
+ Nordmark, "Mobile IP Version 6 Route Optimization Security
+ Design Background", RFC 4225, December 2005.
+
+ [44] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket
+ API for Source Address Selection", RFC 5014, September 2007.
+
+ [45] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of
+ Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
+
+
+
+
+Perkins, et al. Standards Track [Page 165]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+Appendix A. Future Extensions
+
+A.1. Piggybacking
+
+ This document does not specify how to piggyback payload packets on
+ the binding-related messages. However, it is envisioned that this
+ can be specified in a separate document when issues such as the
+ interaction between piggybacking and IPsec are fully resolved (see
+ also Appendix A.3). The return routability messages can indicate
+ support for piggybacking with a new mobility option.
+
+A.2. Triangular Routing
+
+ Due to the concerns about opening reflection attacks with the Home
+ Address destination option, this specification requires that this
+ option be verified against the Binding Cache, i.e., there must be a
+ Binding Cache entry for the home address and care-of address.
+
+ Future extensions may be specified that allow the use of unverified
+ Home Address destination options in ways that do not introduce
+ security issues.
+
+A.3. New Authorization Methods
+
+ While the return routability procedure provides a good level of
+ security, there exist methods that have even higher levels of
+ security. Second, as discussed in Section 15.4, future enhancements
+ of IPv6 security may cause a need to also improve the security of the
+ return routability procedure. Using IPsec as the sole method for
+ authorizing Binding Updates to correspondent nodes is also possible.
+ The protection of the Mobility Header for this purpose is easy,
+ though one must ensure that the IPsec SA was created with appropriate
+ authorization to use the home address referenced in the Binding
+ Update. For instance, a certificate used by IKEv2 to create the
+ security association might contain the home address. A future
+ specification may specify how this is done.
+
+A.4. Neighbor Discovery Extensions
+
+ Future specifications may improve the efficiency of Neighbor
+ Discovery tasks, which could be helpful for fast movements. One
+ factor is currently being looked at: the delays caused by the
+ Duplicate Address Detection mechanism. Currently, Duplicate Address
+ Detection needs to be performed for every new care-of address as the
+ mobile node moves, and for the mobile node's link-local address on
+ every new link. In particular, the need and the trade-offs of
+ re-performing Duplicate Address Detection for the link-local address
+ every time the mobile node moves on to new links will need to be
+
+
+
+Perkins, et al. Standards Track [Page 166]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ examined. Improvements in this area are, however, generally
+ applicable and progress independently from the Mobile IPv6
+ specification.
+
+ Future functional improvements may also be relevant for Mobile IPv6
+ and other applications. For instance, mechanisms that would allow
+ recovery from a Duplicate Address Detection collision would be useful
+ for link-local, care-of, and home addresses.
+
+Appendix B. Changes since RFC 3775
+
+ The following issues were identified during the evolution of the
+ current document. Discussion about most of the issues can be found
+ on the [mext] working group page
+ http://trac.tools.ietf.org/wg/mext/trac/report/6
+
+ Issue #1 Last Accepted SQN [Ahmad Muhanna]
+
+ Solution: specify that the mobile node update its binding sequence
+ number to match the sequence number given in the Binding
+ Acknowledgement (if the Binding Acknowledgement correctly passes
+ authentication and the status is 135 (Sequence Number out of
+ window). See Section 11.7.3.
+
+ Issue #4 Remove references to site-local addresses [George
+ Tsirtsis].
+
+ Fixed.
+
+ Issue #5 Wrong protocol number (2 instead of 135) used in discussion
+ about checksum pseudo-header.
+
+ Fixed. See Section 6.1.1.
+
+ Issue #8 Application using the care-of address [Julien Laganier]
+
+ Cite IPv6 Socket API for Source Address Selection specification
+ [44]. See Section 11.3.4.
+
+ Issue #10 The usage of "HA lifetime" [Ryuji Wakikawa]
+
+ 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. See
+ Section 11.4.1.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 167]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Issue #11 De-registration when returning home [Vijay Devarapalli]
+
+ To be able to send and receive packets using its home address from
+ the home link, the mobile node MUST send a Binding Update to its
+ home agent to instruct its home agent to no longer intercept or
+ tunnel packets for it. Until the mobile node sends such a
+ de-registration Binding Update, it MUST NOT attempt to send and
+ receive packets using its home address from the home link. See
+ Section 11.5.5.
+
+ Issue #12 BErr sent by HA too, not only by CN [Alexandru Petrescu]
+
+ Fixed. See Section 4.2.
+
+ Issue #13 Home Link Detection [Suresh Krishnan]
+
+ Proposal: Add Section 11.5.2 for Home Link Detection, drawing on
+ "MIPv6 Home Link Detection" [29].
+
+ Issue #14 References to bootstrapping [Vijay Devarapalli]
+
+ Cite "Mobile IPv6 Bootstrapping in Split Scenario" [22] and "MIP6-
+ bootstrapping for the Integrated Scenario" [36]. See Section 4.1.
+
+ Issue #17 Multi-homed mobile node can cause routing loop between
+ home agents [Benjamin Lim]
+
+ Added security advisory in Section 15.1, to highlight risk of
+ routing loop among HAs (e.g., in 3GPP):
+
+ A malicious mobile node associated to multiple home agents could
+ create a routing loop amongst them. This would happen when a
+ mobile node binds one home address located on a first home agent
+ to another home address on a second home agent.
+
+ Issue #18 Subject: Issues regarding Home Address Option and ICMP /
+ Binding Errors [Fabian Mauchle]
+
+ Proposal: Use the value in the Next Header field {50 (ESP), 51
+ (AH), 135 (Mobility Header)} to determine, if a Binding Cache
+ entry is required. See Section 9.3.1.
+
+ Proposal: If the Binding Error message was sent by the home agent,
+ the mobile node SHOULD send a Binding Update to the home agent
+ according to Section 11.7.1. See Section 11.3.6.
+
+
+
+
+
+
+Perkins, et al. Standards Track [Page 168]
+
+RFC 6275 Mobility Support in IPv6 July 2011
+
+
+ Issue #19 BU de-registration race condition [Kilian Weniger]
+
+ Problem arises if de-registration arrives at home agent before an
+ immediately preceding Binding Update.
+
+ Solution: Home agent defers BCE removal after sending the Binding
+ Acknowledgement. See Section 10.3.2.
+
+ Issue #6 Minor editorial corrections and updates.
+
+ Update IPsec and IKE references to the revised IPsec architecture
+ and IKEv2.
+
+ 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
+
+ Charles E. Perkins (editor)
+ Tellabs, Inc.
+ 4555 Great America Parkway, Suite 150
+ Santa Clara CA 95054
+ USA
+
+ EMail: charliep@computer.org
+
+
+ David B. Johnson
+ Rice University
+ Dept. of Computer Science, MS 132
+ 6100 Main Street
+ Houston TX 77005-1892
+ USA
+
+ EMail: dbj@cs.rice.edu
+
+
+ Jari Arkko
+ Ericsson
+ Jorvas 02420
+ Finland
+
+ EMail: jari.arkko@ericsson.com
+
+
+
+
+
+Perkins, et al. Standards Track [Page 169]
+