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