Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: March 6, 2001 September 6, 2000 Guidelines for IPv6 local experiments draft-itojun-ipv6-local-experiment-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. 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 March 6, 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: March 6, 2001 [Page 1] DRAFT IPv6 local experiments September 2000 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 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: March 6, 2001 [Page 2] DRAFT IPv6 local experiments September 2000 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. Completely disconnected site If the site has no permanent global IPv4 address with it (like dialup customer site), the site has two choices. o The site may use site local address space. The operation needs great care as presented above. o The site may use the address prefix: 3ffe:0501:ffff::/48. The address prefix was curved out from WIDE 6bone prefix. The site MUST be renumbered, before the site gets connected to the worldwide IPv6 network. The address is provided as the last-resort solution. The site should first try to use other ways. In both cases, the assigned prefix MUST NOT be advertised to the worldwide IPv6 network, from anywhere. 2.4. 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: March 6, 2001 [Page 3] DRAFT IPv6 local experiments September 2000 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. 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. 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. 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: March 6, 2001 [Page 4]