On killing IPv6 transition mechanisms

[Benedikt Stockebrand]

Hi Gert and list,

Gert Doering <gert at space.net> writes:

> If you connect to a dual-stacked host, and your operating system is 
> behaving as Windows does (prefer native IPv6, but if that is not available,
> prefer IPv4 before 6to4 and Teredo), your client will not use 6to4.

ok, you know I'm more of a Unixer.  This approach appears quite
reasonable but either I misinterpret RFC 3484 or it is a
Windows-specific arrangement.

>> 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.
>
> "Roll out IPv6, make 'the ping' slower for IPv4 than for IPv6, that
> will get their attention" :-)
>
> Latency *does* matter!

Sure does:-)

Just don't overdo it: Forcing things this way may actually open
another can of worms, concerning net neutrality (in whatever broad
definition of the term) and whatever else.  From a business
perspective, artificially lowering the quality of your service doesn't
sound too good either, simply because you give an advantage to those
of competitors who don't do this.

In the long run the extra latency caused by bloated routing tables and
NAT in a low-power CPE router should generally make this happen
anyway.

> I've run my machines dual-stacked with a single DNS name for dunno
> how many years, and all these services just work in a mixed v4/v6
> environment - older clients generally use v4-only, newer clients try
> both and fall back to v4 if v6 doesn't work.
>
> Of course there are broken clients, and broken servers, but if you
> do things like "ntp.ipv6.my.domain" and then don't advertise it, you're
> just hiding the problem - it won't go away, just by pretending to the
> broken client that IPv6 doesn't exist.

I'm by no means suggesting this as a permanent approach. It is an
intermediate setup during migration/deployment in scenarios where
everything is currently v4only and v6 is about to get deployed one way
or another.

Using this temporary naming scheme helps to do a finely controlled
gradual move.

In the long run, if there are any legacy systems too broken to be
fixed, too unique to be replaced by anything else and too important to
be kicked out, using the same approach the other way round can also be
helpful, using e.g. A+AAAA for nfs0.example.com. and A-only for
nfs0.v4.example.com.

And another one for migration scenarios: Especially if you have
significant numbers of dual-stacked machines and system/network admins
who haven't had much chance to gather experience with IPv6, I found it
quite helpful to have the PTR records return a name that uniquely
identifies if the address is IPv4 or IPv6.  This is particularly
helpful with applications that log that name to their log files rather
than the IP address, but also helps people new to IPv6 when
troubleshooting.  Just make sure that you don't mess up the
"authentication" mechanisms that use the reverse DNS entry of the
address they see (like Solaris NFS).

> I've seen the newly-presented Cisco NAT Services card, and have a vague
> idea what the list price might be for something that holds 20 million
> nat table entries...

And they don't even tell you the cost to keep that sort of equipment
up and running, or the "opportunity costs" these boxes generate when
they cause problems noticeable to the user base.

>> And we're facing pretty much the same situation with 3G/UMTS even
>> here.
>
> Yes.  But if you remember last year's IPv6 conference, at least Vodafone
> has seen the light regarding UMTS and packet clients.

Must have been while I held the tutorial.

And the 3G/UMTS providers actually have a huge advantage over Korean
ISPs: You can't really do 100 Mbit/s over 3G/UMTS, so the amount of
traffic going through the NAT gateways of 3G/UMTS providers is way
less than what the Koreans experience in their fiber networks.

To my understanding, just rebooting a large, non-redundant NAT gateway
is simply disastrous from an economical point of view---it'll cause an
immediate meltdown in your call center.  Setting up these boxes fully
redundantly is the only option, but but then the synchronization
traffic between them can be rather troublesome by itself.  No matter
what, these "solutions" are ugly at best.

> These enterprises are the ones that will be in for a nasty surprise
> when they roll out Win7 or Server2008R2, and all of a sudden they have
> uncontrolled IPv6 all over the place.  So it's quite important that they
> understand what is coming up, and get prepared.

Right.  But what could they have done so far?  With Vista being
generally considered unfit for enterprise use, they have been stuck
with XP until Win7 was released.  Using IPv6 with XP is infeasible
at least at a larger scale, so they were effectively stuck with IPv4,
too.

Now that Win7 is available they have to get all the software they use
to work with Win7, and possibly even get it certified one way or
another, before they can move on to Win7---and they have to do so
before Microsoft stops providing security fixes for XP.  That's their
primary concern.

Deploying IPv6 in "empty" networks that are then populated with Win7
in the next step adds some extra work that must be done before the XP
deadline, so this is a risky (in the risk management sense) approach
but also the one most rewarding if it succeeds.

First deploying Win7 in an IPv4 environment, next setting up IPv6 and
then finally moving Win7 to IPv6 on the other hand is a sure way to
spend significant extra money, both on immediate expenses as well as
those "opportunity costs" because of extra downtimes, but it is fairly
low risk.

Moving to Win7/IPv4 first, then setting up IPv6 and afterwards
deferring the deployment of Windows to the IPv6 setup until the
successor of Win7 becomes available is another alternative---quite
likely the one a number of companies will choose.  This is rather
risky because they effectively bet their IT-related "competitiveness"
(sorry about all those buzzwords, but they actually mean something in
a business context, and these are arguments from the business
perspective) on the hope that the successor of Win7 is both usable and
available early enough they can get it up and running before IPv6
becomes relevant.


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.