Filtering prefixes longer than /24

Pekka Savola pekkas@netcore.fi
Mon, 9 Jul 2001 16:05:49 +0300 (EEST)


On Mon, 9 Jul 2001 itojun@iijlab.net wrote:
> >The routing document says you MUST make arrangements with your peers if
> >you do longer advertisements, but advertising these prefixes doesn't help
> >any if they are being filtered by the third parties.
>
> 	because third parties are not in your arrangements.

True, which is why I'm taking up the issue for general consideration.

> >Filtering /48 and more specific is IMO ok to me, but /32 appears a little
> >too strict.
>
> 	based on RFC2772 recommendation, i see the following filter in
> 	many places.   how do you measure "too strict"?
>
> ipv6 prefix-list 6bone-filter seq 5 permit 3ffe::/17 le 24 ge 24
> ipv6 prefix-list 6bone-filter seq 10 permit 3ffe:8000::/17 le 28 ge 28
> ipv6 prefix-list 6bone-filter seq 12 deny 3ffe::/16
> ipv6 prefix-list 6bone-filter seq 15 permit 2000::/3 le 16 ge 16
> ipv6 prefix-list 6bone-filter seq 20 permit 2001::/16 le 35 ge 29

With "too strict" I mean preventing prefixes that:
 - aren't there by accident (redistributing connected and static
routes causing various /64 - /128 in DFZ)
 - don't bloat the routing table by too specific routes (/48) as a
principle
 - could actually be used in some valid environments (if your upstream
pTLA peering isn't optimal, you can't go peer with anyone else, or create
backup peering; you have to renumber the site or use two addresses in each
box..)

Ie, the current behaviour is easily defined, but also kind of "because we
can".

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords