[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Filtering prefixes longer than /24
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
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.
Sprint E|Solutions: Thinking outside the 435 box
On Mon, 9 Jul 2001 [email protected] 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
->>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
-> 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