doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc3162.txt b/doc/rfc/rfc3162.txt
new file mode 100644
index 0000000..a62642f
--- /dev/null
+++ b/doc/rfc/rfc3162.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           B. Aboba
+Request for Comments: 3162                                     Microsoft
+Category: Standards Track                                        G. Zorn
+                                                           Cisco Systems
+                                                               D. Mitton
+                                                   Circular Logic UnLtd.
+                                                             August 2001
+
+
+                            RADIUS and IPv6
+
+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 Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document specifies the operation of RADIUS (Remote
+   Authentication Dial In User Service) when run over IPv6 as well as
+   the RADIUS attributes used to support IPv6 network access.
+
+1.  Introduction
+
+   This document specifies the operation of RADIUS [4]-[8] over IPv6
+   [13] as well as the RADIUS attributes used to support IPv6 network
+   access.
+
+   Note that a NAS sending a RADIUS Access-Request may not know a-priori
+   whether the host will be using IPv4, IPv6, or both.  For example,
+   within PPP, IPv6CP [11] occurs after LCP, so that address assignment
+   will not occur until after RADIUS authentication and authorization
+   has completed.
+
+   Therefore it is presumed that the IPv6 attributes described in this
+   document MAY be sent along with IPv4-related attributes within the
+   same RADIUS message and that the NAS will decide which attributes to
+   use.  The NAS SHOULD only allocate addresses and prefixes that the
+   client can actually use, however.  For example, there is no need for
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 1]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   the NAS to reserve use of an IPv4 address for a host that only
+   supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does
+   not require allocation of an IPv6 prefix.
+
+   The NAS can provide IPv6 access natively, or alternatively, via other
+   methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14].  The
+   choice of method for providing IPv6 access has no effect on RADIUS
+   usage per se, although if it is desired that an IPv6 within IPv4
+   tunnel be opened to a particular location, then tunnel attributes
+   should be utilized, as described in [6], [7].
+
+1.1.  Requirements language
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+   described in [1].
+
+2.  Attributes
+
+2.1.  NAS-IPv6-Address
+
+   Description
+
+      This Attribute indicates the identifying IPv6 Address of the NAS
+      which is requesting authentication of the user, and SHOULD be
+      unique to the NAS within the scope of the RADIUS server.  NAS-
+      IPv6-Address is only used in Access-Request packets.  NAS-IPv6-
+      Address and/or NAS-IP-Address MAY be present in an Access-Request
+      packet; however, if neither attribute is present then NAS-
+      Identifier MUST be present.
+
+   A summary of the NAS-IPv6-Address Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    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     |             Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               Address             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 2]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Type
+
+      95 for NAS-IPv6-Address
+
+   Length
+
+      18
+
+   Address
+
+      The Address field is 16 octets.
+
+3.2.  Framed-Interface-Id
+
+   Description
+
+      This Attribute indicates the IPv6 interface identifier to be
+      configured for the user.  It MAY be used in Access-Accept packets.
+      If the Interface-Identifier IPv6CP option [11] has been
+      successfully negotiated, this Attribute MUST be included in an
+      Access-Request packet as a hint by the NAS to the server that it
+      would prefer that value.  It is recommended, but not required,
+      that the server honor the hint.
+
+   A summary of the Framed-Interface-Id Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    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     |             Interface-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Interface-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          Interface-Id             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      96 for Framed-Interface-Id
+
+   Length
+
+      10
+
+   Interface-Id
+
+      The Interface-Id field is 8 octets.
+
+
+
+Aboba, et al.               Standards Track                     [Page 3]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+2.3.  Framed-IPv6-Prefix
+
+   Description
+
+      This Attribute indicates an IPv6 prefix (and corresponding route)
+      to be configured for the user.  It MAY be used in Access-Accept
+      packets, and can appear multiple times.  It MAY be used in an
+      Access-Request packet as a hint by the NAS to the server that it
+      would prefer these prefix(es), but the server is not required to
+      honor the hint.  Since it is assumed that the NAS will plumb a
+      route corresponding to the prefix, it is not necessary for the
+      server to also send a Framed-IPv6-Route attribute for the same
+      prefix.
+
+   A summary of the Framed-IPv6-Prefix Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    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     |  Reserved     | Prefix-Length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      97 for Framed-IPv6-Prefix
+
+   Length
+
+      At least 4 and no larger than 20.
+
+   Reserved
+
+      This field, which is reserved and MUST be present, is always set
+      to zero.
+
+   Prefix-Length
+
+      The length of the prefix, in bits.  At least 0 and no larger than
+      128.
+
+
+
+Aboba, et al.               Standards Track                     [Page 4]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Prefix
+
+      The Prefix field is up to 16 octets in length.  Bits outside of
+      the Prefix-Length, if included, must be zero.
+
+2.4.  Login-IPv6-Host
+
+   Description
+
+      This Attribute indicates the system with which to connect the
+      user, when the Login-Service Attribute is included.  It MAY be
+      used in Access-Accept packets.  It MAY be used in an Access-
+      Request packet as a hint to the server that the NAS would prefer
+      to use that host, but the server is not required to honor the
+      hint.
+
+   A summary of the Login-IPv6-Host Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    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     |             Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      98 for Login-IPv6-Host
+
+   Length
+
+      18
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 5]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Address
+
+      The Address field is 16 octets in length.  The value
+      0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD
+      allow the user to select an address or name to be connected to.
+      The value 0 indicates that the NAS SHOULD select a host to connect
+      the user to.  Other values indicate the address the NAS SHOULD
+      connect the user to.
+
+2.5.  Framed-IPv6-Route
+
+   Description
+
+      This Attribute provides routing information to be configured for
+      the user on the NAS.  It is used in the Access-Accept packet and
+      can appear multiple times.
+
+   A summary of the Framed-IPv6-Route Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      99 for Framed-IPv6-Route
+
+   Length
+
+      >=3
+
+   Text
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  The field is not NUL (hex 00)
+      terminated.  It is intended to be human readable and MUST NOT
+      affect operation of the protocol.
+
+      For IPv6 routes, it SHOULD contain a destination prefix optionally
+      followed by a slash and a decimal length specifier stating how
+      many high order bits of the prefix to use.  That is followed by a
+      space, a gateway address, a space, and one or more metrics
+      (encoded in decimal) separated by spaces.  Prefixes and addresses
+      are formatted as described in [16].  For example,
+      "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
+
+
+
+Aboba, et al.               Standards Track                     [Page 6]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+      Whenever the gateway address is the IPv6 unspecified address the
+      IP address of the user SHOULD be used as the gateway address.  The
+      unspecified address can be expressed in any of the acceptable
+      formats described in [16].  For example, "2000:0:0:106::/64 :: 1".
+
+2.6.  Framed-IPv6-Pool
+
+   Description
+
+      This Attribute contains the name of an assigned pool that SHOULD
+      be used to assign an IPv6 prefix for the user.  If a NAS does not
+      support multiple prefix pools, the NAS MUST ignore this Attribute.
+
+   A summary of the Framed-IPv6-Pool Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      100 for Framed-IPv6-Pool
+
+   Length
+
+      >= 3
+
+   String
+
+      The string field contains the name of an assigned IPv6 prefix pool
+      configured on the NAS.  The field is not NUL (hex 00) terminated.
+
+3.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in which kinds of packets, and in what quantity.
+
+   Request Accept Reject Challenge Accounting  #  Attribute
+                                   Request
+   0-1     0      0      0         0-1        95  NAS-IPv6-Address
+   0-1     0-1    0      0         0-1        96  Framed-Interface-Id
+   0+      0+     0      0         0+         97  Framed-IPv6-Prefix
+   0+      0+     0      0         0+         98  Login-IPv6-Host
+   0       0+     0      0         0+         99  Framed-IPv6-Route
+   0       0-1    0      0         0-1       100  Framed-IPv6-Pool
+
+
+
+Aboba, et al.               Standards Track                     [Page 7]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+4.  References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March, 1997.
+
+   [2]   Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+         10646", RFC 2044, October 1996.
+
+   [3]   Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+         Implementation in Roaming", RFC 2607, June 1999.
+
+   [4]   Rigney, C., Rubens, A., Simpson, W. and S. Willens,  "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2865, June
+         2000.
+
+   [5]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [6]   Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
+         Modifications for Tunnel Protocol Support", RFC 2867, June
+         2000.
+
+   [7]   Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
+         and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
+         RFC 2868, June 2000.
+
+   [8]   Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
+         RFC 2869, June 2000.
+
+   [9]   Kent S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [10]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [11]  Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
+         December 1998.
+
+   [12]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
+         IPv4 Clouds", RFC 3056, February 2001.
+
+   [13]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+   [14]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
+         Domains without Explicit Tunnels", RFC 2529, March 1999.
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 8]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   [15]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
+         Hosts and Routers", RFC 2893, August 2000.
+
+   [16]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 2373, July 1998.
+
+5.  Security Considerations
+
+   This document describes the use of RADIUS for the purposes of
+   authentication, authorization and accounting in IPv6-enabled
+   networks.  In such networks, the RADIUS protocol may run either over
+   IPv4 or over IPv6.  Known security vulnerabilities of the RADIUS
+   protocol are described in [3], [4] and [8].
+
+   Since IPSEC [9] is mandatory to implement for IPv6, it is expected
+   that running RADIUS implementations supporting IPv6 will typically
+   run over IPSEC.  Where RADIUS is run over IPSEC and where
+   certificates are used for authentication, it may be desirable to
+   avoid management of RADIUS shared secrets, so as to leverage the
+   improved scalability of public key infrastructure.
+
+   Within RADIUS, a shared secret is used for hiding of attributes such
+   as User-Password [4] and Tunnel-Password [7].  In addition, the
+   shared secret is used in computation of the Response Authenticator
+   [4], as well as the Message-Authenticator attribute [8].  Therefore,
+   in RADIUS a shared secret is used to provide confidentiality as well
+   as integrity protection and authentication.  As a result, only use of
+   IPSEC ESP with a non-null transform can provide security services
+   sufficient to substitute for RADIUS application-layer security.
+   Therefore, where IPSEC AH or ESP null is used, it will typically
+   still be necessary to configure a RADIUS shared secret.
+
+   However, where RADIUS is run over IPSEC ESP with a non-null
+   transform, the secret shared between the NAS and the RADIUS server
+   MAY NOT be configured.  In this case, a shared secret of zero length
+   MUST be assumed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 9]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+6.  IANA Considerations
+
+   This document requires the assignment of six new RADIUS attribute
+   numbers for the following attributes:
+
+      NAS-IPv6-Address
+      Framed-Interface-Id
+      Framed-IPv6-Prefix
+      Login-IPv6-Host
+      Framed-IPv6-Route
+      Framed-IPv6-Pool
+
+   See section 3 for the registered list of numbers.
+
+7.  Acknowledgments
+
+   The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ
+   Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent
+   for contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 10]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+8.  Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 936 6605
+   Fax:   +1 425 936 7329
+   EMail: bernarda@microsoft.com
+
+
+   Glen Zorn
+   Cisco Systems, Inc.
+   500 108th Avenue N.E., Suite 500
+   Bellevue, WA 98004
+
+   Phone: +1 425 471 4861
+   EMail: gwz@cisco.com
+
+
+   Dave Mitton
+   Circular Logic UnLtd.
+   733 Turnpike Street #154
+   North Andover, MA 01845
+
+   Phone: 978 683-1814
+   Email: david@mitton.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 11]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 12]
+