On 9 Jun 2011, at 18:39, Keith Moore wrote:
If pain associated with 6to4 provides an additional incentive for ISPs to deploy native v6, and for users to use native v6 when it becomes available, that's a Good Thing.
The pain though is felt by the content providers, who still see too much brokenness.
On 9 Jun 2011, at 19:01, james woodyatt wrote:
I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry. We're smart enough to recognize that we're not the target audience for the RFC. The draft that matters is the companion advisory draft. It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome. Alas and alack.
Well, the most important point in this is that 6to4 is disabled by default in every device. Apple did that already, which is good. What is unclear to me though is whether deprecating 2002::/16 means that prefix would no longer be routed, as per 3ffe::/16, or just 'reserved' so it's not reallocated later.
On 9 Jun 2011, at 19:53, Keith Moore wrote:
On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote:
Go to
http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-)
That's who I was using before.
Our staff and students find the HE broker easy to use, though I believe some also use other brokers. One student did a final year project this year developing a Linux home router which included HE broker support. It was simple to use/integrate.
On 9 Jun 2011, at 19:56, james woodyatt wrote:
I need *native* IPv6 into my home in San Francisco for my day job
Have you considered deploying/adding IPv6 VPN support at your day job? So your VPN from home to work gives you IPv4 and IPv6? This is quite a nice model, and is starting to appear in UK universities, and I use it myself for IPv6 training. At least one big vendor offers this today. Users are familiar with VPN use, so adding IPv6 with that comes naturally, and $dayjob provides the support, so you're in control.
Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations have a working return path route to 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory now.
That 'so long as' is the crux though.
Tim