On killing IPv6 transition mechanisms

[Benedikt Stockebrand]

Hi Gert and list,

Gert Doering <gert at space.net> writes:

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

we're still talking different things here: If you are on the
*customer* side and connecting to a dual-stacked host when you are
using 6to4 yourself, then you do see the difference.

>> Because its "kewl" and/or they want to see if it actually works.
>
> We know that IPv6 works.  Since about 10 years. 

Well, six or seven years ago I first had to tell people how to
recompile a kernel on Linux, download some extra software for XP or
update their IOS.  Then it was time to recompile Ssh with the proper
compile time options, the then-standard Apache 1 didn't support IPv6
except through patches, you had to use a beta version of the UDel(?)
NTPD and the Linux people were stuck without an IPv6-capable syslogd.

As far as the network layer goes, yes, IPv6 worked then.  But it has
only become usable with Vista (which was unusable in many other ways)
or Win7, with more up-to-date Linux distributions and whatever else on
the client side.  And considering the problems relating to RFC 3484
alone there is still some way to go.

> The time for testing in "kewl circles" is long over - now we need to
> do production tests, and then production *roll-out*.

The "kewl" people are not the ones who do testing but the ones who
believe and tell everybody that they understand computers:-)

What we need are those enthusiasts spending 500Euro for a new graphics
card, tinker with absolutely everything they find and are generally a
major pain in the rear side for everybody else---but are still asked
for computer-related by their friends and family.

We don't need them for testing but for marketing IPv6.

I don't like this situation either, but we better face it.

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

Agreed, when we're talking web servers and URIs that's not the very
best move.  But I was actually thinking more along the lines of DNS,
NTP, CIFS/SMB, NFS, SMTP, POP3/IMAP and such.

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

I'm afraid you don't:

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

As I pointed out a few minutes ago in reply to Janos, the key point is
that IPv6 will expose hidden problems with existing setups and as such
will be *perceived* as the actual problem.  It is not what factually
*is* the problem, but what is *perceived* by the customer as the
problem that matters when it comes to accepting IPv6.

ISPs who have already provided their customers with IPv6 for some time
don't have that problem because the actual root causes never had a
chance to develop, but that doesn't help those who only now start to
get into IPv6 deployment right now.

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

As far as I can tell that largely depends on which part of the world
you're living in.  

It's a shame you haven't been in Potsdam two years ago, there was a
Korean colleague there who could tell you more about the problems
running large NAT gateways at the ISP side than you wanted to hear
about.

And we're facing pretty much the same situation with 3G/UMTS even
here.

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

This is a bit of a tangent, but: You can already run into this kind of
limitation with the "right" kind of CPE router.

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

If I was still with a larger ISP I'd spend some really serious
thinking on how to do a gradual rollout, too.  As far as I can tell it
is possible even at a larger scale, but you can't do it on short
notice.

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

Larger ISPs at least used to work much like that internally, but as
soon as customers are affected this becomes rather troublesome.

Still, my point was on IPv6 deployment in an enterprise.  Just
recently I got a training request from a customer with such an
enterprise.  Just to give an idea of the numbers: 3 data centers, 150
locations, 40 000 employees.  I don't have the number of desktop and
notebook PCs, but you may well assume in that case that just about
every employee has at least one computer.  In another case I had
participants in a training who were dealing with 8000 locations.

And these are still small compared to the major banks here in
Frankfurt.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.