idnits 2.17.1 draft-miyakawa-ipv6-prefix-delegation-requirement-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages -- Found 5 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 24, 2002) is 7948 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) -- Missing reference section? 'Deering' on line 40 looks like a reference -- Missing reference section? '1998' on line 40 looks like a reference -- Missing reference section? 'RFC2460' on line 110 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Shin Miyakawa 3 INTERNET-DRAFT NTT Communications 4 6 Expires: December 24, 2002 7 June 24, 2002 9 Requirements for IPv6 prefix delegation 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 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 material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be December 24, 2002. 33 Abstract 35 This document describes requirements about how an IPv6 address prefix 36 should be delegated to an IPv6 subscriber's network (or "site"). 38 1. Motivation 40 With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs 41 are ready to offer their services to the public in conjunction with 42 widely deployed IP subscription method such as ADSL and so on. But, 43 thinking about following situation of IPv6 commercial service as one 44 of the most likely examples, 46 IPv6 ISP router 47 | 49 | point-to-point link 50 | 52 User's Site router 53 | 55 ----+----- User's Site Network 57 though it is needed a standardized way to delegate one or more IPv6 58 address prefix(es) from the IPv6 ISP to the User's site 59 automatically, it is not identified clearly yet. 61 Therefore, this documents clarifies requirements for IPv6 address 62 prefix delegation from the ISP to the site, especially from the 63 (commercial) ISP point of view to boost IPv6 business quick as 64 possible. 66 2. Requirements for prefix delegation management 68 Focusing commercial IPv6 ISP service, there are several kinds of 69 category of requirements for the mechanism / protocol to delegate one 70 or more IPv6 prefixes from ISP to a site. 72 - layer 2 consideration 74 The method should work on any layer 2 technologies. In other words, 75 it should be layer 2 technology independent. Though, at the same 76 time, it should be noted that now ISP would like to have a solution 77 for Point-to-Point link which has own authentication mechanism first. 78 PPP link with CHAP authentication is a good example. (Simulated) 79 Ethernet and IEEE802.11 (wireless LAN) should be covered in near 80 future, but they have low priority (just) for now. It should be 81 clarified that the method should work with all L2 protocols either 82 with authentication mechanism or without, but ISP would like to take 83 advantage of a L2 protocol's authentication mechanism if it exits. 85 - accounting 86 It should provides accounting capability such as logging about by 87 whom, when and what prefix(es) is used for the service with proper 88 authentication techniques. 90 - kinds of prefixes 92 It should be able to delegate both statically and dynamically 93 assigned prefix assignment by authenticated identification, depended 94 by resources and/or any reasons. 96 - negotiation between ISP and site 98 ISP may deny the service, due to various reasons such as there is no 99 contract or bad financial credit etc. Also ISP should be able to use 100 one single technique to pass parameters of the prefix such as scope 101 (global and/or site), prefix length (/48, /64 or any other length) 102 and any other appropriate related information to the site. On the 103 other hand, a site should be able to request multiple prefixes to the 104 ISP. Also a site should be able to pass parameters of the prefix 105 such as scope (global and/or site), prefix length (/48, /64 or any 106 other length), number of prefixes and so on to the ISP to negotiate. 108 3. References 110 [RFC2460] 111 Deering, 1998. S. Deering and R. Hinden, "Internet Protocol, Ver- 112 sion 6 (IPv6) Specification", RFC2460 (December 1998). 114 Acknowledgements 116 People in Internet Association of Japan have gave me a lot of good input. 117 Team members of NTT Communications IPv6 project, especially Toshi Yamasaki 118 and Yasuhiro Shirasaki, gave me quite useful suggestions for this 119 document. Chairs of IETF IPv6 working group especially Bob Hinden 120 who gave me a good suggestions before I submitted this draft. 121 Also communications with other folks in the IPv6 community, such 122 as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have 123 been quite helpful. Thanks a lot. 125 Author's address 127 Shin Miyakawa, Ph.D 128 Innovative IP Architecture Center, NTT Communications Corporation 129 Tokyo, Japan 130 Tel: +81-3-6800-3262 131 Fax: +81-3-5265-2990 132 Email: miyakawa@nttv6.jp