On killing IPv6 transition mechanisms

[Benedikt Stockebrand]

Hi Janos (I suppose that's your first name?) and list,

> then this provider did his jobs badly. They did not test when they
> introduced ipv6. Plan, Train, Test in small, learn, train, pilot,
> test, train, test, introduce.

that doesn't solve the problem.  

Consider this example: A company has set up and installed a web server
connected behind a dual-stack uplink.  Between the web server and the
CPE router towards their ISP they installed a packet filter configured
to silently discard all IPv6 traffic from the Internet.  The web
server has both A and AAAA records in the DNS, possibly because it is
accessible internally via IPv6 as well.

The point here is that this setup is broken in a number of ways, but
as long as the "road warriors" only have IPv4 access it still works
fine.

Now bring in your own reasoning:

>> 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.
>
> They should blame the provider! Probably change to another ISP. As
> they would change if IPv4 service is badly provided.

As soon as you, as the ISP, enable IPv6 for your customers, from the
customer's point of view you "break" that web server.

If you think of this at a scale of serveral million users, quite
likely generating significant press coverage along the way, this can
get rather disastrous for the ISP as well as for the entire move
towards IPv6.

It doesn't really matter at this point what actually caused the
problem but what people *perceive* as the cause of the problem.  The
majority will behave pretty much the way you reasoned yourself; they
either lack the necessary knowledge to understand what happened or
they need a scapegoat for one reason or another.  You did something,
then something undesirable happened, so you're "responsible".

> Phased introduction this is the key!

Agreed.  In some cases this may get difficult because it leads to ugly
discussions with the marketing people.  They may want to make the IPv6
deployment a major event---that's difficult if you do it in small
steps.

There is another trick along that line: Make the customers enable IPv6
themselves.  If they have to connect to a web front end, log in and
enable IPv6 for their particular hookup, then you get a somewhat
phased introduction, largely avoid the blame for the broken web server
above, and provide them with a rollback option if things break.

On the ISP side you have to provide that web interface, somehow
convince your access router infrastructure to deal with this level of
user-specific configuration, notify your customer base, find a way how
to estimate and deal with the extra workload in your call centers and
eventually deal with the (quite likely large number of) people who
never bothered to even try.  So it's still a big job.

> This takes time! Therefore many ISPs are already late.

Agreed again.  Which means that many ISPs will have to deploy IPv6 in
a rather chaotic way at some point.

The good news here is that the more competent ISPs are likely to gain
from this.  The bad news is that there will be less ISPs afterwards
than right now, because at least some of them will go out of business;
that's bad as far as competition and alternatives for customers
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.