idnits 2.17.1 draft-ietf-ipv6-prefix-delegation-requirement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 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 9, 2004) is 7344 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 informational reference (is this intentional?): RFC 2460 (ref. '1') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '2') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '3') (Obsoleted by RFC 4291) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Miyakawa 3 Internet-Draft NTT Communications Corporation 4 Expires: August 9, 2004 R. Droms 5 Cisco 6 February 9, 2004 8 Requirements for IPv6 prefix delegation 9 draft-ietf-ipv6-prefix-delegation-requirement-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 9, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes requirements for how IPv6 address prefixes 40 should be delegated to an IPv6 subscriber's network (or "site"). 42 1. Introduction 44 With the deployment of IPv6 [1], several Internet Service Providers 45 are ready to offer IPv6 access to the public. In conjunction with 46 widely deployed "always on" media such as ADSL and the expectation 47 that customers will be assigned a /48 IPv6 unicast address prefix 48 (see RFC3513 [3] and section 3 of RFC3177 [2]), an efficient 49 mechanism for delegating address prefixes to the customers sites is 50 needed. The delegation mechanism will be intended to automate the 51 process of informing the customer's networking equipment of the 52 prefixes to be used at the customer's site. 54 This document clarifies the requirements for IPv6 address prefix 55 delegation from the ISP to the site. 57 2. Scenario and terminology 59 The following figure illustrates a likely example for the 60 organization of a network providing subscription IPv6 service: 62 /------\ 63 / \ 64 + | 65 / \ / 66 +---------------+ +--------+/ \------/ 67 |ISP Edge Router|Point-to-point|Customer+ 68 | +--------------+ Router | Customer networks 69 | (PE) | link | (CPE) + 70 +---------------+ +--------+\ /------\ 71 \ / \ 72 + | 73 \ / 74 \------/ 76 Figure 1: Illustration of ISP-customer network architecture 78 Terminology: 80 PE: Provider edge device; the device connected to the service 81 provider's network infrastructure at which the link to the 82 customer site is terminated 84 CPE: Customer premises equipment; the device at the customer site at 85 which the link to the ISP is terminated 87 3. Requirements for Prefix Delegation 89 The purpose of the prefix delegation mechanism is to delegate and 90 manage prefixes to the CPE automatically. 92 3.1 Number and Length of Delegated Prefixes 94 The prefix delegation mechanism should allow for delegation of 95 prefixes of lengths between /48 and /64, inclusively. Other lengths 96 should also be supported. The mechanism should allow for delegation 97 of more than one prefix to the customer. 99 3.2 Use of Delegated Prefixes in Customer Network 101 The prefix delegation mechanism must not prohibit or inhibit the 102 assignment of longer prefixes, created from the delegated prefixes, 103 to links within the customer network. The prefix delegation mechanism 104 is not required to report any prefix delegations within the 105 customer's network back to the ISP. 107 3.3 Static and Dynamic Assignment 109 The prefix delegation mechanism should allow for long-lived static 110 pre-assignment of prefixes and for automated, possibly short-lived 111 on-demand dynamic assignment of prefixes to a customer. 113 3.4 Policy-based Assignment 115 The prefix delegation mechanism should allow for the use of policy in 116 assigning prefixes to a customer. For example, the customer's 117 identity and type of subscribed service may be used to determine the 118 address block from which the customer's prefix is selected, and the 119 length of the prefix assigned to the customer. 121 3.5 Expression of Requirements or Preferences by the CPE 123 The CPE must be able to express requirements or preferences in its 124 request to the PE. For example, the CPE should be able to express a 125 preference for a prefix length. 127 3.6 Security and Authentication 129 The prefix delegation mechanism must provide for reliable 130 authentication of the identity of the customer to which the prefixes 131 are to be assigned, and must provide for reliable, secure 132 transmission of the delegated prefixes to the customer. 134 The prefix delegation should provide for reliable authentication of 135 the identity of the service provider's edge router. 137 3.7 Accounting 139 The prefix delegation mechanism must allow for the ISP to obtain 140 accounting information about delegated prefixes from the PE. 142 3.8 Hardware technology Considerations 144 The prefix delegation mechanism should work on any hardware link 145 technology between the PE and the CPE and should be hardware 146 technology independent. The mechanism must work on shared links. The 147 mechanism should work with all hardware technologies either with an 148 authentication mechanism or without, but ISPs would like to take 149 advantage of the hardware technology's authentication mechanism if it 150 exists. 152 4. IANA Considerations 154 There are no IANA considerations in this document. 156 5. Security considerations 158 Section 3.6 specifies security requirements for the prefix delegation 159 mechanism. For point to point links, where one trusts that there is 160 no man in the middle, or one trusts layer two authentication, 161 authentication may not be necessary. 163 A rogue PE can issue bogus prefixes to a requesting router. This may 164 cause denial of service due to unreachability. 166 A rogue CPE may be able to mount a denial of service attack by 167 repeated requests for delegated prefixes that exhaust the PE's 168 available prefixes. 170 6. Acknowledgments 172 The authors would like to express our thanks to Randy Bush, Thomas 173 Narten, Micheal Py, Pekka Savola, Dave Thaler, as well as other 174 members of the IPv6 working group and the IESG for their review and 175 constructive comnents and to the people in the IPv6 operation group 176 of the Internet Association of Japan and NTT Communications IPv6 177 project, especially Toshi Yamasaki and Yasuhiro Shirasaki for their 178 original discussion and suggestions. 180 Informative References 182 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 183 Specification", RFC 2460, December 1998. 185 [2] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 186 3177, September 2001. 188 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 189 Addressing Architecture", RFC 3513, April 2003. 191 Authors' Addresses 193 Shin Miyakawa 194 NTT Communications Corporation 195 Tokyo 196 Japan 198 Phone: +81-3-6800-3262 199 EMail: miyakawa@nttv6.jp 201 Ralph Droms 202 Cisco 203 1414 Massachusetts Avenue 204 Boxborough, MA 01719 205 USA 207 Phone: +1 978.936.1674 208 EMail: rdroms@cisco.com 210 Intellectual Property Statement 212 The IETF takes no position regarding the validity or scope of any 213 intellectual property or other rights that might be claimed to 214 pertain to the implementation or use of the technology described in 215 this document or the extent to which any license under such rights 216 might or might not be available; neither does it represent that it 217 has made any effort to identify any such rights. Information on the 218 IETF's procedures with respect to rights in standards-track and 219 standards-related documentation can be found in BCP-11. Copies of 220 claims of rights made available for publication and any assurances of 221 licenses to be made available, or the result of an attempt made to 222 obtain a general license or permission for the use of such 223 proprietary rights by implementors or users of this specification can 224 be obtained from the IETF Secretariat. 226 The IETF invites any interested party to bring to its attention any 227 copyrights, patents or patent applications, or other proprietary 228 rights which may cover technology that may be required to practice 229 this standard. Please address the information to the IETF Executive 230 Director. 232 Full Copyright Statement 234 Copyright (C) The Internet Society (2004). All Rights Reserved. 236 This document and translations of it may be copied and furnished to 237 others, and derivative works that comment on or otherwise explain it 238 or assist in its implementation may be prepared, copied, published 239 and distributed, in whole or in part, without restriction of any 240 kind, provided that the above copyright notice and this paragraph are 241 included on all such copies and derivative works. However, this 242 document itself may not be modified in any way, such as by removing 243 the copyright notice or references to the Internet Society or other 244 Internet organizations, except as needed for the purpose of 245 developing Internet standards in which case the procedures for 246 copyrights defined in the Internet Standards process must be 247 followed, or as required to translate it into languages other than 248 English. 250 The limited permissions granted above are perpetual and will not be 251 revoked by the Internet Society or its successors or assignees. 253 This document and the information contained herein is provided on an 254 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 255 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 256 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 257 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 258 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Acknowledgment 262 Funding for the RFC Editor function is currently provided by the 263 Internet Society.