doc: Add RFC documents

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]
+