idnits 2.17.1 draft-itojun-ipv6-dialup-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '...ge. /128 assignment MUST NOT be made,...' 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 (July 13, 2000) is 8681 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 42 looks like a reference -- Missing reference section? '1998' on line 42 looks like a reference -- Missing reference section? 'McGregor' on line 47 looks like a reference -- Missing reference section? '1992' on line 47 looks like a reference -- Missing reference section? 'Hagino' on line 161 looks like a reference -- Missing reference section? '2000' on line 161 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jun-ichiro itojun Hagino 2 INTERNET-DRAFT IIJ Research Laboratory 3 Expires: January 13, 2001 Kazu YAMAMOTO 4 IIJ Research Laboratory 5 July 13, 2000 7 Requirements for IPv6 dialup PPP operation 8 draft-itojun-ipv6-dialup-requirement-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 The internet-draft will expire in 6 months. The date of expiration will 33 be January 13, 2001. 35 Abstract 37 The memo tries to identify design choices in IPv6 dialup PPP services by 38 ISPs. 40 1. Problem domain 42 With the deployment of IPv6 [Deering, 1998] , it becomes more apparent 43 that we have different operational requirements in IPv6 dialup PPP 44 operation, from IPv4 dialup PPP operation. For example, it would be 45 desirable to see static address allocation, rather than dynamic address 46 allocation, whenever possible. With IPv4 this has been impossible due 47 to address space shortage, and IPCP [McGregor, 1992] dynamic address 48 allocation has been used. With IPv6 it is possible to perform static 49 address allocation from ISPs to downstream customers, as there's enough 50 address to spare. 52 The document tries to summarize possible design choices in IPv6 dialup 53 PPP operation. Actual operational practices should be documented 54 separately. 56 2. Design choices 58 2.1. The usage pattern 60 o Static clients. Computers located in home and offices do not usually 61 change its configurations, nor upstream ISPs. It would be desirable 62 to make a static address allocation in this case. 64 o Roaming clients. Roaming clients, like travelling users with notebook 65 PC, have different requirement from static clients. It is not usually 66 possible to make a static address allocation, as travelling users may 67 connet to multiple ISPs from different countries. 69 2.2. Address space 71 It is desired to assign /48 address space, regardless from usage pattern 72 or size of the downstream site. It is to make future renumbering in 73 downstream site easier on ISP change. /128 assignment MUST NOT be made, 74 as it will advocate IPv6-to-IPv6 NAT. 76 2.3. Address allocation 78 o Static address allocation. ISPs will allocate a static address space 79 (/48) to a downstream customer, on contract time. There will be no 80 protocol involved in address allocation - allocation will be informed 81 by paper. 83 o Static address allocation, with some automation. It may be possible 84 to define a common protocol for configuring customer-side router(s) 85 from the upstream ISP, eliminating necessity of paper-based allocation 86 and configuration labor in the customer site. Note that router 87 renumbering protocol is not always suitable for this. Router 88 renumbering protocol assumes that the routers and control node to be 89 in the same administrative domain. 91 o Dynamic address allocation. 93 2.4. Where to assign address 95 o Assign address to ppp interface. The form assigns /128 to the 96 customer computer, or /64 onto the PPP link. The form of address 97 assignment should not be used, as it advocates IPv6-to-IPv6 NAT. In 98 the following diagram, "Lx" denotes link-local address, and "Gx" 99 denotes global address. 101 ISP router 102 |La, Ga 103 | ppp link 104 |Lb, Gb 105 Customer computer 107 o Assign address to the interface behind the customer router. The form 108 assigns /64 to the network segment behind customer router. 110 ISP router 111 |La 112 | ppp link 113 |Lb 114 Customer router 115 |Gb 116 ==+=== Gx/64 118 In the cases where the customer has only a single computer, it is 119 possible to have virtual network segment behind the customer computer. 121 ISP router 122 |La 123 | ppp link 124 |Lb 125 Customer computer 126 |Gb 127 ==+=== Gx/64 (VIRTUAL) 129 Note that, however, /64 assignment will make it harder for customer 130 site to evolve in the future. /64 assignment is not recommended. 132 o Assign address to the cloud behind the customer router (/48). In this 133 case, the upstream ISP has no idea about the topology in the customer 134 site. Actually, it is not necessary for the upstream ISP to know 135 about the address usage in the customer site. Static address 136 assignment is highly recommended in this case, as it is painful to 137 renumber the whole /48 cloud every time we reconnect the dialup PPP 138 link between the ISP and the customer site. 140 ISP router 141 |La 142 | ppp link 143 |Lb 144 Customer router 145 |Gb 146 (((Gx/48 cloud))) 148 2.5. Routing 150 o Static routing. ISPs will configure static route, pointing to the 151 customer site, for the address space assigned to the customer site. 152 Customer router (or customer computer) will install default route, 153 pointing to the ISP router via PPP link. 155 o Simple dynamic routing. ISPs can exchange routes by using simple 156 dynamic routing protocols like RIPng. This allows the customer site 157 to adapt to PPP link status better. This also makes it easier to 158 detect PPP link disconnection. If the ISP announces non-default 159 routes to the downstream customer, it may help downstream to configure 160 multihomed connectivity (connection to multiple upstream ISPs) 161 [Hagino, 2000] ISPs may want to filter out bogus routing announcements 162 from the downstream. 164 3. Security considerations 166 The document talks about no security issues. 168 References 170 Deering, 1998. 171 S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 172 Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in- 173 notes/rfc2460.txt. 175 McGregor, 1992. 176 G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in 177 RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt. 179 Hagino, 2000. 180 Jun-ichiro Hagino, "IPv6 multihoming support at site exit routers" in 181 draft-ietf-ipngwg-ipv6-2260-00.txt (June 2000). work in progress 182 material. 184 Change history 186 None. 188 Acknowledgements 190 (not yet) 191 Author's address 193 Jun-ichiro itojun HAGINO 194 Research Laboratory, Internet Initiative Japan Inc. 195 Takebashi Yasuda Bldg., 196 3-13 Kanda Nishiki-cho, 197 Chiyoda-ku,Tokyo 101-0054, JAPAN 198 Tel: +81-3-5259-6350 199 Fax: +81-3-5259-6351 200 Email: itojun@iijlab.net 202 Kazu YAMAMOTO 203 Research Laboratory, Internet Initiative Japan Inc. 204 (for postal address, see above) 205 Email: kazu@iijlab.net