Internet DRAFT - draft-itojun-ipv6-local-experiment
draft-itojun-ipv6-local-experiment
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]
