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

[Nicolas DEFFAYET]

On Wed, 2002-11-20 at 13:36, Petr Baudis wrote:
> 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.

Christian is an inmensly irritating clueless kiddie who wants to impress
other 6bone / ipv6 users.

We don't have setup any filters !
My email was only for have a reaction of Christian about him filtering.
I don't appreciate his message on his website about our AS and pTLA
filtering.

Before send my email to Christian, i have checked the reality of him
filtering but Christian is too lame and don't have check the reality of
our filtering before send him email to 6bone mailing-list.


We will NEVER do packet filtering and we will NEVER filter valid ASN and
valid pTLA/sTLA.

We manage our network professionnaly, we will never do filtering for
fun.

> 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."

I support this.

I think that "pTLA providers SHOULD NOT filter traffic, valid ASN and
valid pTLA/sTLA" is better. 


Best Regards,

-- 
Nicolas DEFFAYET, NDSoftware
NOC Website: http://noc.ndsoftwarenet.com/
FNIX6: http://www.fnix6.net/