Bob Fink convened the meeting, giving a status report of the formation of the 6bone WG as part of the ngtrans WG. He noted that 6bone efforts would be kept distinct from ngtrans transition tools current efforts, but that how the two subgroups would interact in the future would be evaluated and modified as appropriate.
Fink noted that there was a 6bone web page at:
http://www-6bone.lbl.gov/6bone/
and a mail list that one can subscribe to:
majordomo@isi.edu
subscribe 6bone
He then asked for additions and changes to the agenda. Due to the large attendance expected at this meting (based on experience at San Jose) it had been decided to use only a one hour time slot, with strict time control on the agenda topics with most discussion and decisions being done via the mail list.
The agenda was modified by Kevin Lahey's request for a quick survey of implementations used on the 6bone. The agenda was accepted and the meeting continued.
Bob Fink reported on the IDR WG meeting earlier in the week, noting that there were two competing BGP proposals. One from Cisco for a BGP4+ that mostly just added IPv6 support to BGP4, while a Bay/ISI proposal for a BGP5 added other features, such as a larger AS, in addition to IPv6 support. He also noted that Cisco had released an early field test version of their BGP4+ that was in the hands of several 6bone sites for experimentation.
Fink stated his desire that the 6bone soon start testing BGP among some 6bone backbone sites for early experience with BGP.
Alain Durand spoke on routing anomolies that he has observed in the running 6bone.
- Inconsistency in method of aggregation. Too many routes.
- Backdoor routes...leads to looping, requires additional routes to supress.
- Unaggregated advertisements (might have been one-time blip)
- "Wierd" prefixes...typos, incorrect scope.
Alain noted that site-local prefix could use a tighter definition.
His conclusion...160 routes today, could easily be cut to 95 through better aggregation. With a better addressing scheme (e.g. GSE's large structure) this could be cut to ~20 (in Default Free Zone).
Dimitry Haskin spoke on the need for a new 6bone address structure and registry. He acknowledged the first steps taken with the 6bone, noting that it now must evolve into a "real" network using a real address structure. Commercial interest in connectivity must be met, and this required moving to a real addressing architecture and registry.
He agreed with plans he was hearing for the 6bone to move to whatever the IPng WG decided as the outcome of its GSE deliberations.
Hsin Fang spoke on problems with the current 6bone RFC1987 address strcuture, how it was being used and how a "real virtual IPv6v network" might be formed based on changes to RFC1987.
6BONE Address Problems:
- No organized hierarchical addressing structure.
- No correlation between DNS structure and addressing structure.
- No correlation between 6bone topology and addressing structure.
- ISPs are not ready to operate as IPv6 service providers.
- 6bone rate of growth indicates that scaling will become an issue before ISPs are ready.
- 6bone "service providers" are typically not ISPs.
- No guarantee that the currently used "subscriber assumed" address prefix will be the actual ISP assigned prefix.
- Real provider based addresses are guaranteed to be different (RFC1897).
- Renumbering WILL happen - why not have a structured hierarchy now?
Suggestions:
Establish the IPv6 address based on 6bone structure.
- Use 6bone virtual provider's ID instead of physical network provider's ASN.
- Use meaningful representation in the subscriber field, e.g. it could be one's own ASN or one's network address.
- Provides valuable experience on IPv6 renumbering on a relatively large scale.
Matt Crawford commented that he welcomed Hsin Fang's ideas, suggesting that implementation of it be done ASAP. There was general agreement from the crowd.
Bob Fink briefly outlined his desire for the 6bone to follow the new IPv6 addressing plan that he expected to result from the IPng WG meeting later in the week. He postulated that, if real operational experience and feedback to developers and the IPng WG was a primary goal of the 6bone, that the 6bone should move quickly to adopt a new addressing plan and to test network renumbering.
Jim Bound expressed his concern that users might not accept the concept of renumbering in the marketplace.
Bob Fink then asked Bob Hinden to comment as IPng WG co-chair.
Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng WG meeting later in the week, and that this would result in an Internet-Draft shortly therafter. He also supported experimentation with renumbering as a goal for the 6bone.
David Kessens spoke on the new RIPE-191 style 6bone routing registry that he had just made operational prior to this IETF meeting. He gave a brief overview of the information he has already sent to the 6bone mail list, noting that there was a web page describing how to use the new registry available through the 6bone web pages.
There is also a whois web-based query tool for the registry that is available through the 6bone web pages.
He noted that the registry and the whois server is at brind.isi.edu and that the registry will be mirrored at several 6bone sites around the world.
David noted Bob Fink's intention to register the domain 6bone.net, and that the registry and whois server could then be renamed under this domain.
Information on the IPv6 site object extension to the RIPE database structure are available from the Internet Draft library as draft-ietf-ngtrans-6bone- registry-00.txt.
Discussion of if and when to convert the 6bone from the existing RIPE-NCC ftp-based routing registry was deferred to the mail list.
Bill Manning spoke on his idea for putting 6bone routing information into the DNS using TXT and/or Kitchen Sink SINK resource records. He noted that this would allow the site to locally maintain their own routing registry information using the well established DNS hierarchy, thereby encouraging a more up-to-date registry due to its locally controlled nature.
Due to limited time (the one hour time slot was up and cookies were availabe so people were drifting out), this was deferred to the mail list.
For those interested in Don Eastlake's Kitchen Sink Resource Record mechanism to extend DNS, please refer to draft-eastlake-kitchen-sink-01.txt.
Bob Fink asked for help on an Internet Draft on Requirements for the New 6bone Infrastructure. A goal would be to have a first draft by the Munich IETF in August.
Those interested were asked to contact Bob offline.
