RFC 5844

IPv4 Support for Proxy Mobile IPv6

📅 published May 2010, from ietf

RFC 5844: IPv4 Support for Proxy Mobile IPv6 🎀 (Part 1 of 10)

Okay bestie, so this is RFC 5844 🦋, published by the IETF in May 2010. It was written by R. Wakikawa from Toyota ITC and S. Gundavelli from Cisco. It's on the Standards Track, so it's a real Internet Standards Track spec 💅 with ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates. ✨

Abstract ✨

This doc adds IPv4 support to the Proxy Mobile IPv6 protocol by specifying extensions to it 💖. The IPv4 support has two parts. First, the mobile node gets IPv4 home address mobility. Second, the mobility entities inside a Proxy Mobile IPv6 domain can swap signaling messages over an IPv4 transport network 🌸.

Status of This Memo 🌈

This is an Internet Standards Track document 🔥.

This doc is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. For more on Internet Standards, check out Section 2 of RFC 5741 📚.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc5844 🍓.

Copyright Notice 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this doc 🧐. Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes 🎀.

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

   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 move from IPv4 to IPv6 is a long process 🕰️. While it's happening, both protocols run over the same network infrastructure 🌐. So it's totally reasonable to assume that a mobile node in a Proxy Mobile IPv6 domain could be running IPv4-only, IPv6-only, or dual-stack mode 💅. The network between the mobile access gateway and a local mobility anchor could be IPv4 or IPv6 too. It's also reasonable to expect the same mobility infrastructure to give mobility to nodes running IPv4, IPv6, or dual mode, no matter whether the transport network is IPv4 or IPv6 👑. The motivation and scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and all of those requirements apply to Proxy Mobile IPv6 as well 🦋.

The Proxy Mobile IPv6 protocol [RFC5213] gives IPv6 home address mobility to a mobile node in a Proxy Mobile IPv6 domain 🎀. It needs an IPv6 transport network between the mobility entities, though 🥲. The extensions in this doc add IPv4 support to the Proxy Mobile IPv6 protocol [RFC5213] ✨.

The IPv4 support in Proxy Mobile IPv6 covers two features:

IPv4 Home Address Mobility Support: A mobile node that's dual-stack or IPv4-only enabled can get an IPv4 address and use it from any access network in that Proxy Mobile IPv6 domain 🌸. The mobile node is not required to be allocated or assigned an IPv6 address to get IPv4 home address support 💖.
IPv4 Transport Network Support: The mobility entities in the Proxy Mobile IPv6 domain can swap Proxy Mobile IPv6 signaling messages over an IPv4 transport 🚀.

These two features, IPv4 home address mobility support and IPv4 transport support, are independent of each other 🙈. Deployments can turn on either one or both, as required 💅.

Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4 transport network and 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 ✨

okay so before we get into the fun stuff, here are the system and config requirements the mobility entities in the Proxy Mobile IPv6 domain need in order to support the extensions in this doc 🫶

okay the local mobility anchor and the mobile access gateway are both dual-stack (IPv4/IPv6) enabled 💅 and no matter what kind of transport network (IPv4 or IPv6) sits between them, the mobility signaling is always based on the Proxy Mobile IPv6 protocol [RFC5213].
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 🙅‍♀️
the mobile node can be operating in IPv4-only, IPv6-only, or dual mode 🦋 depending on how it's configured, the mobile node should be able to get IPv4-only, IPv6-only, or both IPv4 and IPv6 addresses for its interface, and then keep mobility support for those addresses.
for IPv4 home address mobility support to work, the IPv6 home address mobility support does not have to be enabled 🌸 but the protocols (like IPv4 or IPv6 packet forwarding) must be enabled on the access link between the mobile node and the mobile access gateway.
the mobile node can get an IPv4 address for its attached interface 🎀 depending on the type of link, it may be able to get its IPv4 address config using standard IPv4 address configuration mechanisms like DHCP [RFC2131], IP Control Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], or static address configuration. however, how IPCP or IKEv2 can be used for address delivery is outside the scope of this document 🙈
the mobile node's IPv4 home subnet is typically a shared address space 🍓 it's not for the exclusive use of any one mobile node, so there can be multiple mobile nodes assigned IPv4 addresses from the same subnet.
the mobile access gateway is the IPv4 default router for the mobile node on its access link 👑 it's in the forwarding path for the mobile node's data traffic. also, 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. main character energy 🧚

1.2. Relevance to Dual-Stack Mobile IPv6 🌈

IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile IPv6 specification [RFC5555]. this doc borrows some of the approaches, messaging options, and processing logic from that one to extend IPv4 support to Proxy Mobile IPv6 😭 but it deviates in some spots because of the whole network-based mobility model. here are some related considerations:

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 only purpose is to force 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].
the 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 🫧
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 the 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 💀

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 doc are to be interpreted as defined in the Mobile IPv6 specification [RFC3775] and the Proxy Mobile IPv6 specification [RFC5213]. on top of that, this document introduces the following terms 🦋

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 it 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 it 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, and the mobile node configures it on its attached interface. if the mobile node connects to the Proxy Mobile IPv6 domain via multiple interfaces, each of the interfaces is 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
- 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 basically lets a mobile node in a Proxy Mobile IPv6 domain get an IPv4 home address configuration for its attached interfaces 🥹 and keep that address configuration even after a handoff anywhere within that Proxy Mobile IPv6 domain. this section describes the protocol operation and the required extensions to the Proxy Mobile IPv6 protocol for extending IPv4 home address mobility support.

when an IPv4-enabled or 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 start the Proxy Mobile IPv6 signaling with the mobile node's local mobility anchor. the mobile access gateway follows the signaling considerations in Section 3.2 for requesting IPv4 home address mobility support. once the signaling is done, the local mobility anchor and the mobile access gateway set up the required routing states so the mobile node can use its IPv4 home address from its current point of attachment ✨

the mobile node on the access link uses whichever standard IPv4 address configuration mechanisms that access link supports, such as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], to get an IPv4 home address (IPv4-MN-HoA) for its attached interface 💅 the way address configuration gets delivered to the mobile node is independent of the Proxy Mobile IPv6 protocol operation, but there still needs to be some interaction between these two protocol flows. Section 3.4 spells out those interactions for supporting DHCP-based address configuration.

IPv4 home address mobility does not depend on IPv6 home address mobility support 🙌 it is not required that IPv6 home address mobility support be enabled in order to provide IPv4 home address mobility support. a mobile node can get IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its attached interface. the mobile node's policy profile determines whether it is entitled to both protocol versions or just a single one, and based on that policy, only those protocols will be enabled on the access link. also, if the mobile node gets its address configuration on an interface and then performs a handoff (either by changing its point of attachment over the same interface or moving to a different interface), the network makes sure the mobile node can keep using the same IPv4 address configuration after the handoff 🔥

and if the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces at the same time, through different access networks, each connected interface gets a unique IPv4 home address 🍒 in that case 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 are 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 🧚

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's worth noting that this parameter is defined in [RFC5555] and is presented here for completeness 🫶
the IPv4 default router address assigned to the mobile node 🦋

3.1.2. Signaling Considerations ✨

3.1.2.1. Processing Proxy Binding Updates 💖

okay so the processing rules in Section 5.3 of [RFC5213] still run on the received Proxy Binding Update message 💅 BUT if that PBU has an IPv4 Home Address Request option, these extra considerations MUST be applied too 🫶

ngl this one's sneaky 👀 If there's an IPv4 Home Address Request option (Section 3.3.1) in the received Proxy Binding Update message but no Home Network Prefix option [RFC5213], 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, the IPv4 Home Address Request option or the Home Network Prefix option, MUST be present. If there isn't a single instance of either option 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].
if there's at least one Home Network Prefix option [RFC5213] in the received Proxy Binding Update message, but the mobile node's policy profile says it isn't 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). 🙅‍♀️
if there's an IPv4 Home Address Request option in the received Proxy Binding Update message but the policy profile says the mobile node isn't authorized for IPv4 service, or IPv4 routing isn't 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).
if there's more than one IPv4 Home Address Request option in the request, the local mobility anchor MUST reject the request and send a Proxy Binding 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). nope 🚫
for matching the received Proxy Binding Update message to an existing mobility session ✨ the local mobility anchor MUST perform the Binding Cache entry existence test using these considerations:
- if there's at least one Home Network Prefix option [RFC5213] with a NON_ZERO prefix value, or an IPv4 Home Address Request option with the IPv4 address set to ALL_ZERO, considerations from Section 5.4.1 of [RFC5213] MUST be applied.
- if there's an IPv4 Home Address Request option in the request with the IPv4 address set to a NON_ZERO value, considerations from Section 3.1.2.7 MUST be applied.
if there's no existing Binding Cache entry that matches the request, the local mobility anchor MUST treat it as an initial binding registration request, and considerations from Section 3.1.2.2 MUST be applied. Also, if one or more Home Network Prefix options [RFC5213] are in the request, considerations from Section 5.3.2 of [RFC5213] MUST also be applied. 🌸
if there IS a Binding Cache entry that matches the request, the local mobility anchor MUST apply considerations from Section 5.3.1 of [RFC5213], (point 13), to figure out whether it's a re-registration or a de-registration request. For a re-registration, considerations from Section 3.1.2.3 MUST be applied, and for a de-registration, considerations from Section 3.1.2.5 MUST be applied. 🦋
if there's a matching Binding Cache entry and the request is a re-registration that extends IPv4 home address mobility support to an existing IPv6-only mobility session, considerations from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 🎀

3.1.2.2. Initial Binding Registration (New Mobility Session) 🧚

if the Proxy Binding Update message has an IPv4 Home Address Request option with the IPv4 address 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. 🍓
if there's an IPv4 Home Address Request option with the IPv4 address set to a NON_ZERO value, the local mobility anchor MUST, before accepting the request, 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 isn't 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). 🙈
if the local mobility anchor can't allocate an IPv4 address because it's out 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). 😭
once the request is accepted, 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. ✨
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. 🌈
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. 🛣️
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) 🚚

if there's no Home Network Prefix option [RFC5213] in the request, but the Binding Cache entry tied to this request has IPv6 home network prefix(es), the local mobility anchor MUST consider this 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 for that specific attached interface. Similar considerations apply where there's no IPv4 Home Address Request option in the request, but the Binding Cache entry tied to that request has both an IPv4 home address and IPv6 home network prefix(es). 🙃
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 using that tunnel). This will remove the routing state towards the mobile access gateway where the mobile node was anchored prior to the handoff. 🧹
the local mobility anchor MUST create a bidirectional tunnel to the mobile access gateway that sent the request (if there isn't an existing bidirectional tunnel), 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. 🎀
the required forwarding state identified in Section 5.3.6 of [RFC5213] is for IPv6 payload traffic, and those considerations apply to 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 using that tunnel) 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, and only the respective states related to those addresses MUST be deleted. that's the whole vibe of selective de-registration fr fr 🦋

3.1.2.6. Constructing the Proxy Binding Acknowledgement Message ✨

okay so when the local mobility anchor sends a Proxy Binding Acknowledgement back to the mobile access gateway, it MUST build that message the way Section 5.3.6 of [RFC5213] says 💅. On top of that, these extra rules MUST also be applied 🎀

Section 5.3.6 of [RFC5213] wants the local mobility anchor to put at least one Home Network Prefix option [RFC5213] in the Proxy Binding Acknowledgement it sends to the mobile access gateway 🌸 BUT, if the Proxy Binding Update it got only has the IPv4 Home Address Request option and no Home Network Prefix option(s), then the local mobility anchor MUST NOT include any Home Network Prefix option(s) in the reply 🙈. Even so, there MUST be at least one instance of either the Home Network Prefix option [RFC5213] or the IPv4 Home Address Reply option in the Proxy Binding Acknowledgement message 🫶
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 🥺. Its IPv4 address value and prefix length fields should match the request's values, and the Status field value in the option must be set to the specific error code 😭
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, 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) 👑
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 it 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 🔍

bestie this one is a whole vibe. The Binding Cache entry lookup stuff in Section 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as the key for finding the Binding Cache entry 🗝️. BUT when there's not a single Home Network Prefix option with a NON_ZERO value in the request, and there IS an IPv4 Home Address option with a NON_ZERO value in there, then these considerations MUST be applied 🧚

The search rules in Section 5.4.1.1 of [RFC5213] mostly use the IPv6 home network prefix as the search key, and they work just as well with a single IPv4 home address as the key 🦋. So when you apply them, the IPv4 home address from the IPv4 Home Address option in the request MUST be used as the search key, instead of the IPv6 home network prefix(es) 💅
The rules in Section 5.4.1.1 of [RFC5213] assume there are one or more IPv6 home network prefixes in both the received request and the Binding Cache entry 👀. When you're searching by IPv4 home address, though, these considerations MUST always assume just one single IPv4 home address, in both the request and the Binding Cache entry 💜 no exceptions, periodt ✨

3.1.3. Routing Considerations for the Local Mobility Anchor 🛣️

okay routing time 🚗💨

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

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 🌷. That way it can receive packets sent to the mobile node's IPv4 home address 📬. Basically this lets IPv4 routers in that network spot the local mobility anchor as the last-hop router for that subnet 🫶

Forwarding Packets to the Mobile Node:

When a packet comes in from a corresponding node with a destination address matching the mobile node's IPv4 home address, the local mobility anchor MUST forward it through the bidirectional tunnel that was set up for that mobile node 🚇
Here's what the tunneled packet looks like 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:

Every reverse tunneled packet the local mobility anchor gets from the mobile access gateway, once the tunnel header is stripped off, MUST be routed to the destination in the inner IPv4 packet header 🏁. These routed packets will have their Source Address field set to the mobile node's IPv4 home address 💖

3.1.4. ECN and Payload Fragmentation Considerations 🌪️

the ECN stuff from Section 5.6.3 of [RFC5213] applies to IPv4 payload packets too 🙌. The mobility agents at the tunnel entry and exit points MUST handle ECN information the way that document describes ✨

Also, the mobility agents at the tunnel entry and exit points MUST apply the IP packet fragmentation considerations from Section 7 of [RFC2473] 🧩. On top of that, they MUST apply the tunnel error processing and reporting considerations from Section 8 of [RFC2473] 🚨

3.2. Mobile Access Gateway Considerations 🌸

3.2.1. Extensions to Binding Update List Entry 📝

to get IPv4 home address mobility working, the conceptual Binding Update List entry needs two new fields 🎀

The IPv4 home address assigned to the mobile node's attached interface 🏠. It might have been statically configured in the mobile node's policy profile, or dynamically allocated by the local mobility anchor 🤩. The entry also has the matching subnet mask 🎭
The IPv4 default router address of the mobile node 🧭. The mobile access gateway gets this from the local mobility anchor through the Proxy Binding Acknowledgement message it receives 📨

3.2.2. Extensions to Mobile Node's Policy Profile 🗂️

so the mobile node's policy profile (from Section 6.2 of [RFC5213]) MUST be extended with some new fields for IPv4 home address mobility 💅

Extensions to the mandatory section of the policy profile:

This field says which IP versions the home address mobility support needs to reach for the mobile node 🌍. The options are IPv4-only, IPv6-only, and dual IPv4/IPv6 💜

Extensions to the optional section of the policy profile:

The IPv4 home address assigned to the mobile node's attached interface 🏡. How the network keeps track of which address goes with which attached interface is outside the scope of this document 🙈. This address field also has the matching subnet mask 🌷

3.2.3. Signaling Considerations 📡

3.2.3.1. Mobile Node Attachment and Initial Binding Registration 🥰

so a new mobile node shows up on the access link 👀. The mobile access gateway on that link MUST figure out whether IPv4 home address mobility support needs to be enabled for it 🔎. The policy profile tells it which modes (IPv4-only, IPv6-only, or dual IPv4/IPv6) the mobile service should be enabled for 📋. If, based on those policy considerations and other triggers (like something from the network), it's decided that IPv4 home address mobility support should be turned on, then the considerations from Section 6.9.1.1 of [RFC5213] MUST be applied, with these exceptions 🫶

The IPv4 Home Address Request option MUST be present in the Proxy Binding Update message 🎀
- If the mobile access gateway learned the mobile node's IPv4 home address from its policy profile or some other way, it MAY ask the local mobility anchor to allocate that exact address 🎯. To do that, it includes exactly one instance of the IPv4 Home Address Request option, with the IPv4 home address and prefix length fields set to that specific IPv4 address and the prefix length of the corresponding home network 💫
- The mobile access gateway MAY also ask the local mobility anchor for dynamic IPv4 home address allocation 🎲. It can include exactly one instance of the IPv4 Home Address option, with the IPv4 home address and prefix length fields set to the ALL_ZERO value. Furthermore, the (P) flag in the option MUST be set to 0 🚩. This is the request to the local mobility anchor for IPv4 home address allocation 🙌
The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5 of [RFC5213] 🏗️. The Home Network Prefix option(s) [RFC5213] MUST be present in the Proxy Binding Update only if IPv6 home address mobility support also needs to be enabled for the mobile node 🌐. Otherwise, the Home Network Prefix option(s) MUST NOT be present 🙅‍♀️
When the signaling messages are carried over IPv4 transport, the related considerations from Section 4 MUST be applied as well 🛰️

That's the end of part 4, and the next part is coming up! 🌈💖

3.2.3.2. Receiving Proxy Binding Acknowledgement ✨

okay bestie, so when the mobile access gateway gets a Proxy Binding Acknowledgement back, all the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied 💅 but with a few plot twists (listed below) 🦋

If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (The mobile node is not authorized for IPv4 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including a IPv4 Home Address Request option until an administrative action is taken. 🙈
If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (The mobile node is not authorized for the requesting IPv4 home address), the mobile access gateway SHOULD NOT request the same IPv4 address again, but MAY request the local mobility anchor to perform the address assignment by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value. 🌸
If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (The mobile node is not authorized for IPv6 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including any Home Network Prefix option(s) until an administrative action is taken. 😭
If there is no IPv4 Home Address Reply option present in the received Proxy Binding Acknowledgement message, the mobile access gateway MUST NOT enable IPv4 support for the mobile node and the rest of the considerations from this section can be skipped. 💀
If the received Proxy Binding Acknowledgement message has the Status field value in the IPv4 Home Address Reply option set to a value that indicates that the request was rejected by the local mobility anchor, the mobile access gateway MUST NOT enable IPv4 mobility support. 🥀
If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST update a Binding Update List entry for that mobile node. The entry MUST be updated with the assigned IPv4 home address and other accepted registration values. 🎀
If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted) and has the IPv4 Home Address Reply option set to a value that indicates that the request was accepted by the local mobility anchor, the mobile access gateway MUST establish a bidirectional tunnel to the local mobility anchor (if there is no existing bidirectional tunnel to that local mobility anchor) and with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6 packet carried as a payload of an IPv6 packet). Considerations from Section 5.6.1 of [RFC5213] MUST be applied for managing the dynamically created bidirectional tunnel. However, when using IPv4 transport, the encapsulation mode MUST be set to the negotiated encapsulation mode, as specified in Section 4 of this document. 🚇✨
The mobile access gateway MUST set up the route for forwarding the IPv4 packets received from the mobile node (using its IPv4 home address) through the bidirectional tunnel set up for that mobile node. 🛣️
The default router address MUST be obtained from the IPv4 Default-Router Address option present in the received Proxy Binding Acknowledgement message. The mobile access gateway SHOULD configure this address on its interface and respond to any Address Resolution Protocol (ARP) requests sent by the mobile node to resolve the hardware address of the default router. However, since the link between the mobile access gateway and the mobile node is a point-to-point link, implementations will be able receive any packets sent to the default router address without having to explicitly configure the default router address on its interface. The mobile access gateway MAY also use the default router address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MUST also use this address in the DHCP Router option [RFC2132] in the DHCP messages. 🧚
If there is an IPv4 DHCP Support Mode option (Section 3.3.4) present in the received Proxy Binding Acknowledgement message and if the (S) flag in the option is set to a value of (1), then the mobile access gateway MUST function as a DHCP server for the mobile node. If either the (S) flag in the option is set to a value of (0), or if the option is not present in the request, then the mobile access gateway MUST function as a DHCP Relay for the mobile node. 🫶

3.2.3.3. Binding Re-Registration and De-Registrations 🔁

when the mobile access gateway sends a Proxy Binding Update either to extend the lifetime of a mobility session or to de-register it, the respective considerations from [RFC5213] MUST be applied. Furthermore, the following additional considerations MUST also be applied. 📝

If there is an IPv4 home address assigned to the mobility session, then there MUST be exactly one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address and the prefix length fields in the option MUST be set to that specific address and its corresponding subnet-mask length. 🏠
If there was no IPv4 home address requested in the initial Proxy Binding Update message, but it is determined that the IPv4 home address MUST be requested subsequently, then there MUST be exactly one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address in the option MUST be set to either ALL_ZERO or to a specific address that is being requested. 🙋‍♀️
For performing selective de-registration of IPv4 home address but still retaining the mobility session with all the IPv6 home network prefixes, the Proxy Binding Update message with the lifetime value of (0) MUST NOT include any IPv6 Home Network Prefix options [RFC5213]. It MUST include exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the IPv4 home address that is being de-registered. Similarly, for selective de-registration of all the IPv6 home network prefixes, the Proxy Binding Update message MUST NOT include the IPv4 Home address option, it MUST include a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to that respective prefix value. 🪄
The Home Network Prefix option(s) [RFC5213] MUST NOT be present if the same option(s) was not present in the initial Proxy Binding Update message. Otherwise, considerations from [RFC5213] with respect to this option MUST be applied. 🌈
If at any point the mobile access gateway fails to extend the binding lifetime with the local mobility anchor for the mobile node's IPv4 address, it MUST remove any forwarding state set up for the mobile node's IPv4 home address. 🚫

3.2.4. Routing Considerations for the Mobile Access Gateway 🗺️

On receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node. 📦
On receiving a packet from a mobile node connected to its access link, the packet MUST be forwarded to the local mobility anchor through the bidirectional tunnel established with the local mobility anchor. However, when the EnableMAGLocalRouting flag is set, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect to local routing. 🏃‍♀️
When forwarding the packet through the bidirectional tunnel, the encapsulation considerations as specified in Section 3.1.3 MUST be applied (except that the source and destination addresses fields in the outer encapsulation header are reversed). However, before forwarding the packet, the mobile access gateway MUST ensure the source address in the received packet is the address allocated for that mobile node and that there is an active binding on the local mobility anchor for that mobile node. 🔍
The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to reply to ARP Requests that it receives from the mobile node seeking address resolutions for the destinations on the mobile node's home subnet. When receiving an ARP Request, the mobile access gateway SHOULD examine the target IP address of the Request, and if this IP address matches the mobile node's IPv4 home subnet, it SHOULD transmit a Proxy ARP Reply. However, on certain types of links, the mobile node does not use ARP for address resolutions, instead it forwards all the packets to the mobile access gateway. On such types of links, the mobile access gateway is not required to support the Proxy ARP function. At the same time, implementations not supporting the Proxy ARP function on links where the mobile node uses ARP for seeking address resolutions for the destinations on the mobile node's home subnet will result in communication failure. 🙃

3.3. Mobility Options and Status Codes 🎀

to support the IPv4 home address mobility feature, this specification defines the following new options and status codes. 💜

3.3.1. IPv4 Home Address Request Option 🌷

a new option, the IPv4 Home Address Request option, is defined for use with the Proxy Binding Update message sent by the mobile access gateway to the local mobility anchor. This option is used to request IPv4 home address assignment for the mobile node. 📮

The IPv4 Home Address Request option has an alignment requirement of 4n. Its format is as follows: 📐

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |Prefix-len |      Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 home address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: IPv4 Home Address Request Option

Type: 36 🔢
Length: An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6). 📏
Prefix-len: This 6-bit unsigned integer indicating the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option. 🧮
Reserved: This 10-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver. 🤫
IPv4 home address: This 4-byte field containing the IPv4 home address that is being requested. The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation. 🏡

3.3.2. IPv4 Home Address Reply Option 🎀

okay bestie, this one is the reply that the local mobility anchor sends back to the mobile access gateway inside the Proxy Binding Acknowledgement 🦋 it's how the LMA hands over the mobile node's assigned IPv4 home address ✨ the option has an alignment requirement of 4n, so keep that in mind when you're lining up the bytes 💅

    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     |   Status      |Pref-len   |Res|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv4 home address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: IPv4 Home Address Reply Option

Type 💖 the value is 37 ✨

Length 🌸 an 8-bit unsigned integer giving the length of the option in octets, not counting the Type and Length fields. This field MUST be set to (6) 🫶

Status 🔥 this tells you whether the IPv4 home address assignment worked. Values from 0 to 127 mean success, and 128 to 255 mean failure 😭 these are the Status values allocated by this document:

0 Success

128 Failure, reason unspecified

129 Administratively prohibited

130 Incorrect IPv4 home address

131 Invalid IPv4 address

132 Dynamic IPv4 home address assignment not available

Prefix-len 🧚 this 6-bit unsigned integer carries the prefix length of the mobile node's IPv4 home network that goes with the IPv4 home address in the option 💜

Reserved (Res) 🙈 this 2-bit field isn't used yet. The sender MUST initialize it to (0), and the receiver MUST ignore it 🍓

IPv4 home address 👑 this 4-byte field carries the IPv4 home address that was assigned to the mobile node ⭐

3.3.3. IPv4 Default-Router Address Option 🌈

another option the LMA sends to the MAG in the Proxy Binding Acknowledgement 💅 this one passes along the mobile node's IPv4 default router address ✨ it also has an alignment requirement of 4n, so same vibes as before 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |         Reserved (R)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IPv4 Default-Router Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: IPv4 Default-Router Address Option

Type 🍓 the value is 38 💖

Length 🌸 an 8-bit unsigned integer giving the option length in octets, not counting the Type and Length fields. This field MUST be set to (6) 🫶

Reserved (R) 🎀 this 16-bit field isn't used yet. The sender MUST initialize it to (0), and the receiver MUST ignore it 🙈

IPv4 Default-Router Address 🔥 a 4-byte field holding the mobile node's default router address 👑

3.3.4. IPv4 DHCP Support Mode Option 🧚

this option is also sent by the LMA in the Proxy Binding Acknowledgement to the MAG 🦋 its whole job is to tell the MAG whether it should act as a DHCP Server or a DHCP Relay for the attached mobile node 💜 no alignment requirement on this one, so it's pretty chill ✨

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |    Reserved (R)             |S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 6: IPv4 DHCP Support Mode Option

Type 💅 the value is 39 💖

Length 🌸 an 8-bit unsigned integer giving the option length in octets, not counting the Type and Length fields. This field MUST be set to 2 🫶

Reserved (R) 🙈 this 15-bit field isn't used yet. The sender MUST initialize it to (0), and the receiver MUST ignore it 🍓

DHCP Support Mode (S) ⭐ this 1-bit flag picks the role. A value of (0) means the MAG should work as a DHCP Relay, and a value of (1) means it should work as a DHCP Server 🔥

3.3.5. Status Codes 🌸

this document defines some new Status values for the Proxy Binding Acknowledgement message 💜 they come from the same numbering space defined in Section 6.1.8 of [RFC3775] ✨

NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170: the mobile node isn't authorized for IPv4 mobility service 🙈
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171: the mobile node isn't authorized for the IPv4 home address it asked for 😭
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172: the mobile node isn't authorized for IPv6 mobility service 💀
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173: multiple IPv4 home address assignments aren't supported 🫶

3.4. Supporting DHCP-Based Address Configuration 🧚

okay this section is all about how DHCP-based address configuration can work for a mobile node inside a Proxy Mobile IPv6 domain 🦋 it covers how the protocol operates, which DHCP server setups are supported, and how the DHCP agents and the mobility entities talk to each other in each setup 💖

this spec supports two DHCP deployment configurations 🌈

DHCP relay agent co-located with the mobile access gateway. 🎀
DHCP server co-located in the mobile access gateway. 👑

here are the configuration requirements 💅

The DHCP server or the DHCP relay agent configured on the mobile access gateway is required to have an IPv4 address for exchanging the DHCP messages with the mobile node. This address is the mobile node's default router address provided by the local mobility anchor. Optionally, all the DHCP servers co-located with the mobile access gateways in the Proxy Mobile IPv6 domain can be configured with a fixed IPv4 address. This fixed address can be an IPv4 private address [RFC1918] that can be used for the DHCP protocol communication on any of the access links. This address will be used as the server identifier in the DHCP messages. ✨
A DHCP server identifies a DHCP interface from the contents of the DHCP "Client-identifier" option [RFC2132], if present, or from the client hardware address (chaddr), as specified in [RFC2131]. Note that the name "Client-identifier" is a misnomer, because it actually identifies an interface and not the client 🙈 the DHCP server uses this identity to figure out which interface the address is assigned to. A mobile node in a Proxy Mobile IPv6 domain can attach to the network through multiple interfaces and get address configuration for each one. It can also hand off between its interfaces 🔥 here are the things to keep in mind about the identification the DHCP server sees:
- If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple physical interfaces, the DHCP server will uniquely identify each of those interfaces and will perform address assignment. The DHCP server will identify the interface as specified in RFC 2131. The mobile node SHOULD generate and use the "Client-identifier" for each physical interface according to [RFC4361]. Any time the mobile node performs a handoff of a physical interface to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented identifier. The presented identifier (either the "Client-identifier" or the hardware address) will remain as the primary key for each binding, just as how they are unique in a Binding Cache entry. 💖
- If the mobile node is capable of performing a handoff between interfaces, as per [RFC5213], a "Client-identifier" value MUST be used for the attachment point that is not tied to any of the physical interfaces. The identifier MUST be generated according to [RFC4361], which guarantees that the identifier is stable and unique across all "Client-identifier" values in use in the Proxy Mobile IPv6 domain. 🌸
All the DHCP servers co-located with the mobile access gateways in a Proxy Mobile IPv6 domain can be configured with the same set of DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure the mobile node receives the same configuration values on any of the access links in that Proxy Mobile IPv6 domain. 🦋

3.4.1. DHCP Server Co-Located with the Mobile Access Gateway ✨

Okay so this part walks through how home address assignment goes down when the DHCP server is literally chilling on the same box as the mobile access gateway 🏠💖

     MN   MAG(DHCP-S)  LMA
      |------>|        |    1. DHCPDISCOVER
      |       |------->|    2. Proxy Binding Update
      |       |<-------|    3. Proxy Binding Acknowledgement (IPv4 HoA)
      |       |========|    4. Tunnel/Route Setup
      |<------|        |    5. DHCPOFFER  (IPv4 HoA)
      |------>|        |    6. DHCPREQUEST (IPv4 HoA)
      |<------|        |    7. DHCPACK
      |       |        |

Figure 7: Overview of DHCP Server Located at Mobile Access Gateway 🦋

It is possible that the mobile access gateway may have already completed the Proxy Mobile IPv6 signaling with the local mobility anchor to request both IPv6 home network prefix(es) and IPv4 home address assignment prior to Step 1. In such an event, the Proxy Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant. 🧚
It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling prior to Step 1, but only for requesting IPv6 home network prefix(es), and it may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node as shown above. 💅
The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node. 🌸

Initial IPv4 Home Address Assignment:

To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor. 🔥
After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the DHCP server on the mobile access gateway will send a DHCPOFFER message [RFC2131] to the mobile node. The offered address will be the mobile node's IPv4 home address, assigned by the local mobility anchor. The DHCPOFFER message will also have the Subnet Mask option [RFC2132] and Router option [RFC2132], with the values in those options set to the mobile node's IPv4 home subnet mask and default router address, respectively. Additionally, the Server Identifier option will be included and with the value in the option set to the default router address. 🎀
If the mobile node sends the DHCPREQUEST message, the DHCP server will send DHCPACK message, as per [RFC2131]. ✨

IPv4 Home Address Renewal with the DHCP Server (No Handoff):

Any time the mobile node goes into the DHCP RENEWING state [RFC2131], it simply unicasts the DHCPREQUEST message including the assigned IPv4 home address in the 'Requested IP Address' option. The DHCPREQUEST is sent to the address specified in the Server Identifier option of the previously received DHCPOFFER and DHCPACK messages. 🫶
The DHCP server will send a DHCPACK to the mobile node to acknowledge the assignment of the committed IPv4 address. 💖

IPv4 Home Address Renewal with the DHCP Server (after Handoff):

When the mobile node goes into the DHCP RENEWING state [RFC2131], it directly unicasts the DHCPREQUEST message to the DHCP server that currently provided the DHCP lease. However, if the mobile node changed its point of attachment and is attached to a new mobile access gateway, it is required that the mobile node update the DHCP server address and use the address of the DHCP server that is co-located with the new mobile access gateway. The following approach can be adopted to ensure the mobile node uses the DHCP server on the attached link. 🌈

     MN   oMAG(DHCP-S) nMAG(DHCP-S)
      |       :        |
    RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
    BOUND<-------------|    2. DHCPACK (IPv4 HoA) or DHCPNACK
      |       :        |
    *  The use of a fixed DHCP server address on all DHCP servers

Figure 8: Address Renewal with the DHCP Server 👑

The use of a stable address, either the IPv4 default router address of the mobile node or a fixed IPv4 address common in that Proxy Mobile IPv6 domain, as the DHCP Server Identifier will ensure the DHCPREQUEST message sent by the mobile node to renew the address will be received by the new mobile access gateway on the attached link. 🍓
The mobile access gateway after completing the Proxy Mobile IPv6 signaling and upon acquiring the IPv4 home address of the mobile node will return the address in the DHCPACK message. However, if the mobile access gateway is unable to complete the Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4 address as requested by the mobile node, it will send a DHCPNACK message [RFC2131] to the mobile node, as shown in Figure 8. 😭

3.4.2. DHCP Relay Agent Co-Located with the Mobile Access Gateway 🧚‍♀️

A DHCP relay agent is co-located with each mobile access gateway. A DHCP server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is co-located with the local mobility anchor). Figure 9 shows the sequence of IPv4 home address assignment using DHCP Relay. 🌸

    MN   MAG(DHCP-R) LMA   DHCP-S
     |       |------->|      | 1. Proxy Binding Update *
     |       |<-------|      | 2. Proxy Binding Acknowledgement (IPv4 HoA)
     |       |========|      | 3. Tunnel/Route Setup*
     |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
     |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
     |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
     |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
     |       |               |

Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway 💜

The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP address configuration (starting at Step 4) may start in any order. However, the DHCPOFFER (Step 5) and the immediate steps following it will occur in the specified order and only after the Tunnel/Route Setup (Step 3). 🦋
It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling with the local mobility anchor only to request IPv6 home network prefix(es) and may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node (after Step 4). 🙈
The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node. 🫶

Initial IPv4 Home Address Assignment:

To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor. 🔥
After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will enable forwarding for all the DHCP messages between the mobile node and the DHCP server. 💅
The DHCP relay agent on the mobile access gateway will add the DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER message. The assigned IPv4 home address will be included in the Agent Remote ID Sub-option of the DHCP Relay Agent Information option. This sub-option is used as a hint for requesting the DHCP server to allocate that specific IPv4 address. 🎀
On receiving a DHCPOFFER message from the DHCP server, the mobile access gateway will ensure the assigned address is currently assigned by the local mobility anchor to that mobile node. If this address is different from what is assigned to the mobile node, then the mobile access gateway will drop the DHCPOFFER message and an administrative error message will be logged. 😤
When the DHCP messages are sent over administrative boundaries, the operators need to ensure these messages are secured. All the DHCP messages relayed by the mobile access gateway can be tunneled to the local mobility anchor if needed. Alternatively, if the network in the Proxy Mobile IPv6 domain is secure enough, the mobile access gateway can just relay the DHCP messages to the server. To achieve this, all the mobile access gateways need to have a route towards the DHCP server. 🔐

IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)

When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it directly unicasts DHCPREQUEST messages to the DHCP server. The DHCP relay agent may not detect any changes in the DHCP state. For example, if the mobile node releases the IPv4 address, the relay agent would not be aware of it. The following describes additional mechanisms for the mobile access gateway to detect any changes in the DHCP state. 👀
- The DHCP relay agent can intercept all IPv4 DHCP packets destined to the set of addresses used within the Proxy Mobile IPv6 domain as DHCP addresses. Since the link between a mobile node and a mobile access gateway is the point-to-point link, the mobile access gateway will be in path for all the messages. 🛣️
- The DHCP relay agent can use the DHCP Server Identifier Override Sub-option [RFC5107] to be in path for all the DHCP message flows. The DHCP client uses the DHCP server address that is overridden by the DHCP relay agent address as a destination address of DHCPREQUEST. The DHCP Server Identifier Override Sub-option is recommended only when the fixed DHCP relay address is configured on all the mobile access gateways. Otherwise, the DHCP relay agent address is changed when the mobile node changes the attached mobile access gateway. 🧠
However, if the DHCP server is co-located with the local mobility anchor, then the DHCP relay agent is not required to intercept the unicast DHCP messages between the mobile node and the DHCP server. This is because the local mobility anchor will ensure that the DHCP state is consistent with the Proxy Mobile IPv6 binding that exists for the IPv4 address. 🌟
Once the mobile access gateway intercepts the DHCP message from the mobile node to the DHCP server, it can verify if the mobile node is negotiating the same IPv4 address that the local mobility anchor allocated for that mobile node. If the address in the DHCPREQUEST message does not match with the IPv4 address allocated for the mobile node, then the mobile access gateway SHOULD drop the DHCP message and an administrative error message can be logged. 🚫
Any time the mobile access gateway detects that the mobile node has released its IPv4 address, it can send a Proxy Binding Update to the local mobility anchor and de-register the IPv4 mobility session. 🌈

3.4.3. Common DHCP Considerations 🎀

okay so this bit is the stuff that's the same no matter which of the two DHCP setups from Sections 3.4.1 and 3.4.2 you're running. bestie, pay attention 💅

when a mobile node sends a DHCPDISCOVER message [RFC2131], the DHCP server or the relay agent co-located with the mobile access gateway will trigger the mobile access gateway to finish the Proxy Mobile IPv6 signaling 🦋 this interaction is required between these two protocols. once the mobile access gateway gets that trigger, it checks whether the local mobility anchor already gave this mobile node an IPv4 home address. if there's no IPv4 home address assigned to that mobile node, the mobile access gateway finishes the Proxy Mobile IPv6 signaling with the local mobility anchor by sending a Proxy Binding Update message 🌸
the mobile node has to be identified by the MN-Identifier, as specified in Section 6.6 of [RFC5213] 🧚 that identity should be attached to the DHCP messages the mobile node sends.
the mobile access gateway drops all the DHCPDISCOVER messages until it finishes the Proxy Mobile IPv6 signaling. if the mobile access gateway can't finish that signaling, or if the local mobility anchor doesn't assign an IPv4 address to the mobile node, the mobile access gateway MUST NOT enable IPv4 home address mobility support for the mobile node on that access link 🙈 this one is serious, no cap.
the trigger for starting Proxy Mobile IPv6 signaling can also show up as part of a context transfer from the previous mobile access gateway, or it can come from other network elements in the radio network. those details are outside the scope of this document ✨
the DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Subnet Mask option [RFC2132] and the Router option [RFC2132]. the values in those two options MUST be set to the mobile node's IPv4 home subnet mask and its default router address, respectively 💖
the DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Interface MTU option [RFC2132]. the DHCP servers in the Proxy Mobile IPv6 domain MUST be configured to include the Interface MTU option. the MTU value SHOULD reflect the tunnel MTU for the bidirectional tunnel between the mobile access gateway and the local mobility anchor 🌈
the DHCP lease length given for the mobile node's IPv4 home address may be different from the binding lifetime at the local mobility anchor for that mobile node's session. it's not possible to keep these lifetimes synchronized, so it's not required that the configured lifetimes be the same in both DHCP and Proxy Mobile IPv6 🫶
when the mobile node hands off from one mobile access gateway to another, the mobile access gateway on the new link will start the Proxy Mobile IPv6 signaling with the local mobility anchor. once that signaling is finished, the mobile access gateway has the right IPv4 address state that the local mobility anchor allocated for the mobile node, and it can use that to support DHCP-based address configuration on that link 🧚‍♀️
any time the mobile node detects a link change event, whether from a handoff or from other reasons like the link layer being re-established, here's what the mobile node needs to consider for DHCP:
- if the mobile node is DNAv4-capable (Detecting Network Attachment version 4) [RFC4436] and it runs the DNAv4 procedures after getting a link change event, it will always detect the same default router on any of the access links in that Proxy Mobile IPv6 domain. that's because the mobile access gateway configures a fixed link-layer address on all the access links, as per the base Proxy Mobile IPv6 specification [RFC5213]. the mobile node won't do any DHCP operation specifically because of this event 🌸
- if the mobile node is not DNAv4-capable [RFC4436], then after getting the link change event it will enter INIT-REBOOT state [RFC2131] and send a DHCPREQUEST message as specified in Section 3.7 of [RFC2131]. the mobile node will get the same address configuration as before, because the link change doesn't cause any change at the network layer 👑
the mobile node can release its IPv4 home address at any time by sending the DHCPRELEASE message [RFC2131]. when the mobile access gateway detects a DHCPRELEASE message from the mobile node, it should treat that as a trigger for de-registering the mobile node's IPv4 home address. it applies the considerations in Section 3.2.3.3 for carrying out the de-registration procedure. however, this operation MUST NOT release any IPv6 home network prefix(es) assigned to the mobile node 😭

4. IPv4 Transport Support 🌍

okay this next part is where things get a little spicy 🔥 so the Proxy Mobile IPv6 spec [RFC5213] says the signaling messages between the local mobility anchor and the mobile access gateway have to go over an IPv6 transport. but sometimes those two are separated by an IPv4 network, which is a whole vibe 😩

the normal Proxy Mobile IPv6 spec [RFC5213] can run over an IPv4 transport without any changes, using a transition technology that lets IPv6 hosts talk across IPv4 networks. for example, the mobile access gateway and the local mobility anchor could have a simple configured IPv6-over-IPv4 tunnel. automatic tunneling mechanisms could also be used instead of configured tunnels. as far as Proxy Mobile IPv6 is concerned, those tunnels look just like any other application traffic running over IPv6 💅

but here's the catch: treating Proxy Mobile IPv6 like any other IPv6 traffic means an extra layer of encapsulation on the mobile node's tunneled data traffic, which adds 40 octets of overhead to every packet. ngl that's a lot 💀

the extensions in this section let the mobile access gateway and the local mobility anchor talk over an IPv4 network without that overhead ✨

            IPv4-Proxy-CoA                      IPv4-LMAA
                   |         + - - - - - - +        |
   +--+          +---+      /               \     +---+          +--+
   |MN|----------|MAG|=====   IPv4  Network  =====|LMA|----------|CN|
   +--+          +---+      \               /     +---+          +--+
                             + - - - - - - +

Figure 10: IPv4 Transport Network 🦋

when the local mobility anchor and the mobile access gateway are configured and reachable using only IPv4 addresses, the mobile access gateway serving a mobile node can send the signaling messages over IPv4 transport and register its IPv4 address as the care-of address in the mobile node's Binding Cache entry. an IPv4 tunnel (with any of the supported encapsulation modes) can carry the mobile node's data traffic. here are the key things to know about this feature 🌸

the local mobility anchor and the mobile access gateway are both configured and reachable using an IPv4 address of the same scope.
the IPv4 addresses used can be private IPv4 addresses, but it's assumed there's no NAT between the local mobility anchor and the mobile access gateway. it is possible to use UDP encapsulation if other types of middleboxes are present 🧚
the Mobility Header [RFC3775] is carried inside an IPv4 packet with a UDP header (IPv4-UDP-MH), using a UDP port number for Proxy Mobile IPv6 signaling over IPv4 ✨
the mobile node can be an IPv6, IPv4, or dual IPv4/IPv6 node. the IPv4 transport support in this section doesn't care what type of address mobility is enabled for that mobile node 👑
the mobile node's data traffic gets tunneled between the local mobility anchor and the mobile access gateway. there are several encapsulation modes available:
- IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet). if payload protection using IPsec is enabled for the tunneled traffic, the Encapsulating Security Payload (ESP) header follows the outer tunnel header 🔒
- IPv4-UDP (payload packet carried in an IPv4 packet with a UDP header, using a UDP port number for Proxy Mobile IPv6 data; this is a different port than the one used for signaling). if payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3 🌈
- IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP and TLV header) and IPv4-GRE (payload packet carried in an IPv4 packet with GRE header). refer to [GREKEY] 🍓 if payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3.

4.1. Local Mobility Anchor Considerations 🧚‍♀️

4.1.1. Extensions to Binding Cache Entry 💜

to support this feature, the conceptual Binding Cache entry data structure that the local mobility anchor maintains [RFC5213] MUST be extended with the following extra parameters. just so you know, all of these parameters are specified in [RFC5555] and are also required here in this usage context. they're only presented here for completeness 🫶

the IPv4 Proxy Care-of Address configured on the mobile access gateway that sent the Proxy Binding Update message. the address MUST be the same as the source address of the received IPv4 packet that contains the Proxy Binding Update message. however, if the received Proxy Binding Update message isn't sent as an IPv4 packet (for example, when using IPv6 transport), this field in the Binding Cache entry MUST be set to the ALL_ZERO value 😭

4.1.2. Extensions to Mobile Node's Policy Profile 🎀

to support the IPv4 Transport Support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields. these are mandatory fields of the policy profile required for supporting this feature 💖

the IPv4 address of the local mobility anchor (IPv4-LMAA).

4.1.3. Signaling Considerations 🌸

this section gives the rules for processing the Proxy Mobile IPv6 signaling messages received over IPv4 transport ✨

4.1.3.1. Processing Proxy Binding Updates 💅✨

okay so, if the Proxy Binding Update message is protected with IPsec ESP, IPsec processing happens first, before the packet gets handed over to Proxy Mobile IPv6 🔐
all the considerations from Section 5.3.1 of [RFC5213] apply to the encapsulated Proxy Binding Update message EXCEPT Step 1 (the IPsec one, since we already handled it above) 🙈 and the Checksum field in the Mobility Header MUST be ignored, bestie 💀
once the local mobility anchor accepts the request, it MUST set up an IPv4 bidirectional tunnel to the mobile access gateway 🚇 the tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. the encapsulation mode MUST be figured out with these rules:
- if the (F) flag in the received Proxy Binding Update message is set to (1), but the configuration flag AcceptForcedIPv4UDPEncapsulationRequest is set to (0), the local mobility anchor MUST reject the request with the Status field value set to 129 (Administratively prohibited) 🚫
- if the (T) flag is set to (1), or a GRE Key option is included, see [GREKEY] 🗝️
- if the (F) flag in the received Proxy Binding Update message is set to (1), then the encapsulation mode MUST be set to IPv4-UDP. otherwise, it MUST be set to IPv4 🎀
the local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field value set to (0) (Proxy Binding Update accepted) 🥰 and the message MUST be constructed as specified in Section 4.1.3.2.

4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 🧁

When the local mobility anchor sends the Proxy Binding Acknowledgement message to the mobile access gateway, it MUST construct the message as specified in Section 5.3.6 of [RFC5213]. BUT, if the Proxy Binding Update message came in over IPv4, the following extra considerations MUST be applied, so pay attention 👀

the IPv6 Header gets removed, and the Mobility Header holding the Proxy Binding Acknowledgement gets encapsulated in UDP (source port 5436, destination port set to the source port of the received Proxy Binding Update message) 📦 the Mobility Header Checksum field MUST be set to zero, and the UDP checksum MUST be used instead ✨
the source address in the IPv4 header of the message MUST be set to the destination IPv4 address of the received request 🎯
if IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3 🔐
Figure 11 shows the format of the Proxy Binding Acknowledgement message sent over IPv4 and protected using ESP 📸

  IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
    ESP header (in transport mode)
      UDP header (sport=5436, dport=5436)
        Mobility Header (PBA)

    Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over
                                  IPv4

4.1.4. Routing Considerations 🗺️

4.1.4.1. Forwarding Considerations 🏃‍♀️

Forwarding Packets to the Mobile Node:

on receiving an IPv4 or an IPv6 packet from a correspondent node whose destination address matches any of the mobile node's IPv4 or IPv6 home addresses, the local mobility anchor MUST forward the packet through the bidirectional tunnel set up for that mobile node 💌
the format of the tunneled packet is shown below. the IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY] 🧾

IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
  [UDP Header (src port=5437, dst port=5437]   /* If UDP encap nego */
    /* IPv6 or IPv4 Payload Packet */
    IPv6 header (src=CN, dst=MN-HOA)
      OR
    IPv4 header (src=CN, dst=IPv4-MN-HoA)

    Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
                           Encapsulation Mode)

Forwarding Packets Sent by the Mobile Node:
- all the reverse tunneled packets (IPv4 and IPv6) that the local mobility anchor receives from the mobile access gateway MUST be routed to the destination in the inner packet header, once the tunnel header is removed (that's the outer IPv4 header plus the UDP and TLV header, if negotiated) 🚀 these routed packets will have the source address field set to the mobile node's home address 🏡

4.1.4.2. ECN and Payload Fragmentation Considerations 🌪️

The ECN considerations in Section 5.6.3 of [RFC5213] apply to the IPv4 transport tunnels too. 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 [RFC4213]. On top of that, they MUST also apply the considerations about tunnel error processing and reporting from that same specification 🧩

4.1.4.3. Bidirectional Tunnel Management 🎛️

The Tunnel Management considerations in Section 5.6.1 of [RFC5213] apply to the IPv4 transport tunnels as well, with just one difference: the encapsulation mode is different 💁‍♀️

4.2. Mobile Access Gateway Considerations 🌷

4.2.1. Extensions to Binding Update List Entry 📝

To support the IPv4 Transport Support feature, the conceptual Binding Update List entry data structure maintained by the mobile access gateway [RFC5213] MUST be extended with the following additional parameters 💖

the IPv4 address of the local mobility anchor. this address can be obtained from the mobile node's policy profile 🪪

4.2.2. Signaling Considerations 📡

When the mobile access gateway sends a Proxy Binding Update message to the local mobility anchor, it MUST construct the message as specified in Section 6.9.1.5 of [RFC5213]. However, if the mobile access gateway is in an IPv4-only access network, the following extra considerations MUST be applied 🌐

the Proxy Binding Update message MUST be sent over IPv4 as described in Section 4.2.2.1 🚀
just as [RFC5213] says, when sending a Proxy Binding Update message to extend the lifetime of an existing mobility session or to de-register it, the Proxy Binding Update message MUST be constructed just like the initial request 🔁

Receiving Proxy Binding Acknowledgement:

if the received Proxy Binding Acknowledgement message is protected with IPsec ESP, IPsec processing happens before the packet is passed to Proxy Mobile IPv6. considerations from Section 4 of [RFC5213] MUST be applied to authenticate and authorize the message 🛡️
all the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied on the encapsulated Proxy Binding Acknowledgement message. the Checksum field in the Mobility Header MUST be ignored 🙈
if the Status field indicates Success, the mobile access gateway MUST set up a bidirectional tunnel to the local mobility anchor 🥳
upon accepting the request, the mobile access gateway MUST set up an IPv4 bidirectional tunnel to the local mobility anchor. the tunnel endpoint addresses are the IPv4-Proxy-CoA and the IPv4-LMAA. the encapsulation mode MUST be determined from these considerations:
- if the (T) flag is set to (1), or the GRE Key option is included, see [GREKEY] 🗝️
- if there is a NAT Detection option [RFC5555] in the received Proxy Binding Acknowledgement message, and the (F) flag is set to (1), the encapsulation mode for the tunnel MUST be set to IPv4-UDP. otherwise, the encapsulation mode MUST be set to IPv4 🎀

4.2.2.1. Constructing the Proxy Binding Update Message 🧱

the IPv6 Header gets removed, and the Mobility Header holding the Proxy Binding Update message gets encapsulated in UDP (with the destination port set to 5436) 📦 the Mobility Header Checksum field MUST be set to zero, and the UDP checksum MUST be used instead ✨
the source address in the IPv4 header MUST be set to the IPv4-Proxy-CoA of the mobile access gateway, and the destination address MUST be set to the local mobility anchor's IPv4-LMAA 🎯
if the configuration variable ForceIPv4UDPEncapsulationSupport is set to (1), then the (F) flag in the Proxy Binding Update message MUST be set to (1) 🏷️
if IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3 🔐
Figure 13 shows the format of the Proxy Binding Update message sent over IPv4 and protected using ESP 📸

  IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
    ESP header (in transport mode)
      UDP header (sport=5436, dport=5436)
        Mobility Header (PBU)

      Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4

4.2.2.2. Forwarding Considerations 🏃‍♀️

Forwarding Packets Sent by the Mobile Node:

on receiving an IPv4 or an IPv6 packet from the mobile node to any destination, the mobile access gateway MUST tunnel the packet to the local mobility anchor 🚇 the format of the tunneled packet is shown below. the IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY]. however, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect to the local routing and on the use of the EnableMAGLocalRouting flag 🧭

IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */
  [UDP Header (src port=5437, dst port=5437]   /* If UDP encap nego */
    /* IPv6 or IPv4 Payload Packet */
    IPv6 header (src=MN-HOA, dst=CN)
      OR
    IPv4 header (src=IPv4-MN-HOA, dst=CN)

    Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP
                           Encapsulation Mode)

Forwarding Packets Received from the Bidirectional Tunnel:

on receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node 🎁

4.3. IPsec Considerations 🔐

4.3.1. PBU and PBA 🔒

The following section describes how IPsec is used to protect the signaling messages and data packets between the local mobility anchor and mobile access gateway when using IPv4 transport 💫

Here are the Security Policy Database (SPD) example entries to protect PBU and PBA on the local mobility anchor and mobile access gateway 📋

        MAG SPD-S:
          - IF local_address = IPv4-Proxy-CoA_1 &
               remote_address = IPv4-LMAA_1 & proto = UDP &
               remote_port = 5436
            Then use SA ESP transport mode

        LMA SPD-S:
          - IF local_address = IPv4-LMAA_1 &
               remote_address = IPv4-Proxy-CoA_1 & proto = UDP &
               local_port = 5436
            Then use SA ESP transport mode

4.3.2. Payload Packet 🎀

okay so here are the example SPD entries that protect payload packets on the local mobility anchor and the mobile access gateway 💖 ngl these examples cover ALL payload packets sent to and from mobile nodes 😭 if an operator wants a different security mechanism for each mobile node, they need to make a separate SPD and SA entry for every single one 🫶

           MAG SPD-S:
             - IF interface = tunnel to LMAA_1 &
                  local_address != Proxy-CoA_1 &
                  remote_address != LMAA_1 & proto=any
               Then use SA ESP tunnel mode

           LMA SPD-S:
             - IF interface = tunnel to Proxy-CoA_1 &
                  local_address != LMAA_1 &
                  remote_address != Proxy-CoA_1 & proto=any
               Then use SA ESP tunnel mode

when payload packets get IPsec protection, the ones that match the SPDs get handed off to the IPsec module and wrapped up with tunnel mode ESP 🔐 then those ESP tunnel mode packets get sent straight to the peer mobile access gateway or local mobility anchor 🦋 if IPsec isn't applied to payload packets, they get encapsulated the way shown in Figures 12 and 14 🌸

5. Protocol Configuration Variables 💜

5.1. Local Mobility Anchor - Configuration Variables

the local mobility anchor MUST let system management configure the following variables 🎀 and the configured values for these protocol variables MUST survive server reboots and service restarts 💾 no losing your settings, bestie 😤

AcceptForcedIPv4UDPEncapsulationRequest

This flag tells you whether or not the local mobility anchor should accept an IPv4 UDP encapsulation request for the mobile node's data traffic 🦋 The default value for this flag is (0), which means plain IPv4 encapsulation (without UDP) is used for data traffic ✨

5.2. Mobile Access Gateway - Configuration Variables

the mobile access gateway MUST let system management configure the following variables 💅 and the configured values for these protocol variables MUST survive server reboots and service restarts 🫶

ForceIPv4UDPEncapsulationSupport

This flag tells you whether or not the mobile access gateway should ask the mobile node's local mobility anchor to use IPv4-UDP encapsulation mode for the mobile node's data traffic 🌈 The default value for this flag is (0), which means plain IPv4 encapsulation (without UDP) is used for data traffic 💖

6. IANA Considerations 👑

this document defines four new Mobility Header options 🧚 they're the IPv4 Home Address Request option, the IPv4 Home Address Reply option, the IPv4 Default Router Address option, and the IPv4 DHCP Support Mode option ✨ these are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4, respectively 💅 their Type values come from the same number space as the other mobility options, as defined in [RFC3775] 🎀

the IPv4 Home Address Reply option (Section 3.3.2 of this document) brings in a brand new number space, IPv4 Home Address Reply status codes 😭 this document currently reserves these values, and approval of any new status code values goes through IANA Expert Review 🔥

0 Success
128 Failure, Reason Unspecified
129 Administratively prohibited
130 Incorrect IPv4 home address
131 Invalid IPv4 address
132 Dynamic IPv4 home address assignment not available

the IPv4 DHCP Support Mode option (Section 3.3.4 of this document) introduces another new number space, IPv4 DHCP Support Mode Flags 🌸 this document reserves the value 0x1 for the (S) flag, and approval of flag values goes through IANA Expert Review 🦋 there aren't any plans yet for what the new flag allocations could be, so this document leaves that up to the discretion of the Expert Review 🙈

this document also defines new Status values for the Proxy Binding Acknowledgement message, as described in Section 3.3.5 🍓 these values come from the same number space as the other status codes [RFC3775], and each allocated value is greater than 128 💜

NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170 Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171 Mobile node not authorized for the requesting IPv4 home address.
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172 Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173 Multiple IPv4 home address assignment not supported.

IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6-cntl" and "pmip6-data", respectively 🎀 that's the whole port situation, bestie 💖

7. Security Considerations 🔐

okay this section is SERIOUS 😭 all the security considerations from the base Proxy Mobile IPv6 [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 [RFC5555] specifications apply when you use the extensions in this document 🛡️ on top of that, the following security considerations need to be applied too 💀

this document defines new mobility options for supporting the IPv4 Home Address assignment and IPv4 Transport Support features 🌈 these options are carried in Proxy Binding Update and Proxy Binding Acknowledgement messages 🦋 the required security mechanisms in the base Proxy Mobile IPv6 protocol for protecting these signaling messages are sufficient when those mobility options are carried 🫶

this specification describes using IPv4 transport to exchange signaling messages between the local mobility anchor and the mobile access gateway 🧚 these can be protected using IPsec, as described in Section 4.3 🔥

8. Contributors 🫶

this document reflects discussions and contributions from several people (in alphabetical order) 💖

Kuntal Chowdhury kchowdhury@starentnetworks.com

Vijay Devarapalli vijay.devarapalli@azairenet.com

Pasi Eronen Pasi.Eronen@nokia.com

Sangjin Jeong sjjeong@etri.re.kr

Basavaraj Patil basavaraj.patil@nokia.com

Myungki Shin myungki.shin@gmail.com

9. Acknowledgements 🌸

the IPv4 support for Proxy Mobile IPv6 was first covered in "Proxy Mobile IPv6" (March 2007) ✨ we'd like to thank all the authors of that document and acknowledge that early work 🙌

thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu, and Zu Qiang for their helpful review of this document 💅

also, huge thanks to Spencer Dawkins, Tim Polk, Menachem Dodge, Adrian Farrel, and Pekka Savola for their reviews of this document as part of the IESG review process 👑 and special thanks to Jouni Korohonen for his support in addressing the IPsec issues 💜

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.

[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.

[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.

[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.

10.2. Informative References

[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.

[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.

[GREKEY] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "GRE Key Option for Proxy Mobile IPv6", Work in Progress, May 2009.

Authors' Addresses 🦋

Ryuji Wakikawa
TOYOTA InfoTechnology Center, U.S.A., Inc.
465 Bernardo Avenue
Mountain View, CA  94043
USA

EMail: ryuji@us.toyota-itc.com


Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA  95134
USA

EMail: sgundave@cisco.com

📦 where this page comes from

ietf: rfc5844 2010-05
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms