Subject: Re: one data point regarding native IPv6 support

From: [email-masked] (Noel Chiappa)
Date: Mon, 13 Jun 2011 11:28:26 -0400 (EDT)

> From: Keith Moore <[email-masked]>

    > To be fair, I think the argument is more that "ISP managed" IPv6 is
    > preferred over "IPv6 tunneled by end-users through relay routers ..."

It is exactly this sort of 'mandate it and they will come' thinking that IPv6
has relied on since it was rammed through in 1995, over _15 years_ ago - and
we can all see how well it has worked.

If _running out of IPv4 space_ isn't getting ISPs, etc, to deploy native
IPv6, what will? Making 6to4 historic sure isn't going to add much pressure.

If 6to4 has problems, fine, write a document that says something like '6to4
won't work for a host behind a NAT box because the host won't know it's true
IPv4 global-scope address - so you should also not turn 6to4 on by default'
and fix/publicize the issues.

But thinking that changing the standardization level is going to push ISPs
toward providing native IPv6 - give me a break.

	Noel

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 13 Jun 2011 08:50:54 -0700

> IPv6, what will? Making 6to4 historic sure isn't going to add much pressure.

I going to go out on a limb here and speculate that the reason we want to depreciate 6to4 because it causes damage to end users and the resources they want to connect to.

from my vantage point I have no problem serving ipv4 customers.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Jun 2011 11:56:17 +0100

> and fix/publicize the issues.

There has been a good deal of work making tunnel brokers work through IPv4 NATs and with changing IPv4 endpoints.  Both SiXXS and HE brokers handle such issues, e.g. using a heartbeat method. So these ought to be (relatively) attractive to end users who want IPv6?

Presumably the prefixes used by such providers, and others like gogo6, are known so brokenness stats for such services could be deduced?

Tim