RFC 2486

The Network Access Identifier 🦋

Okay bestie, this is RFC 2486 🎀, a Standards Track doc from January 1999. It was written by B. Aboba of Microsoft and M. Beadles of WorldCom Advanced Networks. The title block doesn't say it obsoletes or updates any other RFC, so it's standing on its own. 💅

Status of This Memo 💖

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract ✨

So here's the vibe. To make roaming and tunneling services work together better, we need a standard way to identify users. This doc proposes the syntax for the Network Access Identifier (NAI), which is the userID the client sends during PPP authentication. 🧚 It's expected to matter for roaming and for tunneling. "Roaming capability" basically means you can use any one of several Internet service providers (ISPs) while still having a formal, customer-vendor relationship with just one. 💜 Examples where you'd need it include ISP "confederations" and ISP-provided corporate network access support. 🍓

2. Introduction 🫶

There's been a lot of buzz lately about a bunch of features that fall under "roaming capability" for dialup Internet users. The people who care about this include:

• Regional Internet Service Providers (ISPs) operating within a particular state or province, who want to team up with other regional providers to offer dialup service over a wider area.
• National ISPs who want to combine operations with one or more ISPs in another nation, so they can offer more complete dialup service across a group of countries or on a continent.
• Businesses that want to give their employees a complete package of dialup services on a global basis. Those services can include Internet access, plus secure access to corporate intranets through a Virtual Private Network (VPN), enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode. 😭

To make roaming and tunneling work together better, we need a standardized way to identify users. This document proposes the syntax for the Network Access Identifier (NAI). You can find examples of implementations that use the NAI, plus descriptions of what it means, in [1]. 💅

2.1. Terminology 📚

This document uses these terms a lot:

Network Access Identifier The Network Access Identifier (NAI) is the userID the client sends during PPP authentication. In roaming, the NAI's job is to identify the user and also to help route the authentication request. ✨ Heads up: the NAI might not be the same as the user's e-mail address, or the userID sent in an application layer authentication. 🙈

Network Access Server The Network Access Server (NAS) is the device clients dial into to get access to the network. In PPTP terminology it's called the PPTP Access Concentrator (PAC), and in L2TP terminology it's called the L2TP Access Concentrator (LAC). 🔥

Roaming Capability Roaming capability can be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while keeping a formal, customer-vendor relationship with only one. Examples of cases where it might be needed include ISP "confederations" and ISP-provided corporate network access support. 👑

Tunneling Service A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode. One example is secure access to corporate intranets through a Virtual Private Network (VPN). 🦋

2.2. Requirements language 🎀

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be read as described in [9]. Only the capitalised ones are the official requirement words. 💖

2.3. Purpose 🧚

As [1] explains, there are now a bunch of services doing dialup roaming, and the number of ISPs joining roaming consortia is growing fast. 🚀

To offer roaming capability, one of the requirements is being able to figure out the user's home authentication server. For roaming, this is done with the NAI the user sends to the NAS in the initial PPP authentication. 🌸 The NAI is also expected to be used by NASes when they open a new tunnel, so they can work out the tunnel endpoint. 🍓

2.4. Notes for Implementors 💅

As proposed here, the Network Access Identifier takes the form user@realm. ✨ The user part of the NAI follows the BNF in [5], but the realm part is allowed to start with a digit, which the BNF in [4] doesn't allow. 🙈 This change reflects current practice: even though [4] doesn't allow it, FQDNs like 3com.com are commonly used and accepted by current software. 💜

Also, NAS vendors may need to update their devices to support the NAI as described in this document. 🔧 Devices handling NAIs MUST support an NAI length of at least 72 octets. 🔥

3. Formal definition of the NAI 🌈

The NAI grammar is below, written in ABNF as documented in [7]. The username grammar comes from [5], and the realm grammar is an updated version of [4]. 🎀

nai         = username / ( username "@" realm )
username    = dot-string

realm       = realm "." label

label       = let-dig * (ldh-str)

ldh-str     = *( Alpha / Digit / "-" ) let-dig

dot-string  = string / ( dot-string "." string )

string      = char / ( string char )

char        = c / ( "\" x )

let-dig     = Alpha / Digit

Alpha       = %x41-5A / %x61-7A   ; A-Z / a-z

Digit       = %x30-39  ;0-9

c           = < any one of the 128 ASCII characters, but
              not any special or SP >

x           = %x00-7F
              ; all 127 ASCII characters, no exception

SP          = %x20 ; Space character

special     = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
              / "," / ";" / ":" / "@" / %x22  / Ctl

Ctl         = %x00-1F / %x7F
              ; the control characters (ASCII codes 0 through 31
              ; inclusive and 127)

Here are some examples of valid Network Access Identifiers: 💖

fred@3com.com
fred@foo-9.com
fred_smith@big-co.com
fred=?#$&*+-/^smith@bigco.com
fred@bigco.com
nancy@eng.bigu.edu
eng!nancy@bigu.edu
eng%nancy@bigu.edu

And here are some invalid ones, so you know what to avoid: 🙅‍♀️

fred@foo
fred@foo_9.com
@howard.edu
fred@bigco.com@smallco.com
eng:nancy@bigu.edu
eng;nancy@bigu.edu
<nancy>@bigu.edu

9. Full Copyright Statement ✨

Copyright (C) The Internet Society (1999). All Rights Reserved. 💖

Okay so here's the legal bit, and it's actually pretty generous 🫶 You're allowed to copy this document and pass it around to your friends. You can also make derivative works, like explainers, commentary, or tools that help people build the thing, and publish and distribute those too, in whole or in part, with no restrictions 🎀. The one condition is that the copyright notice and this paragraph have to stay on every copy and every derivative work 📜.

But the document itself? You can't change it in any way ❌. That means no deleting the copyright notice and no removing the references to the Internet Society or other Internet organizations. The only exceptions are when you're developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process 🛠️, or when you're translating it into a language other than English 🌍.

The permissions above are perpetual 💜. The Internet Society, its successors, and its assigns will never revoke them 🦋.

Now the disclaimer, and I need you to read this one 👀. The document and all of its information are provided on an "AS IS" basis 🫠. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 💀. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 😭. So basically, they're not promising it'll work for everything, and that's just how it goes 🤷‍♀️✨.