RFC 3846

Mobile IPv4 Extension for Carrying Network Access Identifiers

📅 published June 2004, from ietf

RFC 3846: Mobile IPv4 Extension for Carrying Network Access Identifiers 🎀

okay bestie, let's get into RFC 3846! 💖 It's a Standards Track document from the Network Working Group, dated June 2004. The authors are F. Johansson (ipUnplugged) and T. Johansson (Bytemobile). Nothing in the title block says it obsoletes or updates another RFC, so it stands on its own ✨

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004).

Abstract 🦋

okay so picture this 🥹 a mobile node moves from one foreign network to another, and it has to get re-authenticated. now, if the home network has multiple AAA servers and Home Agents (HAs) running, the Home AAA server might not have enough info to do the re-auth properly. specifically, it might not be able to make sure the same HA keeps getting used 😭

this doc adds a Mobile IP extension that carries the identities of the Home AAA and HA servers as Network Access Identifiers (NAIs). the HA can tell the mobile node its identity (and the Home AAA server's identity too), and then the mobile node passes that along to the local AAA server when it changes its point of attachment. the extension can also show up in other situations where Mobile IP nodes need to share a NAI, so it's super flexible 💅

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Requirements terminology . . . . . . . . . . . . . . . . . . .  2
3.  NAI Carrying Extension . . . . . . . . . . . . . . . . . . . .  3
    3.1.  Processing of the NAI Carrying Extension . . . . . . . .  3
4.  HA Identity subtype  . . . . . . . . . . . . . . . . . . . . .  4
5.  AAAH Identity subtype  . . . . . . . . . . . . . . . . . . . .  4
6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
9.  Normative References . . . . . . . . . . . . . . . . . . . . .  6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8

1. Introduction 🧚

when you build networks you want redundancy, duh 💅 so you might put multiple AAA servers in one domain. when a mobile node registers through a visited network, one of the AAA servers in the home domain handles the authentication. later, the mobile node moves to another visited domain and has to be authenticated again. but because of the redundancy AAA gives you, there's no guarantee the same AAAH server handles it this time 🙈 so the new AAAH might not know which HA the session got assigned to. this doc defines a Mobile IP extension that spreads the info needed to fix that around 🫶

also, the only HA info normally available in the registration request is the IP address from RFC 3344 [5]. and honestly that might not be enough 💀 some AAA setups (like Diameter [6]) use realm based routing, so they need the FQDN identity of the home agent to handle the HA assignment correctly. a reverse DNS lookup only tells you the Mobile IP interface name for that HA IP address, and that might or might not match the home agent FQDN one-to-one. so the HA also includes its own identity in the registration reply 🍓 the MIP v4 extension in this doc has a subtype for exactly that. the mobile node can then include the HA identity in later registration requests when it changes its point of attachment ✨

2. Requirements terminology 💜

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 BCP 14, RFC 2119 [1].

the Mobile IP terminology from RFC 3344 [5] is used here too. plus, these terms show up:

  • AAAH: one of several possible AAA Servers in the Home Network
  • FQDN: Fully Qualified Domain Name
  • Identity: the identity of a node is equal to its FQDN
  • NAI: Network Access Identifier [2]

3. NAI Carrying Extension 🦋

this section defines the NAI Carrying Extension. it can be used in Mobile IP Registration Request and Reply messages, and also in Mobile IP Agent Advertisements [5]. any node that wants to send identity info as a NAI [4] can use it. the doc also defines some subtype numbers that identify the specific kind of NAI carried in Sections 4 and 5. other docs are expected to define other NAI types in the future 🔥

     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      |   Sub-Type    |    NAI ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's the breakdown 👑

  • Type: 136 (skippable) [5].
  • Length: an 8-bit unsigned integer. it's the length of the extension in octets, not counting the extension Type and Length fields. this field MUST be set to 1 plus the total length of the NAI field.
  • Sub-Type: describes the particular type of NAI carried in the NAI field.
  • NAI: contains the NAI [2] in a string format.

3.1. Processing of the NAI Carrying Extension 🌸

when a mobile node or home agent adds a NAI Carrying Extension to a registration message, the extension MUST appear before any authentication extensions.

if the foreign agent adds a NAI Carrying Extension to a registration message, the extension MUST appear before any authentication extensions the FA added.

if an HA appended a NAI Carrying Extension to a Registration Reply to an MN, and it doesn't get the NAI extension in later Registration Request messages from that MN, the HA can assume the MN doesn't understand this extension. in that case, the HA SHOULD NOT keep appending this NAI extension to future Registration Reply messages to that MN 🙈

4. HA Identity subtype 🍓

the HA identity uses subtype 1 of the NAI Carrying Extension. it holds the HA's NAI in the form hostname@realm. together, the hostname and realm make up the full FQDN (hostname.realm) of the HA 💖

a Home Agent using this extension MUST include it in the first Registration Reply sent to a Mobile Node that isn't currently registered. it only needs to show up in later Registration Replies if the same extension was included in Registration Requests received from that same Mobile Node.

a mobile node using this extension MUST, if it gets it in a registration reply, include it in every later registration request when re-authentication is needed. if re-authentication fails, for example because no AAAH can be reached, the Mobile-IP session gets terminated 😭 when a new session starts, the Mobile Node may be given a new HA Identity NAI, and the requirement above applies to that newly received NAI.

if the mobile node needs a specific home agent and has the NAI available, it MUST include this extension in its initial registration request ✨

a foreign agent that receives the Home Agent NAI through this extension in a registration request SHOULD include the Home Agent NAI when it asks the AAA infrastructure to authenticate the Mobile Node, as long as the AAA protocol in use can carry that info 🫶

7. IANA Considerations ✨

okay bestie, this section is all about the paperwork 📋 and who gets to add new stuff to the registries 🧚 it's giving very "who's in charge of the guest list" energy 💅

This document defines one new Mobile IP extension 🎀 and one new Mobile IP extension sub-type numbering space 🌈 that IANA will manage 👑

The extension is Section 3's Mobile IP NAI Carrying Extension 🦋, with type number 136. Its sub-type numbering space already has values 1 and 2 assigned by this document 💖. New sub-type numbers MUST go through Expert Review, and a specification is REQUIRED [3] 🔥. Yes, that MUST is doing a lot of work here 🙈

The content and format of this extension are not specific to AAA NAIs 🌸 so if new NAIs get defined later that don't strictly fall into the AAA NAI category, they MAY still be accommodated in the sub-type numbering space defined here 🫶 main character energy, no notes 💀

The NAI Carrying Extension SHOULD be assigned a type value from BOTH the IANA number space for Mobile IPv4 skippable extensions AND the IANA number space for Mobile IPv4 advertisement extensions 🍓 Ideally, the two numbers should match 🥹✨

8. Acknowledgements 🫶

Shoutout to the original authors of the GNAIE document: Mohamed M Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. Calhoun 💜 The original document got removed from the MIP WG charter because nobody was using the extension 😭 but the original ideas got reused in this document, so they're still living their best life 🌈 Also big thanks to Henrik Levkowetz and Kevin Purser for the valuable feedback and help while writing this 🎀

9. Normative References 📚

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

[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.

[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[4] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.

[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.

[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

10. Authors' Addresses 🧚

Fredrik Johansson ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN

Phone: +46 8 725 5916 EMail: fredrik@ipunplugged.com

Tony Johansson Bytemobile Inc 2029 Stierlin Court Mountain View, CA 94043 USA

Phone: +1 650 862 0523 EMail: tony.johansson@bytemobile.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💅

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🦋

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from