On killing IPv6 transition mechanisms

[Gert Doering]

Hi,

On Tue, Mar 16, 2010 at 06:14:54PM +0000, Benedikt Stockebrand wrote:
> Gert Doering <gert at space.net> writes:
> 
> >> Do you get the same result when you connect to a statistically
> >> significant selection of IPv4-only ISPs using whatever 6to4 public
> >> relay?
> >
> > I'm not exactly sure how a 6to4 public relay would enable me to connect
> > to an IPv4-only ISP?  (And I don't have a high enough number of servers
> > on 2002:: addresses to make this a meaningful experiment).
> >
> > If I connect to an IPv4-only ISP, I use IPv4 on my end...
> 
> ok, just to rephrase my original question: If you connect to the
> Internet via an IPv4-only ISP (rather than one that offers native
> IPv6) and then alternatively use native IPv4 and 6to4 to access a site
> serving both, do you still notice a difference in latency?

I'm pretty sure that I will.  That was the initial starter for this 
thread - 6to4 is usually worse than native IPv4, and is causing real
problems.

Which is why it is fortunate that all the (recent?) Windows versions do 
the right thing, and prefer native IPv4 before 6to4 and Teredo - so 
for connecting to a dual-stacked hosts, 6to4 latency is irrelevant.

[..]
> >> That's fine if have the resources to do the Google approach
> >> and only serve AAAA's to whitelisted clients.  If you can't do that,
> >> then there's the alternative approach of using "www6.example.com." for
> >> AAAA's---that requires conscious action on the client side.
> >
> > Which was OK for testing IPv6 services in the last century, but this
> > is completely useless as a way forward.  Why should anybody (except
> > somebody wanting to test this) type "www6" or "www.ipv6" or "www.six" 
> > into their web browser?
> 
> Because its "kewl" and/or they want to see if it actually works.

We know that IPv6 works.  Since about 10 years.  The time for testing
in "kewl circles" is long over - now we need to do production tests, 
and then production *roll-out*.

[..]
> Additionally, for internal purposes when you migrate a company or
> government agency network or such it lets you work around a number of
> problems during the transition period.

By replacing them with much larger problems, like "all of the absolute
URLs that your sites might use for links will no longer work" - ask the
heise people what fun they had with www.six.heise.de - they had to 
setup a special proxy that rewrites the HTML pages in-flight to get
the URLs fixed.

For small-scale testing, one can put the IPv6 address in the local
machine's /etc/hosts file.  For medium-scale testing, one can do split-DNS.

This will get you *real* tests - with the right URL leading to the right
site.  With absolute links working, etc.

[..]
> > There is no "end user acceptance of IPv6" - as the end users do not know
> > what IPv4 or IPv6 is, they will use it if it is there, and not use it 
> > if it is not there.
> 
> I was more thinking along the line
[..]
>     Help desk: Ok, that should be an IPv6 address.  I'll check with
>                the network administrators if they did anything.
> 
>     End user:  Whatever this "IPv6" is---turn it off, I want to 
>                work/play/whatever.

OK, I can see your point.  And it has been mentioned before: the support
people need to be trained.  They must not be spooked by IPv6 addresses,
and they need to know that they should not spook the customers.

[..]
> > The challenge for the large-scale providers is to roll out IPv6 to the
> > end customers in a transparent way and without breaking anything in the
> > process - and do this before the NAT4444 architecture is so cemented
> > in all the heads that we're stuck with a completely no-more-end-to-end
> > Internet for ever.
> 
> With the large majority of people (including many professionals and
> wannabe professionals) that has already happened.

Well, fortunately, multiple layers of NAT are still the exception - so the
deployer of the NAT is still in control regarding port forwardings and so
on.

With multiple layers of NAT, you will have to request port forwardings
from your ISP (and likely charge a monthly fee per port...) - goodbye
to anything that is not "consumer only".

> ISPs are somewhat unusual with the IPv6 deployment because to them
> IPv6 is largely an all-or-nothing issue with no way to back out.  

For the mass-market ISPs, certainly.  If they roll out IPv6, and it
doesn't work, game over.

For the smaller ISPs, you can do it more gradually, and that way there
already is some experience regarding IPv6 deployment out there...

> To other customers I suggest to take a gradual approach with plenty of
> pre-planned rollback opportunities and/or use the upcoming move
> towards Windows 7 as a chance to do a reasonably painless move towards
> IPv6.  This is admittedly unpractical to an ISP, but with the
> enterprises or government agency customers I am mostly concerned with
> right now, that's pretty much the way to go.

Smaller ISPs don't do this "we must not do a single change to our IT
infrastructure thing!!!!" that large enterprises and govt. agencies 
are so good at :-) - so for us, IPv6 roll-out for our own infrastructure
and servers goes hand in hand with the continuous change that we 
experience all the time anyway.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/451474c6/attachment.bin