[ipv6-wg at ripe.net] Minutes IPv6 working RIPE44

Hi,

I didn't receive any comments or corrections for the draft minutes
(v1) posted on May 8, 2003 for the ipv6 working group at RIPE44.

Therefore, the draft minutes are now the final minutes. 

David K.
---

Minutes IPv6 working RIPE 44

Meeting: IPv6 Working Group - RIPE 44
Date: Wednesday, 29 January, 2003
Time: 2pm - 4pm
Chair: David Kessens (DK)
Scribe: Timothy Lowe

Webcast: rtsp://webcast.ripe.net:7070/Archive/ipv6-1.rm

A.   Administrative stuff
     - Agenda bashing
       Agenda available at: http://www.kessens.com/~david/presentations/
     - No new agenda updates were proposed

B.   IPv6 version of TTM
     - Henk Uijterwaal

     http://www.ripe.net/ripe/meetings/archive/ripe-44/
                         presentations/ripe44-ipv6-ttm/

     - No questions or comments were made

C.   Presentation - IPv6 whois proxy
     - Shane Kerr (SK)

     http://www.ripe.net/ripe/meetings/archive/ripe-44/
                         presentations/ripe44-ipv6-v6wpd/

Gert Dvring (GD):
     Will IPv6 be integrated into the main whois server, not 
     just on the proxy server?

SK:  Those are our future plans but their some issues including 
     security issues that need to be worked out first. 

DK:  Don't put all your efforts into proxies.

SK:  We won't.

D.   IPv6 state of the art in the Italian educational 
     and research community.
     - Gabriella Paolini (GP)

Francis Dupont:
    Don't use /126 for point to point links

GP:  It avoids unnecessary waste.

Speaker: (Did not use microphone)
     It includes loopback and network so it is
     
DK:  We can come up with a best current practice document on numbering 
     v6 networks as an agenda point for next time.

E.   Global IPv6 routing table status
     - Gert Dvring (GD)

Bernard Tuy (BT): 
     Improving routing is something we should be working on.

GD:  Yes maybe a best current practice document.

BT:  Do we want a guideline document?

GD:  It would be useful

DK:  There is a 6bone document that describes this.

BT:  I want a RIPE document on this and volunteer to write one

DK:  Action on Bernard to co-ordinate for a routing document.

Philip Smith (PFS): 
     Would an IPv6 CIDR Report be useful?

DK:  Yes

PFS: Fine, then Geoff and I will get on that.

PFS: We provide transit to anyone at all right now. We want to 
     change this we can discuss this later.

DK:  I am also encouraging people to look for other transit then 
     from me.

GD:  I wish to keep the link to Cisco now with the shorter path 
     lengths.

PFS: All right I would appreciate any feedback.

F.   Ghost Route Busters
     - Jeroen Masser (JM)
   
     http://www.ripe.net/ripe/meetings/archive/ripe-44/
                         presentations/ripe44-ipv6-ghosts/

Randy Bush (RB): 
     What is TLA?

JM:  Top Level Aggregater

RB:  What?

A short exchange on the deprecation the TLA syntax followed.

G.   Traffic graphs 
     Jeroen Masser

     Presentation was not given but is available from:

     http://www.ipv6.aorta.net

H.   5 year trend in the BGP table 
     Ronald van der Pol

     http://www.nlnetlabs.nl/ipv6/measurements/index.en.html

I.   Workable approaches for IPv6 multihoming in the absence of 
     a better solution than the one we use in the IPv4 Internet 
     - Iljitsch van Beijnum (IvB)

     http://www.bgpexpert.com/ripe44/

BT:  Why is the draft not out?

IvB: The IETF can't agree on it.

BT:  We could write a draft here?

DK:  Bernard that is IETF work

IvB: It is possible that we could submit a draft to them but 
     let me finish here my presentation and we can discuss it 
     later.

Clemens Zauner (CZ): 
     Putting multi addressing and multihoming in the same 
     presentation is not so logical.

IvB: Are you saying if you are doing multi addressing you are 
     not really doing multihoming?

DK:  There are people that say if you do multi addressing right now you 
     don't need to multihome.

CZ:  Also most of the deaggregation taking place is not due to 
     multihoming.

IvB: I agree this premise is false even if every ISP announces 
     10000 routes ....

CZ:  Even so I don't belive in millions of multihomers.

IvB: Neither do I but v4 style multihoming won't scale.

CZ:  Even so I don't belive multihoming will break things if you 
     look at it now.

IvB: Yes but we also have to think 20 years ahead.

CZ:  Maybe we could make them prove a need for multi homing

IvB: There is the possibility of coming up with an administrative 
     solution like that but one solution could be to make them pay 
     a fee. You cannot have an upstream for free whether it is
     one or many upstreams.

GD:  There are a number of routes that shouldn't be there but are 
     for traffic engineering reasons. A reason for multihoming that 
     I see is that they want connectivity redundancy due to ISP 
     bankruptcies.

IvB: I want to take this discussion offline to go into it further

J.   IPv6 Multihoming part 2
     - Kurt Erik Lindqvist (KEL)
   
     http://www.ripe.net/ripe/meetings/archive/ripe-44/
                         presentations/ripe44-ipv6-multihoming/

GD:  I like this idea.  of increasing the allocation from IANA to 
     the RIR's. Make it an action on the RIPE NCC to talk to IANA 
     about this. If this gets out of hand we can roll it back. It 
     is pretty radical.

KEL: It is not a long term solution but it buys us time.

IvB: 64,000 multihomers is not the upper limit.

KEL: Even so it still won't break routers at twice as many.

DK:  Should we go to routing with this?

GD:  Yes.
 
KEL: Yes

K.   Discussion point - Fragmentation of the IPv6 address space from 
     the top down by allocating /23's to RIRs
     - Gert Dvring

AOB

DK:  Another IPv6 survey is in the works and the RIPE NCC needs 
     input on what questions to ask in the survey. Please give 
     them input.

BT:  Presenting useful data is a good idea if you have any ideas on 
     this pass them on. Also we have a v6 project the M6bone please 
     come play with us. 

DK:  We arranged this working group session to avoid overlap with 
     the other working group sessions and we have moved topics to 
     other appropriate wg's. We would like input on if you like this 
     approach. Please inform me.

I.   Workable approaches for IPv6 multihoming in the absence of a 
     better solution than the one we use in the IPv4 Internet
     - Kurt Erik Lindqvist, Iljitsch van Beijnum

     brief discussion

K.   Developments/initiatives regarding IPv6 in the RIPE region and 
     beyond input from the audience

L.   Input to the RIPE NCC Activity Plan & results of KPMG survey
     input from the audience

DK:  It is very important that the RIPE community tells the RIPE NCC
     what IPv6 activities should be put into the activity plan

Z.   AOB

Agenda point for RIPE 45 best current practice document on numbering IPv6
networks


Action Points from Previous meetings:

42.1: Investigate the CNAME and other solutions for 
      IPv6 reverse delegation - RIPE NCC
42.2: Give an overview of 6-to-4 reverse delegation 
      issues at RIPE 43 - RIPE NCC
42.3: IPv6 capable RR DNS servers - what is needed, 
      what are the issues? - RIPE NCC

Action points 42.1-3 were rewritten and closed.

New Actions Points:

44.1 Enable reverse delegation For 6bone (RIPE NCC)
44.2 To co-ordinate an IPv6 routing guideline document (Bernard Tuy)
44.3 To investigate with IANA increasing the size of RIR allocations to 
     rationalize routing (RIPE NCC)
44.4 Report back to the working group what the status is and what the issues
     are regarding:

     - enabling AAAA glue records in the . zone
       - AAAA glue records for delegations to TLDs
       - AAAA glue records for the root servers themselves
     - enabling ipv6 transport to the . zone

     and come back with ideas on how these issues can be overcome (RIPE NCC).


-----------