[99476] in North American Network Operators' Group
Forward for filtering, was: Re: Route table growth and hardware limits...talk to the filter
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Sun Sep 23 16:52:48 2007
In-Reply-To: <Pine.LNX.4.61.0709071849500.30395@soloth.lewis.org>
Cc: nanog@nanog.org
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Sun, 23 Sep 2007 22:38:40 +0200
To: Jon Lewis <jlewis@lewis.org>
Errors-To: owner-nanog@merit.edu
[changed subject because I'm back to the original subject...]
On 8-sep-2007, at 1:14, Jon Lewis wrote:
> The prefix-list presented below should be considered a proof-of-
> concept / work-in-progress. As stated below, no testing has been
> done to verfiy it will cause no loss in connectivity (i.e. due to
> networks deaggregating their space and announcing it only as longer
> subnets than their RIR states are the minimum allocation size for
> the range from which their CIDRs were carved).
I think this is a good idea. Others have pointed out some problems
with people who use PA to multihome or do traffic engineering with
longer prefixes. A good way to go forward with this type of filtering
without hurting people who rely on these types of deaggregation too
much would be to only apply this filter to address space from RIRs in
other regions. I.e., someone in the US would apply the RIR allocation
size filters for address space from all RIRs except ARIN.
This way, multihoming and traffic engineering still work for the most
part. If I multihome with PA or traffic engineer here in the
Netherlands and someone from the US doesn't see my more specifics,
they at least see my aggregate or my ISP's aggregate, and when the
traffic arrives in RIPE land the more specifics kick in.
> While working on this, I noticed a bunch of inconsistencies in the
> expected RIR minimum allocations in ISP-Ingress-In-Strict and in
> the data actually published by the various RIRs.
I have a few more for you by dredging up the actual minimum size
allocations from the allocation records on their FTP sites:
> ip prefix-list ISP-Ingress-In-Strict SEQ 4000 deny 58.0.0.0/8 ge 22
> ip prefix-list ISP-Ingress-In-Strict SEQ 4001 deny 59.0.0.0/8 ge 21
> ip prefix-list ISP-Ingress-In-Strict SEQ 4002 deny 60.0.0.0/7 ge 21
I see /21, /19, /20 and /21 for 58, 59, 60 and 61.
> ip prefix-list ISP-Ingress-In-Strict SEQ 4008 deny 120.0.0.0/7 ge 22
Hm, I don't see 120, probably not in use yet.
> ip prefix-list ISP-Ingress-In-Strict SEQ 4009 deny 122.0.0.0/7 ge 22
/21
> ip prefix-list ISP-Ingress-In-Strict SEQ 4011 deny 124.0.0.0/8 ge 21
/24
> ip prefix-list ISP-Ingress-In-Strict SEQ 4013 deny 126.0.0.0/8 ge 21
/8 (!)
> ip prefix-list ISP-Ingress-In-Strict SEQ 4014 deny 202.0.0.0/7 ge 25
/24
> ip prefix-list ISP-Ingress-In-Strict SEQ 4016 deny 210.0.0.0/7 ge 21
210 = /24, 211 = /19
> ip prefix-list ISP-Ingress-In-Strict SEQ 4019 deny 218.0.0.0/7 ge 21
218 = /24, 219 = /20
> ip prefix-list ISP-Ingress-In-Strict seq 4023 deny 222.0.0.0/8 ge 21
Don't see it.
> ip prefix-list ISP-Ingress-In-Strict SEQ 5000 deny 24.0.0.0/8 ge 21
/24
> ip prefix-list ISP-Ingress-In-Strict SEQ 5004 deny 66.0.0.0/6 ge 21
66 = /20; 67, 68, 69 = /24
> ip prefix-list ISP-Ingress-In-Strict SEQ 5008 deny 70.0.0.0/7 ge 21
70 = /22, 71 has a block of 20480 addresses as its smallest allocation
> ip prefix-list ISP-Ingress-In-Strict SEQ 5010 deny 72.0.0.0/6 ge 21
72 = /22, 73 = /8; 74, 75 = /20
> ip prefix-list ISP-Ingress-In-Strict SEQ 5014 deny 76.0.0.0/8 ge 21
/22
> ip prefix-list ISP-Ingress-In-Strict SEQ 5015 deny 96.0.0.0/6 ge 21
/96 = /19, rest /16
> ! these ge 25's are redundant, but left in for accounting purposes
> ip prefix-list ISP-Ingress-In-Strict SEQ 5020 deny 198.0.0.0/7 ge 25
> ip prefix-list ISP-Ingress-In-Strict SEQ 5022 deny 204.0.0.0/7 ge 25
> ip prefix-list ISP-Ingress-In-Strict SEQ 5023 deny 206.0.0.0/7 ge 25
> ip prefix-list ISP-Ingress-In-Strict SEQ 5032 deny 208.0.0.0/8 ge 23
> ip prefix-list ISP-Ingress-In-Strict SEQ 5033 deny 209.0.0.0/8 ge 21
> ip prefix-list ISP-Ingress-In-Strict SEQ 5034 deny 216.0.0.0/8 ge 21
/24, /24, /24, /20, /20, /24
I suspect the /21 vs /22 discrepancy is where ARIN gives out /22s but
reserves /21s.
(oh and I mistyped /20 a few places that need to be /22 but don't
want to go back and correct, mail me for the raw data per /8 if you
want it)
> ip prefix-list ISP-Ingress-In-Strict SEQ 6001 deny 77.0.0.0/8 ge 22
> ip prefix-list ISP-Ingress-In-Strict SEQ 6002 deny 78.0.0.0/7 ge 22
/21
> ip prefix-list ISP-Ingress-In-Strict SEQ 6004 deny 80.0.0.0/7 ge 21
/20
> ip prefix-list ISP-Ingress-In-Strict SEQ 6006 deny 82.0.0.0/8 ge 21
/20
> ip prefix-list ISP-Ingress-In-Strict SEQ 6007 deny 83.0.0.0/8 ge 22
> ip prefix-list ISP-Ingress-In-Strict SEQ 6008 deny 84.0.0.0/6 ge 22
> ip prefix-list ISP-Ingress-In-Strict SEQ 6012 deny 88.0.0.0/7 ge 22
/21
> ip prefix-list ISP-Ingress-In-Strict SEQ 6014 deny 90.0.0.0/8 ge 22
/17
> ip prefix-list ISP-Ingress-In-Strict SEQ 6015 deny 91.0.0.0/8 ge 25
/24
> ip prefix-list ISP-Ingress-In-Strict SEQ 6016 deny 92.0.0.0/6 ge 22
/13
> ip prefix-list ISP-Ingress-In-Strict SEQ 6020 deny 193.0.0.0/8 ge 25
/29
> ip prefix-list ISP-Ingress-In-Strict SEQ 6021 deny 194.0.0.0/7 ge 25
194 = /28, 195 = block of 26 addresses
> ip prefix-list ISP-Ingress-In-Strict SEQ 6025 deny 217.0.0.0/8 ge 21
/20
> ip prefix-list ISP-Ingress-In-Strict SEQ 7000 deny 189.0.0.0/8 ge 21
/12
> ip prefix-list ISP-Ingress-In-Strict SEQ 7001 deny 190.0.0.0/8 ge 21
/20
> ip prefix-list ISP-Ingress-In-Strict SEQ 7002 deny 200.0.0.0/8 ge 25
/24
> ip prefix-list ISP-Ingress-In-Strict SEQ 7003 deny 201.0.0.0/8 ge 21
/20
> ip prefix-list ISP-Ingress-In-Strict SEQ 8000 deny 41.0.0.0/8 ge 23
/22
> ip prefix-list ISP-Ingress-In-Strict SEQ 8001 deny 196.0.0.0/8 ge 23
/24
> !
> ip prefix-list ISP-Ingress-In-Strict seq 10200 permit 0.0.0.0/0 le 24
Legacy class A space are all /8 except that some of those are de
facto used as RIR space, I think 4/8 and 12/8. Non-RIR class B should
all be /16 but:
| various | 128 | 32768 |
| various | 129 | 20480 |
| various | 131 | 32768 |
| various | 133 | 16777216 |
| various | 137 | 8192 |
| various | 142 | 32768 |
| various | 143 | 32768 |
| various | 146 | 32768 |
| various | 158 | 32768 |
| various | 161 | 8192 |
| various | 166 | 8192 |
| various | 167 | 2304 |
| various | 169 | 256 |
| various | 170 | 32768 |
| various | 172 | 1638400 |
| various | 188 | 65536 |
| various | 192 | 256 |
| various | 198 | 256 |
Also, there are only a few very small blocks so either ignoring those
or making special case exceptions would allow even tighther filters:
+---------+-----------------+------+
| rir | descr | num |
+---------+-----------------+------+
| ripencc | 193.58.0.0 | 16 |
| ripencc | 193.58.0.16 | 8 |
| ripencc | 193.58.0.24 | 16 |
| ripencc | 193.58.0.40 | 8 |
| ripencc | 193.58.0.48 | 8 |
| ripencc | 193.58.0.56 | 8 |
| ripencc | 193.188.134.64 | 16 |
| ripencc | 193.188.134.160 | 8 |
| ripencc | 193.188.134.200 | 8 |
| ripencc | 193.188.134.208 | 8 |
| ripencc | 193.188.134.216 | 8 |
| ripencc | 193.188.134.224 | 16 |
| ripencc | 193.188.134.240 | 16 |
| ripencc | 193.192.15.0 | 16 |
| ripencc | 193.192.15.16 | 16 |
| ripencc | 193.219.15.0 | 16 |
| ripencc | 194.149.71.192 | 16 |
| ripencc | 194.149.71.208 | 16 |
| ripencc | 194.149.71.224 | 16 |
| ripencc | 194.149.71.240 | 16 |
| ripencc | 195.95.173.0 | 26 |
+---------+-----------------+------+
21 rows in set (0.16 sec)
select rir, count(*) from addrspace where type='ipv4' and num < 256
group by rir;
+---------+----------+
| rir | count(*) |
+---------+----------+
| ripencc | 200 |
+---------+----------+
