6BONE meeting report - 25 Jun 96 - Montreal

[Bob Fink LBNL]

                     6BONE Meeting Report
                        26 June 1996
                    Montreal, Canada  IETF

The agenda was:

1. Opening remarks & agenda bashing

        a. background of 6bone to date
        b. 6bone purpose
        c. web site:  www-6bone.lbl.gov/6bone

2. Technical discussion issues

        a. what routing to use
        b. routing registry
        c. how/when to use v4 compatible v6 addresses
        d. v6 address assignment
        e. tunnelling
        f. v6 testbed interconnect/regional process startup

3. Particpant Reports/Plans

        a. ESnet
        b. Dartnet
        c. G6
        d. Japan
        e. RIPE
        f. UNI-C

4. 6bone Regional Coordinators

        a. Europe
        b. Pacific Rim
        c. US/Canada

=3D=3D=3D
1. Opening remarks and agenda bashing


An unofficial IETF BOF was convened with Bob Fink as chair.  He noted that
it had been too late to get an official BOF slot due to IETF plenary
requirements to keep the number of parallel tracks to 7 or less.  Thus the
meeting was held unofficially during the lunch hour (thanks to the IETF
organizers) following the IPng session that morning.

Jim Bound asked if it was appropriate that we try to become involved with
the IETF "official" process as he wanted to see the 6bone effort free to
operate without unecessary rules and procedures.  This was left as an open
issue.


a. background of 6bone to date

The background of the 6bone "startup" meeting at the LA IETF was stated,
and those interested are referred to the 6bone web site.


b. 6bone purpose

The chair displayed the purpose statement and Steve Deering asked that the
sentence on tunnel endpoints typically being workstation-class machnines be
removed.  There was consensus to do so.


c. web site:  www-6bone.lbl.gov/6bone

This web site includes the purpose statement, the notes of the LA IETF
"startup" meeting and instructions on joining the mailer.



2. Technical discussion issues


a. what routing to use

Steve Deering started the discussion by noting the need to start small and
grow as needed.  Static routes at the start seemed best.  There was
consensus on this, with the caveat that there be freedom/ability to change
as the 6bone grows.

Comments made by various folk supported this position.

It was noted that it wasn't necessary to specify routing for within
"islands of v6", rather how they interconnected.


b. routing registry

Becca Nitzan (ESnet) echoed the need for simplicity as well as a mandatory
routing registry from the start.  She suggested at least contact, tunnel
info and prefix be required from all participants.

Gert Jan de Groot offerred the RIPE NCC routing registry service to start
with.  There was consensus to accept this offer.

Bill Manning noted that the RA db software could also handle this registry.


During this discussion there were several pointed comments about the need
to a concrete plan for the 6bone, and to move quickly.  This led to the
items e. and f. below.


Also during this discusson, Dmitri Haskins asked how he might become
involved by offerring Bay routers as backbone routers for the 6bone.  It
was felt that these offers should be made through the mailer (or directly
to appropriate groups) so that conversations could proceed appropriately in
either an open forum (thus for all to see) or in a private fashion when
specific agreements were being made.  It was felt that this would be
fairest to all router vendors and would serve to keep the process open and
above board.


c. how/when to use v4 compatible v6 addresses

Steve Deering renewed his suggestion of the prior evening's IPng meeting
that the convention of use for v4 compatible v6 addresses be that they are
reserved for use when there is no adjacent v6 routing.  In this sense these
addresses then act as a flag that the host is not v6 reachable.

Though there was much agreement on this point, there was controversy, and
in the interest of time it was agreed to continue the discussion of this
convention on the 6bone mailer.


d. v6 address assignment

There was consensus that RFC 1897 should be used for the assignment of
native IPv6 addresses for the 6bone.  As this format uses the IPv4 AS
(Autonomous System) number as part of its prefix, these addresses may be
self assigned.

This choice also avoids falling own the "rat hole" of politics over
provider-based v6 address assignment.


e. tunnelling

it was generally felt that to move the 6bone forward, an immediate effort
be made to get existing v6 "islands" interconnected with tunnels.  To
identify the possible "tunnellees", the meeting briefly moved to item 3 on
the agenda to understand possible participant status.


f. v6 testbed interconnect/regional process startup

After identifying the particpants able to immediately tunnel, it was agreed
that there be a lunchtime meeting (immediately after the Wed. morning IPng
meeting) to discuss the details.


3. Particpant Reports/Plans

a. ESnet
b. Dartnet
c. G6
d. Japan
e. RIPE
f. UNI-C

These reports were kept so brief as to be impossible to report here.  It
was clear that of the six above efforts, that the European and Japanes
efforts were already running "islands" of IPv6 and could participate
immediately in 6bone tunnelling agreements.

The chair noted that the UNI-C (Danish university) folk, using the Danish
Telebit routers, seemed to be the first to provide native v6 packet
transport for a production network.  Kudos to UNI-C!

ESnet and Dartnet have plans to be "6bone" ready later this summer.

The chair encouraged all the participants to post their reports and web
pointers on the 6bone mailer.


4. 6bone Regional Coordinators

a. Europe
b. Pacific Rim
c. US/Canada

There was no time for discussion of this item.


- end