[6bone] Blackholing on 6bone (possible RFC 2772-bis bit?)

[Petr Baudis]

Dear diary, on Tue, Nov 19, 2002 at 06:15:51PM CET, I got a letter,
where Christian Nickel <dragon@tdoi.org> told me, that...
> > I'm glad to announce that NDSoftware (AS25358) has setup filters for
> > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48,
> > 2001:768:1800::/40.
> > 
> > >From your website (http://www.tdoi.org):
> > "Our Autonomous System does not accept prefix 3ffe:4013::/32.
> > Any route via AS25358 will be removed.
> > You cannot reach any prefix routed via AS25358!"
> > 
> > It's too funny.
> > 
> > You don't have an Autonomous System, you have a private ASN with 2 /48
> > and 1 /40 for play.


I believe that introducing such a practice to 6bone is potentially very
dangerous; it can possibly devolve to endless revenges chain and further
irresponsible behaviour affecting reachability of nodes over the whole IPv6
world, further harming the reputation and transition to IPv6. This is no longer
even 6bone itself issue, since the blackholed host is from the production
RIPE's space. This practice can thus help the argumentation for isolation of
the 6bone prefixes.

There's a question if pTLA operators should fall into revenge to end sites
(even connected by other pTLAs). It is private decision of the end user TDOI to
filter announcements made by other ASN and it is private decision of NDSOFTWARE
to filter TDOI _for ourselves_. But it affects the whole 6bone routing if one
pTLA is effectively blackholing some arbitrary prefix for not well-posed and
well-announced reasons. Thus, it would be probably extremely desirable if
(choose one):

a) NDSOFTWARE terminated this filtering
b) NDSOFTWARE filtered this prefix only for its customers, not peers
c) NDSOFTWARE did not announce the prefix (2001:768::/32) to its peers
d) NDSOFTWARE peers re-thought the peering policy and were careful about
accepting full transit from NDSOFTWARE
e) 6bone community was careful about prefixes it's receiving which have
NDSOFTWARE's ASN in their AS path

I basically believe that leaving this uncommented can settle dangerous
precedent for the future, thus this case should be carefully dealt with. Note
that I have no positive relation with TDOI and I try hard to have no negative
relation with NDSOFTWARE.


Further, I think that maybe it would be desirable to add some tiny paragraph
about this to RFC 2772. Kind of: "pTLA providers SHOULD NOT filter traffic
destinating at arbitrary prefixes while still announcing the prefix,
effectively blackholing the prefix, unless it properly announces and reasonates
such action and is ready to re-think the measure if it met disagreement in the
6bone community."


Any comments welcomed! :-) "Oh no, another policial thread," I know, but I
think that these issues should be discussed and solved somehow.

Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
weapon, n.:
        An index of the lack of development of a culture.
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/