tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5844

Proposed STD
Pages: 49
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NETLMM

IPv4 Support for Proxy Mobile IPv6

Part 1 of 3, p. 1 to 16
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       R. Wakikawa
Request for Comments: 5844                                    Toyota ITC
Category: Standards Track                                  S. Gundavelli
ISSN: 2070-1721                                                    Cisco
                                                                May 2010


                   IPv4 Support for Proxy Mobile IPv6

Abstract

   This document specifies extensions to the Proxy Mobile IPv6 protocol
   for adding IPv4 protocol support.  The scope of IPv4 protocol support
   is two-fold: 1) enable IPv4 home address mobility support to the
   mobile node, and 2) allow the mobility entities in the Proxy Mobile
   IPv6 domain to exchange signaling messages over an IPv4 transport
   network.

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/rfc5844.

Copyright Notice

   Copyright (c) 2010 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.

Top       Page 2 
Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Stated Assumptions . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Relevance to Dual-Stack Mobile IPv6  . . . . . . . . . . .  5
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  6
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  IPv4 Home Address Mobility Support . . . . . . . . . . . . . .  8
     3.1.  Local Mobility Anchor Considerations . . . . . . . . . . .  9
       3.1.1.  Extensions to Binding Cache Entry  . . . . . . . . . .  9
       3.1.2.  Signaling Considerations . . . . . . . . . . . . . . . 10
       3.1.3.  Routing Considerations for the Local Mobility
               Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.1.4.  ECN and Payload Fragmentation Considerations . . . . . 16
     3.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 17
       3.2.1.  Extensions to Binding Update List Entry  . . . . . . . 17
       3.2.2.  Extensions to Mobile Node's Policy Profile . . . . . . 17
       3.2.3.  Signaling Considerations . . . . . . . . . . . . . . . 17
       3.2.4.  Routing Considerations for the Mobile Access
               Gateway  . . . . . . . . . . . . . . . . . . . . . . . 21
     3.3.  Mobility Options and Status Codes  . . . . . . . . . . . . 22
       3.3.1.  IPv4 Home Address Request Option . . . . . . . . . . . 22
       3.3.2.  IPv4 Home Address Reply Option . . . . . . . . . . . . 23
       3.3.3.  IPv4 Default-Router Address Option . . . . . . . . . . 25
       3.3.4.  IPv4 DHCP Support Mode Option  . . . . . . . . . . . . 25
       3.3.5.  Status Codes . . . . . . . . . . . . . . . . . . . . . 26
     3.4.  Supporting DHCP-Based Address Configuration  . . . . . . . 27
       3.4.1.  DHCP Server Co-Located with the Mobile Access
               Gateway  . . . . . . . . . . . . . . . . . . . . . . . 28
       3.4.2.  DHCP Relay Agent Co-Located with the Mobile Access
               Gateway  . . . . . . . . . . . . . . . . . . . . . . . 31
       3.4.3.  Common DHCP Considerations . . . . . . . . . . . . . . 33
   4.  IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35
     4.1.  Local Mobility Anchor Considerations . . . . . . . . . . . 37
       4.1.1.  Extensions to Binding Cache Entry  . . . . . . . . . . 37
       4.1.2.  Extensions to Mobile Node's Policy Profile . . . . . . 37
       4.1.3.  Signaling Considerations . . . . . . . . . . . . . . . 37
       4.1.4.  Routing Considerations . . . . . . . . . . . . . . . . 39
     4.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 40
       4.2.1.  Extensions to Binding Update List Entry  . . . . . . . 40
       4.2.2.  Signaling Considerations . . . . . . . . . . . . . . . 40
     4.3.  IPsec Considerations . . . . . . . . . . . . . . . . . . . 43
       4.3.1.  PBU and PBA  . . . . . . . . . . . . . . . . . . . . . 43
       4.3.2.  Payload Packet . . . . . . . . . . . . . . . . . . . . 43
   5.  Protocol Configuration Variables . . . . . . . . . . . . . . . 44
     5.1.  Local Mobility Anchor - Configuration Variables  . . . . . 44
     5.2.  Mobile Access Gateway - Configuration Variables  . . . . . 44

Top      ToC       Page 3 
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 45
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 46
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
     10.2. Informative References . . . . . . . . . . . . . . . . . . 48

1.  Overview

   The transition from IPv4 to IPv6 is a long process, and during this
   period of transition, both the protocols will be enabled over the
   same network infrastructure.  Thus, it is reasonable to assume that a
   mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-
   only, IPv6-only, or dual-stack mode, and the network between the
   mobile access gateway and a local mobility anchor may be an IPv4 or
   an IPv6 network.  It is also reasonable to expect the same mobility
   infrastructure in the Proxy Mobile IPv6 domain to provide mobility to
   the mobile nodes operating in IPv4, IPv6, or in dual mode and whether
   the transport network is IPv4 or IPv6 network.  The motivation and
   scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and
   all those requirements apply to Proxy Mobile IPv6 protocol as well.

   The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for
   providing IPv6 home address mobility support to a mobile node in a
   Proxy Mobile IPv6 domain.  The protocol requires IPv6 transport
   network between the mobility entities.  The extensions defined in
   this document specify IPv4 support to the Proxy Mobile IPv6 protocol
   [RFC5213].

   The scope of IPv4 support in Proxy Mobile IPv6 includes the support
   for the following two features:

   o  IPv4 Home Address Mobility Support: A mobile node that is dual-
      stack or IPv4-only enabled will be able to obtain an IPv4 address
      and be able to use that address from any of the access networks in
      that Proxy Mobile IPv6 domain.  The mobile node is not required to
      be allocated or assigned an IPv6 address to enable IPv4 home
      address support.

   o  IPv4 Transport Network Support: The mobility entities in the Proxy
      Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
      signaling messages over an IPv4 transport.

   These two features, the IPv4 home address mobility support and the
   IPv4 transport support features, are independent of each other, and
   deployments may choose to enable either one or both of these features
   as required.

Top      ToC       Page 4 
   Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4
   transport network and with IPv4 enabled mobile nodes.  The terms used
   in this illustration are explained in the Terminology section.

               +----+                +----+
               |LMA1|                |LMA2|
               +----+                +----+
   IPv4-LMAA  -> |          IPv4-LMAA-> | <-- LMAA
                 |                      |
                 \\                    //\\
                  \\                  //  \\
                   \\                //    \\
                +---\\------------- //------\\----+
               (     \\  IPv4/IPv6 //        \\    )
               (      \\  Network //          \\   )
                +------\\--------//------------\\-+
                        \\      //              \\
                         \\    //                \\
                          \\  //                  \\
         IPv4-Proxy-CoA --> |                      | <-- Proxy-CoA
                         +----+                 +----+
                         |MAG1|-----{MN2}       |MAG2|
                         +----+    |            +----+
        (MN-HoA)           |       |              | <-- (MN-HoA)
        (IPv4-MN-HoA) -->  |   (IPv4-MN-HoA)      | <-- (IPv4-MN-HoA)
                         {MN1}                   {MN3}

               Figure 1: IPv4 Support for Proxy Mobile IPv6

1.1.  Stated Assumptions

   The following are the system and configuration requirements from the
   mobility entities in the Proxy Mobile IPv6 domain for supporting the
   extensions defined in this document.

   o  Both the mobility entities, the local mobility anchor and the
      mobile access gateway are dual-stack (IPv4/IPv6) enabled.
      Irrespective of the type of transport network (IPv4 or IPv6)
      separating these two entities, the mobility signaling is always
      based on Proxy Mobile IPv6 protocol [RFC5213].

   o  A deployment where a mobile access gateway uses an IPv4 private
      address with NAT [RFC3022] translation devices in the path to a
      local mobility anchor is not supported by this specification.

Top      ToC       Page 5 
   o  The mobile node can be operating in IPv4-only, IPv6-only or in
      dual mode.  Based on the enabled configuration for a mobile node,
      the mobile node should be able to obtain IPv4-only, IPv6-only, or
      both IPv4 and IPv6 addresses for its interface and furthermore
      achieve mobility support for those addresses.

   o  For enabling IPv4 home address mobility support to a mobile node,
      it is not required that the IPv6 home address mobility support
      need be enabled.  However, the respective protocol(s) support,
      such as IPv4 or IPv6 packet forwarding, must be enabled on the
      access link between the mobile node and the mobile access gateway.

   o  The mobile node can obtain an IPv4 address for its attached
      interface.  Based on the type of link, it may be able to acquire
      its IPv4 address configuration using standard IPv4 address
      configuration mechanisms such as DHCP [RFC2131], IP Control
      Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version
      2 (IKEv2) [RFC4306], or static address configuration.  However,
      the details on how IPCP or IKEv2 can be used for address delivery
      are outside the scope of this document.

   o  The mobile node's IPv4 home subnet is typically a shared address
      space.  It is not for the exclusive use of any one mobile node.
      There can be multiple mobile nodes that are assigned IPv4
      addresses from the same subnet.

   o  The mobile access gateway is the IPv4 default router for the
      mobile node on its access link.  It will be in the forwarding path
      for the mobile node's data traffic.  Additionally, as specified in
      Section 6.9.3 of [RFC5213], all the mobile access gateways in the
      Proxy Mobile IPv6 domain MUST use the same link-layer address on
      any of the access links wherever the mobile node attaches.

1.2.  Relevance to Dual-Stack Mobile IPv6

   IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile
   IPv6 specification [RFC5555].  This document leverages some of the
   approaches, messaging options, and processing logic defined in that
   document for extending IPv4 support to Proxy Mobile IPv6, except with
   deviation in some aspects for obvious reasons of supporting a
   network-based mobility model.  The following are some of the related
   considerations.

   o  The Binding Update message flag 'F' and the NAT Detection Option
      defined in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this
      specification in Proxy Binding Update and Proxy Binding
      Acknowledgement messages.  Their sole purpose is to allow forcing

Top      ToC       Page 6 
      of UDP encapsulation between a mobile access gateway and a local
      mobility anchor in situations similar to those discussed in
      Sections 4.1 and 4.4.1 of [RFC5555].

   o  The necessary extensions to the conceptual data structures,
      Binding Cache entry and Binding Update List entry, for storing the
      state related to the IPv4 support defined in [RFC5555], will all
      be needed and relevant for this document.

   o  In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555],
      IPsec security associations (SAs) are specific to a single mobile
      node; they use the identifier visible to upper-layer protocols
      (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to
      be updated when the mobile node moves.

      In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec
      SAs are specific to the mobile access gateway (and used for a
      potentially large number of mobile nodes); they use the locators
      used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selectors;
      and they are not updated when the mobile node moves.

      This means the IPsec processing for Mobile IPv6 and Proxy Mobile
      IPv6 (whether IPv6-only or dual-stack) is very different.

   o  The tunneling considerations specified in [RFC5555] for supporting
      IPv4 transport are relevant for this document as well.

2.  Conventions and Terminology

2.1.  Conventions

   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 [RFC2119].

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in the Mobile IPv6 specification [RFC3775] and
   Proxy Mobile IPv6 specification [RFC5213].  In addition, this
   document introduces the following terms.

Top      ToC       Page 7 
   IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)

      The IPv4 address that is configured on the egress-interface of the
      mobile access gateway.  When using IPv4 transport, this address
      will be the registered care-of address in the mobile node's
      Binding Cache entry and will also be the transport-endpoint of the
      tunnel between the local mobility anchor and a mobile access
      gateway.

   IPv4 Local Mobility Anchor Address (IPv4-LMAA)

      The IPv4 address that is configured on the egress-interface of the
      local mobility anchor.  When using IPv4 transport, the mobile
      access gateway sends the Proxy Binding Update messages to this
      address and will be the transport-endpoint of the tunnel between
      the local mobility anchor and the mobile access gateway.

   Mobile Node's IPv4 Home Address (IPv4-MN-HoA)

      The IPv4 home address assigned to the mobile node's attached
      interface.  This address is topologically anchored at the mobile
      node's local mobility anchor.  The mobile node configures this
      address on its attached interface.  If the mobile node connects to
      the Proxy Mobile IPv6 domain via multiple interfaces each of the
      interfaces are assigned a unique IPv4 address.  All the IPv6 home
      network prefixes and the IPv4 home address assigned to a given
      interface of a mobile node will be managed under one mobility
      session.

   Selective De-registration

      A procedure for partial de-registration of all the addresses that
      belong to one address family, i.e., de-registration of either the
      IPv4 home address or one or more of the assigned IPv6 home network
      prefixes.

   Encapsulation Modes

      This document uses the following terms when referring to the
      different encapsulation modes.

      IPv4-or-IPv6-over-IPv6

         IPv4 or IPv6 packet carried as a payload of an IPv6 packet

      IPv4-or-IPv6-over-IPv4

         IPv4 or IPv6 packet carried as a payload of an IPv4 packet

Top      ToC       Page 8 
      IPv4-or-IPv6-over-IPv4-UDP

         IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
         a UDP header

      IPv4-or-IPv6-over-IPv4-UDP-TLV

         IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
         UDP and TLV headers

      IPv4-or-IPv6-over-IPv4-GRE

         IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
         a Generic Routing Encapsulation (GRE) header (but no UDP or TLV
         header)

3.  IPv4 Home Address Mobility Support

   The IPv4 home address mobility support essentially enables a mobile
   node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
   configuration for its attached interfaces and be able to retain that
   address configuration even after performing a handoff anywhere within
   that Proxy Mobile IPv6 domain.  This section describes the protocol
   operation and the required extensions to Proxy Mobile IPv6 protocol
   for extending IPv4 home address mobility support.

   When an IPv4-enabled or a dual-stack-enabled mobile node attaches to
   the Proxy Mobile IPv6 domain, the mobile access gateway on the access
   link where the mobile node is attached will identify the mobile node
   and will initiate the Proxy Mobile IPv6 signaling with the mobile
   node's local mobility anchor.  The mobile access gateway will follow
   the signaling considerations specified in Section 3.2 for requesting
   IPv4 home address mobility support.  Upon the completion of the
   signaling, the local mobility anchor and the mobile access gateway
   will establish the required routing states for allowing the mobile
   node to use its IPv4 home address from its current point of
   attachment.

   The mobile node on the access link using any of the standard IPv4
   address configuration mechanisms supported on that access link, such
   as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], will be able
   to obtain an IPv4 home address (IPv4-MN-HoA) for its attached
   interface.  Although the address configuration mechanisms for
   delivering the address configuration to the mobile node is
   independent of the Proxy Mobile IPv6 protocol operation, there needs
   to be some interaction between these two protocol flows.  Section 3.4
   identifies these interactions for supporting DHCP-based address
   configuration.

Top      ToC       Page 9 
   The support for IPv4 home address mobility is not dependent on the
   IPv6 home address mobility support.  It is not required that the IPv6
   home address mobility support needs to be enabled for providing IPv4
   home address mobility support.  A mobile node will be able to obtain
   IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its
   attached interface.  The mobile node's policy profile will determine
   if the mobile node is entitled to both the protocol versions or a
   single protocol version.  Based on the policy, only those protocols
   will be enabled on the access link.  Furthermore, if the mobile node,
   after obtaining the address configuration on its interface, performs
   a handoff, either by changing its point of attachment over the same
   interface or to a different interface, the network will ensure the
   mobile node will be able to use the same IPv4 address configuration
   after the handoff.

   Additionally, if the mobile node connects to the Proxy Mobile IPv6
   domain, through multiple interfaces and simultaneously through
   different access networks, each of the connected interfaces will
   obtain a unique IPv4 home address.  In such a scenario, there will be
   multiple Binding Cache entries for the mobile node on the local
   mobility anchor.  All the addresses (IPv4/IPv6) assigned to a given
   interface will be managed as part of one mobility session, as
   specified in Section 5.4 of [RFC5213].

3.1.  Local Mobility Anchor Considerations

3.1.1.  Extensions to Binding Cache Entry

   To support this feature, the conceptual Binding Cache entry data
   structure maintained by the local mobility anchor needs to include
   the following parameters.

   o  The IPv4 home address assigned to the mobile node's interface and
      registered by the mobile access gateway.  The IPv4 home address
      entry also includes the corresponding subnet mask.  It is to be
      noted that this parameter is defined in [RFC5555] and is presented
      here for completeness.

   o  The IPv4 default router address assigned to the mobile node.

Top      ToC       Page 10 
3.1.2.  Signaling Considerations

3.1.2.1.  Processing Proxy Binding Updates

   The processing rules specified in Section 5.3 of [RFC5213] are
   applied for processing the received Proxy Binding Update message.
   However, if the received Proxy Binding Update message has an IPv4
   Home Address Request option, the following considerations MUST be
   applied additionally.

   o  If there is an IPv4 Home Address Request option (Section 3.3.1)
      present in the received Proxy Binding Update message, but no Home
      Network Prefix option [RFC5213] present in the received Proxy
      Binding Update message, the local mobility anchor MUST NOT reject
      the request as specified in Section 5.3.1 of [RFC5213].  At least
      one instance of either of these two options, either the IPv4 Home
      Address Request option or the Home Network Prefix option, MUST be
      present.  If there is not a single instance of either of these two
      options present in the request, the local mobility anchor MUST
      reject the request and send a Proxy Binding Acknowledgement
      message with the Status field set to
      MISSING_HOME_NETWORK_PREFIX_OPTION (missing the mobile node's home
      network prefix option) [RFC5213].

   o  If there is at least one instance of the Home Network Prefix
      option [RFC5213] present in the received Proxy Binding Update
      message, but it is known from the mobile node's policy profile
      that the mobile node is not authorized for IPv6 service, or IPv6
      routing in not enabled in the home network, the local mobility
      anchor MUST reject the request and send a Proxy Binding
      Acknowledgement message with the Status field set to
      NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not
      authorized for IPv6 mobility service; see Section 3.3.5).

   o  If there is an IPv4 Home Address Request option present in the
      received Proxy Binding Update message, but it is known from the
      mobile node's policy profile that the mobile node is not
      authorized for IPv4 service, or if IPv4 routing is not enabled in
      the home network, the local mobility anchor MUST reject the
      request and send a Proxy Binding Acknowledgement message with the
      Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE
      (mobile node not authorized for IPv4 mobility service; see
      Section 3.3.5).

   o  If there is more than one instance of the IPv4 Home Address
      Request option present in the request, then the local mobility
      anchor MUST reject the request and send a Proxy Binding

Top      ToC       Page 11 
      Acknowledgement message with the Status field set to
      MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
      home address assignments not supported; see Section 3.3.5).

   o  For associating the received Proxy Binding Update message to an
      existing mobility session, the local mobility anchor MUST perform
      the Binding Cache entry existence test by applying the following
      considerations.

      *  If there is at least one instance of the Home Network Prefix
         option [RFC5213] with a NON_ZERO prefix value, or, if there is
         an IPv4 Home Address Request option with the IPv4 address in
         the option set to ALL_ZERO, considerations from Section 5.4.1
         of [RFC5213] MUST be applied.

      *  If there is an IPv4 Home Address Request option present in the
         request with the IPv4 address value in the option set to a
         NON_ZERO value, considerations from Section 3.1.2.7 MUST be
         applied.

   o  If there is no existing Binding Cache entry that can be associated
      with the request, the local mobility anchor MUST consider this
      request as an initial binding registration request, and
      considerations from Section 3.1.2.2 MUST be applied.
      Additionally, if there are one or more Home Network Prefix options
      [RFC5213] present in the request, considerations from Section
      5.3.2 of [RFC5213] MUST also be applied.

   o  If there exists a Binding Cache entry that can be associated with
      the request, the local mobility anchor MUST apply considerations
      from Section 5.3.1 of [RFC5213], (point 13), to determine if the
      request is a re-registration or a de-registration request.  If the
      request is a re-registration request, considerations from
      Section 3.1.2.3 MUST be applied, and if it is a de-registration
      request, considerations from Section 3.1.2.5 MUST be applied.

   o  If there exists a Binding Cache entry that can be associated with
      the request and if it is determined that the request is a re-
      registration request for extending an IPv4 home address mobility
      support to the existing IPv6-only mobility session, considerations
      from Section 3.1.2.2 MUST be applied with respect to IPv4 support.

Top      ToC       Page 12 
3.1.2.2.  Initial Binding Registration (New Mobility Session)

   o  If there is an IPv4 Home Address Request option present in the
      Proxy Binding Update message with the IPv4 address value in the
      option set to ALL_ZERO, the local mobility anchor MUST allocate an
      IPv4 home address to the mobile node and associate it with the new
      mobility session created for that mobile node.

   o  If there is an IPv4 Home Address Request option with the IPv4
      address in the option set to a NON_ZERO value, the local mobility
      anchor, before accepting the request, MUST ensure that the address
      is topologically anchored on the local mobility anchor and
      furthermore that the mobile node is authorized to use that
      address.  If the mobile node is not authorized for that specific
      address, the local mobility anchor MUST reject the request and
      send a Proxy Binding Acknowledgement message with the Status field
      set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not
      authorized for the requesting IPv4 address; see Section 3.3.5).
      It MUST also include the IPv4 Home Address Reply option
      (Section 3.3.2). in the reply with the Status field value in the
      option set to 129 (Administratively prohibited).

   o  If the local mobility anchor is unable to allocate an IPv4 address
      due to lack of resources, it MUST reject the request and send a
      Proxy Binding Acknowledgement message with Status field set to 130
      (Insufficient resources).  It MUST also include the IPv4 Home
      Address Reply option in the reply with the Status field value in
      the option set to 128 (Failure, reason unspecified).

   o  Upon accepting the request, the local mobility anchor MUST create
      a Binding Cache entry for this mobility session.  However, if the
      request also contains one or more Home Network Prefix options
      [RFC5213], there should still be only one Binding Cache entry that
      should be created for this mobility session.  The created Binding
      Cache entry MUST be used for managing both IPv4 and IPv6 home
      address bindings.  The fields in the Binding Cache entry MUST be
      updated with the accepted values for that session.

   o  The local mobility anchor MUST establish a bidirectional tunnel to
      the mobile access gateway with the encapsulation mode set to the
      negotiated mode for carrying the IPv4 payload traffic.  When using
      IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over-IPv6
      (IPv4 or IPv6 packet carried as a payload of an IPv6 packet).
      When using IPv4 transport, the encapsulation mode is as specified
      in Section 4.

Top      ToC       Page 13 
   o  The local mobility anchor MUST create an IPv4 host route (or a
      platform-specific equivalent function that sets up the forwarding)
      for tunneling the packets received for the mobile node's home
      address associated with this mobility session.

   o  The local mobility anchor MUST send the Proxy Binding
      Acknowledgement message with the Status field set to 0 (Proxy
      Binding Update accepted).  The message MUST be constructed as
      specified in Section 3.1.2.6.

3.1.2.3.  Binding Lifetime Extension (No Handoff)

   All the considerations from Section 5.3.3 of [RFC5213] MUST be
   applied.

3.1.2.4.  Binding Lifetime Extension (after Handoff)

   o  If there is no Home Network Prefix option [RFC5213] present in the
      request, but if the Binding Cache entry associated with this
      request has IPv6 home network prefix(es), the local mobility
      anchor MUST consider this as a request to extend lifetime only for
      the IPv4 home address and not for the IPv6 home network
      prefix(es).  Hence, the local mobility anchor SHOULD release all
      the IPv6 home network prefix(es) assigned to that mobile node and
      for that specific attached interface.  Similar considerations
      apply for the case where there is no IPv4 Home Address Request
      option present in the request, but if the Binding Cache entry
      associated with that request has both IPv4 home address and IPv6
      home network prefix(es).

   o  The local mobility anchor MUST remove the previously created IPv4
      host route (or the forwarding state) and the dynamically created
      bidirectional tunnel for carrying the IPv4 payload traffic (if
      there are no other mobile nodes for which the tunnel is being
      used).  This will remove the routing state towards the mobile
      access gateway where the mobile node was anchored prior to the
      handoff.

   o  The local mobility anchor MUST create a bidirectional tunnel to
      the mobile access gateway that sent the request (if there is no
      existing bidirectional tunnel) and with the encapsulation mode set
      to the negotiated mode for carrying the IPv4 payload traffic.  An
      IPv4 host route for tunneling the packets received for the mobile
      node's IPv4 home address MUST also be added.

Top      ToC       Page 14 
   o  The required forwarding state identified in Section 5.3.6 of
      [RFC5213] is for IPv6 payload traffic.  Those considerations apply
      for IPv4 payload traffic as well.  However, if IPv4 transport is
      in use, considerations from Section 4 MUST be applied.

3.1.2.5.  Binding De-Registration

   All the considerations from Section 5.3.5 of [RFC5213] MUST be
   applied.  Additionally, to remove the IPv4 state as part of the
   Binding Cache entry deletion, the IPv4 host route and the dynamically
   created bidirectional tunnel for carrying the IPv4 payload traffic
   (if there are no other mobile nodes for which the tunnel is being
   used) MUST be removed.  However, if the request is for a selective
   de-registration (IPv4 home address only, or all the IPv6 home network
   prefixes), the Binding Cache entry MUST NOT be deleted, only the
   respective states related to those addresses MUST be deleted.

3.1.2.6.  Constructing the Proxy Binding Acknowledgement Message

   When sending the Proxy Binding Acknowledgement message to the mobile
   access gateway, the local mobility anchor MUST construct the message
   as specified in Section 5.3.6 of [RFC5213].  Additionally, the
   following considerations MUST be applied.

   o  Section 5.3.6 of [RFC5213] requires the local mobility anchor to
      include at least one instance of the Home Network Prefix option
      [RFC5213] in the Proxy Binding Acknowledgement message that it
      sends to the mobile access gateway.  However, if the received
      Proxy Binding Update message has only the IPv4 Home Address
      Request option and does not contain the Home Network Prefix
      option(s), then the local mobility anchor MUST NOT include any
      Home Network Prefix option(s) in the reply.  However, there MUST
      be at least one instance of either the Home Network Prefix option
      [RFC5213] or the IPv4 Home Address Reply option present in the
      Proxy Binding Acknowledgement message.

   o  The IPv4 Home Address Reply option MUST be present in the Proxy
      Binding Acknowledgement message.

      1.  If the Status field is set to a value greater than or equal to
          128, i.e., if the Proxy Binding Update is rejected, then there
          MUST be an IPv4 Home Address Reply option corresponding to the
          IPv4 Home Address Request option present in the request and
          with the IPv4 address value and the prefix length fields in
          the option set to the corresponding values in the request.
          The Status field value in the option must be set to the
          specific error code.

Top      ToC       Page 15 
      2.  For all other cases, there MUST be an IPv4 Home Address Reply
          option to carry the IPv4 home address assigned for that
          mobility session and with the value in the option set to the
          allocated IPv4 address.  The prefix length in the option MUST
          be set to the prefix length of the mobile node's IPv4 home
          network.  The Status field value in the option must be set to
          0 (Success).

   o  The IPv4 Default-Router Address option (Section 3.3.3) MUST be
      present, if the Status field value in the Proxy Binding
      Acknowledgement message is set to 0 (Proxy Binding Update
      accepted) [RFC5213].  Otherwise, the option MUST NOT be present.
      If the option is present, the default router address in the option
      MUST be set to the mobile node's default router address.

3.1.2.7.  Binding Cache Entry Lookup Considerations

   The Binding Cache entry lookup considerations specified in Section
   5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as
   the key parameter for identifying the Binding Cache entry.  However,
   when there is not a single Home Network Prefix option with a NON_ZERO
   value present in the request, but there is an IPv4 Home Address
   option with a NON_ZERO value present in the request, then the
   following considerations MUST be applied.

   o  The search rules specified in Section 5.4.1.1 of [RFC5213], which
      primarily uses IPv6 home network prefix set as the search key, are
      equally valid when using a single IPv4 home address as the key.
      When applying those considerations, instead of the IPv6 home
      network prefix(es), the IPv4 home address from the IPv4 Home
      Address option present in the request MUST be used as the search
      key.

   o  The rules specified in Section 5.4.1.1 of [RFC5213] assume the
      presence of one or more IPv6 home network prefixes in the received
      request and also in the Binding Cache entry.  But, when using the
      IPv4 home address as the search key, these considerations MUST
      always assume just one single IPv4 home address, both in the
      request and also in the Binding Cache entry.

3.1.3.  Routing Considerations for the Local Mobility Anchor

   Intercepting Packets Sent to the Mobile Node's IPv4 Home Address:

   o  When the local mobility anchor is serving a mobile node, it MUST
      advertise a connected route into the Routing Infrastructure for
      the mobile node's IPv4 home address or for its home subnet, in
      order to receive packets that are sent to the mobile node's IPv4

Top      ToC       Page 16 
      home address.  This essentially enables IPv4 routers in that
      network to detect the local mobility anchor as the last-hop router
      for that subnet.

   Forwarding Packets to the Mobile Node:

   o  On receiving a packet from a corresponding node with the
      destination address matching the mobile node's IPv4 home address,
      the local mobility anchor MUST forward the packet through the
      bidirectional tunnel setup for that mobile node.

   o  The format of the tunneled packet when payload protection is not
      enabled:

        IPv6 header (src= LMAA, dst= Proxy-CoA       /* Tunnel Header */
           IPv4 header (src= CN, dst= IPv4-MN-HOA )  /* Packet Header */
              Upper-layer protocols                  /* Packet Content*/

      Figure 2: Tunneled Packets from the Local Mobility Anchor (LMA) to
                       the Mobile Access Gateway (MAG)

   Forwarding Packets Sent by the Mobile Node:

   o  All the reverse tunneled packets that the local mobility anchor
      receives from the mobile access gateway, after removing the tunnel
      header, MUST be routed to the destination specified in the inner
      IPv4 packet header.  These routed packets will have the Source
      Address field set to the mobile node's IPv4 home address.

3.1.4.  ECN and Payload Fragmentation Considerations

   The Explicit Congestion Notification (ECN) considerations specified
   in Section 5.6.3 of [RFC5213] apply for the IPv4 payload packets as
   well.  The mobility agents at the tunnel entry and exit points MUST
   handle ECN information as specified in that document.

   The mobility agents at the tunnel entry and exit points MUST apply
   the IP packet fragmentation considerations as specified in Section 7
   of [RFC2473]; additionally, they MUST apply the considerations
   related to tunnel error processing and reporting as specified in
   Section 8 of [RFC2473].


Next RFC Part