May 2003 - ipv6-wg - mailman.ripe.net

RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 19 May '03

19 May '03

Gert, > Gert Doering wrote: > I have just added an update to the "strict" filter list of > my IPv6 filter list recommendations on > http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for the heads-up. Some comments: > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe::/18 ge 24 le 24 > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe:8000::/22 ge 28 le 28 This part is fine. > ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/32 ge 48 le 48 It would be interesting to have more refinement here. What I mean is that I would be open to allow a /48 that contains a root server but not a /48 that serves an IXP. More details/specifics to what is inside 2001:500::/32 would be appreciated. > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35 I think this could be refined too. The range where /35s were originally allocated from is much smaller than 2001::/16. > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 24 le 32 This could also be refined. Not all 2001::/16 has been delegated to RIRs. ARIN got a block, RIPE got a block, APNIC got a block, but there still is some undelegated space. The drawback of refining to that level is that it will inevitably induce a situation similar to 69/8 and will require maintenance, but the other side of that coin is that it would prevent people from hijacking prefixes from undelegated space. As an example and please correct me if wrong in the address I picked because it's all from memory, if I hijack and announce 2001:FEED::/32 that would pass your filter but this prefix can't be assigned to anybody now as it is not part of a larger block that has been delegated to a RIR, so it must be a hijack. Michel.

4 4

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recomme ndation
by João Carlos Neves Cabral 16 May '03

16 May '03

On Fri, 16 May 2003, leo vegoda wrote: > Hank Nussbacher <hank(a)att.net.il> writes: > > [...] > > >What are the RIRs doing to reclaim all those "red" lines of allocations > >that have never once appeared in a routing table? I would say all > >assignments from before Jan 2002 and that have "never"in the "last > >seen" column are ripe for revocation.Question is, why hasn't this > >been done before and has this been discussed so far? > > Is there a policy requirement that IPv6 prefixes allocated by RIRs must > be routed on The Internet? I've not found it in the current "IPv6 > Address Allocation and Assignment Policy". :Is there such a requirement for IPv4 prefixes? If yes (and I would hope :so, otherwise why would anyone want RFC1918 addresses when one can get :"real" IPs), then I think the same should apply for IPv6 prefixes. Allow me to give my two cents on this one: I should think not! I'm not thinking in terms of announcing /32s on the Internet; if announcing a /32 on the Internet is a requirement, I can easily cope with it. But what about in terms of private versus globally reachable IPv6 addresses ? In IPv4 we need to be careful and save IP addresses because there aren't that many and hence, we use RFC1918. In IPv6 we no longer have that problem ... so why should anyone need to use private addresses unless for a really small guarenteed closed network (i.e. site i.e. site-local within the site only) ? My question is, how do RIRs look at a company or institution using a slice of its /32 for their internal not reachable from the Internet networks ? Is this acceptable usage of IPv6 addresses or do we need to all start using the same site-local addresses as we do for RFC1918 in our internal networks and end up with endless problems with address conflicts ? Back on the subject, I wouldn't be shocked if IPv6 /32s were assigned by RIRs to LIRs that need these addresses for uniqueness and yet, don't need for them to be announced on the Internet. regards, Joao. ---

1 0

[ipv6-wg@ripe.net] 6BONE database entries for non-3FFE space?
by Pekka Savola 14 May '03

14 May '03

Hi, I'd like to hear what others have done with regard to this.. Currently, we only have the RIPE 2001:FOO::/32 space anymore. The assignments have been recorded in the RIPE database in the normal fashion, of course. (Of course, the situation is the same with ARIN/APNIC/.. space too, but just to take an example.) Have folks w/ production space kept the 6bone database http://www.viagenie.qc.ca/en/ipv6/registry/ and http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/ up-to-date especially regard to assigned /48 sites? Or is there a rough consensus to let it rot in pieces for non-3FFE address space? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

2 1

[ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Gert Doering 14 May '03

14 May '03

Hi, I have just added an update to the "strict" filter list of my IPv6 filter list recommendations on http://www.space.net/~gert/RIPE/ipv6-filters.html The new thing is that inside 2001:500::/29, the "strict" list is now permitting /48s. This is because 2001:500:: is used for ARIN microallocations, and /48s are the "normal" allocation boundary in there. Two networks are already announced from within that block, 2001:500::/48 and 2001:500:1::/48, and some ISPs promtly can't reach them due to too tight filtering. So if you filter very strictly, please adapt your filters for that block. (Thanks to Carlos Friacas for pointing that out to me). 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

7 10

[ipv6-wg@ripe.net] Webcast RIPE 45 Announcement
by RIPE NCC Meeting Registration 13 May '03

13 May '03

Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to <ripecast(a)ripe.net>. Regards, RIPE Meeting Coordination Team

5 4

RE: [ipv6-wg@ripe.net] Webcast RIPE 45 Announcement
by matthew.ford＠bt.com 13 May '03

13 May '03

Could whoever is operating the camera please drink less coffee..... just point the thing at the screen and be done with it .... I'm getting motion sickness ;-) Mat -----Original Message----- From: RIPE NCC Meeting Registration [mailto:meeting@ripe.net] Sent: Tue 13/05/2003 14:50 To: local-ir(a)ripe.net; ripe-list(a)ripe.net; ripecast(a)ripe.net; lir-wg(a)ripe.net; routing-wg(a)ripe.net; db-wg(a)ripe.net; ipmt-dev(a)ripe.net; ipv6-wg(a)ripe.net Cc: meeting(a)ripe.net Subject: [ipv6-wg(a)ripe.net] Webcast RIPE 45 Announcement Dear Colleages, Please note that several sessions at RIPE 45 are being webcast. These sessions include the following: - - EOF - - Routing Working Group - - LIR Working Group - - Tools Working Group - - The RIPE NCC Services BoF - - IPv6 Working Group - - Database Working Group - - Plenary To see the meeting in real time, please use one of the following URLs. As we have limited bandwith to the meeting venue, we ask that you choose a server that is physically closer to you: - - RIPE Meeting Attendees only: mms://webcast.ripemtg.ripe.net/ripemtg - - Spain Mirror: mms://media.rediris.es/ripelive - - Portugal Mirror: mms://wms.fccn.pt/ripelive - - Italy Mirror: mms://stream1-wg.cineca.it/ripelive - - Denmark Mirror: mms://wmslave.fsknet.dk/ripelive - - Czech Republic Mirror: mms://server1.streaming.cesnet.cz/ripemtg - - United Kingdom Mirror: mms://ccs-web2k.brynmill.swan.ac.uk/ripelive - - Netherlands Mirror: mms://stream-ripe.wind.surfnet.nl/ripelive - - Amsterdam Mirror (RIPE NCC Office): mms://webcast.ripe.net/ripemtg Please note that the webcastings are technical trials only and the broadcasts should not be regarded as an official implementation of a webcasting service. More information on the webcastings with detailed instructions can be found at: http://www.ripe.net/ripe/meetings/ripe-45/webcast.html We welcome your feedback on these trials. Please send your comments to <ripecast(a)ripe.net>. Regards, RIPE Meeting Coordination Team

1 0

[ipv6-wg@ripe.net] unsubscribe
by Carlo Van Wordragen 13 May '03

13 May '03

unscubscribe c.v.wordragen(a)aranea.nl

1 0

RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 13 May '03

13 May '03

> Gert Doering wrote: > Micro-Allocations are *bad*. If they end up in the Global Routing Table, yes they are. > I can see two exceptions that can be clearly defined and are > really "exceptionable enough" (and not "just convenient") - > that's IXPs, and root name servers. We have policies for > those. Root name servers, no doubt. For IXPs, I do understand and support the need for micro-allocations but I am not convinced that they need to be announced in the GRT. > All other Micro-Allocations boil down to inventing PI > in one region only. Thank you. Michel.

1 0

RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 12 May '03

12 May '03

> Pekka Savola wrote: > There is a danger that this uncoordinated madness will spread. Indeed it _is_ spreading already. I get a bunch of /64s, /48s, any kind of prefix if you can name it I get it already from some peering in North America when I drop my filters. > There has been a proposal to extend the microallocation policy, > but luckily enough it has been shot down. Fortunately it has although we can expect that there will be more tries. I will stay on the line of filtering anything that has not been approved by all 4 RIRs (LATNIC is live I hear). Michel.

1 0

[ipv6-wg@ripe.net] Draft minutes (v1) RIPE 44
by David Kessens 08 May '03

08 May '03

Hi, Please see below for the draft minutes of the ipv6 working goup at last RIPE meeting. The minutes will be declared final if I don't receive major objections by friday May 23 2003. I hope this helps, David K. --- Draft minutes (v1) 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