idnits 2.17.1 draft-ietf-radext-delegated-prefix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 210. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3633 (ref. '2') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '6') ** Obsolete normative reference: RFC 2401 (ref. '7') (Obsoleted by RFC 4301) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft R. Droms 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 29, 2006 February 25, 2006 7 RADIUS Delegated-IPv6-Prefix Attribute 8 draft-ietf-radext-delegated-prefix-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is 42 to be delegated to the user. 44 1. Introduction 46 The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated to 47 the user. For example, the prefix in a Delegated-IPv6-Prefix 48 attribute can be delegated to another node through DHCP Prefix 49 Delegation [2]. 51 The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and 52 can appear multiple times. It MAY be used in an Access-Request 53 packet as a hint by the NAS to the server that it would prefer these 54 prefix(es), but the server is not required to honor the hint. 56 2. Terminology 58 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 59 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 60 interpreted as described in RFC 2119 [3]. 62 3. Attribute format 64 The format of the Delegated-IPv6-Prefix is: 66 0 1 2 3 67 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 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 69 | Type | Length | Reserved | Prefix-Length | 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 Prefix 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 Prefix 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 Prefix 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 Prefix | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 Type 82 TBD for Delegated-IPv6-Prefix 84 Length 86 At least 4 and no larger than 20 88 Reserved 90 Always set to zero 92 Prefix-Length 94 The length of the prefix, in bits. At least 0 and no larger 95 than 128 97 Note that the prefix field is only required to be long enough to hold 98 the prefix bits and can be shorter than 16 bytes. Any bits in the 99 prefix field that are not part of the prefix MUST be zero. 101 The definition of the Delegated-IPv6-Prefix Attribute is based on the 102 Framed-IPv6-Prefix attribute. 104 The following table describes which messages the Delegated-IPv6- 105 Prefix attribute can appear in and in what quantity. 107 Request Accept Challenge Reject Accounting # Attribute 108 Request 109 0+ 0+ 0 0 0+ TBD Delegated-IPv6-Prefix 111 In this table 0 indicates that an attribute MUST NOT be present in 112 the packet and 0+ means that zero or more instances of this attribute 113 MAY be present in packet. 115 4. IANA Considerations 117 IANA is requested to assign a Type value, TBD, for this attribute 118 from the RADIUS Types registry. 120 5. Security Considerations 122 Known security vulnerabilities of the RADIUS protocol are discussed 123 in RFC 2607 [4], RFC 2865 [5] and RFC 2869 [6]. Use of IP SEC [7] 124 for providing security when RADIUS is carried in IPv6 is discussed in 125 RFC 3162 [1]. 127 6. Normative References 129 [1] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 130 August 2001. 132 [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 133 Configuration Protocol (DHCP) version 6", RFC 3633, 134 December 2003. 136 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 137 Levels", BCP 14, RFC 2119, March 1997. 139 [4] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 140 Implementation in Roaming", RFC 2607, June 1999. 142 [5] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 143 Authentication Dial In User Service (RADIUS)", RFC 2865, 144 June 2000. 146 [6] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 147 RFC 2869, June 2000. 149 [7] Kent, S. and R. Atkinson, "Security Architecture for the 150 Internet Protocol", RFC 2401, November 1998. 152 Authors' Addresses 154 Joe Salowey 155 Cisco Systems, Inc. 156 2901 Third Avenue 157 Seattle, WA 98121 158 USA 160 Phone: +1 206.310.0596 161 Email: jsalowey@cisco.com 163 Ralph Droms 164 Cisco Systems, Inc. 165 1414 Massachusetts Avenue 166 Boxborough, MA 01719 167 USA 169 Phone: +1 978.936.1674 170 Email: rdroms@cisco.com 172 Full Copyright Statement 174 Copyright (C) The Internet Society (2006). 176 This document is subject to the rights, licenses and restrictions 177 contained in BCP 78, and except as set forth therein, the authors 178 retain all their rights. 180 This document and the information contained herein are provided on an 181 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 182 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 183 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 184 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 185 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 186 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 188 Intellectual Property 190 The IETF takes no position regarding the validity or scope of any 191 Intellectual Property Rights or other rights that might be claimed to 192 pertain to the implementation or use of the technology described in 193 this document or the extent to which any license under such rights 194 might or might not be available; nor does it represent that it has 195 made any independent effort to identify any such rights. Information 196 on the procedures with respect to rights in RFC documents can be 197 found in BCP 78 and BCP 79. 199 Copies of IPR disclosures made to the IETF Secretariat and any 200 assurances of licenses to be made available, or the result of an 201 attempt made to obtain a general license or permission for the use of 202 such proprietary rights by implementers or users of this 203 specification can be obtained from the IETF on-line IPR repository at 204 http://www.ietf.org/ipr. 206 The IETF invites any interested party to bring to its attention any 207 copyrights, patents or patent applications, or other proprietary 208 rights that may cover technology that may be required to implement 209 this standard. Please address the information to the IETF at 210 ietf-ipr@ietf.org. 212 Acknowledgment 214 Funding for the RFC Editor function is provided by the IETF 215 Administrative Support Activity (IASA).