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

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

19 May '03

Carlos, > Carlos Morgado wrote: > Yes, that is indeed one scenario. But consider the extreme > case of an operator which only sells transits to multihomed > customers who already have their own address. Can you come with a real example? More, can you come up with a real example that has applied for space and has been denied the prefix? On paper, this is an issue but policies are not on planning on every possible hypothetical case. Michel.

2 1

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 recommendation
by Jeroen Massar 19 May '03

19 May '03

Gert Doering wrote: <SNIP> > > 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. > > Someone else already commented on this. As the address space > is pretty > sparsely populated, people still would be able to hijack addresses > (like "2001:609::/32", which is adjacent to our /32, but > right now just unallocated). *whisper in ear* not after tonight when the bogon reporting gets active :) Things that it does cover already: - unallocated prefixes - wrong source ASN's Though ofcourse one could bypass that when using the registered source ASN. That could be detected if we knew every 'upstream' for that prefix... Greets, Jeroen

1 0

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

19 May '03

Hi, On Fri, May 16, 2003 at 10:17:11AM -0400, Kimmo Suominen wrote: > I've used IPv4 space in the past to connect to extranet providers using > unique addresses, without connecting to the Internet. Is such use not > allowed in the IPv6 world? One must promise to advertise the addresses > to the Internet to get an allocation? End to extranet providers? I wouldn't go so far as to say "it's not allowed". What I am saying is that the current IPv6 allocation policy was made with the needs of people in mind that want to connect to "the global Internet", so there is no clear answer how to fulfill those people's needs. When the policy was made, people were still suggesting the use of site-local addresses for "non-global" usage. Site-locals seem to be dead, so there is a hole in the policies right now. Passing on the question from the registry point of view to the IETF people (Michael & co): what are your recommendations how this can be addressed (in the double sense)? 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

3 8

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

RE: [6bone] Re: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Jeroen Massar 13 May '03

13 May '03

John Fraizer [mailto:tvo@EnterZone.Net] wrote: > On Tue, 13 May 2003, Jeroen Massar wrote: > > > John Fraizer wrote: > > > > > I don't think that an exception should be made for > microallocations at > > > all. To paraphrase what ARIN says, there is no guarantee > that address > > > space that they assign will be globally routable. > > > > You should note that that also goes for the rest of the allocations. > > 69/8 in IPv4 anyone ? :) > > The alloocations I have seen have problems out of 69/8 were not > micro-allocations. They were /19's and /18's. I'm sure that > there are a few /20's in there with a token /24 perhaps but, the ones I > have knowledge of were _real_ allocations and not micro-allocations. Yes, but what I meant is the fact that a RIR can't possibly guarantee routability of a prefix. Which was the case seen with 69/8. Even then if a big transit doesn't want to carry your prefix for $reason it won't be reachable either ;) Greets, Jeroen

1 0

[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