From shane at ripe.net Fri Aug 8 15:35:40 2003 From: shane at ripe.net (Shane Kerr) Date: Fri, 08 Aug 2003 15:35:40 +0200 Subject: [ipv6-wg@ripe.net] Re: [db-wg] Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0) In-Reply-To: <20030808150743.N67740@Space.Net> References: <200308060750.h767o93j003700@birch.ripe.net> <20030808150743.N67740@Space.Net> Message-ID: <3F33A72C.7020301@ripe.net> 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-update/page16.htm 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-v6wpd/page2.htm 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 From pim at ipng.nl Fri Aug 8 15:46:01 2003 From: pim at ipng.nl (Pim van Pelt) Date: Fri, 8 Aug 2003 15:46:01 +0200 Subject: [ipv6-wg@ripe.net] Re: [db-wg] Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0) In-Reply-To: <3F33A72C.7020301@ripe.net> References: <200308060750.h767o93j003700@birch.ripe.net> <20030808150743.N67740@Space.Net> <3F33A72C.7020301@ripe.net> Message-ID: <20030808134601.GC2422@bfib.colo.bit.nl> Hi Shane, | 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. There's one idea worth mentioning, allthough I'm quite certain it will not suffice in itself. If you'd like to limit the amount of queries an individual/company can do, you may want to use the database itself for some sort of constraint. Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to look something up. You can check its most specific inet6num which would be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num and limit that. If there is no object in the database, you would then fallback to the /35 or /32 and limit the queries per ISP. If any ISP engineer feels like this is punishment for them, you can advise them to make assignments visible in the database (ie, create inet6nums for their customer assignments like they should). You can then limit the amount of queries originating from within inet6num ranges. It may not be easily implemented though, but that's not up to me to decide :-) -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From gert at space.net Fri Aug 8 15:55:52 2003 From: gert at space.net (Gert Doering) Date: Fri, 8 Aug 2003 15:55:52 +0200 Subject: [ipv6-wg@ripe.net] Re: [db-wg] Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0) In-Reply-To: <20030808134601.GC2422@bfib.colo.bit.nl>; from pim@ipng.nl on Fri, Aug 08, 2003 at 03:46:01PM +0200 References: <200308060750.h767o93j003700@birch.ripe.net> <20030808150743.N67740@Space.Net> <3F33A72C.7020301@ripe.net> <20030808134601.GC2422@bfib.colo.bit.nl> Message-ID: <20030808155552.Q67740@Space.Net> Hi, On Fri, Aug 08, 2003 at 03:46:01PM +0200, Pim van Pelt wrote: > Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to > look something up. You can check its most specific inet6num which would > be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num > and limit that. Cool idea. One would need to mirror the other registries for that to work for "foreign" IPv6 addresses, but overall, cool idea :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56318 (55442) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From david at iprg.nokia.com Wed Aug 13 00:51:03 2003 From: david at iprg.nokia.com (David Kessens) Date: Tue, 12 Aug 2003 15:51:03 -0700 Subject: [ipv6-wg@ripe.net] Call for agenda items & draft agenda (v1) for ipv6 wg RIPE46 Message-ID: <20030812155103.K26389@iprg.nokia.com> 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 --- From david at iprg.nokia.com Wed Aug 13 01:04:44 2003 From: david at iprg.nokia.com (David Kessens) Date: Tue, 12 Aug 2003 16:04:44 -0700 Subject: [ipv6-wg@ripe.net] Minutes IPv6 working RIPE44 Message-ID: <20030812160444.B26795@iprg.nokia.com> 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). ----------- From hroi at asdf.dk Wed Aug 13 23:28:52 2003 From: hroi at asdf.dk (Hroi Sigurdsson) Date: Wed, 13 Aug 2003 23:28:52 +0200 Subject: [ipv6-wg@ripe.net] Re: Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0) In-Reply-To: <20030808134601.GC2422@bfib.colo.bit.nl> Message-ID: <229A6F00-CDD5-11D7-862A-003065D651F4@asdf.dk> Pim van Pelt wrote: > If you'd like to limit the amount of queries an individual/company can > do, you may want to use the database itself for some sort of > constraint. > > Let us say that a user from 2001:7b8:3:32:202:b3ff:fe2a:1e2d wants to > look something up. You can check its most specific inet6num which would > be NL-BIT1-PN1-POP3 and account queries per timeinterval per inet6num > and limit that. That seems a bit complicated. Why not just limit per /64 or /48? Aside, how important is this for privacy anyway, given the fact that the whole database is also available via FTP? -- Hroi From gert at space.net Thu Aug 14 14:41:46 2003 From: gert at space.net (Gert Doering) Date: Thu, 14 Aug 2003 14:41:46 +0200 Subject: [ipv6-wg@ripe.net] Re: [db-wg] Re: Whois IPv6 proxy status (was RIPE Whois Server version 3.2.0) In-Reply-To: <229A6F00-CDD5-11D7-862A-003065D651F4@asdf.dk>; from hroi@asdf.dk on Wed, Aug 13, 2003 at 11:28:52PM +0200 References: <20030808134601.GC2422@bfib.colo.bit.nl> <229A6F00-CDD5-11D7-862A-003065D651F4@asdf.dk> Message-ID: <20030814144146.Q67740@Space.Net> Hi, On Wed, Aug 13, 2003 at 11:28:52PM +0200, Hroi Sigurdsson wrote: > Aside, how important is this for privacy anyway, given the fact that > the whole database is also available via FTP? It isn't. The person objects are not available by FTP. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From david at iprg.nokia.com Thu Aug 28 01:57:30 2003 From: david at iprg.nokia.com (David Kessens) Date: Wed, 27 Aug 2003 16:57:30 -0700 Subject: [ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE46 Message-ID: <20030827165730.A23694@iprg.nokia.com> 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 ---