The Network Access Identifier Microsoft Corporation
One Microsoft Way Redmond WA 98052 USA +1 425 936 6605 bernarda@microsoft.com
WorldCom Advanced Networks
5000 Britton Rd. Hilliard OH 43026 USA +1 614 723 1941 mbeadles@wcom.net
In order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. It is expected that this will be of interest for support of roaming as well as tunneling. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support.
Review of Roaming Implementations Microsoft Corporation
One Microsoft Way Redmond WA 98052 US +1 206 936 6605 bernarda@microsoft.com
 AimQuest Corporation
1381 McCarthy Boulevard Milpitas CA 95035 US +1 408 273 2730 x2762 juanlu@aimnet.net
 i-Pass Alliance Inc.
650 Castro Street Suite 280 Mountain View CA 94041 US +1 415 968 2200 +1 415 968 2266 jalsop@ipass.com
 Asiainfo
13355 Noel Road #1340 Dallas TX 75240 US +1 214 788 4141 +1 214 788 0729 ding@bjai.asiainfo.com
 Merit Network, Inc.
4251 Plymouth Road Suite C Ann Arbor MI 48105-2785 US +1 313 764 2874 weiwang@merit.edu
 This document reviews the design and functionality of existing roaming implementations. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. Remote Authentication Dial In User Service (RADIUS) Livingston Enterprises
4464 Willow Road Pleasanton California 94588 +1 510 426 0770 cdr@livingston.com
 Livingston Enterprises
4464 Willow Road Pleasanton California 94588 +1 510 426 0770 cdr@livingston.com
 Merit Network, Inc.
4251 Plymouth Road Ann Arbor Michigan 48105-2785 acr@merit.edu
 Daydreamer
Computer Systems Consulting Services 1384 Fontaine Madison Heights Michigan 48071 wsimpson@greendragon.com
 Livingston Enterprises
4464 Willow Road Pleasanton California 94588 steve@livingston.com
 Security authentication remote authentication dial in user service This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. RADIUS Accounting Livingston Enterprises
4464 Willow Road Pleasanton California 94588 +1 510 426 0770 cdr@livingston.com
 Livingston Enterprises
4464 Willow Road Pleasanton California 94588 cdr@livingston.com
 Security Radius accounting authentication remote authentication dial in user service This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. Domain names - implementation and specification USC/ISI
4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511
 Simple Mail Transfer Protocol University of Southern California (USC)/Information Sciences Institute
4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511
 A DNS RR for specifying the location of services (DNS SRV) Troll Tech
Postboks 6133 Etterstad Oslo N-0602 NO +47 22 646966 agulbra@troll.no
 Vixie Enterprises
Star Route 159A Woodside CA 94062 US +1 415 747 0204 paul@vix.com
 This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). Augmented BNF for Syntax Specifications: ABNF Internet Mail Consortium
675 Spruce Dr. Sunnyvale CA 94086 US +1 408 246 8253 +1 408 249 6205 dcrocker@imc.org
 Demon Internet Ltd
Dorking Business Park Dorking Surrey England RH4 1HN UK paulo@turnpike.com
 Security Architecture for the Internet Protocol BBN Corporation
70 Fawcett Street Cambridge MA 02140 USA +1 (617) 873-3988 kent@bbn.com
 @Home Network
425 Broadway Redwood City CA 94063 USA +1 (415) 569-5000 rja@corp.home.net
 Security IP security protocol IPSEC internet protocol version 6 security Key words for use in RFCs to Indicate Requirement Levels Harvard University
1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu
 General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used.