Subject: Re: [v6ops] I-D Action:draft-troan-v6ops-6to4-to-historic-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2011 15:59:56 +1300

Hi,

There's a slight improvement in that this version actually
mentions the culprit, RFC 3068. But that has been forgotten
in the "Obsoletes: (if approved)" header.

However, I still don't think it should be approved. For a start, this
is untrue:

>    The IPv6 transitioning mechanism "Connection of IPv6 Domains via IPv4
>    Clouds (6to4) described in [RFC3056] and the extension in "An Anycast
>    Prefix for 6to4 Relay Routers" RFC3068 [RFC3068] have been shown to
>    have severe practical problems being used in the Internet. 

Actually the mechanism described in RFC 3056 has, as far as I know,
never been seriously deployed. The operational problems are analysed at
some length in draft-carpenter-v6ops-6to4-teredo-advisory (based on
input from about 20 people) and as far as I can see they are due to the
RFC 3068 anycast mechanism, inappropriate firewall behaviour, use of
bogon address space, or failure to follow the rules of RFC 3056 about
announcing 2002::/16.

In that situation, I can't see any justification for obsoleting RFC 3056,
and I think our cycles are better spent on advising people how to
configure things properly.

I tend to agree that new implementations of RFC 3068 will not be
helpful. But is that a real risk?

Regards
   Brian Carpenter

---

From: Ole Troan <[email-masked]>
Date: Mon, 14 Mar 2011 11:51:05 +0100

Brian,

> in the "Obsoletes: (if approved)" header.

it hasn't, I just couldn't figure out how to put two RFCs in obsolete in xml2rfc.
3068 isn't the only "culprit", 3056 is equally problematic. 3056 creates the reverse-path problem,
3068 the forward-path.

> bogon address space, or failure to follow the rules of RFC 3056 about

_one_ of the deployment models in 3056 hasn't been deployed.
possibly because it is undeployable. as it requires a mesh of BGP sessions between consenting 6to4 relays.
making 6to4 deployment equally in effort to manually configured tunnels. those are deployed, and people run BGP over those. the 6to4 deployment model you are referring to has little to offer here.
(6to4 is also used as 'transport' for BGP tunnels, but then the mechanism is contained within an SP network, and native addresses are used. I don't see this use of 6to4 (where ISATAP, 6rd or others could also work) as problematic.

> configure things properly.

I think we have had this discussion already.
there is nothing that can be "configured properly". unfortunately. apart from you mean configure properly as in configure 6to4 to off.

> helpful. But is that a real risk?

the purpose of this draft is to show that 6to4 is an evolutionary dead end, and that one should apply extreme caution in its use.

I don't think the two of us will reach agreement on this. I think there will be two or three drafts on 6to4 presented in Prague. let's see what the consensus is in the room for the various approaches (as opposed to continuing the 240 mail thread that revision 00 generated. ;-))

cheers,
Ole