--- 1/draft-ietf-ipv6-prefix-delegation-requirement-00.txt 2006-02-05 00:03:04.000000000 +0100 +++ 2/draft-ietf-ipv6-prefix-delegation-requirement-01.txt 2006-02-05 00:03:04.000000000 +0100 @@ -1,149 +1,214 @@ -Internet Engineering Task Force Shin Miyakawa -INTERNET-DRAFT NTT Communications - - -Expires: May 1, 2003 - Nov 1, 2002 +Network Working Group S. Miyakawa +Internet-Draft NTT Communications Corporation +Expires: Aug 25, 2003 R. Droms + Cisco Systems + Feb 2003 Requirements for IPv6 prefix delegation + draft-ietf-ipv6-prefix-delegation-requirement-01.txt Status of this Memo -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as ``work in progress.'' + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." -To view the list Internet-Draft Shadow Directories, see + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. -Distribution of this memo is unlimited. + This Internet-Draft will expire on Aug 25, 2003. -The internet-draft will expire in 6 months. The date of expiration will -be May 1, 2003. +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract - This document describes requirements about how an IPv6 address prefix + This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). -Motivation +1. Introduction - With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs - are ready to offer their services to the public in conjunction with - widely deployed IP subscription method such as ADSL and so on. But, - thinking about following situation of IPv6 commercial service as one - of the most likely examples, + With the deployment of IPv6 [2], several Internet Service Providers + are ready to offer IPv6 access to the public. In conjunction with + widely deployed "always on" media as ADSL, and the expectation that + customers will be assigned a /48 IPv6 address prefix, an efficient + mechanism for delegating address prefixes to the customers sites is + needed. The delegation mechanism will be intended to automate the + process of informing the customer's networking equipment of the + prefixes to be used at the customer's site. - IPv6 ISP router - | - | point-to-point link - | - User's Site router - | - ----+----- User's Site Network + This document clarifies the requirements for IPv6 address prefix + delegation from the ISP to the site. - though it is needed a standardized way to delegate one or more IPv6 - address prefix(es) from the IPv6 ISP to the User's site - automatically, it is not identified clearly yet. +2. Requirements - Originally, it seemed that just RA (Router Avertisement) considered - as good enough to be used for P-P link between ISP and User's site, - but according to the NCCs' recommendations, one site should be - delegated /48 usually. + 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 RFC2119 [1]. - So, ISP which now would like to start its own IPv6 commercial service - TODAY, need to have some method other than RA protocol which only can - handle one signle /64 prefix but something else or enhanced +3. Scenario and terminology - - to delegate not just one signle /64 prefix to the user - to satisfy - all the other (standard) requirements which is needed to realize - commercial service + The following figure illustrates a likely example for the + organization of a network providing subscription IPv6 service: - Therefore, this documents clarifies requirements for IPv6 address - prefix delegation from the ISP to the site, especially from the - (commercial) ISP point of view to boost IPv6 business quick as - possible. + /------\ + / \ + + | + / \ / + +---------------+ +--------+/ \------/ + |ISP Edge Router|Point-to-point|Customer+ + | +--------------+ Router | Customer networks + | (PE) | link | (CPE) + + +---------------+ +--------+\ /------\ + \ / \ + + | + \ / + \------/ - Requirements for prefix delegation management - Focusing commercial IPv6 ISP service, there are several kinds of - category of requirements for the mechanism / protocol to delegate one - or more IPv6 prefixes from ISP to a site. + Illustration of ISP-customer network architecture - - layer 2 consideration + Terminology: - The method should work on any layer 2 technologies. In other words, + PE Provider edge device; the device at which the link to the customer + site is terminated + + CPE Customer provided equipment; the device at the customer site at + which the link to the ISP is terminated + +4. Requirements for Prefix Delegation + + The purpose of the prefix delegation mechanism is to communicate + prefixes to the CPE automatically. + +4.1 Number and Length of Delegated Prefixed + + The prefix delegation mechanism SHOULD allow for delegation of + prefixes of length /48, /64 and other lengths, and SHOULD allow for + delegation of more than one prefix to the customer. + +4.2 Use of Delegated Prefixes in Customer Network + + The prefix delegation mechanism MUST NOT prohibit or inhibit the + assignment of longer prefixes, created from the delegated prefixes, + to links within the customer network. It is not a requirement that + the prefix delegation mechanism provide for the reporting of prefix + delegation within the customer network back to the ISP. + +4.3 Automated Assignment + + The prefix delegation mechanism SHOULD allow for long-lived pre- + assignment of one or more prefix(es) to a customer and for + automated, possibly short-lived assignment of a prefix to a customer + on demand. + +4.4 Policy-based Assignment + + The prefix delegation mechanism SHOULD allow for the use of policy in + assigning prefixes to a customer. For example, the customer's + identity and type of subscribed service may be used to determine the + address block from which the customer's prefix is selected, and the + length of the prefix assigned to the customer. + +4.5 Security and Authentication + + The prefix delegation mechanism MUST provide for reliable + authentication of the identity of the customer to which the prefixes + are to be assigned, and MUST provide for reliable, secure + transmission of the delegated prefixes to the customer. + +4.6 Accounting + + The prefix delegation mechanism MUST allow for the ISP to provide + accounting information about delegated prefixes. + +4.7 Layer 2 Considerations + + The method SHOULD work on any layer 2 technologies. In other words, it should be layer 2 technology independent. Though, at the same time, it should be noted that now ISP would like to have a solution for Point-to-Point link which has own authentication mechanism first. PPP link with CHAP authentication is a good example. (Simulated) Ethernet and IEEE802.11 (wireless LAN) should be covered in near future, but they have low priority (just) for now. It should be clarified that the method should work with all L2 protocols either with authentication mechanism or without, but ISP would like to take advantage of a L2 protocol's authentication mechanism if it exits. - - accounting +5. IANA Considerations - It should provide accounting capability such as logging about by - whom, when and what prefix(es) is used for the service with proper - authentication techniques. + There are no IANA considerations in this document. - - kinds of prefixes +6. Security considerations - It should be able to delegate both statically and dynamically - assigned prefix assignment by authenticated identification, depended - by resources and/or any reasons. + Section 4.5 specifies security requirements for the prefix delegation + mechanism. - - negotiation between ISP and site +References - ISP may deny the service, due to various reasons such as there is no - contract or bad financial credit etc. Also ISP should be able to use - one single technique to pass parameters of the prefix such as scope - (global and/or site), prefix length (/48, /64 or any other length) - and any other appropriate related information to the site. On the - other hand, a site should be able to request multiple prefixes to the - ISP. Also a site should be able to pass parameters of the prefix - such as scope (global and/or site), prefix length (/48, /64 or any - other length), number of prefixes and so on to the ISP to negotiate. + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. - - less impact on ISP equipments + [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. - ISP usualy use some kind of equipment to provide subscription service - to the users such as access concentrating router, PPP server and so - on. This may aggregate thousands or more connections toward the - ISP's backbone. Prefix delegation mechanism must be compatible with - this situation. +Author's Address - References Deering, 1998. S. Deering and R. Hinden, "Internet - Protocol, Version 6 (IPv6) Specification", RFC2460 (December 1998). + Shin Miyakawa + Innovative IP Architecture Center, NTT Communications Corporation + Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo, + Japan + Phone: +81-3-6800-3262 + EMail: miyakawa@nttv6.jp -History - Jun 2002, first draft was presented as personal submission. - At the IETF-54th at Yokohama, it became a working group draft. - Nov 2003, the draft published as -01 draft. + Ralph Droms + Cisco Systems + 300 Apollo Drive + Chelmsford, MA 01886 + Phone: +1-978-497-4733 + EMail: rdroms@cisco.com -Acknowledgements - People in Internet Association of Japan have gave me a lot of good input. - Team members of NTT Communications IPv6 project, especially Toshi Yamasaki - and Yasuhiro Shirasaki, gave me quite useful suggestions for this - document. Chairs of IETF IPv6 working group especially Bob Hinden - who gave me a good suggestions before I submitted this draft. - Also communications with other folks in the IPv6 community, such - as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have - been quite helpful. Thanks a lot. +Full Copyright Statement -Author's address - Shin Miyakawa, Ph.D - Innovative IP Architecture Center, NTT Communications Corporation - Tokyo, Japan - Tel: +81-3-6800-3262 - Fax: +81-3-5265-2990 - Email: miyakawa@nttv6.jp + Copyright (C) The Internet Society (2003). 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.