Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications"

From: Ole Troan <[email-masked]>
Date: Sun, 1 May 2011 11:45:48 +0200

Dmitry,

> I agree with the recommendations 1-2-3 in the section 4 in the draft version dated April 27 and I think those are sufficient, hence I suggest to remove wording regarding deprecation of RFC 3056 and prefix 2002::/16.

the deployed part of rfc3056 have the same problem that rfc3068. i.e. the return relay, filtering and so on.

you have argued that 6to4 provide some benefits in that it allows for "globally scoped" IPv6 address assignment independently of an ISP and that it can be used for tunneling in "private" networks, e.g. on top of other tunnels like DirectAccess.

I don't think it is feasible to deprecate section x,y,z of 3056 and not section n,m and o.

I would suggest you wrote a new draft of a peer to peer only 6to4 version.

cheers,
Ole

> ________________________________________
> From: Fred Baker [[email-masked]]
> Sent: Wednesday, April 27, 2011 1:17 PM
> To: Tore Anderson; Dmitry Anipko
> Cc: [email-masked] WG
> Subject: 6to4-historic summary point: 5. "Clarifications"
> 
>> 5. "Clarifications"
>> -------------------
>> 
>>> The approach that's most likely to get widespread support is:
>>> 
>>> 1. make it not be on by default
>>> 2. make noise about it being A Bad Thing
>>> 3. deprioritise 2002::/16 addresses in resolver libs
>>> 4. then make the option hard to find on operating systems / CPEs
>>> 5. then remove the option on operating systems
>>> 6. then slowly decommission 6to4 relays over many years
>>> 
>>> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3.
>> 
>>   I do think it would be useful to elaborate on the arguments Tore just
>>   provided to Dmitry for deprecation of 3056 in the draft, as a form of
>>   history writing for the archives.
>> 
>> Actions: Proposed text?
> 
> Tore and Dmitry, this appears to be directed to you. Could you please work with Ole on proposed text?
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Sun, 01 May 2011 11:56:47 +0200

>I would suggest you wrote a new draft of a peer to peer only 6to4 version.

Is that realistic? (anyone can author an informational RFC, so not that part).

6to4 has a lot of problems with NAT. And the place where peer-to-peer has
most problems is in systems with lots of NAT, in particular carrier-grade NAT.

So presenting a protocol that has lots of problems with carrier-grade NAT
as a solution to a problem mostly caused by carrier-grade NAT strikes me
as a bad idea.

---

From: Ole Troan <[email-masked]>
Date: Sun, 1 May 2011 12:03:24 +0200

Ole,

> Is that realistic? (anyone can author an informational RFC, so not that part).

probably not ;-)

> as a solution to a problem mostly caused by carrier-grade NAT strikes me

iff the argument was to keep some aspects of 6to4 to use it in a private network context, then I think a new draft would be better,
than to try to deprecate only half of 3056. only retaining the 'managed' part of 3056.

I'm suggesting that as a way out to avoid this discussion on private use 6to4, derailing the effort to fix the mistakes with did with 6to4 in the Internet.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 May 2011 09:29:13 +1200

> I'm suggesting that as a way out to avoid this discussion on private use 6to4, derailing the effort to fix the mistakes with did with 6to4 in the Internet.

But there's nothing in the act of marking RFC 3056 as Historic that
prevents such use; that's my difficulty in understanding Dmitry's
objections.

However, this is why I am dead against the proposal for a sunset date and
against advice to operators to filter 2002::/16 unconditionally. That
would break successful use of 6to4 for no reason.

Nature will take its course: IPv4 runout is what will finally break 6to4;
it does not work in a fragmented IPv4 network (which is what CGN creates).
That is clearly stated in RFC 3056, by the way, although we didn't
anticipate CGN specifically.

    Brian