7 Network Working Group D. Mitton
8 Request for Comments: 2882 Nortel Networks
9 Category: Informational July 2000
12 Network Access Servers Requirements:
13 Extended RADIUS Practices
17 This memo provides information for the Internet community. It does
18 not specify an Internet standard of any kind. Distribution of this
23 Copyright (C) The Internet Society (2000). All Rights Reserved.
27 This document describes current practices implemented in NAS products
28 that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
29 purpose of this effort is to give examples that show the need for
30 addressing and standardizing these types of ad-hoc functions. Since
31 many of these features require a matching server support component,
32 the ability to deploy and manage interoperable NAS and AAA server
33 products is severely hindered.
35 These practices are documented here to show functions that are
36 obviously desired in developing future AAA protocols for NAS
41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
42 1.1. Disclaimers . . . . . . . . . . . . . . . . . . . . . . . 3
43 1.2. Presentation . . . . . . . . . . . . . . . . . . . . . . 3
44 2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . 3
45 2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . 4
46 2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . 4
47 2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . 4
48 2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . 5
49 2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . 5
50 2.3.2 Clients that support multiple Vendors: . . . . . . . . . 5
51 3. Attribute Data Types . . . . . . . . . . . . . . . . . . . 6
52 4. New Messages . . . . . . . . . . . . . . . . . . . . . . . 7
53 5. Additional Functions . . . . . . . . . . . . . . . . . . . 7
54 5.1 Password Change . . . . . . . . . . . . . . . . . . . . . 8
58 Mitton Informational [Page 1]
60 RFC 2882 Extended RADIUS Practices July 2000
63 5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . 8
64 5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
65 5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . 9
66 6. Resource Management . . . . . . . . . . . . . . . . . . . . 9
67 6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . 9
68 6.2 Resource Management Messages . . . . . . . . . . . . . . . 10
69 6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
70 6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
71 7. Policy Services . . . . . . . . . . . . . . . . . . . . . . 11
72 8. Accounting Extensions . . . . . . . . . . . . . . . . . . . 12
73 8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
74 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 12
75 10. Security Considerations . . . . . . . . . . . . . . . . . . 13
76 11. Implementation Documents . . . . . . . . . . . . . . . . . 13
77 11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
78 11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
79 12. References . . . . . . . . . . . . . . . . . . . . . . . . 14
80 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 15
81 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
85 The RADIUS Working Group was formed in 1995 to document the protocol
86 of the same name, and was chartered to stay within a set of bounds
87 for dial-in terminal servers. Unfortunately the real world of
88 Network Access Servers (NASes) hasn't stayed that small and simple,
89 and continues to evolve at an amazing rate.
91 This document shows some of the current implementations on the market
92 have already outstripped the capabilities of the RADIUS protocol. A
93 quite a few features have been developed completely outside the
94 protocol. These features use the RADIUS protocol structure and
95 format, but employ operations and semantics well beyond the RFC
98 I learn of the details of these functions from reading industry
99 manuals and often have to respond to them in competive bid
100 specifications. As they become deployed in the field, they gather
101 the force of de-facto standards.
103 Because they have been done outside scope of the RFCs, they are
104 vendor specific, and introduce significant problems in offering an
105 interoperable product.
114 Mitton Informational [Page 2]
116 RFC 2882 Extended RADIUS Practices July 2000
121 The data and numbers in this document have been gleaned from public
122 sources and vendor documents along the way. Actual implementation of
123 many these features and variation from the documentation has not been
126 This document is a snapshot of known practices at the time of
127 writing. It is not intended to standardize these practices here, or
128 keep this document current, beyond initial publication. While some
129 detailed information is given, it is not the purpose of this document
130 to directly or sufficiently describe the functions mentioned to the
131 level of a complete functional specification.
133 The author has not transcribed copyrighted material, and is not aware
134 of whether any of these practices have of intellectual property
137 Any numeric assignments or functional operations are subject to
138 change by vendors without notice. I would appreciate any direct
139 input, preferably first hand, from implementors.
143 Without any easy organization for the material, information is
144 arranged in a simple taxonomy from bottom-up complexity:
148 - Attribute Data Types
156 The RADIUS RFCs define attribute type ranges and specific attribute
160 - There are about 70 defined RADIUS attributes:
162 - Values 192-223 are reserved for experimental use
164 - Values 224-240 are reserved for implementation-specific use
166 - Values 241-255 are reserved and should not be used.
170 Mitton Informational [Page 3]
172 RFC 2882 Extended RADIUS Practices July 2000
175 Attribute 26 was defined to be the Vendor Specific Attribute (VSA)
176 with further internal structure to allow vendor expansion.
178 2.1. Attribute conflicts
180 In practice attributes 92-255 are in use by a vendor. And another
181 vendor also use attributes in the 90-104 range and conflicts with
184 To deal with these issues, server vendors have added vendor specific
185 parameters to their client database files. The administrator has to
186 indicate the vendor type of NAS along with the client IP address and
187 secret, so that the server can disambiguate the attribute usage.
189 One server has a single large vendors file to describe the mapping
190 all attributes to an internal format that retains the vendor id.
191 Another server implementation uses multiple dictionaries, each
192 indexed to a NAS and Vendor Model definition list.
194 2.2. Attribute Value Conflicts
196 Adding additional attributes may be more trouble than necessary for
197 simple features. Often existing RADIUS attributes could be extended
198 with additional values (particularly attributes that are enumerated
199 choices). But in doing such there is no way to guarantee not
200 conflicting with other vendor's extensions.
202 2.2.1. Vendor Specific Enumerations proposal
204 One proposed solution to this problem was Vendor Specific
205 Enumerations (VSEs). That is to imbed the vendor's management ID in
206 the numeric value (ala VSAs) which would to divide up the attribute
207 value space. This technique has not seen any acceptance by the
208 working group or other vendors, however, the vendor did accomplish
209 the goal of not conflicting with working group additions or other
212 Example dictionary of VSE values:
214 VALUE Service-Type VSE-Authorize-Only 0x06300001
216 VALUE Acct-Status-Type VSE-User-Reject 0x06300001
217 VALUE Acct-Status-Type VSE-Call-Reject 0x06300002
218 VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003
219 VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004
220 VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005
221 VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006
222 VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007
226 Mitton Informational [Page 4]
228 RFC 2882 Extended RADIUS Practices July 2000
231 VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008
232 VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009
233 VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a
234 VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b
235 VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c
236 VALUE Acct-Status-Type VSE-MP-Start 0x0630000d
237 VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e
238 VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f
239 VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010
240 VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011
242 2.3. Vendor Specific Attribute Usage
244 Because attribute 26 Vendor Specific Attributes (VSAs) came late in
245 the RADIUS working group development, there were some server
246 implementations that were late to support them. Today, there are
247 several leading implementations of clients that make extensive use of
248 VSAs. What's unfortunate is that there is also several different
249 formats of VSAs implemented. This is because the RFC suggested
250 format does not support more than 256 attributes.
252 2.3.1. VSAs in use by some clients:
254 At the time this document was written, the following had be observed:
256 - Microsoft: several for MS-CHAP authentication support [9]
260 - Nortel(Bay): about 60 VSAs and 16 VSEs
262 - Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header.
263 Aptis VSAs have shifted from a regular format to a 4-byte header
264 format, due to the large number of attributes implemented.
266 - 3Com (USR): about 130
267 USR VSAs are different than the format suggested in RFC 2138.
268 They have a 4 byte type field and have no internal length.
270 Some vendors that did not initially use VSAs, have shifted in later
271 releases VSA usage as a configuration option.
273 2.3.2. Clients that support Multiple Vendor Attributes
275 Now that MS-CHAP RADIUS attributes have been published in RFC 2548
276 [9] as Microsoft VSA attributes, it will become typical that for NAS
277 clients that support MS-CHAP authentication to process several
282 Mitton Informational [Page 5]
284 RFC 2882 Extended RADIUS Practices July 2000
287 different vendor VSA types. This has implications for RADIUS servers
288 that filter or "prune" return attributes based on the vendor
289 make/model of the NAS client.
291 One NAS implementation can receive up to three different vendor
292 specific attribute sets, but will only send attributes according to
293 the "mode" that has been configured by the operator. This allows it
294 to fit into environments where the customer has become dependent on a
295 particular set of RADIUS attributes, and allows the NAS to "drop-in"
296 without server attribute changes.
298 There is another NAS that supports 3 vendor attributes sets
299 concurrently. That is, it will normally use a combination of
300 different vendor VSAs in return profiles from the server. This was
301 done to support a superset of competing vendor's extensions, as well
302 as it's own, and include an extensions from a sister product.
304 3. Attribute Data Types
306 The base RFCs define only has 4 basic data types:
308 - integer, 32 bit unsigned
310 - string, 1-253 bytes, counted.
312 - ipaddr, 32 bit IPv4
314 - date, 32 bit Unix format.
316 Since then, various variations have been added:
318 The tunnel authentication document [6] adds an optional compound
319 "tag" byte to tunnel attributes. These are a single byte prepended
320 to the data field in order to support sets of attributes to be
321 returned. The byte value must be in the range 01-3F hex or it is
322 considered to be data.
324 Note that there is no native support for IPv6 addresses. In fact IPv6
325 support is missing in some fixed message components too.
327 There have been special attribute types created within servers. For
328 packet filters, the format called "abinary" was created. The user
329 enters an ASCII string filter description in the user profile, but
330 the server parses it into a binary string before passing it to the
331 NAS. This lowers the complexity of the NAS parser. Also a
332 "phonestring" server data type allows additional data type checking
333 at the entry application.
338 Mitton Informational [Page 6]
340 RFC 2882 Extended RADIUS Practices July 2000
345 A number of new message types have been introduced by various parties
346 over time. The base specification has 6, vendors have added 26.
348 These fall into a number of categories which are described in the
349 next section below. Some of these messages are actually used between
350 the RADIUS server and some other resource server, using a RADIUS-like
351 protocol to implement new functions.
354 (now Interim Accounting [5])
358 10 Accounting Message
360 21 Resource Free Request
361 22 Resource Free Response
362 23 Resource Query Request
363 24 Resource Query Response
364 25 Alternate Resource Reclaim Request
365 26 NAS Reboot Request
366 27 NAS Reboot Response
374 40 Disconnect Request
377 43 Change Filters Request
378 44 Change Filters Ack
379 45 Change Filters Nak
380 50 IP Address Allocate
381 51 IP Address Release
383 5. Additional Functions
385 These are operations performed using RADIUS extensions and additional
394 Mitton Informational [Page 7]
396 RFC 2882 Extended RADIUS Practices July 2000
401 Remotely requested password change operations were described and
402 proposed, but rejected by the working group. None the less, the
403 feature is still deployed in a number of products.
408 - Password Ack or Reject
410 5.2. Authentication Modes
412 Additional message types have been added to negotiate passcode
413 changes for token card servers.
419 They allow the NAS or RADIUS server negotiate passcode changes with
420 an external security server.
424 At least two vendors have built menuing interaction systems for use
425 with terminal dial-ins.
427 One implementation uses the Reply-Message string as the menu text to
428 be displayed, and the State attribute to keep track of the place in
429 the menu. The menu is displayed using the Access-Challenge message.
430 The response is encoded in the User-Password field like an ordinary
431 challenge sequence would.
433 Some RADIUS clients have problems with this because they cannot
434 handle long or multiple Reply-Message attributes that may have
435 embedded carriage returns and line-feeds. The new Echo attribute
436 should also control echo behavior on the menu response. Use of the
437 State attribute to keep track of a Challenge sequence is also
440 Another implementation uses two vendor attributes (VSA-Menu-Item, and
441 VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this
442 information. This implementation is vendor specific.
450 Mitton Informational [Page 8]
452 RFC 2882 Extended RADIUS Practices July 2000
457 One client implementation takes advantage of your vanilla RADIUS
458 server's ability to be used as a remote database server. By using
459 some well-known, implementation specific, strings for Username and
460 Password attributes, the NAS can request information from the server,
461 such as: Static IP routes, Static IPX routes, or the Message of the
464 These are called pseudo-user requests, because they use a user entry
465 with this manufactured name, for purposes other than authentication.
467 Another client also uses a pseudo-user technique for resolving
468 unknown Filter-ID(11) values. An Access-Request message is sent to
469 the RADIUS server with the Filter-ID as the Username value, the
470 password is a known string, and the Service-Type is VSE-
471 Authorization-Only. The response must also be of the same Service-
472 Type, or the response will be ignored. The responding profile should
473 contain the IP-Filter VSA attributes that will define the desired
476 It should be noticed that pseudo-user profiles could be a security
477 problem if a specific or operationally invalid Service-Type is not
478 attached to the profile. The client should test for this returned
479 value, to prevent normal dial-in users from gaining access via this
482 6. Resource Management
484 Authorized sessions may need to be allocated additional dynamic
485 resources in order to perform their services. The most typical is IP
486 addresses. The allocation may want to be delayed until needed or
487 coordinated on a scale independent of the RADIUS server. Additional
488 messages may be used to allocate and free these resources. The
489 RADIUS server may proxy these requests to another server.
491 Examples: Certain servers can allocate addresses local to the NAS or
492 use an outboard address server. Other servers have an internal
493 address pool capability, which will fill in the Framed-IP-Address
494 attribute with an assigned value based on pool selected.
496 6.1. Managed Resources:
498 Resources managed include: IP Addresses, Concurrent Logins, Dial-in
499 Port allocation policies, Tunnel limits and load distribution.
506 Mitton Informational [Page 9]
508 RFC 2882 Extended RADIUS Practices July 2000
511 There are several different types of implementation techniques:
513 - Explicit request/free resource requests
514 - Monitor usage with deamons watching the state
515 - Explicit messages to a state deamon
516 - Monitor Accounting messages for state changes
518 6.2. Resource Management Messages
520 Messages used for resource management
522 - IP Address Allocate
527 - Resource Free Request
528 - Resource Free Response
529 - Resource Reclaim Request
530 - NAS Reboot Request/Response
532 These messages are used to allocate and free resources for a NAS from
533 a centralized server. These mechanisms allows the service provider
534 better administrative control than some automated LAN services, which
535 don't have policy inputs or controls.
537 6.3. Concurrent Logins
539 The RADIUS protocol was designed to allow stateless servers. That
540 is, servers that don't know the status of the active sessions.
541 However, it is very important for many service providers to keep
542 track of how many sessions a given user may have open, and
543 accordingly disallow access.
545 There are several different techniques used to implement login limits
546 on a RADIUS environment. Some vendors have build NAS monitoring
547 tools either into their RADIUS servers, either directly or as
548 auxiliary deamons, that can check the session status of the
549 controlled NASes by SNMP or proprietary methods.
551 Other vendors monitor the RADIUS accesses and accounting messages and
552 derive state information from the requests. This monitoring is not
553 as reliable as directly auditing the NAS, but it is also less vendor
554 specific, and can work with any RADIUS NAS, provided it sends both
555 streams to the same server.
557 Some of the approaches used:
562 Mitton Informational [Page 10]
564 RFC 2882 Extended RADIUS Practices July 2000
568 - Telnet monitor deamon
571 6.4. Authorization Changes:
573 To implement an active changes to a running session, such as filter
574 changes or timeout and disconnect, at least one vendor has added a
575 RADIUS "server" to his NAS. This server accepts messages sent from an
576 application in the network, and upon matching some session
577 information, will perform such operations.
579 Messages sent from Server to NAS
581 - Change Filter Request
582 - Change Filter Ack / Nak
584 - Disconnect Response
586 Filters are used to limit the access the user has to the network by
587 restricting the systems and protocols he can send packets to. Upon
588 fulfilling some registration with an authorization server, the
589 service provider may wish to remove those restrictions, or disconnect
594 Some vendors have implemented policy servers using RADIUS as the
595 control protocol. Two prominent Policy Managers act as RADIUS proxy
596 filters and use RADIUS messages to deny access to new sessions that
597 exceed active policy limits.
599 One implementation behaves like a RADIUS proxy server, but with a
600 policy process governing it's forward decisions. Typically a pre-
601 authentication message (like the new RADIUS draft Service-Type =
602 CallCheck) is emitted by the NAS upon call arrival. This message will
603 contain only the Dialed-Number information in the Username field.
604 The server receives the Access-Request messages and processes them
605 against it's knowledge of the network state and the provisioned
608 An Access-Accept will be returned to the system to accept the call,
609 and many also contain dynamic policy information and Virtual POP
610 specific default parameters. When the real PPP authentication is
611 engaged, the proxy will forwards the Access-Request to a RADIUS
612 server, if this session was approved at pre-auth. It can also
613 process Access-Requests that were not preceded by a pre-auth
614 exchange, and use the Username field for information about the
618 Mitton Informational [Page 11]
620 RFC 2882 Extended RADIUS Practices July 2000
623 desired realm, in it's policy evaluation.
625 The other implementation performs a similar operations. It uses VSAs
626 in the Access-Request to distinguish pre-authentication message
629 8. Accounting Extensions
631 Traditional Accounting only records session starts and stops which is
632 pretty boring. Additional session information reporting can be added
633 easily which gives a better picture of operation in use as they
634 happen. Some event types are listed below.
636 8.1. Auditing/Activity
638 - Call or Modem Starts, Stops
639 - Tunnel Starts, Stops
640 - Tunnel Link Starts & Stops
643 These events if monitored by a stateful server can be used to gather
644 information about the usage of the network on a user/session basis.
645 Information about when a particular user entered the network is more
646 relevant to network service management than attempting track
647 backwards from low level IP address flows. Useful information about
648 port usage across a range of NASes allows service provider to quickly
649 find problem areas or users.
651 Information about call failures, successes, and quality are also
652 deemed important many service providers.
654 Extending RADIUS accounting is easy, it's surprising that more
655 implementations have not been made in this area.
659 In real life RADIUS Servers are becoming rather complex software
660 implementations. They are often brokering authentication and
661 authorization to other authorities or repositories. Variants of
662 RADIUS protocol is often used as glue protocol for these type of
665 Some of the solutions are kludges that could be cleaned up by better
668 What this means to the implementor is that RADIUS as the RFCs
669 describe it is becoming less relevant. Many additional features
670 require matching client and server processing message processing.
674 Mitton Informational [Page 12]
676 RFC 2882 Extended RADIUS Practices July 2000
679 Without standardization of these functions we don't have much
680 interoperability in the field and much effort is spent in reverse
681 engineering and reaction to unknown areas.
683 This memo is not a complete survey by any means. It is a
684 representative summary of practices that I am aware of at the time of
685 writing. I still appreciate input from vendors or users on practices
686 and details known, and particularly any reference material you can
689 10. Security Considerations
691 This document documents known practices, and does not propose any
692 particular new protocols. Extensions to RADIUS protocols create new
693 security implications because of their functions go beyond those
694 considered in the RFCs. Some of these include:
696 - The ability to change passwords via a RADIUS exchange was
697 deliberately left out of the protocol by the working group,
698 because of security concerns.
699 - The Pseudo-User profiles and the Call-Check operation may allow
700 unintended access if static and well-know account names and
701 passwords are allowed to be used by regular interactive accounts.
702 - Resource Management operations must be protected from denial of
704 - Client side authorization change exchanges need to be secured from
705 attacks that could disconnect or restrict user services.
707 11. Implementation Documents
709 Information about the following implementations can be obtained from
710 the respective owners. Most listed are available from the
711 manufacturer's web site.
715 - 3Com(USR) Total Control Hub
716 - Ericsson(ACC) Tigris
717 draft-ilgun-radius-accvsa-01.txt, Dec 1998
718 - Lucent(Ascend) MAX TNT
719 - Lucent(Livingston) Portmaster
720 - Nortel(Aptis) CVX 1800
721 - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
730 Mitton Informational [Page 13]
732 RFC 2882 Extended RADIUS Practices July 2000
737 - Ericsson(ACC) Virtual Port Server Manager
738 - Funk Steel-Belted RADIUS
739 - Intel(Shiva) Access Manager
740 - Lucent(Ascend) Access Control
741 - Lucent(Ascend) NavisAccess
742 - Lucent(Ascend) Modified Livingston 1.16
743 - Lucent(Livingston) V2.01
744 - Lucent(Livingston) ABM
745 - Lucent Port Authority
747 - Nortel(Bay Networks) BaySecure Access Control
748 - Nortel Preside Radius
749 - Nortel CVX Policy Manager
753 [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
754 Authentication Dial In User Service (RADIUS)", RFC 2138, April
757 [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
759 [3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
760 Authentication Dial In User Service (RADIUS)", RFC 2865, June
763 [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
765 [5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
768 [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
769 I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
772 [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
773 Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
775 [8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
776 Tunneling via RADIUS", RFC 2809, April 2000.
778 [9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
781 [10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson
782 Datacom Access", Work in Progress.
786 Mitton Informational [Page 14]
788 RFC 2882 Extended RADIUS Practices July 2000
795 880 Technology Park Drive
799 EMail: dmitton@nortelnetworks.com
842 Mitton Informational [Page 15]
844 RFC 2882 Extended RADIUS Practices July 2000
847 14. Full Copyright Statement
849 Copyright (C) The Internet Society (2000). All Rights Reserved.
851 This document and translations of it may be copied and furnished to
852 others, and derivative works that comment on or otherwise explain it
853 or assist in its implementation may be prepared, copied, published
854 and distributed, in whole or in part, without restriction of any
855 kind, provided that the above copyright notice and this paragraph are
856 included on all such copies and derivative works. However, this
857 document itself may not be modified in any way, such as by removing
858 the copyright notice or references to the Internet Society or other
859 Internet organizations, except as needed for the purpose of
860 developing Internet standards in which case the procedures for
861 copyrights defined in the Internet Standards process must be
862 followed, or as required to translate it into languages other than
865 The limited permissions granted above are perpetual and will not be
866 revoked by the Internet Society or its successors or assigns.
868 This document and the information contained herein is provided on an
869 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
870 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
871 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
872 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
873 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
877 Funding for the RFC Editor function is currently provided by the
898 Mitton Informational [Page 16]