- ipv6-wg - mailman.ripe.net

[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

[ipv6-wg@ripe.net] New IPv6 block allocated to RIPE NCC
by leo vegoda 30 Jul '03

30 Jul '03

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:1600::/23 from the IANA in July 2003. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

[ipv6-wg@ripe.net] Help: Cannot assign requested address?
by Polychronis Ypodimatopoulos 15 Jul '03

15 Jul '03

You usually get this problem when your interface (ethX) has not been assigned a global IPv6 address. But you seem to already have done this. Try pinging yourself: # ping6 -I eth1 ::1 If you still get this error then something is buggered. Try reloading the ipv6 module. br. -- =============================== Polychronis Ypodimatopoulos MSc Software Engineer Defense Systems Development INTRACOM S.A. Markopoulo Ave, 190 02 Peania Tel: (+30)210-667 9067 Fax: (+30)210-667 4634 email: ypol at intracom dot gr http://www.intracom.gr

1 0

[ipv6-wg@ripe.net] FWD: Document action: 'Use of /127 Prefix Length Between Routers Considered Harmful'
by David Kessens 15 Jul '03

15 Jul '03

We have had some discussions about this topic so people might be interested to read this rfc. David K. --- ----- Forwarded message from ext The IESG <iesg-secretary(a)ietf.org> ----- X-Delivered-For: <david(a)iprg.nokia.com> From: "ext The IESG" <iesg-secretary(a)ietf.org> To: IETF-Announce:; Cc: "RFC Editor" <rfc-editor(a)isi.edu>, "Internet Architecture Board"@asgard.ietf.org Message-Id: <E19cMuA-0008Ot-8X(a)asgard.ietf.org> Date: Tue, 15 Jul 2003 06:19:30 -0400 X-OriginalArrivalTime: 15 Jul 2003 10:29:30.0873 (UTC) FILETIME=[F9EA5690:01C34ABB] <iab(a)iab.org> Subject: Document Action: 'Use of /127 Prefix Length Between Routers Considered Harmful' to an Informational RFC ------------------------ The IESG has approved the Internet-Draft 'Use of /127 Prefix Length Between Routers Considered Harmful' <draft-savola-ipv6-127-prefixlen-04.txt> as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Randy Bush. ----- End forwarded message -----

1 0

[ipv6-wg@ripe.net] reverse, whois..
by Andrius Kasparavicius 25 Jun '03

25 Jun '03

hi, why there is no "nameserver" records in inet6num? Also it would be useful to have reverse zones on ftp.ripe.net, like in-addr now is. Also, maybe could someone explain why dig -x 2001:778:: NS doesn't work? Is it my fault? best regards, Andrius

13 24

[ipv6-wg@ripe.net] Florian Frotzler's master thesis
by Henk Uijterwaal (RIPE-NCC) 27 May '03

27 May '03

Dear All, In my talks in Barcelona on "first results of the IPv6 version of TTM", I referred to Florian Frotzler's master thesis. This document is now on the web at: http://www.ripe.net/ttm/Documents/Various/ffrotzler.pdf Kind regards, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

1 0

[ipv6-wg@ripe.net] Fw: Help setting ipv6 address on my machine with two ethernet cards
by mario 26 May '03

26 May '03

> i've two ethernet card on two host and i'm not able to set ipv6 address on > both ethernet card. > how can i do? > > question : > the device name of ethernet card for ipv6 is sit0 sit1 sit2 etc etc??? > > if not, how can i set ipv6 address for every interface that i have? >

2 1

[ipv6-wg@ripe.net] Discussion about RIPE-261
by Gert Doering 23 May '03

23 May '03

Hi, those of you that have been to Barcelona have heard the presentation by Paul Wilson from APNIC concerning the RIPE-261 document. In short, it's a proposal how to reorganize distributing IPv6 allocations "from the root" to the LIRs, fixing the way it's done now (ICANN allocating /23 fragments to the RIRs, and the RIRs having to fill them quite thoroughly, not leaving space for an ISP to grow past a /29). Technically, this is a matter between the RIRs and ICANN, but as this proposal affects routing and filtering as well, it would be useful to have consensus among the members that it's a good thing. So: please read the document (ftp://ftp.ripe.net/ripe/docs/ripe-261.txt) and comment on it. Note: this e-mail goes to ipv6-wg and lir-wg, but please don't followup to ipv6-wg - keep all of the discussion in the lir-wg mailing list. Speaking as "me personally" (this is not the official WG chair speaking here, just a concerned IPv6 user!), I have the following comments: - The /23 allocations ICANN -> RIRs are bad, because they lead to address space fragmentation, and the blocks are too small to do useful allocation towards the LIRs. Something NEEDS to be changed here. - Nevertheless, I do NOT like the idea of a "common address pool". People want to be able to see the "region" that a prefix is coming from by looking at the address. This is working fine now in v4 (except for the swamp and part of ERX) and in the so-far IPv6 allocations (except that due to the /23s it's getting messy), but would be broken by the CAP. - As a technical reason: people want to be able to filter IPv6 prefixes by region, like "I only have one uplink that provides me with US connectivity, so there's no need to carry any US prefixes in my routing table, I just point a summary down that line". This is not yet done, but I am convinced that we shouldn't break routing hierarchy without good need. - If people *really* go into "multiple /48s per site" multihoming, source address selection works by doing a longest-match check, and this will work better if same-region addresses have something like a common prefix, instead of "everythins smeared everywhere". So my personal recommendation would be: - change the /23 allocation boundary ICANN -> RIR to something more useful, like a /12 or so (a /12 means "512 of them are available, so we're not yet burning bridges - but a /8 would work as well. A /16 is already somewhat tight). - every RIR still gets its own allocation from where RIR->LIR allocations are taken - inside that RIR allocation, use the binary chop algorithm described in RIPE-261 for the RIR->LIR distribution. So - let the discussion start now! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Re: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Gert Doering 23 May '03

23 May '03

Hi, On Mon, May 12, 2003 at 09:27:04PM +0200, Jeroen Massar wrote: > > LACNIC has allocated to /32s, as far as I can see. One is already > > visible (2001:1200::/32). > > Grmbl, those don't show up in http://www.ripe.net/ipv6/ipv6allocs.html > :( No (database mirroring issue). RIPE people know about it and are working on it. > Okay going to fix up the bogon filter so I will at least catch them on > sight. :) > http://www.sixxs.net/tools/grh/tla/lacnic/ : > 2001:1200::/32 - 2002-12-19 - visible > 2001:1208::/32 - 2003-02-03 - not visible Yup :) > http://www.sixxs.net/tools/grh/tla/ now reads: > 8<----------------------------- > Prefix Length distribution > The following prefixlengths are delegated by the above RIR's. > > 58x /24 > 56x /28 > 336x /32 > 50x /35 > Totaling in 500 TLA prefixes. > ------------------------------>8 > > 500 TLA's over 54 countries! Oh, wow. Very impressive, this! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

8 18