Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: October 3, 2001 April 3, 2001 Guidelines for IPv6 local experiments draft-itojun-ipv6-local-experiment-02.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/1id-abstracts.html 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 October 3, 2001. Abstract The memo defines how a (IPv6-wise) disconnected network should conduct local IPv6 experiment. The document tries to give guidelines for novice IPv6 experimenters, and tries to help them from falling into common pitfalls. 1. Problem space There are potential IPv6 users who would like to perform experiments locally, in their IPv6 network disjoint from the worldwide IPv6 network at large (or 6bone). Site-local address [Hinden, 1998] could be used where appropriate. However, site-local address has several operational differences from global address (like below), and it is harder for novice users to configure site-local address right than global address. Also, due to the differences, some of the things the user learnt from local experiments may not be directly relevant when they get connected to the HAGINO Expires: October 3, 2001 [Page 1] DRAFT IPv6 local experiments April 2001 worldwide IPv6 network - it reduces usefulness of their local experiments. o Site-local addresses are "scoped" address, while global addresses are not. o Configuration must correctly identify site border routers. This is an additional requirement. o There are proposals on scoped routing exist [Deering, 2000] , however, implementation status is still rather disappointing. For experiments over single link, link-local address could be used. However, again, link-local address is a scoped address, and has radical operational differences from global IPv6 (or IPv4) address. 2. Recommendations First of all, do not cook up IPv6 prefix on your own. You cannot pick random prefix number, that can jeopadize the whole point of experiment. Next, it is recommended to use global addresses for early stage of experiments. As presented in the previous section, scoped (site- local/link-local) IPv6 addresses have different operational characteritics from global IPv6 addresses, or global IPv4 address. In the later stage of experients, you may want to play with scoped addresses, and try to understand how they behave. In the following text of the draft, we list possible routes a disconnected IPv6 network may want to take. Once the site gets connected to worldwide IPv6 network at large, the site MUST be renumbered to the addresses assigned by the (real) upstream. 2.1. A site with 6bone site/IPv6 ISP nearby If it is possible, try to contact nearest upstream 6bone site, or upstream ISP, to assign you an IPv6 prefix. By getting IPv6 address space properly, the site will have less problem when they get conneted to the worldwide IPv6 network. The address space can (supposedly) be used for future IPv6 upstream connectivity, if you connect your site to the upstream which assigned the address space to you. If you pick a different upstream, the site MUST be renumbered. To measure "nearness" between you and the upstream IPv6-over-IPv4 tunnel [Gilligan, 1996] provider (like a 6bone site), use IPv4 hop counts. 2.2. A site with global IPv4 connectivity Whenever the site has a permanent global IPv4 address with it, the site should use the 6to4 IPv6 address prefix [Carpenter, 2000] derived from the IPv4 address space, for local experiments. The prefix will be HAGINO Expires: October 3, 2001 [Page 2] DRAFT IPv6 local experiments April 2001 2002:xxyy:zzuu::/48, where "xxyy:zzuu" is a hexadecimal notation of an global IPv4 address that belongs to the site. However, such a /48 prefix can never be routed globally in the world IPv6 network in a normal sense. When the site wants to get external IPv6 connectivity, it must if possible renumber to a normal IPv6 prefix from its ISP (or 6bone upstream). Otherwise it must find a 6to4 relay router to connect it to the IPv6 world. For detailed discussion about how packets from 6to4 site are handled, please refer to 6to4 document. 2.3. A site with dynamic IPv4 address If a site has dialup IPv4 connectivity (ISP assigns dynamic IPv4 address on connetion), the site should obtain IPv6 address space for testing, from the nearest tunnel broker [Durand, 2001] or similar services. Many of the existing tunnel brokers will assign a static IPv6 prefix on registration. 2.4. Completely disconnected site If the site has no external IP connectivity, the site may use site local address space. The operation needs great care as presented above. When the site gets connected to the outside, administrators MUST renumber the site, or add a global IPv6 address prefix to the site, based on the guidelines presented above. The site MUST NOT advertise reachability information of site local address the worldwide IPv6 network. 2.5. Other comments If there are multiple administrative domains in the site, the site is responsible for its internal coordination (the draft cannot solve your local politics). 3. Security considerations The document talks about no security issues. References Hinden, 1998. R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. Deering, 2000. S. Deering, B. Haberman, and B. Zill, "IP Version 6 Scoped Address Architecture," internet draft (March 2000). work in progress material. Gilligan, 1996. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in RFC1933 (April 1996). ftp://ftp.isi.edu/in- HAGINO Expires: October 3, 2001 [Page 3] DRAFT IPv6 local experiments April 2001 notes/rfc1933.txt. Carpenter, 2000. Brian Carpenter and Keith Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels" in draft-ietf-ngtrans-6to4-06.txt (June 2000). work in progress. Durand, 2001. A. Durand, P. Fasano, I. Guardini, and D. Lento, "IPv6 Tunnel Broker" in RFC3053 (January 2001). ftp://ftp.isi.edu/in-notes/rfc3053.txt. Change history 00 -> 01 More warning on the use of 3ffe:0501:ffff::/48. It is the last resort solution and not recommended. More comments on 6to4 case, based on comments from Brian Carpenter. 01 -> 02 Remove 3ffe:0501:ffff::/48. Add tunnel broker case based on comment from Alain Durand. Acknowledgements The draft was written based on discussions with Japanese IPv6 users, and help from WIDE research group. During the draft period, the author received valuable comments from: Brian Carpenter and Alain Durand. 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 HAGINO Expires: October 3, 2001 [Page 4]