Subject: Re: [v6ops] 6to4v2 (as in ripv2)?

From: Jeroen Massar <[email-masked]>
Date: Mon, 01 Aug 2011 14:10:32 +0200

On 2011-07-30 03:06 , Mark Andrews wrote:
> In message <[email-masked]>, Jeroen Massar writes:
>> On 2011-07-28 01:36 , Mark Andrews wrote:
>> [..]
>>> Is there *one* tunnel management protocol that they all support or
>>> does a cpe vendor have to implement multiple ones to reach them
>>> all?  I'm pretty sure I know the answer to this question but I'd
>>> love to be proved wrong.
>>
>> There is no 'one' solution to the problems that they are solving.
>>
>> As such there tend to be a combo of:
>>  - static proto-41 tunnel
>>  - 6to4
>>  - 6rd
>>  - TSP => dynamic NATted addresses
>>  - proto-41 + heartbeat + TIC => dynamic public addresses
>>  - AYIYA + TIC => dynamic NATted addresses
> 
> I was more thinking about commonality with tunnel brokers.

These all are implemented by "tunnelbrokers", be they tunnel brokers
where you can just fill in the details yourself (6to4) or the others
where the parameters are provided by the entity you want to connect to.

> 6rd is not a replacement for 6to4 as it requires ISP involment or
> someone to create a registry of 3rd party 6rd providers along with
> associated parameters sets similar non anycast 6to4.

6rd is then also intended for a per ISP deployment.

> static proto-41
> tunnel is also not a viable replacement as it doesn't handle address
> reassignment at the CPE end.

See the "proto-41 + heartbeat" option, that is standard proto-41 but
with a side-channel which beats where the endpoint currently is.

But why are you trying to replace 6to4? What are the requirements that
you have that are not satisfied by any of the above methods?

Greets,
 Jeroen

---

From: "Frank Bulk" <[email-masked]>
Date: Sun, 7 Aug 2011 23:22:29 -0500

Hmmm...it's been well documented that 6to4 causes bad experiences, not
decreases the chance of having them.  Since much of the IPv6-accssible
content is dual-stacked, unless you're using an application that implements
HE, the odds are in your favor to use IPv4 rather than IPv4+6to4.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Keith Moore
Sent: Wednesday, July 27, 2011 1:25 PM
To: Philip Homburg
Cc: IPv6 Operations; Keith Moore; [email-masked]
Subject: Re: [v6ops] 6to4v2 (as in ripv2)?

On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote:

> In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote:
>> In message <[email-masked]>, Brian E Carpenter writes:
>>> Of course, if implementors choose to drop the code you might not be
>>> able to upgrade software versions - but hopefully by that time you
>>> will have native IPv6 service anyway.
>> 
>> Which is exactly why HISTORIC is NOT appropriate. 
> 
> With rfc3484-revise and the documented brokenness of 6to4, it doesn't make
> any sense for implementors to offer 6to4 anyhow.

False.  It makes even more sense to offer 6to4 because it significantly
decreases the chance that it will cause a bad experience for users of
services that provide both v4 and v6 addresses, while increasing the chance
letting local hosts/users talk to v6-only services/hosts.

<snip>

Keith

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