doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5454.txt b/doc/rfc/rfc5454.txt
new file mode 100644
index 0000000..6ff82bb
--- /dev/null
+++ b/doc/rfc/rfc5454.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                        G. Tsirtsis
+Request for Comments: 5454                                       V. Park
+Category: Standards Track                                       Qualcomm
+                                                              H. Soliman
+                                                    Elevate Technologies
+                                                              March 2009
+
+
+                         Dual-Stack Mobile IPv4
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This specification provides IPv6 extensions to the Mobile IPv4
+   protocol.  The extensions allow a dual-stack node to use IPv4 and
+   IPv6 home addresses as well as to move between IPv4 and dual stack
+   network infrastructures.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 1]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Notation ......................................3
+      1.2. Goals ......................................................3
+      1.3. Non-Goals ..................................................4
+      1.4. Implicit and Explicit Modes ................................4
+   2. Extension Formats ...............................................4
+      2.1. IPv6 Prefix Request Extension ..............................4
+      2.2. IPv6 Prefix Reply Extension ................................5
+      2.3. IPv6 Tunneling Mode Extension ..............................7
+   3. Mobile IP Registrations .........................................8
+      3.1. Registration Request .......................................8
+      3.2. Registration Reply .........................................8
+      3.3. Home Agent Considerations ..................................9
+           3.3.1. IPv6 Reachability ..................................10
+           3.3.2. Processing Intercepted IPv6 Packets ................10
+           3.3.3. IPv6 Multicast Membership Control ..................12
+      3.4. Foreign Agent Considerations ..............................12
+      3.5. Mobile Node Considerations ................................12
+      3.6. Tunneling Impacts .........................................13
+      3.7. IPv6 Prefixes .............................................14
+           3.7.1. Dynamic IPv6 Prefix Delegation .....................14
+      3.8. Deregistration of IPv6 Prefix .............................15
+      3.9. Registration with a Private CoA ...........................15
+   4. Security Considerations ........................................15
+   5. IANA Considerations ............................................16
+   6. Acknowledgements ...............................................16
+   7. References .....................................................16
+      7.1. Normative References ......................................16
+      7.2. Informative References ....................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 2]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+1.  Introduction
+
+   Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to
+   maintain communications while moving in an IPv4 network.
+
+   Extensions defined in this document allow a node that has IPv4 and
+   IPv6 addresses [RFC2460] to maintain communications through any of
+   its addresses while moving in IPv4 or dual stack networks.
+
+   Essentially, this specification separates the Mobile IPv4 signaling
+   from the IP version of the traffic it tunnels.  Mobile IPv4 with the
+   present extensions remains a signaling protocol that runs over IPv4,
+   and yet can set up both IPv4 and IPv6 tunnels over IPv4.
+
+   The aim is two-fold:
+
+      On one hand, Mobile IPv4 with the present extensions becomes a
+      useful transition mechanism, allowing automated but controlled
+      tunneling of IPv6 traffic over IPv4 tunnels.  Dual-stack nodes in
+      dual-stack home networks can now roam to and from legacy IPv4
+      networks, while IPv4 mobile nodes and networks can migrate to IPv6
+      without changing mobility management, and without upgrading all
+      network nodes to IPv6 at once.
+
+      On the other hand, and more importantly, it allows dual-stack
+      mobile nodes and networks to utilize a single protocol for the
+      movement of both IPv4 and IPv6 stacks in the network topology.
+
+   Note that features like Mobile IPv6 [RFC3775] style route
+   optimization will not be possible with this solution as it still
+   relies on Mobile IPv4 signaling, which does not provide route
+   optimization.
+
+1.1.  Requirements Notation
+
+   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 [RFC2119].
+
+1.2.  Goals
+
+   a.  The solution supports the registration of IPv6 home prefix(es) in
+       addition to regular IPv4 home address (HoA) registration.
+
+   b.  The solution supports static and dynamic IPv6 prefix delegation.
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 3]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+1.3.  Non-Goals
+
+   a.  The solution does not provide support for IPv6 care-of address
+       (CoA) registration.
+
+1.4.  Implicit and Explicit Modes
+
+   As defined in Network Mobility (NEMO) [RFC3963], this specification
+   also supports two modes of operation; the implicit mode and the
+   explicit mode.
+
+   In the implicit mode, the mobile node does not include any IPv6
+   prefix request extensions in the registration request.  The home
+   agent can use any mechanism (not defined in this document) to
+   determine the IPv6 prefix(es) owned by the mobile node and to set up
+   forwarding for these prefixes.  In this mode of operation, all
+   traffic to and from the IPv6 prefixes MUST be encapsulated over the
+   IPv4 tunnel between the mobile node's IPv4 home address and the IPv4
+   address of the home agent, and as such, it is transparent to any
+   foreign agent in the path.  This IPv4 tunnel is established by
+   mechanisms that are out of the scope of this document on both the
+   mobile node and home agent when operating in the implicit mode.
+
+   In the explicit mode, IPv6 bindings are signaled explicitly.  The
+   mobile node includes one or more IPv6 prefix request extensions in
+   the registration request, while the home agent returns corresponding
+   IPv6 prefix reply extensions to accept/reject the IPv6 bindings.
+
+   Additionally, in the explicit mode, the mobile node (when co-located
+   mode of operation is used) can indicate whether IPv6 traffic should
+   be tunneled to the care-of address or the home address of the mobile
+   node.
+
+   The rest of this specification is primarily defining the explicit
+   mode.
+
+2.  Extension Formats
+
+   The following extensions are defined according to this specification.
+
+2.1.  IPv6 Prefix Request Extension
+
+   A new skippable extension to the Mobile IPv4 registration request
+   message in accordance to the short extension format of [RFC3344] is
+   defined here.
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 4]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   This extension contains a Mobile IPv6 network prefix and its prefix
+   length.
+
+       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      |   Subtype     | Prefix Length |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                   Mobile IPv6 Network Prefix                  +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 1:  IPv6 Prefix Request Extension
+
+   Type
+
+      152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension)
+
+   Length
+
+      18
+
+   Subtype
+
+      1 (IPv6 Prefix Request)
+
+   Prefix Length
+
+      A sixteen-byte field containing the Mobile IPv6 Network Prefix;
+      all insignificant (low-order) bits (beyond the Prefix Length) MUST
+      be set to 0 by the originator of the option and ignored by the
+      receiver.
+
+   Mobile IPv6 Network Prefix
+
+      A sixteen-byte field containing the Mobile IPv6 Network Prefix
+
+2.2.  IPv6 Prefix Reply Extension
+
+   A new skippable extension to the Mobile IPv4 registration reply
+   message in accordance to the short extension format of [RFC3344] is
+   defined here.
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 5]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   This extension defines a Mobile IPv6 Network Prefix and its prefix
+   length, as well as a code.
+
+       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      |   Subtype     |     Code      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Prefix Length |    Reserved   |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                   Mobile IPv6 Network Prefix                  +
+      |                                                               |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 2: IPv6 Prefix Reply Extension
+
+   Type
+
+      152 (DSMIPv4 Extension)
+
+   Length
+
+      20
+
+   Subtype
+
+      2 (IPv6 Prefix Reply)
+
+   Code
+
+      A value indicating the result of the registration request with
+      respect to the IPv6 home prefix registration.  See below for
+      currently defined Codes.
+
+   Prefix Length
+
+      Indicates the prefix length of the prefix included in the Mobile
+      IPv6 Network Prefix field.  A value of 255 indicates that a link-
+      local address is included in the Mobile IPv6 Network Prefix field.
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 6]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   Reserved
+
+      Set to 0 by the sender, ignored by the receiver
+
+   Mobile IPv6 Network Prefix
+
+      A sixteen-byte field containing the Mobile IPv6 Network Prefix;
+      all insignificant (low-order) bits (beyond the Prefix Length) MUST
+      be set to 0 by the originator of the option and ignored by the
+      receiver.
+
+   The following values are defined for use as a Code value in the above
+   extension:
+
+      0 registration accepted, IPv6 to be tunneled to HoA
+
+      1 registration accepted, IPv6 to be tunneled to CoA
+
+      8 registration rejected, reason unspecified
+
+      9 registration rejected, administratively prohibited
+
+   Note that a registration reply that does not include an IPv6 prefix
+   reply extension, when received in response to a registration request
+   carrying at least one instance of the IPv6 prefix request extension,
+   indicates that the home agent does not support IPv6 extensions and
+   thus has ignored such extensions in the registration request.
+
+2.3.  IPv6 Tunneling Mode Extension
+
+   A new skippable extension to the Mobile IPv4 registration request
+   message in accordance to the short extension format of [RFC3344] is
+   defined here.
+
+   By including this extension in a registration request, the sender
+   indicates that IPv6 traffic can be tunneled to the mobile node's CoA.
+
+   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      |    Subtype    |   Reserved    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 3: IPv6 Tunneling Mode Extension
+
+   Type
+
+      152 (DSMIPv4 Extension)
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 7]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   Length
+
+      2
+
+   Subtype
+
+      3 (IPv6 Tunneling Mode)
+
+   Reserved
+
+      Set to 0 by the sender, ignored by the receiver
+
+3.  Mobile IP Registrations
+
+3.1.  Registration Request
+
+   A mobile node MAY include in a registration request one or more IPv6
+   prefix request extensions defined in this specification.
+
+   A mobile node MAY also include exactly one IPv6 tunneling mode
+   extension when it uses the co-located care-of address mode of
+   [RFC3344].
+
+   When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
+   the mobile IP client, they MUST be placed after the registration
+   request header and before the mobile -- home authentication extension
+   so they MUST be included in the computation of any authentication
+   extension.
+
+3.2.  Registration Reply
+
+   The mechanism described in this specification depends on skippable
+   extensions.  For that reason, a registration reply that does not
+   include an IPv6 prefix reply extension, in response to a registration
+   request including an IPv6 prefix request extension, indicates that
+   the home agent does not support IPv6 extensions and has ignored the
+   request.
+
+   If an IPv6 prefix reply extension is included in a registration
+   reply, then the extension indicates the success or failure of the
+   IPv6 prefix registration.  The IPv6 prefix reply extension does not
+   affect, in any way, the code value in the registration reply header
+   but it is superseded by it.  In other words, if the code field in the
+   registration reply header is set to a reject code, then all IPv6
+   prefix request extensions are also rejected.  If the code field in
+   the registration reply header, however, is set to an accept code,
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 8]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   then an IPv6 prefix reply extension with a code field set to a reject
+   code only rejects the binding for the specific IPv6 prefix indicated
+   in the same extension.
+
+   Note that a rejecting IPv6 prefix reply extension has the same effect
+   as not including such an extension at all, in the sense that, in both
+   cases, the mobile node must act as if the corresponding IPv6 prefix
+   request extension included in the registration request was rejected.
+   Of course, the inclusion of the IPv6 prefix reply extension allows
+   the home agent to indicate why a given IPv6 prefix request extension
+   was rejected.  A detailed description of how the mobile node handles
+   different IPv6 prefix reply extension code values and the absence of
+   IPv6 prefix reply extensions is given in Section 3.5.
+
+3.3.  Home Agent Considerations
+
+   The dual-stack home agent defined in this specification is a Mobile
+   IPv4 home agent in that, it MUST operate as defined in MIPv4
+   [RFC3344].  In addition to that, the following mechanisms are defined
+   in this specification.
+
+   For each IPv6 prefix request extension included in a valid
+   registration request, a home agent that supports this specification
+   SHOULD include a corresponding IPv6 prefix reply extension in the
+   registration reply message.  The home agent MUST NOT include more
+   than one IPv6 prefix reply extension for the same prefix.  For each
+   accepted IPv6 prefix, the home agent MUST decide the tunneling mode
+   it is going to use and set the code field of the IPv6 prefix reply
+   extension to the appropriate value.  The IPv6 prefix field of each of
+   the IPv6 prefix reply extensions included in the registration reply
+   MUST match the IPv6 prefix field of an IPv6 prefix request extension
+   included in the corresponding registration request message.
+
+   When the home agent sends a successful registration reply to the
+   mobile node, with the code field of a corresponding IPv6 prefix reply
+   extension set to one of the "registration accepted" values, the home
+   agent indicates that the IPv6 prefix is registered for the lifetime
+   granted for the binding.  It also indicates the tunneling mode used
+   i.e., tunneling to home address or care-of address, based on the
+   value of the code field used in the IPv6 prefix reply extension.
+
+   Note that since only IPv6 prefixes (and not addresses) are supported
+   by this specification, there is no need for Duplicate Address
+   Detection.  The home agent, however, MUST check that registered
+   prefixes are not overlapping so that all addresses under each
+   registered prefix belong to a single mobile node at any one time.
+   These prefixes MUST NOT appear as on-link to any other node (e.g.,
+   via Router Advertisements).
+
+
+
+Tsirtsis, et al.            Standards Track                     [Page 9]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+3.3.1.  IPv6 Reachability
+
+   For each registered IPv6 prefix, the home agent MUST advertise its
+   reachability as defined in NEMO Section 6.3 of [RFC3963].
+
+3.3.2.  Processing Intercepted IPv6 Packets
+
+   A dual-stack home agent that supports the IPv6 extensions defined in
+   this specification MUST keep track of the following IPv6 related
+   state for the mobile nodes it supports, in addition to the state
+   defined in [RFC3344].
+
+   - Registered IPv6 prefix(es) and prefix length(s).
+
+   - Tunneling mode for IPv6 traffic:
+
+      - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
+
+      - Tunnel to CoA and accept IPv6 tunneled from CoA.
+
+   When IPv6 traffic is encapsulated over the tunnel between the home
+   agent (HA) and the mobile node's care-of address, the tunneling
+   mechanism used should be the same as the mechanism negotiated by the
+   Mobile IP header as defined in MIPv4 [RFC3344].  In that case, when
+   IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4
+   according to [RFC4213].  Generic Routing Encapsulation (GRE) also
+   allows tunneling of IPv6 packets by setting the Protocol Type
+   [RFC2784] field, to the appropriate payload type defined for IPv6 by
+   IANA.  Minimal Encapsulation [RFC2004] cannot be used, since the
+   second (inner) IP header is IPv6, which is not supported by
+   [RFC2004].
+
+   When IPv6 traffic is encapsulated over the tunnel between the HA and
+   the mobile node's home address, IPv6 is always tunneled over IPv4
+   according to [RFC4213].  The resulting IPv4 packet is then delivered
+   just like any other IPv4 packet addressed to the IPv4 HoA (using the
+   tunneling for normal IPv4 traffic, possibly going via the foreign
+   agent (FA)).
+
+   Tunneling mode selection for IPv6 traffic depends on the following
+   parameters in a successful registration request:
+
+   1)  A registration request is received with one or more IPv6 prefix
+       request extensions.  An IPv6 tunneling mode extension is not
+       included.
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 10]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+          All IPv6 packets destined to the registered IPv6 prefix(es)
+          MUST be tunneled by the home agent to the registered IPv4 home
+          address of the mobile node.  The home agent first encapsulates
+          the IPv6 packet, addressing it to the mobile node's IPv4 home
+          address, and then tunnels this encapsulated packet to the
+          foreign agent.  This extra level of encapsulation is required
+          so that IPv6 routing remains transparent to a foreign agent
+          that does not support IPv6.  When received by the foreign
+          agent, the unicast encapsulated packet is de-tunneled and
+          delivered to the mobile node in the same way as any other
+          packet.  The mobile node must decapsulate the received IPv4
+          packet in order to recover the original IPv6 packet.
+
+          Additionally, the home agent MUST be prepared to accept
+          reverse-tunneled packets from the IPv4 home address of the
+          mobile node encapsulating IPv6 packets sent by that mobile
+          node.
+
+   2)  A registration request is received with one or more IPv6 prefix
+       request extensions.  An IPv6 tunneling mode extension is
+       included.
+
+          All IPv6 packets destined to the registered IPv6 prefix(es)
+          SHOULD be tunneled by the home agent to the registered care-of
+          address of the mobile node.  Additionally, the home agent
+          SHOULD be prepared to accept reverse-tunneled packets from the
+          care-of address of the mobile node encapsulating IPv6 packets
+          sent by that mobile node.  The home agent MAY ignore the
+          presence of the IPv6 tunneling mode extension and act as in
+          case (1) above.
+
+   The home agent MUST check that all inner IPv6 packets received from
+   the mobile node over a tunnel with the mobile node's home address or
+   the care-of address as the outer source address, include a source
+   address that falls under the registered IPv6 prefix(es) for that
+   mobile node.  If the source address of the outer header of a tunneled
+   packet is not the registered IPv4 care-of address or the registered
+   IPv4 home addresses, the packet SHOULD be dropped.  If the source
+   address of the inner header of an tunneled packet does not match any
+   of the registered prefixes, the packet SHOULD be dropped.
+
+   Multicast packets addressed to a group to which the mobile node has
+   successfully subscribed, MUST be tunneled to the mobile node.
+
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 11]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+3.3.3.  IPv6 Multicast Membership Control
+
+   IPv6 multicast membership control is provided as defined in MIPv6
+   [RFC3775], Section 10.4.3.  The only clarification required for the
+   purpose of this specification is that all Multicast Listener
+   Discovery (MLD) [RFC2710] or MLDv2 [RFC3810] messages between the
+   mobile node and the home agent MUST be tunneled over an IPv4 tunnel
+   between the mobile node's IPv4 home address and the home agent's IPv4
+   address, bypassing the foreign agent.  Note that if tunneling to the
+   care-of address has been negotiated for other traffic, then the rest
+   of the traffic continues using this tunnel.
+
+3.4.  Foreign Agent Considerations
+
+   This specification does not affect the operation of the foreign
+   agent.
+
+3.5.  Mobile Node Considerations
+
+   A dual-stack mobile node that supports the extensions described in
+   this document MAY use these extensions to register its IPv6
+   prefix(es) while moving between access routers.
+
+   The mobile node MAY include one or more IPv6 prefix request
+   extension(s) in the registration request.
+
+   In this case, the mobile node MUST take the following action
+   depending on the extensions included in the registration reply it
+   receives in response to the registration request:
+
+   1)  The registration reply does not include any IPv6 prefix reply
+       extensions.
+
+          The mobile node MUST assume that the home agent does not
+          support the extensions defined in this specification.  The
+          mobile node SHOULD continue to operate according to MIPv4
+          [RFC3344].
+
+   2)  The registration reply includes one or more IPv6 prefix reply
+       extensions.
+
+          The mobile node MUST match each IPv6 prefix reply extension
+          with one of the IPv6 prefix request extensions included
+          earlier in the corresponding registration request message.
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 12]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+          If a matching IPv6 prefix reply extension is not included for
+          one or more of corresponding IPv6 prefix request extensions
+          included in the registration request message, the mobile node
+          MUST assume that these IPv6 prefixes are rejected.
+
+          For each matching IPv6 prefix reply extension, the mobile node
+          MUST inspect the code field.  If the field is set to a
+          rejection code, then the corresponding IPv6 prefix
+          registration has been rejected.  If the code field is set to
+          an acceptance code, then the corresponding IPv6 prefix
+          registration has been accepted.
+
+          If the code field is set to "0", then the mobile node MUST be
+          prepared to send/receive IPv6 packets encapsulated in the
+          bidirectional tunnel between the home agent address and the
+          registered IPv4 home address of the mobile node.
+
+          If the code field is set to "1", then the mobile node MUST act
+          as follows:
+
+          -  Assuming the co-located care-of address mode is used, the
+             mobile node MUST be prepared to send/receive IPv6 packets
+             over the bidirectional tunnel between the home agent
+             address and its co-located care-of address.  Otherwise, the
+             mobile node SHOULD act as in the case where the code field
+             is set to "0".
+
+   The mobile node SHOULD include exactly one IPv6 tunneling mode
+   extension if it uses the co-located care-of address model and it
+   wants to request that IPv6 packets are tunneled to its co-located
+   care-of address.  If the mobile node uses the co-located care-of
+   address model but it does not include the IPv6 tunneling mode
+   extension, the home agent will tunnel IPv6 traffic to the mobile
+   node's IPv4 home address.  The mobile node MUST NOT include an IPv6
+   tunneling mode extension if it uses the foreign agent care-of address
+   mode of operation.  Note that if the mobile node includes an IPv6
+   tunneling mode extension in this case, IPv6 packets could be tunneled
+   to the FA by the HA.  The FA is then likely to drop them since it
+   will not have appropriate state to process them.
+
+3.6.  Tunneling Impacts
+
+   When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can
+   treat the IPv4 tunnel as a single hop link as defined in [RFC4213].
+   The two tunnel endpoints, e.g., mobile node and home agent, MUST
+   configure link-local IPv6 addresses as defined in Section 3.7 of
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 13]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   [RFC4213], while they MUST also adhere to the neighbor discovery
+   requirements of the same specification, Section 3.8, and the hop
+   limit requirements of Section 3.3.
+
+   With respect to the Tunnel MTU, an implementation MUST support the
+   Static Tunnel MTU approach as defined in Section 3.2 of [RFC4213].
+   Implementation and use of the Dynamic Tunnel MTU method defined in
+   the same section of [RFC4213] is OPTIONAL.
+
+   To accommodate traffic that uses Explicit Congestion Notification
+   (ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP)
+   information is copied between the inner and outer header as defined
+   in [RFC3168] and [RFC2983].  It is RECOMMENDED that the full-
+   functionality option defined in Section 9.1.1 of [RFC3168] be used to
+   deal with ECN.
+
+3.7.  IPv6 Prefixes
+
+   An implementation can use any number of mechanisms to allocate IPv6
+   prefixes to a mobile node.  Once one or more IPv6 prefixes are
+   allocated, they can be registered using the extensions and mechanism
+   already described in this specification.
+
+   How a home agent decides to accept an IPv6 prefix for a given mobile
+   node is out of scope of this specification.  Local configuration or
+   external authorization via an authorization system, e.g., Diameter
+   [RFC3588], or other mechanisms may be used to make such
+   determination.
+
+3.7.1.  Dynamic IPv6 Prefix Delegation
+
+   A dual-stack mobile node MAY use prefix delegation as defined in
+   DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes.
+   In that case, if the mobile node is not directly attached to its home
+   agent, the mobile node MUST first register its IPv4 home address as
+   per MIPv4 [RFC3344].  When that is done, the mobile node can generate
+   a link-local IPv6 address as per Section 3.7 of [RFC4213].  The
+   mobile node then sends a registration request to its home agent,
+   including an IPv6 prefix request extension with the prefix length
+   field set to 255 and setting the Mobile IPv6 Network Prefix field to
+   the locally generated link-local address.  If the registration reply
+   message includes an IPv6 prefix reply extension with the code field
+   set to a success code, the mobile node can use the tunnel to send and
+   receive IPv6 link-local packets.  The mobile node can now send DHCPv6
+   messages according to [RFC3633].  All IPv6 messages at this stage
+   MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4
+   home address and the home agent's IPv4 address.
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 14]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   Once prefixes are delegated, and assuming explicit mode is used, the
+   mobile node SHOULD send a registration request with the appropriate
+   IPv6 prefix request extensions to the home agent to register the
+   delegated prefixes.
+
+3.8.  Deregistration of IPv6 Prefix
+
+   The mobile IP registration lifetime included in the registration
+   request header is valid for all the bindings created by the
+   registration request, which may include bindings for IPv6 prefix(es).
+
+   A registration request with a zero lifetime can be used to remove all
+   bindings from the home agent.
+
+   A re-registration request with non-zero lifetime can be used to
+   deregister some of the registered IPv6 prefixes by not including
+   corresponding IPv6 prefix request extensions in the registration
+   request message.
+
+3.9.  Registration with a Private CoA
+
+   If the care-of address is a private address, then Mobile IP NAT
+   Traversal as [RFC3519] MAY be used in combination with the extensions
+   described in this specification.  In that case, to transport IPv6
+   packets, the next header field of the Mobile Tunnel Data message
+   header [RFC3519] MUST be set to the value for IPv6.  Note that in
+   that case, the encapsulation field of the UDP Tunnel Request
+   Extension defined in [RFC3519] MUST be set to zero.
+
+4.  Security Considerations
+
+   This specification operates in the security constraints and
+   requirements of [RFC3344].  It extends the operations defined in
+   [RFC3344] for IPv4 home addresses to cover home IPv6 prefixes and
+   provides the same level of security for both IP address versions.
+
+   Home agents MUST perform appropriate checks for reverse-tunneled IPv6
+   packets similar to what is defined in [RFC3024] for IPv4 packets.
+   The check defined in [RFC3024] requires that the outer header's
+   source address is set to a registered care-of address for the mobile
+   node and as such the same check protects from attacks whether the
+   encapsulated (inner) header is IPv4 or IPv6.
+
+   In addition to that, the home agent MUST check that the source
+   address of the inner header is a registered IPv4 home address or IPv6
+   prefix for this mobile node.  If that is not the case, the home agent
+   SHOULD silently discard the packet and log the event as a security
+   exception.
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 15]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   Security devices should look for IPv6 packets encapsulated over IPv4
+   either directly to the mobile node's care-of address or via double
+   encapsulation first to the mobile node's IPv4 home address and then
+   to the mobile node's care-of address.  Interactions with Mobile IPv4
+   and IPsec have been covered elsewhere, for instance in [RFC5265] and
+   [RFC5266].
+
+5.  IANA Considerations
+
+   A new type number (152) for DSMIPv4 extensions has been registered
+   from the space of numbers for skippable mobility extensions (i.e.,
+   128-255), defined for Mobile IPv4 [RFC3344].  This registry is
+   available from http://www.iana.org under "Extensions appearing in
+   Mobile IP control messages".
+
+   A new subtype space for the type number of this extension has been
+   created: "DSMIPv4 Extension subtypes".  The subtype values 1, 2, and
+   3 are defined in this specification, while the rest of the subtypes
+   are reserved and available for allocation based on Expert Review.
+
+   Finally, a new space for the code field of the IPv6 prefix reply
+   extension has been created: "IPv6 Prefix Reply Extension Codes".
+   Values 0, 1, 8, and 9 are defined in this specification.  Values 2-7
+   are reserved for accept codes, and values 10-255 are reserved for
+   reject codes.
+
+   Similar to the procedures specified for Mobile IPv4 [RFC3344] number
+   spaces, future allocations from the two number spaces require Expert
+   Review [RFC5226].
+
+6.  Acknowledgements
+
+   Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann
+   for earlier work on this subject.  Thanks also to Alex Petrescu for
+   various suggestions.  Special thanks also to Sri Gundavelli and Kent
+   Leung for their thorough review and suggestions.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 16]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
+              revised", RFC 3024, January 2001.
+
+   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
+              August 2002.
+
+   [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
+              Network Address Translation (NAT) Devices", RFC 3519,
+              April 2003.
+
+   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+              Host Configuration Protocol (DHCP) version 6", RFC 3633,
+              December 2003.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
+              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
+              RFC 3963, January 2005.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+7.2.  Informative References
+
+   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+              October 1996.
+
+   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
+              Listener Discovery (MLD) for IPv6", RFC 2710,
+              October 1999.
+
+   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+              March 2000.
+
+   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
+              RFC 2983, October 2000.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, September 2001.
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 17]
+
+RFC 5454                 Dual-Stack Mobile IPv4               March 2009
+
+
+   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
+              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [RFC5265]  Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
+              IPsec-Based VPN Gateways", RFC 5265, June 2008.
+
+   [RFC5266]  Devarapalli, V. and P. Eronen, "Secure Connectivity and
+              Mobility Using Mobile IPv4 and IKEv2 Mobility and
+              Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
+
+Authors' Addresses
+
+   George Tsirtsis
+   Qualcomm
+
+   EMail: tsirtsis@googlemail.com
+
+
+   Vincent Park
+   Qualcomm
+
+   Phone: +908-947-7084
+   EMail: vpark@qualcomm.com
+
+
+   Hesham Soliman
+   Elevate Technologies
+
+   Phone: +614-111-410-445
+   EMail: hesham@elevatemobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis, et al.            Standards Track                    [Page 18]
+