[6bone] separating IPv6 experimental from production traffic

[Ronald van der Pol]

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.

It's becoming so bad that almost every week I have a major IPv6
connectivity problem which prevents me from doing my daily work.
I run dual stack and my applications try IPv6 first. When IPv6
traffic is blackholed somewhere I have a problem. When I am lucky,
the application times out and tries IPv4. If not, I just don't get
a connection. I have to manually type in an IPv4 address.

We are at a stage now that in parts of the world IPv6 is used on
a daily basis. In Japan it's a commercial service for a long time
now. People are paying for IPv6 transport and expect to have a good
IPv6 connectivity.

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.

BTW, in my opinion "IPv6_production == native_IPv6, per definition"
is *not* true. I think you can do IPv6 production service partly
with tunnels, as long as you are very, very careful about choosing
the paths of the tunnels and the peerings are monitored closely. On
the other hand, accidents will happen on the production IPv6 network,
just as in the IPv4 network. But these should be exceptions, just
as in the IPv4 world and not the daily routine from the current
6bone.

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.

Comments?

	rvdp