5. AVP Occurrence Tables
The following tables present the AVPs used by NAS applications in NAS messages and specify in which Diameter messages they may or may not be present. Messages and AVPs defined in the Diameter Base protocol [RFC6733] are not described in this document. Note that AVPs that can only be present within a grouped AVP are not represented in this table. The tables use the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message.
0-1 Zero or one instance of the AVP MAY be present in the message. 1 Exactly one instance of the AVP MUST be present in the message.5.1. AA-Request / AA-Answer AVP Table
The table in this section is limited to the Command Codes defined in this specification. +-----------+ | Command | |-----+-----+ Attribute Name | AAR | AAA | ------------------------------|-----+-----+ Acct-Interim-Interval | 0 | 0-1 | ARAP-Challenge-Response | 0 | 0-1 | ARAP-Features | 0 | 0-1 | ARAP-Password | 0-1 | 0 | ARAP-Security | 0-1 | 0-1 | ARAP-Security-Data | 0+ | 0+ | ARAP-Zone-Access | 0 | 0-1 | Auth-Application-Id | 1 | 1 | Auth-Grace-Period | 0-1 | 0-1 | Auth-Request-Type | 1 | 1 | Auth-Session-State | 0-1 | 0-1 | Authorization-Lifetime | 0-1 | 0-1 | ------------------------------|-----+-----+
+-----------+ | Command | |-----+-----+ Attribute Name | AAR | AAA | ------------------------------|-----+-----+ Callback-Id | 0 | 0-1 | Callback-Number | 0-1 | 0-1 | Called-Station-Id | 0-1 | 0 | Calling-Station-Id | 0-1 | 0 | CHAP-Auth | 0-1 | 0 | CHAP-Challenge | 0-1 | 0 | Class | 0 | 0+ | Configuration-Token | 0 | 0+ | Connect-Info | 0+ | 0 | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Error-Message | 0 | 0-1 | Error-Reporting-Host | 0 | 0-1 | Failed-AVP | 0+ | 0+ | Filter-Id | 0 | 0+ | Framed-Appletalk-Link | 0 | 0-1 | Framed-Appletalk-Network | 0 | 0+ | Framed-Appletalk-Zone | 0 | 0-1 | Framed-Compression | 0+ | 0+ | Framed-Interface-Id | 0-1 | 0-1 | Framed-IP-Address | 0-1 | 0-1 | Framed-IP-Netmask | 0-1 | 0-1 | Framed-IPv6-Prefix | 0+ | 0+ | Framed-IPv6-Pool | 0 | 0-1 | Framed-IPv6-Route | 0 | 0+ | Framed-IPX-Network | 0 | 0-1 | Framed-MTU | 0-1 | 0-1 | Framed-Pool | 0 | 0-1 | Framed-Protocol | 0-1 | 0-1 | Framed-Route | 0 | 0+ | Framed-Routing | 0 | 0-1 | Idle-Timeout | 0 | 0-1 | Login-IP-Host | 0+ | 0+ | Login-IPv6-Host | 0+ | 0+ | Login-LAT-Group | 0-1 | 0-1 | Login-LAT-Node | 0-1 | 0-1 | Login-LAT-Port | 0-1 | 0-1 | Login-LAT-Service | 0-1 | 0-1 | Login-Service | 0 | 0-1 | Login-TCP-Port | 0 | 0-1 | Multi-Round-Time-Out | 0 | 0-1 | ------------------------------|-----+-----+
+-----------+ | Command | |-----+-----+ Attribute Name | AAR | AAA | ------------------------------|-----+-----+ NAS-Filter-Rule | 0 | 0+ | NAS-Identifier | 0-1 | 0 | NAS-IP-Address | 0-1 | 0 | NAS-IPv6-Address | 0-1 | 0 | NAS-Port | 0-1 | 0 | NAS-Port-Id | 0-1 | 0 | NAS-Port-Type | 0-1 | 0 | Origin-AAA-Protocol | 0-1 | 0-1 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Origin-State-Id | 0-1 | 0-1 | Originating-Line-Info | 0-1 | 0 | Password-Retry | 0 | 0-1 | Port-Limit | 0-1 | 0-1 | Prompt | 0 | 0-1 | Proxy-Info | 0+ | 0+ | QoS-Filter-Rule | 0 | 0+ | Re-Auth-Request-Type | 0 | 0-1 | Redirect-Host | 0 | 0+ | Redirect-Host-Usage | 0 | 0-1 | Redirect-Max-Cache-Time | 0 | 0-1 | Reply-Message | 0 | 0+ | Result-Code | 0 | 1 | Route-Record | 0+ | 0 | Service-Type | 0-1 | 0-1 | Session-Id | 1 | 1 | Session-Timeout | 0 | 0-1 | State | 0-1 | 0-1 | Tunneling | 0+ | 0+ | User-Name | 0-1 | 0-1 | User-Password | 0-1 | 0 | ------------------------------|-----+-----+5.2. Accounting AVP Tables
The tables in this section are used to show which AVPs defined in this document are to be present and used in NAS application Accounting messages. These AVPs are defined in this document, as well as in [RFC6733] and [RFC2866].
5.2.1. Framed Access Accounting AVP Table
The table in this section is used when the Service-Type AVP (Section 4.4.1) specifies Framed Access. +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Auth-Method | 0-1 | 0 | Accounting-Input-Octets | 1 | 0 | Accounting-Input-Packets | 1 | 0 | Accounting-Output-Octets | 1 | 0 | Accounting-Output-Packets | 1 | 0 | Accounting-Record-Number | 0-1 | 0-1 | Accounting-Record-Type | 1 | 1 | Accounting-Realtime-Required | 0-1 | 0-1 | Accounting-Sub-Session-Id | 0-1 | 0-1 | Acct-Application-Id | 0-1 | 0-1 | Acct-Session-Id | 1 | 0-1 | Acct-Multi-Session-Id | 0-1 | 0-1 | Acct-Authentic | 1 | 0 | Acct-Delay-Time | 0-1 | 0 | Acct-Interim-Interval | 0-1 | 0-1 | Acct-Link-Count | 0-1 | 0 | Acct-Session-Time | 1 | 0 | Acct-Tunnel-Connection | 0-1 | 0 | Acct-Tunnel-Packets-Lost | 0-1 | 0 | Authorization-Lifetime | 0-1 | 0 | Callback-Id | 0-1 | 0 | Callback-Number | 0-1 | 0 | Called-Station-Id | 0-1 | 0 | Calling-Station-Id | 0-1 | 0 | Class | 0+ | 0+ | Connection-Info | 0+ | 0 | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Event-Timestamp | 0-1 | 0-1 | Error-Message | 0 | 0-1 | Error-Reporting-Host | 0 | 0-1 | Failed-AVP | 0 | 0+ | ---------------------------------------|-----+-----+
+-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Framed-Appletalk-Link | 0-1 | 0 | Framed-Appletalk-Network | 0-1 | 0 | Framed-Appletalk-Zone | 0-1 | 0 | Framed-Compression | 0-1 | 0 | Framed-IP-Address | 0-1 | 0 | Framed-IP-Netmask | 0-1 | 0 | Framed-IPv6-Prefix | 0+ | 0 | Framed-IPv6-Pool | 0-1 | 0 | Framed-IPX-Network | 0-1 | 0 | Framed-MTU | 0-1 | 0 | Framed-Pool | 0-1 | 0 | Framed-Protocol | 0-1 | 0 | Framed-Route | 0-1 | 0 | Framed-Routing | 0-1 | 0 | NAS-Filter-Rule | 0+ | 0 | NAS-Identifier | 0-1 | 0-1 | NAS-IP-Address | 0-1 | 0-1 | NAS-IPv6-Address | 0-1 | 0-1 | NAS-Port | 0-1 | 0-1 | NAS-Port-Id | 0-1 | 0-1 | NAS-Port-Type | 0-1 | 0-1 | Origin-AAA-Protocol | 0-1 | 0-1 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Origin-State-Id | 0-1 | 0-1 | Originating-Line-Info | 0-1 | 0 | Proxy-Info | 0+ | 0+ | QoS-Filter-Rule | 0+ | 0 | Route-Record | 0+ | 0 | Result-Code | 0 | 1 | Service-Type | 0-1 | 0-1 | Session-Id | 1 | 1 | Termination-Cause | 0-1 | 0-1 | Tunnel-Assignment-Id | 0-1 | 0 | Tunnel-Client-Endpoint | 0-1 | 0 | Tunnel-Medium-Type | 0-1 | 0 | Tunnel-Private-Group-Id | 0-1 | 0 | Tunnel-Server-Endpoint | 0-1 | 0 | Tunnel-Type | 0-1 | 0 | User-Name | 0-1 | 0-1 | ---------------------------------------|-----+-----+
5.2.2. Non-Framed Access Accounting AVP Table
The table in this section is used when the Service-Type AVP (Section 4.4.1) specifies Non-Framed Access. +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Auth-Method | 0-1 | 0 | Accounting-Input-Octets | 1 | 0 | Accounting-Output-Octets | 1 | 0 | Accounting-Record-Type | 1 | 1 | Accounting-Record-Number | 0-1 | 0-1 | Accounting-Realtime-Required | 0-1 | 0-1 | Accounting-Sub-Session-Id | 0-1 | 0-1 | Acct-Application-Id | 0-1 | 0-1 | Acct-Session-Id | 1 | 0-1 | Acct-Multi-Session-Id | 0-1 | 0-1 | Acct-Authentic | 1 | 0 | Acct-Delay-Time | 0-1 | 0 | Acct-Interim-Interval | 0-1 | 0-1 | Acct-Link-Count | 0-1 | 0 | Acct-Session-Time | 1 | 0 | Authorization-Lifetime | 0-1 | 0 | Callback-Id | 0-1 | 0 | Callback-Number | 0-1 | 0 | Called-Station-Id | 0-1 | 0 | Calling-Station-Id | 0-1 | 0 | Class | 0+ | 0+ | Connection-Info | 0+ | 0 | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Event-Timestamp | 0-1 | 0-1 | Error-Message | 0 | 0-1 | Error-Reporting-Host | 0 | 0-1 | Failed-AVP | 0 | 0+ | Login-IP-Host | 0+ | 0 | Login-IPv6-Host | 0+ | 0 | Login-LAT-Service | 0-1 | 0 | Login-LAT-Node | 0-1 | 0 | Login-LAT-Group | 0-1 | 0 | Login-LAT-Port | 0-1 | 0 | Login-Service | 0-1 | 0 | Login-TCP-Port | 0-1 | 0 | ---------------------------------------|-----+-----+
+-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ NAS-Identifier | 0-1 | 0-1 | NAS-IP-Address | 0-1 | 0-1 | NAS-IPv6-Address | 0-1 | 0-1 | NAS-Port | 0-1 | 0-1 | NAS-Port-Id | 0-1 | 0-1 | NAS-Port-Type | 0-1 | 0-1 | Origin-AAA-Protocol | 0-1 | 0-1 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Origin-State-Id | 0-1 | 0-1 | Originating-Line-Info | 0-1 | 0 | Proxy-Info | 0+ | 0+ | QoS-Filter-Rule | 0+ | 0 | Route-Record | 0+ | 0 | Result-Code | 0 | 1 | Session-Id | 1 | 1 | Service-Type | 0-1 | 0-1 | Termination-Cause | 0-1 | 0-1 | User-Name | 0-1 | 0-1 | ---------------------------------------|-----+-----+6. Unicode Considerations
A number of the AVPs in this RFC use the UTF8String type specified in the Diameter Base protocol [RFC6733]. Implementation differences in Unicode input processing may result in the same Unicode input characters generating different UTF-8 strings that fail to match when compared for equality. This may result in interoperability problems between a network access server and a Diameter server when a UTF-8 string entered locally is compared with one received via Diameter. Many of the uses of UTF8String in this RFC are limited to the 7-bit US-ASCII-compatible subset of UTF-8, where this class of Unicode string comparison problems does not arise. Careful preparation of Unicode strings can increase the likelihood that string comparison will work in ways that make sense for typical users throughout the world; [RFC3454] is an example a framework for such Unicode string preparation. The Diameter application specified in this RFC has been deployed with use of Unicode in accordance with [RFC4005], which does not require any Unicode string preparation. As a result, additional requirements for Unicode string preparation in this RFC would not be backwards compatible with existing usage.
The Diameter server and the network access servers that it serves can be assumed to be under common administrative control, and all of the UTF-8 strings involved are part of the configuration of these servers. Therefore, administrative interfaces for implementations of this RFC: a. SHOULD accept direct UTF-8 input of all configuration strings for AVPs that allow Unicode characters beyond the 7-bit US-ASCII- compatible subset of Unicode (in addition to any provisions for accepting Unicode characters for processing into UTF-8), and b. SHOULD make all such configuration strings available as UTF-8 strings. This functionality enables an administrator who encounters Unicode string comparison problems to copy one instance of aproblematic UTF-8 string from one server to the other, after which the two (now identical) copies should compare as expected.7. IANA Considerations
Several of the namespaces used in this document are managed by the Internet Assigned Numbers Authority [IANA], including the AVP Codes [AVP-Codes], AVP Specific Values [AVP-Vals], Application IDs [App-Ids], Command Codes [Command-Codes], and RADIUS Attribute Values [RADIUSAttrVals]. For the current values allocated, and the policies governing allocation in those namespaces, please see the above-referenced registries.8. Security Considerations
This document describes the extension of Diameter for the NAS application. Security considerations regarding the Diameter protocol itself are discussed in [RFC6733]. Use of this application of Diameter MUST take into consideration the security issues and requirements of the Base protocol.8.1. Authentication Considerations
This document does not contain a security protocol but does discuss how PPP authentication protocols can be carried within the Diameter protocol. The PPP authentication protocols described are PAP and CHAP.
The use of PAP SHOULD be discouraged, as it exposes users' passwords to possibly non-trusted entities. However, PAP is also frequently used for use with one-time passwords, which do not expose a security risk. This document also describes how CHAP can be carried within the Diameter protocol, which is required for RADIUS backward compatibility. The CHAP protocol, as used in a RADIUS environment, facilitates authentication replay attacks. The use of the EAP authentication protocols [RFC4072] can offer better security, given a method suitable for the circumstances. Depending on the value of the Auth-Request-Type AVP, the Diameter protocol allows authorization-only requests that contain no authentication information from the client. This capability goes beyond the Call Check capabilities provided by RADIUS (Section 5.6 of [RFC2865]) in that no access decision is requested. As a result, a new session cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability.8.2. AVP Considerations
Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. With the exception of the Configuration-Token (Section 4.4.8), QoS-Filter-Rule (Section 4.4.9), and Tunneling (Section 4.5.1) AVPs, all of the AVPs defined in this document are considered to be security-sensitive. Diameter messages containing any AVPs considered to be security- sensitive MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. For example, end-to-end security may not be required in the case where an intermediary node is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. Note that no end-to-end security mechanism is specified in this document.
9. References
9.1. Normative References
[ANITypes] NANPA Number Resource Info, "ANI Assignments", <http://www.nanpa.com/number_resource_info/ ani_ii_assignments.html>. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.9.2. Informative References
[ARAP] Apple Computer, "Apple Remote Access Protocol (ARAP) Version 2.0 External Reference Specification", R0612LL/B , September 1994. [AVP-Codes] IANA, "AVP Codes", <http://www.iana.org/assignments/aaa-parameters/>.
[AVP-Vals] IANA, "AVP Specific Values", <http://www.iana.org/assignments/aaa-parameters/>. [App-Ids] IANA, "Application IDs", <http://www.iana.org/assignments/aaa-parameters/>. [AppleTalk] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk", Second Edition Apple Computer, 1990. [BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [Command-Codes] IANA, "Command Codes", <http://www.iana.org/assignments/aaa-parameters/>. [IANA] IANA, "Internet Assigned Numbers Authority", <http://www.iana.org/>. [IPX] Novell, Inc., "NetWare System Technical Interface Overview", #883-000780-001, June 1989. [ISO.8859-1.1987] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO Standard 8859-1, 1987. [LAT] Digital Equipment Corp., "Local Area Transport (LAT) Specification V5.0", AA-NL26A-TE, June 1989. [RADIUSAttrVals] IANA, "Radius Attribute Values", <http://www.iana.org/assignments/radius-types/>. [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000. [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S., and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000. [RFC3169] Beadles, M. and D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Acknowledgements
A.1. This Document
The vast majority of the text in this document was taken directly from RFC 4005; the editor owes a debt of gratitude to the authors thereof (especially Dave Mitton, who somehow managed to make nroff paginate the AVP Occurance Tables correctly!). Thanks (in no particular order) to Jai-Jin Lim, Liu Hans, Sebastien Decugis, Jouni Korhonen, Mark Jones, Hannes Tschofenig, Dave Crocker, David Black, Barry Leiba, Peter Saint-Andre, Stefan Winter, and Lionel Morand for their useful reviews and helpful comments.A.2. RFC 4005
The authors would like to thank Carl Rigney, Allan C. Rubens, William Allen Simpson, and Steve Willens for their work on the original RADIUS protocol, from which many of the concepts in this specification were derived. Thanks, also, to Carl Rigney for [RFC2866] and [RFC2869]; Ward Willats for [RFC2869]; Glen Zorn, Bernard Aboba, and Dave Mitton for [RFC2867] and [RFC3162]; and Dory Leifer, John Shriver, Matt Holdrege, Allan Rubens, Glen Zorn, and Ignacio Goyret for their work on [RFC2868]. This document stole text and concepts from both [RFC2868] and [RFC2869]. Thanks go to Carl Williams for providing IPv6-specific text. The authors would also like to acknowledge the following people for their contributions in the development of the Diameter protocol: Bernard Aboba, Jari Arkko, William Bulley, Kuntal Chowdhury, Daniel C. Fox, Lol Grant, Nancy Greene, Jeff Hagg, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht, and Jeff Weisberg. Finally, Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ.
Author's Address
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0)8-1000-4155 EMail: glenzorn@gmail.com