Hello, following are the (draft) Minutes of the IPV6-WG meeting of RIPE 26. Thanks to Mirjam for taking the minutes. If there are any changes for the minutes please eMail me. Regards, Thomas IPv6 Working Group - Minutes (draft) RIPE 26, January 20-22, 1997 1. Administrative stuff (T. Trede, chair) Thomas trede is the new chair since last RIPE Meeting. - volunteering of the scribe Mirjam Kuehne volunteered as scribe. - co-chairs Geert Jan de Groot and Francis Dupont will be co chairs of the RIPE IPv6-WG. - agenda bashing Geert Jan would like to add a report about upcoming IP routing protocols. 2. Reports - 6Bone connectivity Francis Dupont reported from the 6bone activities: - 6bone is a network for testing IPv6 - there are only few sites in France, Denmark and Japan - Francis showed a slide with the current 6bone topology (version 43, December 1996) [I was unable to find the "old" map under the mentioned URL because the new map is already at this URL] - this topology will be replaced by a new one (version 44, January 1997) the drawing can be found at http://www-6bone.lbl.gov/6bone/6bone-drawing.html Geert Jan reports on developments of new IP routing protocols: - initial intent of 6bone was to help migrating into IPv6 - not happening currently, just testing - originally set up with static routes - this is not practical anymore - maybe use RIP2 - maybe new EGP soon? IGP EGP --- --- RIP2 IDRP (probably not initially) OSPF (no implementation yet) M-BGP (multiprotocol BGP) IS-IS ( " ) BGP5 AS number space can be made largr by BGP enhancements (BGP5 wants to do this) DFK: if more than 64k ASes used, BGP also need to support this Erik: How could you multihome a customer without using an additional AS? Geert Jan gave a brief summary of possible ways how to multihome a customer to the same ISP (not to multiple ISPs) 1. use real AS 2. use private AS (RFC1930) 3. use 1 AS for all customers that multihome to you (John Stewarts proposal) Erik: real problem is multihoming to different ISPs possible solution: 8+8 proposal from Mike O'Dell Juergen: Why is IDRP not pushed forward anymore (in favour of BGP)? Geert Jan: People are afraid of change and BGP is known Geert Jan reports on IETF developments: - documents moved forward to proposed standards - default hop lmit (TTL) discussed: 64? or 255? - IPv6 on token ring - small changes in tunneling document - University of New Hampshire made operability tests: - 2/3 got neighbour discovery right this time - only 1/4 of the implementations had serious problems - Mike O'Dells 8+8 proposal - 6bone will be official IETF WG - News about manufacturers implementation Geert Jan: - Some manufactures working on it - new alpha version in Singapour - INRIA published new linux version Francis: - IBM - Cisco (not official yet) - Novell (new IPv6 version for IPX) Marten: - BayNetworks is working on it, too - first release mid 1997 - available for testing now 3. Current status of RIPE regarding address assignments in IPV6 DFK: - in November number of messages on mailing list - 3 people from Germany said we should be prepared to assign IPv6 - they made detailed proposal to include a country ID after the region ID in order to provide more hierarchy - inconclusive discussion afterwards DFKs opinion: too early to allocate high order bits for two reasons: 1. process reason: discussions are still going on IETF 2. experience reason: - you loose flexibility - if you don't know where addresses will be used in the end, its difficult to make good decision - how many ISPs will there be? - interconnection model? - backbone capabilities? - routing technology used? - you can only make guesses, not operation decisions about codifying bits DFKs proposal: continue with the way we allocate IPv4, because it works add warning that scheme might change Geert Jan: other reasons not start with IPv6 allocation yet: - about country field in IPv6: - there is no such thing as country based aggregation in Europe - therefore assigning address based on country not practical - why IPv6 now? - you can use test IPv6 addresses - argument that people don't want to renumber later doesn't hold, because IPv6 is supposed to make renumbering easier Juergen: right attempt to start discussion we all learned from it how to proceed further we need more hierachy somewhere, either in the protocols or in the allocation scheme Guido gave an overview of the 8+8 proposals from Mike O'Dell and Masataka Ohta (slides are available at: ftp://ftp.ripe.net/ripe/presentations/ripe-m-25-gl-8+8.ps) There will be a meeting about 8+8 soon. Shall we be present there? DFK: - It is difficult to form a RIPE opinion after this short tutorial. - It should be persued, could help scaling - Doesn't think that 8+8 proposal introduces much additional delay in the IPv6 deployment, it mainly discusses issues that aren't specified yet. Conclusion: general opinion to wait for new proposal DFK: RIPE is not a standards making body (the IETF is), but we can take a message to the 8+8 meeting from the RIPE IPv6 WG Action Point: 26.I1: action on Guido to report there from our discussion and to express our input in new draft and to report back to us at the next RIPE meeting or on the mailing list. DFK: Do people want provider based IPv6 addresses now? general opinion: no Juergen: We need to further think about long term allocation policies/structures. Geert Jan and DFK: as long as renumbering is not possible without pain, we shouldn't start assigning IPv6 addresses 4. General Input from other Working Groups - Database Working Group: IPV6 object report on this issue hadn't been given yet in DB WG 5. AOB - none ------------------------------------------------------------------- Thomas Trede NACAMAR Data Communications Technical Director Frankfurter Strasse 135-141 63303 Dreieich / Germany e-mail: trede@nacamar.net voice: +49-6103-9901-0 www : www.nacamar.net fax : +49-6103-9901-18 -------------------------------------------------------------------