Minutes of the 6bone Working Group.
Reported by: Dan Harrington and Bob Fink.
I. Introduction and Agenda Bashing / Bob Fink
II. CAIRN Backbone / Allison Mankin
III. Status from the IDR WG / Bob Fink
IV. Prefix aggregation problems / Alain Durand
V. A 6BONE address block and registry / Dimitry Haskin
VI. Toward establishing a real virtual IPv6 network / Hsin Fang
VII. Addressing beyond RFC1987 / Bob Fink
VIII. Representing IPv6 Tunnels in RPSL / David Meyer
IX. New 6BONE registry / David Kessens
X. DNS is your friend / Bill Manning
XI. Internet Draft on requirements for new 6bone infrastructure / Bob Fink
XII. Survey of implementations / Bob Fink
I. Introduction and Agenda Bashing / Bob Fink
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 will be kept distinct from ngtrans transition tools current efforts, but that how the two subgroups interact in the future will be evaluated and modified as appropriate.
Fink noted that there is a 6bone web page at: http://www-6bone.lbl.gov/6bone/ and a mail list that one can subscribe to: majordomo@isi.edu (include "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 was decided to use a one-hour time slot, with strict time control on the agenda topics with most discussion and decisions 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.
II. CAIRN Backbone / Allison Mankin
Allison Mankin presented her ideas for a native IPv6 backbone using the CAIRN research backbone network.
- High bandwidth backbone for research, etc. (U.S. federal funding)
- A diagram of the CAIRN topology was shown:
+ connectivity ranges from DS-3 to full OC-3.
+ several current v6 sites are CAIRN sites (ISI, LBL...)
+ each site has a PC/FreeBSD router and/or an Ascend GRL w/v6 support
- Proposed possibilities for the backbone included:
+ Transit bandwidth service with native IPv6 unicast
+ Software distribution center
Jim Bound commented that it is important for CAIRN's IPv6 implementation to
use UNH interop lab/events to make sure there is proper interoperability before
direct connectivity is attempted. Allison expressed her desire to join in the UNH testing. Further discussion was deferred to the mail list.
III. Status from the IDR WG / Bob Fink
Bob Fink reported on the IDR Working Group 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 released an early field test version of their BGP4+ that is 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. Further discussion was deferred to the mail list.
IV. Prefix aggregation problems / Alain Durand
Alain Durand spoke on routing anomalies that he has observed in the running 6bone.
Inconsistency in method of aggregation. Too many routes. Backdoor routes...lead to looping, requires additional routes to suppress. Unaggregated advertisements (might have been one-time blip) "Weird" prefixes...typos, incorrect scope.
Alain noted that site-local prefix could use a tighter definition. His conclusion is that 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).
VI. A 6BONE address block and registry / Dimitry Haskin
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 heard for the 6bone to move to whatever the IPng Working Group decided as the outcome of its GSE deliberations.
VI. Toward establishing a real virtual IPv6 network / Hsin Fang
Hsin Fang spoke on problems with the current 6bone RFC1987 address structure, how it is 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?
· 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.
| 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 64 bits |
+---+----------+----------+---+------------+---+----------------+
|010|RegistryID|ProviderID|RES|SubscriberID|RES|Intra-Subscriber|
+---+----------+----------+---+------------+---+----------------+
| 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits|
+---+----------+----------+---+------------+---+--------+-------+
| | |Autonomous| | IPv4 | | Subnet | Intf. |
|010| 11111 | System |RES| Network |RES| | |
| | | Number | | Address | | Address| ID |
+---+----------+----------+---+------------+---+--------+-------+
Suggested New 6bone Address Format
| 3 | 5 bits | 16 bits | 8 | 24 bits | 8 | 16 bits|48 bits|
+---+----------+----------+---+------------+---+--------+-------+
| | | IPv6 | | ASN* or | | Subnet | Intf. |
|010| 11111 | VPID |RES|IPv4 prefix |RES| | |
+---+----------+----------+---+------------+---+--------+-------+
IPv6 VPID : Virtual Provider Identifier
IPv4 Prefix : Your ISP provided network address
Benefits:
· More accurate delegation of 6bone. · Provide reasonable address/DNS aggregation. · More efficient routing table aggregation. · 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. Further discussion was deferred to the mail list.
VII. Addressing beyond RFC1987 / Bob Fink
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 Working Group co-chair.
Bob Hinden commented that he would be presenting a preliminary new unicast addressing plan at the IPng Working Group meeting later in the week, and that this would result in an Internet-Draft shortly thereafter. He also supported experimentation with renumbering as a goal for the 6bone. Further discussion was deferred to the mail list.
VIII.. Representing IPv6 Tunnels in RPSL / David Meyer
David Meyer presented his ideas on representing IPv6 tunnels in RPSL that were published in the Internet Draft library as draft-ietf-rps-rpsl-00.txt.
inet-rtr object in RPSL is extended - tunnels modeled as an interface new inet-tunnel object defined follows RIPE-181/RPSL paradigm of specifying "your" side of the policyPlease refer to the I-D for details.David outlined outstanding issues:
· Formal syntax for IPv6 Route Object?
· Tunnel object would like to use general RPSL syntax to describe policy · Finessed in the examples (ANY) · Generally, should RPSL be used for IPv6? · Transition from RIPE registry to ? · Tools · Others (such as David Kessen's comments)
David described David Kessens offline comments on the draft, which he will continue to pursue offline.
There was a question on filtering/policy that was unanswered due to time constraints on the schedule.
Bob Fink requested feedback to David on his draft via the mail list.
IX. New 6BONE registry / David Kessens
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 is 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 are 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 is 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.
X. DNS is your friend / Bill Manning
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 available 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.
XI. Internet Draft on requirements for new 6bone infrastructure / Bob Fink
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.
XII. Survey of Implementations / Bob Fink
The survey of IPv6 implementations in use on the 6bone was postponed due to lack of time. Bob Fink volunteered to do this survey via the mail list.