On killing IPv6 transition mechanisms

[Ivan Shmakov]

>>>>> Ole Troan <otroan at employees.org> writes:

 >>>> I wonder, how no connectivity could be better than some?

 >>> because content providers measure the difference between IPv4 and
 >>> IPv6 behaviour for dual stack hosts. if the number of hosts with
 >>> broken IPv6 connectivity or with significantly worse latency than
 >>> IPv4, they will not enable IPv6.

	To my mind this is only an issue when 6to4 is both used widely
	and cared for only superficially.

 >>> to put it bluntly: if you don't get IPv6 from your SP, then don't
 >>> bother. you are doing more harm to IPv6 deployment than good.

	And, BTW, I don't get IPv4 from my SP, either.  Or does NAT
	count as “IPv4 connectivity” nowadays?

 >> Would I bother not, who will?

 > there are lots of things you can do. make sure you're own network is
 > IPv6 enabled, including hosts, applications, services, management...,

	That's a great deal easier when there's both an address space
	assigned and the connectivity to the outer world, ain't it?

 > nag your SP about IPv6.

	With a single private customer demanding a service available to
	no one in the city, I'm in doubt that they are going to care.

 > most of the SPs I talk with are thinking hard about IPv6 now, and I
 > hope we'll start to see some big deployments during this year and
 > next. that's a biased view though, since I'm only speak with people
 > interested in IPv6. ;)

	And that view is, so to speak, is somewhat biased both
	“geographically” and “nationally”, isn't it?

	Some time ago I did a quick scan over some BGP data.  In
	particular, it was easy to find that RUNNet, which claims to
	offer services to more than 400 universities and research
	institutes [1], has only a handful of IPv6 downlinks.

	The consequences are.

[1] http://www.runnet.ru/

-- 
FSF associate member #7257
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100314/f21ed71e/attachment.bin