doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc4818.txt b/doc/rfc/rfc4818.txt
new file mode 100644
index 0000000..8a7d969
--- /dev/null
+++ b/doc/rfc/rfc4818.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         J. Salowey
+Request for Comments: 4818                                      R. Droms
+Category: Standards Track                            Cisco Systems, Inc.
+                                                              April 2007
+
+
+                 RADIUS Delegated-IPv6-Prefix Attribute
+
+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 IETF Trust (2007).
+
+Abstract
+
+   This document defines a RADIUS (Remote Authentication Dial In User
+   Service) attribute that carries an IPv6 prefix that is to be
+   delegated to the user.  This attribute is usable within either RADIUS
+   or Diameter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 1]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+1.  Introduction
+
+   This document defines the Delegated-IPv6-Prefix attribute as a RADIUS
+   [1] attribute that carries an IPv6 prefix to be delegated to the
+   user, for use in the user's network.  For example, the prefix in a
+   Delegated-IPv6-Prefix attribute can be delegated to another node
+   through DHCP Prefix Delegation [2].
+
+   The Delegated-IPv6-Prefix attribute can be used in DHCP Prefix
+   Delegation between the delegating router and a RADIUS server, as
+   illustrated in the following message sequence.
+
+
+   Requesting Router   Delegating Router                   RADIUS Server
+         |                     |                                 |
+         |-Solicit------------>|                                 |
+         |                     |-Request------------------------>|
+         |                     |<--Accept(Delegated-IPv6-Prefix)-|
+         |<--Advertise(Prefix)-|                                 |
+         |-Request(Prefix)---->|                                 |
+         |<--Reply(Prefix)-----|                                 |
+         |                     |                                 |
+                DHCP PD                      RADIUS
+
+
+   The Framed-IPv6-Prefix attribute [4] is not designed to support
+   delegation of IPv6 prefixes to be used in the user's network, and
+   therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may
+   be included in the same RADIUS packet.
+
+2.  Terminology
+
+   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 [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 2]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+3.  Attribute Format
+
+   The format of the Delegated-IPv6-Prefix is:
+
+       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
+
+           123 for Delegated-IPv6-Prefix
+
+      Length
+
+           The length of the entire attribute, in bytes.  At least 4 (to
+           hold Type/Length/Reserved/Prefix-Length for a 0-bit prefix),
+           and no larger than 20 (to hold Type/Length/ Reserved/Prefix-
+           Length for a 128-bit prefix)
+
+      Reserved
+
+           Always set to zero by sender; ignored by receiver
+
+      Prefix-Length
+
+           The length of the prefix being delegated, in bits.  At least
+           0 and no larger than 128 bits (identifying a single IPv6
+           address)
+
+   Note that the prefix field is only required to be long enough to hold
+   the prefix bits and can be shorter than 16 bytes.  Any bits in the
+   prefix field that are not part of the prefix MUST be zero.
+
+   The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and
+   can appear multiple times.  It MAY appear 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.
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 3]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+   The Delegated-IPv6-Prefix attribute MAY appear in an Accounting-
+   Request packet.
+
+   The Delegated-IPv6-Prefix MUST NOT appear in any other RADIUS
+   packets.
+
+4.  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+      0+     0      0         0+          123 Delegated-IPv6-   |
+   |                                                 Prefix            |
+   +-------------------------------------------------------------------+
+
+   The meaning of the above table entries is as follows:
+      0   This attribute MUST NOT be present.
+      0+  Zero or more instances of this attribute MAY be present.
+      0-1 Zero or one instance of this attribute MAY be present.
+      1   Exactly one instance of this attribute MUST be present.
+      1+  One or more of these attributes MUST be present.
+
+5.  Diameter Considerations
+
+   When used in Diameter, the attribute defined in this specification
+   can be used as a Diameter AVP from the Code space 1-255, i.e., RADIUS
+   attribute compatibility space.  No additional Diameter Code values
+   are therefore allocated.  The data types of the attributes are as
+   follows:
+
+        Delegated-IPv6-Prefix             OctetString
+
+   The attribute in this specification has no special translation
+   requirements for Diameter to RADIUS or RADIUS to Diameter gateways,
+   i.e., the attribute is copied as is, except for changes relating to
+   headers, alignment, and padding.  See also RFC 3588 [5], Section 4.1,
+   and RFC 4005 [6], Section 9.
+
+   The text in this specification describing the applicability of the
+   Delegated-IPv6-Prefix attribute for RADIUS Access-Request applies in
+   Diameter to AA-Request [6] or Diameter-EAP-Request [7].
+
+   The text in this specification describing the applicability of the
+   Delegated-IPv6-Prefix attribute for RADIUS Access-Accept applies in
+   Diameter to AA-Answer or Diameter-EAP-Answer that indicates success.
+
+
+
+Salowey & Droms             Standards Track                     [Page 4]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+   The text in this specification describing the applicability of the
+   Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request applies
+   to Diameter Accounting-Request [6] as well.
+
+   The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:
+
+                                      +---------------------+
+                                      |    AVP Flag rules   |
+                                      |----+-----+----+-----|----+
+                     AVP              |    |     |SHLD| MUST|    |
+     Attribute Name  Code  Value Type |MUST| MAY | NOT|  NOT|Encr|
+     ---------------------------------|----+-----+----+-----|----|
+     Delegated-IPv6- 123   OctetString| M  |  P  |    |  V  | Y  |
+       Prefix                         |    |     |    |     |    |
+     ---------------------------------|----+-----+----+-----|----|
+
+6.  IANA Considerations
+
+   IANA assigned a Type value, 123, for this attribute from the RADIUS
+   Attribute Types registry.
+
+7.  Security Considerations
+
+   Known security vulnerabilities of the RADIUS protocol are discussed
+   in RFC 2607 [8], RFC 2865 [1], and RFC 2869 [9].  Use of IPsec [10]
+   for providing security when RADIUS is carried in IPv6 is discussed in
+   RFC 3162.
+
+   Security considerations for the Diameter protocol are discussed in
+   RFC 3588 [5].
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [2]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+        Configuration Protocol (DHCP) version 6", RFC 3633, December
+        2003.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 5]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+9.2.  Informative References
+
+   [4]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162,
+        August 2001.
+
+   [5]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
+        "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [6]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
+        Network Access Server Application", RFC 4005, August 2005.
+
+   [7]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
+        Authentication Protocol (EAP) Application", RFC 4072, August
+        2005.
+
+   [8]  Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+        Implementation in Roaming", RFC 2607, June 1999.
+
+   [9]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
+        RFC 2869, June 2000.
+
+   [10] Kent, S. and K. Seo, "Security Architecture for the Internet
+        Protocol", RFC 4301, December 2005.
+
+Authors' Addresses
+
+   Joe Salowey
+   Cisco Systems, Inc.
+   2901 Third Avenue
+   Seattle, WA  98121
+   USA
+
+   Phone: +1 206.310.0596
+   EMail: jsalowey@cisco.com
+
+
+   Ralph Droms
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   Phone: +1 978.936.1674
+   EMail: rdroms@cisco.com
+
+
+
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 6]
+
+RFC 4818            Delegated-IPv6-Prefix Attribute           April 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Salowey & Droms             Standards Track                     [Page 7]
+