- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE46
by David Kessens 27 Aug '03

27 Aug '03

Hi, Below follows the agenda for the ipv6 wg for RIPE46. We still have some time left in the agenda so I will be accepting last minute additions. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE46 When: 16:00 - 17:30, Wednesday September 3, 2003 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Reports from the IETF - multi6 working group summary (Kurt Erik Lindqvist) D. Update on ttm progress (Henk Uijterwaal) E. Global IPv6 routing table status - Global IPv6 routing table status (Gert Doering) - IPv6 routing table anomalies http://www.sixxs.net/tools/grh/ (Jeroen Massar) F. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

[ipv6-wg@ripe.net] Re: [db-wg] Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0)
by Shane Kerr 14 Aug '03

14 Aug '03

Gert, Gert Doering wrote: > > as there have been some IPv6 problems again today (connections over IPv6 > were greeted with "permission denied"): what's the current state of IPv6 > integration into the RIPE Whois server? Is it still done via Proxy, or > is it properly integrated now? Thanks for reporting the problem. We noticed it ourselves, and are looking into it. Looks like a mismatch of the configuration of our secondary server during an upgrade caused the problem. We're looking into fixing that now. As for the state of IPv6 integration... We are still using the proxy. We continue to get about 10000 WHOIS queries per day on IPv6, with the majority coming from a small number of addresses (about 0.5% of our queries). I haven't done any further analysis since the last RIPE meeting (RIPE 45): http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-db-whoisdb-u… I'd like to emphasize that the reason we chose to use a proxy is *not* because it was easier or faster to implement, or because we wanted to understand the technology better. I talked a bit about the reasons in the presentation I gave at RIPE 44 when we introduced the proxy: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-ipv6… The main point is that we currently use client IP address to limit the amount of personal data that a user can query. This does not make sense in the IPv6 universe. While using client IP to identify users is imperfect in an IPv4 world, it is even less meaningful in the IPv6 world. We simply don't know how to protect the privacy of our users in the IPv6 world! The main motivation for the proxy was to study access behaviour and how, if at all, we can effectively protect user's privacy. From the user point of view, the proxy should be identical to a "native" server. When we fix our config, it transparent again! One possibility that may address the client-identification issue is to move to a protocol that supports client authentication. The CRISP protocol, currently in discussion in the IETF, promises to offer such a feature. It is intended to be something that serves the same function as WHOIS, while fixing many of the limitations. http://www.ietf.org/html.charters/crisp-charter.html As I mentioned in the past, I am very eager to hear suggestions on how to deal with the privacy issue in IPv6! Any real-world experience from IPv6 operators or developers would be appreciated. We do have several months of logs now, so we can do some data mining to check theories. -- Shane Kerr RIPE NCC

4 4

[ipv6-wg@ripe.net] Minutes IPv6 working RIPE44
by David Kessens 12 Aug '03

12 Aug '03

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). -----------

1 0

[ipv6-wg@ripe.net] Call for agenda items & draft agenda (v1) for ipv6 wg RIPE46
by David Kessens 12 Aug '03

12 Aug '03

Hi, Below follows the draft agenda (v1) for the ipv6 wg for RIPE46. Please contact me if you would like to propose an agenda item. Thanks, David K. --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE46 When: 16:00 - 17:30, Wednesday September 3, 2003 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0