Filtering prefixes longer than /24

[Robert J. Rockell]

I think the basis for 2772 was to establish a 'minimal' set of filtering
guidelines upon which we could form a 'stable' 6bone. Without at least this
much participation in filtering, it would be difficult to find problems in
Ipv6 deployment (at the protocol level; not necessarily the
implementations).  What one does with their immediate upstream for
load-sharing when they have multiple connections to one upstream is up to
them and their upstream. I agree with Itojun here.

If this makes multi-homing difficult, or the like; that is sort of the
point. This is all supposed to be aggregatable at the most fundamental
levels, thus putting a top limit on the number of non-customer routes a TLA
will have to carry. Violating this just adds factors of 2 to the routing
table size, in theoretical limit.  I agree there is problems, specifically
in multi-homing.  The goal was to fix the problems with multi-homing, and
this was a good way to bring the problems out.  IMHO, I don't want to fix
the symptoms.

If you are homed to one provider with multiple connections, and have a /32
from them, one can either negotiate de-aggregation with them, or use other
BGP attributes to make one's desired policy to work. If you are announcing
pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you
have violated rfc2772 already.  

Thanks
Rob Rockell
Principal Engineer
SprintLink Europe/Asia
Sprint E|Solutions: Thinking outside the 435 box
-----------------------------------------------------------------------

On Mon, 9 Jul 2001 itojun@iijlab.net wrote:

->>It appears some people are filtering prefixes longer than /24 in 6bone.
->>We'd like to advertise /32.
->>This was noticed when we wanted to change the peerings to a second router,
->>and moved a "backup one" first and forced the traffic go through there; to
->>certain locations, the return packets disappeared to the network
->>advertising /24.
->>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.
->
->>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
->
->itojun
->