Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: January 13, 2001 Kazu YAMAMOTO IIJ Research Laboratory July 13, 2000 Requirements for IPv6 dialup PPP operation draft-itojun-ipv6-dialup-requirement-00.txt Status of this Memo 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 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.'' 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. The internet-draft will expire in 6 months. The date of expiration will be January 13, 2001. Abstract The memo tries to identify design choices in IPv6 dialup PPP services by ISPs. 1. Problem domain With the deployment of IPv6 [Deering, 1998] , it becomes more apparent that we have different operational requirements in IPv6 dialup PPP operation, from IPv4 dialup PPP operation. For example, it would be desirable to see static address allocation, rather than dynamic address allocation, whenever possible. With IPv4 this has been impossible due to address space shortage, and IPCP [McGregor, 1992] dynamic address allocation has been used. With IPv6 it is possible to perform static address allocation from ISPs to downstream customers, as there's enough address to spare. HAGINO and YAMAMOTO Expires: January 13, 2001 [Page 1] DRAFT Requirements for IPv6 dialup PPP operation July 2000 The document tries to summarize possible design choices in IPv6 dialup PPP operation. Actual operational practices should be documented separately. 2. Design choices 2.1. The usage pattern o Static clients. Computers located in home and offices do not usually change its configurations, nor upstream ISPs. It would be desirable to make a static address allocation in this case. o Roaming clients. Roaming clients, like travelling users with notebook PC, have different requirement from static clients. It is not usually possible to make a static address allocation, as travelling users may connet to multiple ISPs from different countries. 2.2. Address space It is desired to assign /48 address space, regardless from usage pattern or size of the downstream site. It is to make future renumbering in downstream site easier on ISP change. /128 assignment MUST NOT be made, as it will advocate IPv6-to-IPv6 NAT. 2.3. Address allocation o Static address allocation. ISPs will allocate a static address space (/48) to a downstream customer, on contract time. There will be no protocol involved in address allocation - allocation will be informed by paper. o Static address allocation, with some automation. It may be possible to define a common protocol for configuring customer-side router(s) from the upstream ISP, eliminating necessity of paper-based allocation and configuration labor in the customer site. Note that router renumbering protocol is not always suitable for this. Router renumbering protocol assumes that the routers and control node to be in the same administrative domain. o Dynamic address allocation. 2.4. Where to assign address o Assign address to ppp interface. The form assigns /128 to the customer computer, or /64 onto the PPP link. The form of address assignment should not be used, as it advocates IPv6-to-IPv6 NAT. In the following diagram, "Lx" denotes link-local address, and "Gx" denotes global address. HAGINO and YAMAMOTO Expires: January 13, 2001 [Page 2] DRAFT Requirements for IPv6 dialup PPP operation July 2000 ISP router |La, Ga | ppp link |Lb, Gb Customer computer o Assign address to the interface behind the customer router. The form assigns /64 to the network segment behind customer router. ISP router |La | ppp link |Lb Customer router |Gb ==+=== Gx/64 In the cases where the customer has only a single computer, it is possible to have virtual network segment behind the customer computer. ISP router |La | ppp link |Lb Customer computer |Gb ==+=== Gx/64 (VIRTUAL) Note that, however, /64 assignment will make it harder for customer site to evolve in the future. /64 assignment is not recommended. o Assign address to the cloud behind the customer router (/48). In this case, the upstream ISP has no idea about the topology in the customer site. Actually, it is not necessary for the upstream ISP to know about the address usage in the customer site. Static address assignment is highly recommended in this case, as it is painful to renumber the whole /48 cloud every time we reconnect the dialup PPP link between the ISP and the customer site. ISP router |La | ppp link |Lb Customer router |Gb (((Gx/48 cloud))) HAGINO and YAMAMOTO Expires: January 13, 2001 [Page 3] DRAFT Requirements for IPv6 dialup PPP operation July 2000 2.5. Routing o Static routing. ISPs will configure static route, pointing to the customer site, for the address space assigned to the customer site. Customer router (or customer computer) will install default route, pointing to the ISP router via PPP link. o Simple dynamic routing. ISPs can exchange routes by using simple dynamic routing protocols like RIPng. This allows the customer site to adapt to PPP link status better. This also makes it easier to detect PPP link disconnection. If the ISP announces non-default routes to the downstream customer, it may help downstream to configure multihomed connectivity (connection to multiple upstream ISPs) [Hagino, 2000] ISPs may want to filter out bogus routing announcements from the downstream. 3. Security considerations The document talks about no security issues. References Deering, 1998. S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in- notes/rfc2460.txt. McGregor, 1992. G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt. Hagino, 2000. Jun-ichiro Hagino, "IPv6 multihoming support at site exit routers" in draft-ietf-ipngwg-ipv6-2260-00.txt (June 2000). work in progress material. Change history None. Acknowledgements (not yet) HAGINO and YAMAMOTO Expires: January 13, 2001 [Page 4] DRAFT Requirements for IPv6 dialup PPP operation July 2000 Author's address Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 Email: itojun@iijlab.net Kazu YAMAMOTO Research Laboratory, Internet Initiative Japan Inc. (for postal address, see above) Email: kazu@iijlab.net HAGINO and YAMAMOTO Expires: January 13, 2001 [Page 5]