[6bone] Re: routing concern

[Petr Baudis]

Dear diary, on Wed, Jul 31, 2002 at 12:10:35PM CEST, I got a letter,
where Ronald van der Pol <Ronald.vanderPol@rvdp.org> told me, that...
> On Tue, Jul 30, 2002 at 11:13:36 -0700, Michel Py wrote:
> 
> > As I said before, the 6bone is the right place for this. Has anyone been
> > hurt? Anyone lost money? The lessons we collectively learn each time
> > someone messes up a route are far more valuable than the consequences of
> > messing up the route.
> 
> Is it time to start making a clear distinction between IPv6 production
> and IPv6 experimentation/learning? I think today the 6bone is used for
> both.
>  
> Many use IPv6 for their daily work *). We *need* a stable network for
> that.  If we don't do that we risk scaring people away from IPv6. Most
> OSes support IPv6 nowadays. When an enduser starts using IPv6 for the
> first time and she notices all kinds of networking problems, many will
> think: "OK, let's turn off IPv6. It does not work."
>  
> The RIR prefixes are meant for IPv6 production. So, I think they should
> not be used on the 6bone. The 6bone should only be used for experiments
> and possibly learning. And on the other hand, I think production services
> should not use 6bone prefixes, but RIR prefixes.
>  
> 	rvdp
>  
> *) I frequently use ftp, cvs and http over IPv6 to sites far away in
> the internet. Too often, there are routing problems and IPv6 traffic
> is blackholed (routing loops, etc). Most application time out and try
> IPv4. But this means annoying delays. Many of these problems occur
> because people are running production services over the 6bone.

This is wild world and natural processes mostly rule this world. Basically, I
believe that unreliability of the IPv6 internet is generally caused by the fact
that it does not run native, but tunnelled through IPv4. And people tend to
create peerings through tunnels even with peers they have poor latency to etc.
It's not the 2001::/16 what saves you, it's the unwritten (?) rule that native
links usually live inside 2001::/16 and tunnels inside 3ffe::/16. As people
continue with establishing of native IPv6 links and peerings, the situation
improves and the native peering usually tends to be much more stable and
reliable than the peering through tunnels, especially when driven on some
official base (and this is also another difference between IPv4 and IPv6, IPv4
peerings are protected by various contracts and agreements, being ran on
commercial base; IPv6 usually aren't [altough there are obviously exceptions
already]). And as the time goes on, people obviously tend to sacrifice the
tunnel peerings for native ones and the reliability improves. The natural
process.  You can obviously push it a lot by preferring native peerings before
the tunneled ones, and this should probably become another written unwritten
rule.

This has been said before already in few mails undirectly, this mail is meant
generally as a summary of that view (not the only one here, obviously, just the
one I agree with).

-- 
 
				Petr "Pasky" Baudis
 
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI occassional hacker
.
You can get much further with a kind word and a gun than you can with a
kind word alone. -- Al Capone
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/