[6bone] Re: separating IPv6 experimental from production traffic
Petr Baudis
pasky@pasky.ji.cz
Sun, 25 Aug 2002 21:42:26 +0200
Dear diary, on Wed, Aug 21, 2002 at 03:41:25PM CEST, I got a letter,
where Ronald van der Pol <Ronald.vanderPol@rvdp.org> told me, that...
> As you know I am increasingly worried about the quality of IPv6
> transport. I have far more problems reaching IPv6 destinations than
> I have reaching IPv4 destinations. This is not because I have a
> bad provider, but because my traffic is blackholed somewhere far
> away in the 'Net.
..snip..
> The current situation is that we have one network, the 6bone
> (although it is hard to define what it is exactly). The current
> 6bone is used for all kinds of experiments (even with old or alpha
> routing software) and is used as a playground for people new to
> IPv6 (no problem, it's very good, as long as it doesn't interfere
> with my production traffic).
>
> I think we should work towards separating experiment and playing
> from production. Experimenting needs to be done, but it should
> have minimal impact on production. This is what most :-) do in the
> IPv4 world. However, I do not propose to disconnect one from the
> other. On the contrary, there should be good connectivity between
> them. But I think we should stop the current situation where
> production traffic is routed *via* an experimental network. What I
> want is IPv6 transport that is treated similar to IPv4 transport.
>
> In the current situation this is hard to accomplish by individual
> ISPs because of the tunnels all over the world and transit to
> everyone. So I guess we first have to reach concensus whether we
> want this separation or not.
As I already expressed few times before, let this be a natural process. Any
administrative decision and forced moves and peering terminations etc won't be
followed by the whole community anyway and they will only create big mess. As I
understand term "productional", it's basically about money ;-) - so, if you
want it stable and.. hmh, productional, why do you do transit through 6bone
people? Do it through productional networks and you should do fine - do your
productional peers do transit through 6bone people? Ask them not to - if they
will refuse and their 6bone peers are unstable, they probably don't care about
stability and production a lot - are they right people to peer with? Or, can't
you filter 6bone prefix propagations from them if they let unstable 6bone
people do transit for them? Are people with RIR ("productional") allocations
making you problems? Then efforts to separate 6bone from productional networks
are irrelevant.
If your peers will hear your calling and do same as you, you will reach
technical and *effective* consensus, and the real IPv6 community "voted" about
solution of this problem. If they won't hear you, they probably don't care
about IPv6 much enough yet, and your efforts are useless yet anyway.
> At this stage I am only asking for separation of experiment from
> production. I am not saying anything yet about what prefixes to
> use where. I am also not saying yet what the experimental network
> (the 6bone) should be used for. I guess all I am saying is: don't
> use the 6bone for production traffic. In my view in the new situation
> a site can have two kinds of peerings: 6bone peering or production
> peering. What should be prevented is traffic coming from the
> production network, going via the experimental network to a production
> destination.
Sure, if you want separation of productional and experimental network, first
thing you probably want to do is separation of allocations (pushing
experimental allocations to 3ffe::/16 and productional allocations out of
that), so that you can *identify* subjects you want to separate from ;-).
--
Petr "Pasky" Baudis
* ELinks maintainer * IPv6 guy (XS26 co-coordinator)
* IRCnet operator * FreeCiv AI occassional hacker
.
> Girls are like internet domain names, the ones I like are already taken.
Well, you can still get one from a strange country :-P
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/