RFC 5454

Dual-Stack Mobile IPv4

📅 published March 2009, from ietf

Dual-Stack Mobile IPv4 🎀

Okay bestie, this is RFC 5454 💖. It came out in March 2009 from the Network Working Group, written by G. Tsirtsis, V. Park (both at Qualcomm) and H. Soliman (Elevate Technologies). It's on the Standards Track, so it's a real protocol spec for the Internet community 🌈. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

Status of This Memo 📜

This is a Standards Track protocol spec for the Internet community, and the authors want discussion and suggestions for making it better 💅. If you want to know where the protocol actually stands, check the current edition of "Internet Official Protocol Standards" (STD 1) 🧚. Distribution is unlimited, so share away 🌸.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the date it was published. Please read those documents carefully, because they explain your rights and restrictions for this doc 🫶. You can find them at http://trustee.ietf.org/license-info.

Abstract 🦋

This spec adds IPv6 extensions to Mobile IPv4 ✨. The extensions let a dual-stack node use both IPv4 and IPv6 home addresses, and let it move between IPv4 and dual-stack network infrastructures 🔥.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Requirements Notation ......................................3
      1.2. Goals ......................................................3
      1.3. Non-Goals ..................................................4
      1.4. Implicit and Explicit Modes ................................4
   2. Extension Formats ...............................................4
      2.1. IPv6 Prefix Request Extension ..............................4
      2.2. IPv6 Prefix Reply Extension ................................5
      2.3. IPv6 Tunneling Mode Extension ..............................7
   3. Mobile IP Registrations .........................................8
      3.1. Registration Request .......................................8
      3.2. Registration Reply .........................................8
      3.3. Home Agent Considerations ..................................9
           3.3.1. IPv6 Reachability ..................................10
           3.3.2. Processing Intercepted IPv6 Packets ................10
           3.3.3. IPv6 Multicast Membership Control ..................12
      3.4. Foreign Agent Considerations ..............................12
      3.5. Mobile Node Considerations ................................12
      3.6. Tunneling Impacts .........................................13
      3.7. IPv6 Prefixes .............................................14
           3.7.1. Dynamic IPv6 Prefix Delegation .....................14
      3.8. Deregistration of IPv6 Prefix .............................15
      3.9. Registration with a Private CoA ...........................15
   4. Security Considerations ........................................15
   5. IANA Considerations ............................................16
   6. Acknowledgements ...............................................16
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17

1. Introduction 🌟

Mobile IPv4 [RFC3344] lets a mobile node with an IPv4 address keep its conversations going while it moves around an IPv4 network 🚗.

The extensions in this doc let a node with both IPv4 and IPv6 addresses [RFC2460] keep talking through any of its addresses while it moves through IPv4 or dual-stack networks 💫.

Basically, this spec separates the Mobile IPv4 signaling from the IP version of the traffic being tunneled 🎀. Mobile IPv4 with these extensions is still a signaling protocol that runs over IPv4, and it can still set up both IPv4 and IPv6 tunnels over IPv4 🦋.

The aim is two-fold 👑:

On one hand, Mobile IPv4 with these extensions becomes a useful transition mechanism. It allows automated but controlled tunneling of IPv6 traffic over IPv4 tunnels 🌈. Dual-stack nodes on dual-stack home networks can now roam to and from legacy IPv4 networks. IPv4 mobile nodes and networks can migrate to IPv6 without changing mobility management, and without upgrading every network node to IPv6 at once 😭.

On the other hand, and more importantly, it lets dual-stack mobile nodes and networks use a single protocol to move both IPv4 and IPv6 stacks around the network topology 💅.

Note that features like Mobile IPv6 [RFC3775] style route optimization won't be possible with this solution 🙈. It still relies on Mobile IPv4 signaling, and Mobile IPv4 doesn't provide route optimization 💀.

1.1. Requirements Notation 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧚.

1.2. Goals 🎯

a. The solution supports registration of IPv6 home prefix(es) in addition to regular IPv4 home address (HoA) registration 💖.

b. The solution supports static and dynamic IPv6 prefix delegation ✨.

1.3. Non-Goals 🙅‍♀️

a. The solution does not provide support for IPv6 care-of address (CoA) registration 🚫.

1.4. Implicit and Explicit Modes 🔀

As defined in Network Mobility (NEMO) [RFC3963], this spec also supports two modes of operation: the implicit mode and the explicit mode 🌸.

In the implicit mode, the mobile node doesn't include any IPv6 prefix request extensions in the registration request. The home agent can use any mechanism (not defined in this document) to figure out which IPv6 prefix(es) the mobile node owns, and to set up forwarding for those prefixes 🕵️‍♀️. In this mode, all traffic to and from the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between the mobile node's IPv4 home address and the IPv4 address of the home agent. That makes it transparent to any foreign agent in the path 🫠. This IPv4 tunnel is set up by mechanisms that are out of scope for this document, on both the mobile node and the home agent when they're in implicit mode 🛠️.

In the explicit mode, IPv6 bindings are signaled explicitly 📣. The mobile node includes one or more IPv6 prefix request extensions in the registration request, and the home agent sends back matching IPv6 prefix reply extensions to accept or reject those IPv6 bindings 🎀.

Also, in explicit mode, the mobile node (when co-located mode of operation is used) can indicate whether IPv6 traffic should be tunneled to the care-of address or the home address of the mobile node 🦋.

The rest of this spec is mainly about the explicit mode 💅.

2. Extension Formats 🧩

The following extensions are defined by this specification ✨.

2.1. IPv6 Prefix Request Extension 🌈

This is a new skippable extension to the Mobile IPv4 registration request message, following the short extension format of [RFC3344] 💜.

It carries a Mobile IPv6 network prefix and its prefix length 🍓.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |   Length      |   Subtype     | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                   Mobile IPv6 Network Prefix                  +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1:  IPv6 Prefix Request Extension

Type 🏷️ 152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension) 🎀

Length 📏 18

Subtype 🔢 1 (IPv6 Prefix Request)

Prefix Length 🔍 A sixteen-byte field containing the Mobile IPv6 Network Prefix. All insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver 🫶.

Mobile IPv6 Network Prefix 🌐 A sixteen-byte field containing the Mobile IPv6 Network Prefix 💖.

2.2. IPv6 Prefix Reply Extension ✨

Okay bestie, so this is a brand new skippable extension 💅 for the Mobile IPv4 registration reply message. It's built on the short extension format from [RFC3344], and it's giving main character energy because it carries a Mobile IPv6 Network Prefix, its prefix length, and a code 🦋

Here's the layout (obsessed with this diagram 😭):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |   Subtype     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |    Reserved   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                   Mobile IPv6 Network Prefix                  +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: IPv6 Prefix Reply Extension 🎀

Type

  • 152 (DSMIPv4 Extension) 🌸

Length

  • 20

Subtype

  • 2 (IPv6 Prefix Reply)

Code

  • A value indicating the result of the registration request with respect to the IPv6 home prefix registration. See below for currently defined Codes.

Prefix Length

  • Indicates the prefix length of the prefix included in the Mobile IPv6 Network Prefix field. A value of 255 indicates that a link-local address is included in the Mobile IPv6 Network Prefix field.

Reserved

  • Set to 0 by the sender, ignored by the receiver.

Mobile IPv6 Network Prefix

  • A sixteen-byte field containing the Mobile IPv6 Network Prefix. All insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver.

These are the values defined for use as a Code value in the extension above 👑

  • 0 registration accepted, IPv6 to be tunneled to HoA
  • 1 registration accepted, IPv6 to be tunneled to CoA
  • 8 registration rejected, reason unspecified
  • 9 registration rejected, administratively prohibited

Note that a registration reply that does not include an IPv6 prefix reply extension, when received in response to a registration request carrying at least one instance of the IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and thus has ignored such extensions in the registration request. 🙈

2.3. IPv6 Tunneling Mode Extension 🧚

Another new skippable extension, this time for the Mobile IPv4 registration request message, also built on the short extension format of [RFC3344] 💜

By including this extension in a registration request, the sender indicates that IPv6 traffic can be tunneled to the mobile node's CoA. Slay 🔥

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |    Subtype    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: IPv6 Tunneling Mode Extension ✨

Type

  • 152 (DSMIPv4 Extension)

Length

  • 2

Subtype

  • 3 (IPv6 Tunneling Mode)

Reserved

  • Set to 0 by the sender, ignored by the receiver.

3. Mobile IP Registrations 🎀

3.1. Registration Request 📝

A mobile node MAY include in a registration request one or more IPv6 prefix request extensions defined in this specification. Totally optional, totally valid 💖

A mobile node MAY also include exactly one IPv6 tunneling mode extension when it uses the co-located care-of address mode of [RFC3344]. Just one, bestie, don't get greedy 😭

When IPv6 prefix and/or IPv6 tunneling mode extensions are used by the mobile IP client, they MUST be placed after the registration request header and before the mobile -- home authentication extension so they MUST be included in the computation of any authentication extension. Placement matters, so get it right 🫶

3.2. Registration Reply 🦋

The mechanism described in this specification depends on skippable extensions. For that reason, a registration reply that does not include an IPv6 prefix reply extension, in response to a registration request including an IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and has ignored the request. Ghosted, but make it technical 💀

If an IPv6 prefix reply extension is included in a registration reply, then the extension indicates the success or failure of the IPv6 prefix registration. The IPv6 prefix reply extension does not affect, in any way, the code value in the registration reply header but it is superseded by it. In other words, if the code field in the registration reply header is set to a reject code, then all IPv6 prefix request extensions are also rejected. If the code field in the registration reply header, however, is set to an accept code, then an IPv6 prefix reply extension with a code field set to a reject code only rejects the binding for the specific IPv6 prefix indicated in the same extension. So the header is the boss, but the extension can still say no to one prefix 😤💅

Note that a rejecting IPv6 prefix reply extension has the same effect as not including such an extension at all, in the sense that, in both cases, the mobile node must act as if the corresponding IPv6 prefix request extension included in the registration request was rejected. Of course, the inclusion of the IPv6 prefix reply extension allows the home agent to indicate why a given IPv6 prefix request extension was rejected. A detailed description of how the mobile node handles different IPv6 prefix reply extension code values and the absence of IPv6 prefix reply extensions is given in Section 3.5. 🌈

3.3. Home Agent Considerations 🏠

The dual-stack home agent defined in this specification is a Mobile IPv4 home agent in that, it MUST operate as defined in MIPv4 [RFC3344]. In addition to that, the following mechanisms are defined in this specification. Basically it's an MIPv4 home agent with extra drip ✨

For each IPv6 prefix request extension included in a valid registration request, a home agent that supports this specification SHOULD include a corresponding IPv6 prefix reply extension in the registration reply message. The home agent MUST NOT include more than one IPv6 prefix reply extension for the same prefix. For each accepted IPv6 prefix, the home agent MUST decide the tunneling mode it is going to use and set the code field of the IPv6 prefix reply extension to the appropriate value. The IPv6 prefix field of each of the IPv6 prefix reply extensions included in the registration reply MUST match the IPv6 prefix field of an IPv6 prefix request extension included in the corresponding registration request message. No duplicates, no mismatches, periodt 💅

When the home agent sends a successful registration reply to the mobile node, with the code field of a corresponding IPv6 prefix reply extension set to one of the "registration accepted" values, the home agent indicates that the IPv6 prefix is registered for the lifetime granted for the binding. It also indicates the tunneling mode used, i.e., tunneling to home address or care-of address, based on the value of the code field used in the IPv6 prefix reply extension. Accepted, registered, and the tunneling mode is spelled out too 🎀

Note that since only IPv6 prefixes (and not addresses) are supported by this specification, there is no need for Duplicate Address Detection. The home agent, however, MUST check that registered prefixes are not overlapping so that all addresses under each registered prefix belong to a single mobile node at any one time. These prefixes MUST NOT appear as on-link to any other node (e.g., via Router Advertisements). No overlaps, no sharing, no on-link drama 🫶

3.3.1. IPv6 Reachability 🌸

For each registered IPv6 prefix, the home agent MUST advertise its reachability as defined in NEMO Section 6.3 of [RFC3963]. Reachability gets advertised, no exceptions 🧚

3.3.2. Processing Intercepted IPv6 Packets 🎀

okay so bestie, a dual-stack home agent that supports the IPv6 extensions in this spec MUST keep track of the IPv6 stuff below, on top of everything already defined in [RFC3344] 💅

  • Registered IPv6 prefix(es) and prefix length(s). ✨
  • Tunneling mode for IPv6 traffic:
    • Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA. 🦋
    • Tunnel to CoA and accept IPv6 tunneled from CoA. 🌸

when IPv6 traffic gets encapsulated over the tunnel between the home agent (HA) and the mobile node's care-of address, the tunneling mechanism SHOULD be the same one negotiated by the Mobile IP header as defined in MIPv4 [RFC3344] 🧚 so if IPinIP encapsulation was negotiated, IPv6 gets tunneled over IPv4 according to [RFC4213]. GRE also lets you tunnel IPv6 packets by setting the Protocol Type [RFC2784] field to the right payload type IANA defined for IPv6 💜 Minimal Encapsulation [RFC2004] is a no-go, because the inner IP header is IPv6 and [RFC2004] doesn't support that 💀

when IPv6 traffic gets encapsulated over the tunnel between the HA and the mobile node's home address, IPv6 is ALWAYS tunneled over IPv4 according to [RFC4213]. The resulting IPv4 packet then gets delivered just like any other IPv4 packet addressed to the IPv4 HoA (using the normal IPv4 tunneling, possibly going via the foreign agent (FA)) 🍓

tunneling mode selection for IPv6 traffic depends on these parameters in a successful registration request:

  1. a registration request arrives with one or more IPv6 prefix request extensions, and NO IPv6 tunneling mode extension 🌈

all IPv6 packets destined to the registered IPv6 prefix(es) MUST be tunneled by the home agent to the mobile node's registered IPv4 home address. The HA first encapsulates the IPv6 packet, addressed to the mobile node's IPv4 home address, and then tunnels that encapsulated packet to the foreign agent. This extra layer of encapsulation is needed so IPv6 routing stays transparent to a foreign agent that doesn't support IPv6 ✨ When the FA receives it, the unicast encapsulated packet gets de-tunneled and delivered to the mobile node like any other packet. The mobile node MUST decapsulate the received IPv4 packet to recover the original IPv6 packet 🫶

on top of that, the home agent MUST be ready to accept reverse-tunneled packets from the mobile node's IPv4 home address that encapsulate IPv6 packets the mobile node sends 👑

  1. a registration request arrives with one or more IPv6 prefix request extensions, AND an IPv6 tunneling mode extension is included 🔥

all IPv6 packets destined to the registered IPv6 prefix(es) SHOULD be tunneled by the home agent to the mobile node's registered care-of address. The HA SHOULD also be ready to accept reverse-tunneled packets from the mobile node's care-of address that encapsulate IPv6 packets that mobile node sends 🙈 The HA MAY ignore the IPv6 tunneling mode extension and act like case (1) above 😭

the home agent MUST check that every inner IPv6 packet received from the mobile node over a tunnel, with either the mobile node's home address or the care-of address as the outer source address, has a source address that falls under the registered IPv6 prefix(es) for that mobile node. If the outer header's source address is not the registered IPv4 care-of address or the registered IPv4 home address, the packet SHOULD be dropped. If the inner header's source address doesn't match any of the registered prefixes, the packet SHOULD be dropped 🙅‍♀️

multicast packets addressed to a group the mobile node has successfully subscribed to MUST be tunneled to the mobile node 🎶

3.3.3. IPv6 Multicast Membership Control 🌟

IPv6 multicast membership control is provided as defined in MIPv6 [RFC3775], Section 10.4.3. The only clarification this spec needs is that all Multicast Listener Discovery (MLD) [RFC2710] or MLDv2 [RFC3810] messages between the mobile node and the home agent MUST be tunneled over an IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address, bypassing the foreign agent 🧜‍♀️ Note that if tunneling to the care-of address was negotiated for other traffic, the rest of the traffic keeps using that tunnel 💖

3.4. Foreign Agent Considerations 🏡

this specification does not affect the operation of the foreign agent. Nothing to see here, bestie 🙆‍♀️

3.5. Mobile Node Considerations 📱

a dual-stack mobile node that supports the extensions in this document MAY use them to register its IPv6 prefix(es) while moving between access routers 🦋

the mobile node MAY include one or more IPv6 prefix request extension(s) in the registration request.

in that case, the mobile node MUST take the following action depending on the extensions included in the registration reply it gets back:

  1. the registration reply does NOT include any IPv6 prefix reply extensions. 🥺

the mobile node MUST assume the home agent does not support the extensions defined in this specification. The mobile node SHOULD keep operating according to MIPv4 [RFC3344] 🌸

  1. the registration reply includes one or more IPv6 prefix reply extensions. ✨

the mobile node MUST match each IPv6 prefix reply extension with one of the IPv6 prefix request extensions that were included earlier in the corresponding registration request message 💅

if a matching IPv6 prefix reply extension is not included for one or more of the IPv6 prefix request extensions in the registration request message, the mobile node MUST assume those IPv6 prefixes are rejected 🚫

for each matching IPv6 prefix reply extension, the mobile node MUST inspect the code field. If the field is set to a rejection code, then that IPv6 prefix registration has been rejected. If the code field is set to an acceptance code, then that IPv6 prefix registration has been accepted 🎀

if the code field is set to "0", the mobile node MUST be ready to send/receive IPv6 packets encapsulated in the bidirectional tunnel between the home agent address and the mobile node's registered IPv4 home address 🫧

if the code field is set to "1", the mobile node MUST act as follows:

  • assuming the co-located care-of address mode is used, the mobile node MUST be ready to send/receive IPv6 packets over the bidirectional tunnel between the home agent address and its co-located care-of address. Otherwise, the mobile node SHOULD act as in the case where the code field is set to "0" 🌷

the mobile node SHOULD include exactly one IPv6 tunneling mode extension if it uses the co-located care-of address model and wants IPv6 packets tunneled to its co-located care-of address 🌈 If the mobile node uses the co-located care-of address model but doesn't include the IPv6 tunneling mode extension, the home agent will tunnel IPv6 traffic to the mobile node's IPv4 home address. The mobile node MUST NOT include an IPv6 tunneling mode extension if it uses the foreign agent care-of address mode of operation 🙅‍♀️ Heads up: if the mobile node does include an IPv6 tunneling mode extension in that case, the HA could tunnel IPv6 packets to the FA. The FA will likely drop them, since it won't have the state needed to process them 😬

3.6. Tunneling Impacts 🚇

when IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can treat the IPv4 tunnel as a single-hop link as defined in [RFC4213]. The two tunnel endpoints, e.g., the mobile node and the home agent, MUST configure link-local IPv6 addresses as defined in Section 3.7 of [RFC4213], and they MUST also follow the neighbor discovery requirements of that same specification, Section 3.8, plus the hop limit requirements of Section 3.3 💫

with respect to the Tunnel MTU, an implementation MUST support the Static Tunnel MTU approach as defined in Section 3.2 of [RFC4213]. Implementing and using the Dynamic Tunnel MTU method defined in that same section of [RFC4213] is OPTIONAL 🍰

to accommodate traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP) information is copied between the inner and outer headers as defined in [RFC3168] and [RFC2983]. It is RECOMMENDED that the full-functionality option defined in Section 9.1.1 of [RFC3168] be used to deal with ECN 🌪️

3.7. IPv6 Prefixes 🌍

an implementation can use any number of mechanisms to allocate IPv6 prefixes to a mobile node. Once one or more IPv6 prefixes are allocated, they can be registered using the extensions and mechanism already described in this specification 🧁

how a home agent decides to accept an IPv6 prefix for a given mobile node is out of scope for this specification. Local configuration or external authorization via an authorization system, e.g., Diameter [RFC3588], or other mechanisms may be used to make that call 🔐

3.7.1. Dynamic IPv6 Prefix Delegation 🪄

a dual-stack mobile node MAY use prefix delegation as defined in DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes. In that case, if the mobile node is not directly attached to its home agent, the mobile node MUST first register its IPv4 home address as per MIPv4 [RFC3344]. Once that's done, the mobile node can generate a link-local IPv6 address as per Section 3.7 of [RFC4213]. The mobile node then sends a registration request to its home agent, including an IPv6 prefix request extension with the prefix length field set to 255 and the Mobile IPv6 Network Prefix field set to the locally generated link-local address. If the registration reply message includes an IPv6 prefix reply extension with the code field set to a success code, the mobile node can use the tunnel to send and receive IPv6 link-local packets. The mobile node can now send DHCPv6 messages according to [RFC3633]. All IPv6 messages at this stage MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address 🛡️

once prefixes are delegated, and assuming explicit mode is used, the mobile node SHOULD send a registration request with the appropriate IPv6 prefix request extensions to the home agent to register the delegated prefixes 💌

3.8. Deregistration of IPv6 Prefix 🧹

okay so the mobile IP registration lifetime sitting in the registration request header is valid for all the bindings that the registration request creates, and that can include bindings for IPv6 prefix(es) 🎀

a registration request with a zero lifetime can be used to remove all bindings from the home agent 💅

a re-registration request with non-zero lifetime can be used to deregister some of the registered IPv6 prefixes, by not including the corresponding IPv6 prefix request extensions in the registration request message 🦋

3.9. Registration with a Private CoA 🌈

if the care-of address is a private address, then Mobile IP NAT Traversal as [RFC3519] MAY be used in combination with the extensions described in this specification ✨ in that case, to transport IPv6 packets, the next header field of the Mobile Tunnel Data message header [RFC3519] MUST be set to the value for IPv6 💖 and note that in that case, the encapsulation field of the UDP Tunnel Request Extension defined in [RFC3519] MUST be set to zero 🫶

4. Security Considerations 🚨

bestie, this part is SERIOUS 😭 so read it carefully!!

this specification operates within the security constraints and requirements of [RFC3344]. it extends the operations defined in [RFC3344] for IPv4 home addresses so they cover home IPv6 prefixes, and it provides the same level of security for both IP address versions 🔥

Home agents MUST perform appropriate checks for reverse-tunneled IPv6 packets, similar to what is defined in [RFC3024] for IPv4 packets. the check defined in [RFC3024] requires that the outer header's source address is set to a registered care-of address for the mobile node, and as such the same check protects against attacks whether the encapsulated (inner) header is IPv4 or IPv6 👑

on top of that, the home agent MUST check that the source address of the inner header is a registered IPv4 home address or IPv6 prefix for this mobile node. if that is not the case, the home agent SHOULD silently discard the packet and log the event as a security exception 🙈

security devices should look for IPv6 packets encapsulated over IPv4, either directly to the mobile node's care-of address or via double encapsulation, first to the mobile node's IPv4 home address and then to the mobile node's care-of address. this one is iconic for catching sneaky packets 🕵️‍♀️

interactions with Mobile IPv4 and IPsec have been covered elsewhere, for instance in [RFC5265] and [RFC5266] 🧚

5. IANA Considerations 📋

a new type number (152) for DSMIPv4 extensions has been registered from the space of numbers for skippable mobility extensions (i.e., 128-255), which is defined for Mobile IPv4 [RFC3344]. this registry is available from http://www.iana.org under "Extensions appearing in Mobile IP control messages" 🍓

a new subtype space for the type number of this extension has been created: "DSMIPv4 Extension subtypes". the subtype values 1, 2, and 3 are defined in this specification, while the rest of the subtypes are reserved and available for allocation based on Expert Review 🌸

finally, a new space for the code field of the IPv6 prefix reply extension has been created: "IPv6 Prefix Reply Extension Codes". values 0, 1, 8, and 9 are defined in this specification. values 2-7 are reserved for accept codes, and values 10-255 are reserved for reject codes 💜

similar to the procedures specified for the Mobile IPv4 [RFC3344] number spaces, future allocations from the two number spaces require Expert Review [RFC5226] 🎀

6. Acknowledgements 🫶

thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann for earlier work on this subject. thanks also to Alex Petrescu for various suggestions. special thanks also to Sri Gundavelli and Kent Leung for their thorough review and suggestions 💖

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
  • [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
  • [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
  • [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

7.2. Informative References

  • [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
  • [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
  • [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
  • [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
  • [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
  • [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
  • [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
  • [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
  • [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.

Authors' Addresses 🦋

  • George Tsirtsis
    • Qualcomm
    • EMail: tsirtsis@googlemail.com
  • Vincent Park
    • Qualcomm
    • Phone: +908-947-7084
    • EMail: vpark@qualcomm.com
  • Hesham Soliman
    • Elevate Technologies
    • Phone: +614-111-410-445
    • EMail: hesham@elevatemobile.com
📦 where this page comes from