On killing IPv6 transition mechanisms

[Mohacsi Janos]

Hi Benedikt,

On Thu, 18 Mar 2010, Benedikt Stockebrand wrote:

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

If they install packet filter that discard all the IPv6 traffic, why they 
install A and AAAA records in  the DNS. If they want to make it accessible 
internally via IPv6, they have to implement either split DNS (since they 
want different behaviour internally than from outside), or install 
IPv6 capable packet filter and allow proper IPv6 filtering


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

I don't see the reason. If I run webserver I control what address I want 
in the DNS.

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

Or some knowledgeable and competitive new ISPs  will emerge...

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