Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5844

IPv4 Support for Proxy Mobile IPv6

Pages: 49
Proposed Standard
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC5844 - 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   ToC   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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   RFC5844 - 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 page on part 2)

Next Section