On killing IPv6 transition mechanisms

[Benedikt Stockebrand]

Hi Gert and list,

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?

>> On another track: Much of the discussion in this thread makes an
>> implicit assumption that there's a single DNS name for both IPv4 and
>> IPv6 services, i.e. "www.example.com." has both an A and a AAAA
>> record.  
>
> Which is the ONLY thing that makes sense in the long run.

Yes, but we're talking transition mechanisms here.

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

Just because end users can be rather irrational doesn't mean that you
can't sometimes make good use of 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.

> [..]
>> These points aren't only crucial to keep in mind if you do business
>> with end users; they also apply to end user acceptance of IPv6 and as
>> such the move towards IPv6.
>
> 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

    End user:  My Internet is broken.

    Help desk: What exactly do you want to do?

    End user:  Connect to the Internet, with the funny colored letters.

    Help desk: Oh, you mean Google.  Ok.  What happens?

    End user:  It doesn't work and says there is something wrong about
               some silly letters and colons there.

    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.

If IPv6 disrupts a business customer's business or an end user's
entertainment, there is a good chance they pick up "IPv6" as the
keyword to blame.  It doesn't take actually understanding what IPv6 is
to do so.  

Neither do end users care that because of some reasonable change on
your side the brokenness of their router (which "has been working fine
as long as I had it") is actually causing them trouble now.

> Which is why the argument "my customes are not asking for IPv6" is
> not very useful for this sort of customers either.

That's an entirely different discussion.

As an ISP I wouldn't wait until people request IPv6 because by then it
is too late to sort things out on the ISP side.

By now I generally---including ISPs---tell people that IPv6 is
somewhat like Y2K (except that it doesn't come at a fixed, and
predictable, time): It doesn't have a "business case" but ignoring it
will still cost significant money.

As far as ISPs go: Since they are all equally affected the ones who
deal best with it are likely to increase their market share.  (Sorry
about using one of the no-no words.)

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

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


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.