Connecting to 6bone guidelines (*VERY* rough draft)

[Harrington, Dan]

Hello all,

The enclosed is a preliminary (and incomplete) draft of a document
which I had envisioned as a web page for www.6bone.net, as a sort of
FAQ (in non-Q/A format).  Bob Fink reviewed the outline, and had
suggested that it might be a worthwhile I-D for the 6bone group as
well.  In any event, the flurry of mail messages from folks wanting
to connect to the 6BONE made me decide to throw this out to the
group now, incomplete or not, for feedback.  What I would like to
get from reviewers are:

	- low-level review for accuracy, clarity, grammar, etc.
	- suggestions for additional material, topics, expansion...
	- comments on applicability of this as an Internet-Draft

Thanks,

Dan
======================================================================

Q: Style question..."6BONE" or "6bone"?

NB: Using new registry and addressing plan info, although neither is
    yet operational.  (OK, David, you made a liar of me... :-)

Introduction:

This document is an attempt to provide guidance for those wishing to
participate in the ongoing 6BONE experiment.  The 6BONE is a virtual
network of IPv6-capable systems, which utilizes the world-wide
connectivity of the Internet to link researchers, developers and
users of IPv6.  The scope of work on this testbed is varied and
variable, but the overriding focus is to develop protocols and
applications related to the IPv6 deployment.  For further details
about the 6BONE, including how to join the 6BONE user mailing list,
please see the official Web site at http://www.6bone.net/.

In the following sections, we will review the steps required to
connect to the 6BONE.  These steps have been organized as a series
of stages:  Planning, Training, and Deployment.  Please keep in mind
that these are fairly arbitrary stages, meant mainly to organize
the data in the document, but it may also help to organize you as
you proceed.

Finally, this document is only as useful as the information it 
contains.  If you have any suggestions regarding content or style,
and especially if you discover any errors, please contact the author
with your comments.  Thank you.

Planning
========

The most important (and possibly the most time consuming) step you will
take on the road to 6BONE connectivity is that of planning what  you
will
do.  If you organize yourself at the beginning of the task, you will
find
that the completion of the task is smooth and simple.  So even if you
have
to get connected to the 6BONE this minute, and not a moment later,
please
take the time to review the following items;  you just might save
yourself
some effort and frustration!

The first thing to consider before connecting to the 6BONE is what you
will
do when you get there.  The 6BONE is a test network, made up almost
entirely
of prototype software in various stages of development.  It is not a
final
destination really, but a road towards a future Internet.  And this
particular road is not a superhighway, but more like the first road to a
pioneer community, somewhat bumpy, full of adventure and peril, and
populated by intrepid travelers.  Before you start down this road you
should
form some idea of where you want to end up.  The reason need not be
deeply
profound!  You may be a network operator who plans to support this new
family of protocols for your users or customers, and need to gain
operational experience with the new addressing formats and new tools.
Or you may be a researcher or developer working on a new protocol or
application.  You may merely be driven to use the newest technology, and
to figure out new tools and techniques.  In any event, welcome! It's not
important what your purpose is on the 6BONE, but rather that you have
one.

The next issue to consider is what type of network you are planning to
support.  It may be a small set of systems under your direct control, or
it could be a larger set of disperse systems within your larger network.
The mechanisms you will use to coordinate activities in these distinct
environments will be rather different.  The amount and type of internal
infrastructure you will require must take into consideration the types
of
users (naive or experienced), the systems and software you plan to
deploy
(homogeneous vs. completely mixed), and the management style used in
your
network (centrally controlled vs. distributed autonomy).  In any event
you
should maintain mailing lists, telephone lists, and supported procedures

for regularly scheduled events in your network. [This last bit doesn't
seem clear...try to clarify, Dan]

Finally, the type of 6BONE connectivity you plan
will dictate the level of support you will dedicate to this activity.
The
6BONE currently supports three levels of hierarchy, with leaf sites
having
or more connections into the 6BONE, purely for their own reachability.
Transit sites, as their name indicates, permit data to travel through
their site from leaf networks, in addition to terminating their own 
communications.  The highest levels of support would be required for
core
sites, which maintain the 6BONE's backbone connectivity with a high
proportion of other core sites in addition to providing access to one or
more transit or leaf sites. This breakdown of the 6BONE hierarchy can be
seen in the current 6BONE map, at
http://www.6bone.net/6bone-drawing.html.

Another important aspect of planning will be to determine what software
you will be using in your network.  There are a number of different
packages
available for evaluating IPv6, ranging from freely-available source code
for popular UNIX implementations to commercially available kits for both
hosts and routers.  In order to determine what best fits your needs, a
bit of research is in order.  You can get a good idea of what is
currently
available by checking the "Implementations" page under the IPng
homepage,
at URL http::/playground.sun.com/ipng/ipng-implementations.2.html, where
both host and router software is described, often with pointers to
further
information.  If you know in advance which systems you will be using for
IPv6 testing, you may wish to gather current version information, for
quick
cross-referencing against what is required.  It is also important to
note
just which capabilities you will require (e.g. DNS/BIND server, Basic
API
support), as this may help to focus your search.  The minimum set of
capabilities required by most 6BONE sites would be a router (i.e., the
ability to forward packets off-site to the 6BONE), a DNS/BIND server
capable of storing AAAA records and resolving your branch of the ip6.int
tree [although this service could potentially be provided by other
means,
e.g. by 6BONE transit site...could be clunky, but should this be in
minimum set? dth], and a host with ping, nslookup and traceroute
utilities.
[Again, this last set is arbitrarily defined by me...anybody feel like
arguing? dth].  Bear in mind that a single system is quite capable of
performing all these functions, although it may be more typical to
distribute this work among several machines.

Having determined what you plan to do, and what systems you plan to
do it with, the final and critical planning step remains; where will you
connect to the 6BONE?  Because the 6BONE is not a simple Internet
Service
Provider, but a loose agglomeration of interested parties, there is no
support center or NOC (Network Operations Center) to call for help.  It
is up to you to find someone already connected to the 6BONE who would be
willing to provide access to your site.  This is not as daunting a task
as it might seem at first, for the people and organizations which are
already connected to the 6BONE are there because they want to make it
work, and you will certainly find a willing partner.  The research you
should do in this area is to determine who is already connected, and
which of these sites are near yours.

	[Is the following useful?  It seems like we should make an
	 effort to be efficient when connecting...dth]

	Aside:  Note that use of the "near" above is deliberately
	ambiguous.  While it is highly desirable to utilize a contact
	located geographically close to your site, this may in fact
	not make the most sense from a topological point of view.  It is
	important to keep in mind that the 6BONE is overlayed upon the
	existing Internet infrastructure, largely using IPv4 tunnels
from
	site to site.  Thus, a single IPv6 router-to-router hop may
	require multiple IPv4 hops to complete.

	For example, two independent networks located just a few miles
	apart may utilize different ISPs, such that traffic between them
	may travel 15-20 hops on average.  On the other hand, two sites
	located in different states or countries may use the same ISP,
	and may thus traverse significantly fewer hops.  Given that
	your 6BONE contact site will be the first hop onto the 6BONE,
	it makes sense to reduce the overhead of connectivity as much
	as possible.  If you identify multiple potential 6BONE
	contacts, it would be a worthwhile exercise to spend some time
	running traceroute to determine how reachable they are from
	your network.

	[Is this a potential tool requirement for the 6BONE?  As the
	 6BONE gets larger its growing pains will reflect its lack of
	 relationship with the underlying IPv4 network.  Has the MBONE
	 gone through this stage already?  Do some of their documents
	 cover this ground?  Check it out...dth]

Some tools which can you can use to figure out where you might be able
to connect include the 6BONE map (at URL 
<http://www.6bone.net/6bone-drawing.html>), 
the ISI 6BONE registry (at URL <http://www.isi.edu/~davidk/6bone>),
and the 6BONE mailing list itself. 
[This last method is not the preferred mechanism, but it usually
does prove effective if all else fails.]
The information you are looking
for begins with a contact name, and should include both e-mail and
telephone addresses.  Make sure to inquire of a potential site which
style
of communication they prefer, and make a note of it...not everyone
enjoys
receiving telephone calls.  Should the potential site be located in
a different timezone or another country, make a note of this with your
contact information, so that you remember to call at the correct time.

Once a 6bone contact has been identified and has agreed to serve
as your transit or backbone service provider, you are ready to
develop your addressing plan.  While the initial stages of 6bone
deployment took place using RFC 1897
<URL ftp://ds.internic.net/rfc/rfc1897.txt>, this addressing
plan has been superseded for a couple of reasons.  First of all,
it used IPv4 addressing elements (including the Autonomous System
number) of a site to generate the IPv6 address.  Because the 6bone
uses the IPv4 network as a virtual network, and not as a strict
topology guide, the address prefixes defined in this manner did
not aggregate; that is, each site had a unique prefix, and routing
was done on an essentially flat space.  This type of plan is known
to not scale well.  Secondly, the IPng Working Group has made some
fundamental changes to the IPv6 Addressing Architecure 
<URL ftp://ds.internic.net/internet-drafts/
			draft-ietf-ipngwg-ipv6-arch-00.txt>,
which has resulted in a new unicast address assignment plan 
<URL ftp://ds.internic.net/internet-drafts/
			draft-ietf-ipngwg-unicast-aggr-00.txt>
and a new 6bone address allocation plan
<URL ftp://ds.internic.net/internet-drafts/
			draft-ietf-ipngwg-testv2-addralloc-00.txt.
While still in draft form, it is expected that these new schemes
will be deployed and tested as 1997 progresses.
 
[too much history there?  dth]

The basic scheme for 6bone addresses is that those sites providing
backbone connectivity are labeled with Top-Level Aggregators,
and are identified by a short <13-bit?> prefix.  Those sites, leaf
or transit, which connect to these TLA's receive a first level
Next-Level Aggregator identifier.  There is a tertiary level
which uses a third field known as the Site-Level Aggregator, 
which provides a field for subnet assignments.  Together these 
fields form a 64-bit route to a particular network/subnet.  The
other 64-bit value in an address is the interface identifier.
The IPv6 addresses in use on the 6bone would then have the
following format:

	0x3FFE<TLA><NLA><SLA><64-bit interface ID>

Please check the current Internet-Drafts in this area (as referenced
above) for further details.  In summary, your 6bone address will
be based on (and provided by) your 6bone connection point.  In the
event that you plan to be a 6bone core (or backbone) site, please
review the registry information at www.6bone.net [good punt, eh?].

[Further info here re. addressing plan...small site vs. large network,
flat routed vs. subnets, etc.]

At the same time that you develop your addressing plan it is suggested
that you should arrange for the delegation of your portion of the
ip6.int tree in the Domain Name System [RFC1034] 
<URL ftp://ds.internic.net/rfc/rfc1034.txt>, which is described
in RFC 1886.
 

	    * Get DNS delegation, create zone files (see current
		info under 6BONE page for current hints/tips)

Training
========

This can be as limited as you personally feel necessary in order to
begin deployment,  but may be more extensive if you include the
training you may provide to operators, users, customers and
programmers  within your network.  Some initial sources of information
include the following:

	www=> IPng page, IETF's working group I-D page, vendor sites
		and white papers
	    * Current IPv6 RFC's and Internet-Drafts
	    * Books on the subject
	    * Mbone sessions (IETF working groups, etc.) (???)
	    * mailing lists (6bone, personal, other)
	    * Magazine and journal articless
	    * seminars and presentations
	    * share what you learn!  Write up experiences, tips,
		present them to user's group or other forum, answer
		queries on mailing list, etc.

Deployment
==========

Actually doing something at last!  Put your plans into action...if
you've planned well, this should be smooth and relatively quick.

      - Gather systems, software, equipment as per planning
      - Do preliminary builds, installations.  Test internal
	connectivity, gain experience with tools, initialize
	DNS infrastructure.
      - Connect as planned...tie in zones to DNS...test tunnel
	or link as appropriate
      - Register in new RIPE style registry db at ISI
      - Announce yourself on 6BONE mailing list

References
==========


   [RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
	RFC1034, 11/01/1987

   [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP 
	version 6", RFC 1886, December 1995.

   ...and many more...