RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
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.
On Tue, 13 May 2003, Michel Py wrote:
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.
RIR's have obtained multiple blocks, as they receive them in the chunks of /23's from IANA. (A thing I've complained about to IANA, btw.). So, they need a new one every 2^6 = 64 allocations. That's way too often, and maintenance would be a pain. With current mechanisms, there's always a way to hijack space (e.g. you could announce a slice of /32 from the /29 everyone has been reserved), we really can't avoid it using bogon filters.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hi, ok, now to followup on this: On Tue, May 13, 2003 at 09:13:04PM -0700, Michel Py 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 [..] 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.
Unfortunately the ARIN database is too broken to permit queries like "tell me everything inside 2001:500::/32" (the RIPE and APNIC databases do this just fine). So you'll have to check them manually - tedious - or check http://www.arin.net/registration/ipv6/micro_alloc.html. Unfortunately, the URL only lists "those prefixes are allocated to IXPs" (from 2001:504::/32) and "those are for critical infrastructure" (from 2001:500::/32), but without specifying for *what* parts of the infrastructure... Checking the allocations individually with "whois", I find: 2001:500::/48 --> ISC 2001:500:1::/48 --> US Army Research/H-ROOT-NET 2001:500:2::/48 --> "Cogent Communications" 2001:500:3::/48 --> ICANN/L-ROOT-NET The docs on http://www.root-servers.org/ imply that 2001:500::/48 is also used as root name server network (F), and most likely the network for Cogent Communications will be used for (C).
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.
Good point. I will try to figure out what /35s are still out there and adapt the (strict) filter accordingly.
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.
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). So I'm not sure whether the drawbacks you mention are not really worth the gains. (Also, the IPv6 address allocation strategy IANA -> RIRs is currently so messy that quite frequent updates would be needed)
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.
Yes, this is true. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
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
On Mon, 19 May 2003, Gert Doering wrote:
Unfortunately the ARIN database is too broken to permit queries like "tell me everything inside 2001:500::/32" (the RIPE and APNIC databases do this just fine). So you'll have to check them manually - tedious - or check
Currently ARIN WHOIS does not support CIDR queries. However, the information you desire can be obtain. The best way to get this, would be to query the following: 2001:0500* 2001:0504* This would provide the information in list format. If you would like full details of all these allocations, query: +2001:0500* +2001:0504* More information on how to use the ARIN WHOIS can be found in a tutorial locate at: http://www.arin.net/library/training/WHOIS_CBT/whois.htm Ginny Listman Director of Engineering ARIN
Hi, On Mon, May 19, 2003 at 08:51:04AM -0400, ginny@arin.net wrote:
Unfortunately the ARIN database is too broken to permit queries like "tell me everything inside 2001:500::/32" (the RIPE and APNIC databases do this just fine). So you'll have to check them manually - tedious - or check
Currently ARIN WHOIS does not support CIDR queries. However, the information you desire can be obtain. The best way to get this, would be to query the following:
[ query for '2001:0500:*' ] While "*" wildcards are somewhat counterintuitive in IP context, I'm glad to learn that there *is* a way to get the data. Others have pointed out to me that by querying the RIPE database for mirrored ARIN data whois -h whois.ripe.net -s arin -M -r 2001:500::/32 (with or without "-r") the data can be obtained as well. [..]
More information on how to use the ARIN WHOIS can be found in a tutorial locate at: http://www.arin.net/library/training/WHOIS_CBT/whois.htm
Thanks. (ObNag: I still don't understand why ARIN just needs to do everything differently. Just using the RIPE output and query format would be so much easier than inventing every wheel anew. But then, I don't know all of the political background struggles...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (4)
-
Gert Doering -
ginny＠arin.net -
Jeroen Massar -
Michel Py -
Pekka Savola