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(a)nacamar.net voice: +49-6103-9901-0
www : www.nacamar.net fax : +49-6103-9901-18
-------------------------------------------------------------------
Hello folks,
here comes the first proposal for the IPV6-WG agenda for the next RIPE
meeting.
Regards,
Thomas
Proposed Agenda for the IPV6 Working Group
RIPE-26, January 1997, Amsterdam
1st Draft, 11.1.1997
1. Administrative stuff (T. Trede, chair)
- volunteering of the scribe
- co-chairs
- agenda bashing
2. Reports
- 6Bone connectivity
- News about manufacturers implementation
3. Current status of RIPE regarding address assignments in IPV6
4. General Input from other Working Groups
- Database Working Group: IPV6 object
5. AOB
-------------------------------------------------------------------
Thomas Trede NACAMAR Data Communications
Frankfurter Strasse 135-141
63303 Dreieich / Germany
e-mail: trede(a)nacamar.net voice: +49-6103-9901-0
www : www.nacamar.net fax : +49-6103-9901-18
-------------------------------------------------------------------
