idnits 2.17.1 draft-salowey-radext-delegated-prefix-01.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 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 202. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (September 2005) is 6795 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) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '7') ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 3 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 Expires: March 5, 2006 Cisco Systems, Inc. 5 September 2005 7 RADIUS Delegated-IPv6-Prefix Attribute 8 draft-salowey-radext-delegated-prefix-01.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 March 5, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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]. This is different from the usage of Framed-IPv6- 50 Prefix attribute in which the prefix remains in control of the 51 Network Access Server (NAS). The prefix in the Framed-IPv6-Prefix 52 attribute can be assigned to a link to which the NAS is attached, and 53 may subsequently be advertised through Router Advertisement messages 54 [3]. 56 The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and 57 can appear multiple times. It MAY be used in an Access-Request 58 packet as a hint by the NAS to the server that it would prefer these 59 prefix(es), but the server is not required to honor the hint. 61 2. Terminology 63 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 64 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 65 interpreted as described in RFC 2119 [4]. 67 3. Attribute format 69 The format of the Delegated-IPv6-Prefix is: 71 0 1 2 3 72 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 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | Type | Length | Reserved | Prefix-Length | 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 Prefix 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 Prefix 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 Prefix 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 Prefix | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 Type 87 TBD for Delegated-IPv6-Prefix 89 Length 91 At least 4 and no larger than 20 93 Reserved 95 Always set to zero 97 Prefix-Length 99 The length of the prefix, in bits. At least 0 and no larger 100 than 128 102 Note that the prefix field is only required to be long enough to hold 103 the prefix bits and can be shorter than 16 bytes. Any bits in the 104 prefix field that are not part of the prefix MUST be zero. 106 The definition of the Delegated-IPv6-Prefix Attribute is based on the 107 Framed-IPv6-Prefix attribute. 109 The following table describes which messages the Delegated-IPv6- 110 Prefix attribute can appear in and in what quantity. 112 Request Accept Challenge Reject Accounting # Attribute 113 Request 114 0+ 0+ 0 0 0+ TBD Delegated-IPv6-Prefix 116 In this table 0 indicates that an attribute MUST NOT be present in 117 the packet and 0+ means that zero or more instances of this attribute 118 MAY be present in packet. 120 4. IANA Considerations 122 IANA is requested to assign a Type value, TBD, for this attribute 123 from the RADIUS Types registry. 125 5. Security Considerations 127 Known security vulnerabilities of the RADIUS protocol are discussed 128 in RFC 2607 [5], RFC 2865 [6] and RFC 2869 [7]. Use of IP SEC [8] 129 for providing security when RADIUS is carried in IPv6 is discussed in 130 RFC 3162 [1]. 132 6. Normative References 134 [1] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 135 August 2001. 137 [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 138 Configuration Protocol (DHCP) version 6", RFC 3633, 139 December 2003. 141 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 142 for IP Version 6 (IPv6)", RFC 2461, December 1998. 144 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 145 Levels", BCP 14, RFC 2119, March 1997. 147 [5] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 148 Implementation in Roaming", RFC 2607, June 1999. 150 [6] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 151 Authentication Dial In User Service (RADIUS)", RFC 2865, 152 June 2000. 154 [7] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 155 RFC 2869, June 2000. 157 [8] Kent, S. and R. Atkinson, "Security Architecture for the 158 Internet Protocol", RFC 2401, November 1998. 160 Authors' Addresses 162 Joe Salowey 163 Cisco Systems, Inc. 164 2901 Third Avenue 165 Seattle, WA 98121 166 USA 168 Phone: +1 206.310.0596 169 Email: jsalowey@cisco.com 171 Ralph Droms 172 Cisco Systems, Inc. 173 1414 Massachusetts Avenue 174 Boxborough, MA 01719 175 USA 177 Phone: +1 978.936.1674 178 Email: rdroms@cisco.com 180 Intellectual Property Statement 182 The IETF takes no position regarding the validity or scope of any 183 Intellectual Property Rights or other rights that might be claimed to 184 pertain to the implementation or use of the technology described in 185 this document or the extent to which any license under such rights 186 might or might not be available; nor does it represent that it has 187 made any independent effort to identify any such rights. Information 188 on the procedures with respect to rights in RFC documents can be 189 found in BCP 78 and BCP 79. 191 Copies of IPR disclosures made to the IETF Secretariat and any 192 assurances of licenses to be made available, or the result of an 193 attempt made to obtain a general license or permission for the use of 194 such proprietary rights by implementers or users of this 195 specification can be obtained from the IETF on-line IPR repository at 196 http://www.ietf.org/ipr. 198 The IETF invites any interested party to bring to its attention any 199 copyrights, patents or patent applications, or other proprietary 200 rights that may cover technology that may be required to implement 201 this standard. Please address the information to the IETF at 202 ietf-ipr@ietf.org. 204 The IETF has been notified of intellectual property rights claimed in 205 regard to some or all of the specification contained in this 206 document. For more information consult the online list of claimed 207 rights. 209 Disclaimer of Validity 211 This document and the information contained herein are provided on an 212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 214 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 215 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 216 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 219 Copyright Statement 221 Copyright (C) The Internet Society (2005). This document is subject 222 to the rights, licenses and restrictions contained in BCP 78, and 223 except as set forth therein, the authors retain all their rights. 225 Acknowledgment 227 Funding for the RFC Editor function is currently provided by the 228 Internet Society.