Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>

From: [email-masked] (Noel Chiappa)
Date: Wed, 8 Jun 2011 12:04:15 -0400 (EDT)

> From: Martin Rex <[email-masked]>

    > Classification of 6to4 as historic is [in]appropriate use of the IETF
    > process, because it would be a political .. statement.

Well, we've never done _that_ before, have we? Wouldn't want to set an
unfortunate precedent.

	Noel

---

From: james woodyatt <[email-masked]>
Date: Wed, 08 Jun 2011 09:17:41 -0700

On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote:
>> Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement.
> 
> Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent.

I see no reason for IETF to avoid setting standards for layer-9 protocols.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jun 2011 05:52:43 +1200

> I see no reason for IETF to avoid setting standards for layer-9 protocols.

In any case, I don't see the politics, unless (for example) declaring
RFC 1267 Historic was politics too.

   Brian

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Jun 2011 11:45:49 -0700

Hi -

> From: "james woodyatt" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 08, 2011 9:17 AM
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>
>

I'm pretty sure Noel was being scarcastic.  There's clear precedent in the
analogous case where RFC 1227 was  declared historic, despite its
widespread use for that particular application at the time.

On the other side of the argument, declaring RFC 1227 historic had little
(I'm being generous) impact on its continued use.  The folks that needed it
kept using it, in some cases long after the IETF's replacement for it became
widely available.

Randy

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Jun 2011 22:37:07 +0200 (MEST)

> Well, we've never done _that_ before, have we? Wouldn't want to set an

I'm much more worried about the important part that you didn't quote,
that moving 6to4 to historic is a technically inaccurate statement.

How about downgrading it (rfc3056+rfc3068, I assume) from "Proposed" to
"Experimental", acknowledging the fact that "consumers" will likely
have to set it up themselves, it is rarely going to work out of the box
and might not be available in all implementations.

-Martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jun 2011 10:30:28 -0700

Hi -

> From: "Rémi Després" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 09, 2011 1:11 AM
...
> RFC 1227 specified an experimental protocol.
> The 6to4 specification is standard track.
> Declaring historic a standard track specification although it still serves
> legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO.

Consider, then, RFC 1157.

It was, quite rightly, declared historic years ago, even though it
was a full standard and in rather widespread use at the time.
Despite that declaration, it remains in use.  This despite all the
good reasons that its replacement should be used instead.

The point is that the "historic" declaration can be a statement
about how the IETF wants things to be, rather than how they are.
If one happens to be a user or vendor of a "historic" technology,
the declaration might sting a little, but it's really not a big deal, IMO.

Randy

---

From: TJ <[email-masked]>
Date: Thu, 9 Jun 2011 13:36:57 -0400

On Thu, Jun 9, 2011 at 13:30, Randy Presuhn <[email-masked]>wrote:

> > Subject: Re: [v6ops] Last Call:
> <draft-ietf-v6ops-6to4-to-historic-04.txt>
> ...

Although I have already stated my position in this issue (against, for now),
I have a problem with the above logic.
You are effectively arguing that this move won't really impact anything ...
in which case I would ask, why are we doing it?

I suspect that 6to4 is a fairly unique case in that it, as pointed out
earlier, relies on the good nature of others to operate relays "for the
public good".  Marking it as historic would, I imagine, demotivate ISPs to
operate those relays and thus render the connectivity even worse than we are
fearing.

Please don't confuse my position - I wholeheartedly believe the right answer
is, and am very vocal in promoting, native IPv6 (dual stack) everywhere, for
everyone.  But we aren't there yet.  Even though my home ISP has done more
IPv6 than many|most, they aren't ready to do native here, yet.  I often rely
on 6to4 is _many) scenarios and simply want something that exists to keep
working until the alternatives are more available.

/TJ

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jun 2011 10:59:24 -0700

Hi -

> From: "TJ" <[email-masked]>
> Sent: Thursday, June 09, 2011 10:36 AM
...
> in which case I would ask, why are we doing it?

No, what I'm saying is that declaring a technology "historic" does not
make it go away.  If accompanied by strong advice and good alternatives,
it might contribute to a reduced likelihood that one will encounter the
offensive technology, but things rarely disappear completely, nor as
quickly as one might like.

Speaking in horribly general terms, rather than the specifics of 6to4:

The folks who believe they have a legitimate need for a technology will
continue to use it as long as they are able to.  The folks who don't find
it causing problems for them will tend to leave things alone - there's
always the fear that turning something off, even if it appears to be
little-used, might break some critical but low-frequency application
somewhere in the enterprise. The folks for whom the historic
technology has been causing a problem will rejoice and turn it off or
remove it from their products, but will still need to defend against it,
because you never know what's going to come in from the
big bad internet.

Randy

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jun 2011 20:49:43 -0400

> was a full standard and in rather widespread use at the time.

Was there a replacement for RFC 1157 (presumably, a new version of SNMP) generally available at the time that document was moved to Historic? 

I mean, it would make perfect sense to want to declare 1157 historic if there were a new version available that clearly worked better.  Right now, there's not a readily available replacement for 6to4 that is clearly better.

So I think the comparison is not valid.  SNMP (of whatever version) is a protocol that you can use on your own network if you want to, and that's where most of its utility is.  You don't have to get your ISP to support it before it's significantly useful to you.  By contrast, the very purpose of 6to4 is to communicate with peers over someone else's network(s).  If you want to run IPv6 over your own IPv4 network, 6rd or maybe 6over4 are better suited to that.

Keith

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 9 Jun 2011 18:25:18 -0700

Hi -

> From: "Keith Moore" <[email-masked]>
> Sent: Thursday, June 09, 2011 5:49 PM
...
> Was there a replacement for RFC 1157 (presumably, a new version
> of SNMP) generally available at the time that document was moved to Historic? 

Yes, with some arguments about "generally".

> I mean, it would make perfect sense to want to declare 1157 historic
> if there were a new version available that clearly worked better.  Right
> now, there's not a readily available replacement for 6to4 that is clearly better.
>
> So I think the comparison is not valid.  SNMP (of whatever version) is a
> protocol that you can use on your own network if you want to, and that's
> where most of its utility is.  You don't have to get your ISP to support it
> before it's significantly useful to you.  By contrast, the very purpose
> of 6to4 is to communicate with peers over someone else's network(s).
>  If you want to run IPv6 over your own IPv4 network, 6rd or maybe
> 6over4 are better suited to that.

There appears to be some dispute about whether the functionality of 6to4 is
really needed.  I take no sides in that part of the debate.

My comment was in response to the claim (which you have not made, AFAIK)
that it was inappropriate to declare a standards-track protocol historic while
still in widespread use, for reasonable interpretations of "widespread". 
I was making no claims about 6to4's (de)merits.

Your argument seems to be that the peculiar operational characteristics of 6to4
should give it additional immunity to being declared historic. I don't find that
argument persuasive.  The history of multiple protocols that have been
declared "historic" shows that vendors seem to care about that designation
only when it is convenient for them to do so.  Installed base, customer
demand, operational considerations and so on all trump whatever the IETF
might say about a "historic" protocol.  This works both ways: folks might
decide to kill something before it becomes historic, or support it long after.
We can't compel people to continue supporting it any more than we can
make them stop.  At most, we can give them (hopefully convincing) reasons
to change.  If the SNMP experience shows anything, it shows that even
that isn't enough.  For that reason, I find it amusing when others write of 
"killing" 6to4.  We don't have that kind of power.

Randy

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jun 2011 11:59:31 +1000

In message <000901cc270d$430ec000$6801a8c0@oemcomputer>, "Randy Presuhn" writes
> "killing" 6to4.  We don't have that kind of power.

But you can give them a big excuse not to support it.

Customer: "Where did the 6to4 support go?"
Vendor: "The IETF declared it historic so we removed it."
Customer: "I was using it, can you put it back?"
Vendor: "I repeat the IETF declared it historic."

6to4 on by default is wrong. 

However if a user/site turns 6to4 on they do that with the full
knowledge that it will add delays and it does use third party relays.
As to those that say users won't accept 100ms delays many actually
will accept the delay and it does not impact on what they do. The
tunnel I use adds +300ms to some IPv6 sites compared to IPv4 but
unless I explicitly measure it I don't notice it.

Making 6to4 historic is a knee jerk reaction to a bad default setting.
Fix the default.  Don't make 6to4 historic.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Jun 2011 04:40:45 +0200 (MEST)

Mark Andrews wrote:
> 
> In message "Randy Presuhn" writes:
> >

> Fix the default.  Don't make 6to4 historic.

I fully agree about your description of the purpose of "historic"
for vendor and its usage by vendors.

The only sensible use of historic is to promote active de-support
on the part of vendors -- literally for "ripping things out".

I just did that myself 4 weeks ago, justifying the complete removal
of support for MD2-based digital signatures from our PKI software
with a pointer to

  http://tools.ietf.org/html/rfc6149   "MD2 to Historic Status"

Moving 6to4 seems premature by several years.

-Martin

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Jun 2011 14:20:41 -0400

On Jun 9, 2011, at 9:25 PM, Randy Presuhn wrote:

> argument persuasive.  

That's not my argument.  My argument is that declaring 6to4 Historic is inconsistent with the way we've used Historic in the past - namely to label something that either 'hardly anybody uses anymore' or something that should be abandoned because a better alternative is now generally available.

> The history of multiple protocols that have been

Declaring 6to4 Historic certainly won't prevent people from implementing it.  But the proposed action is clearly intended to discourage implementation of 6to4.  It says so explicitly.  Of course some vendors will ignore it, but some vendors will probably not ignore it.

Keith

---

From: james woodyatt <[email-masked]>
Date: Fri, 10 Jun 2011 11:41:23 -0700

> Declaring 6to4 Historic certainly won't prevent people from implementing it.  But the proposed action is clearly intended to discourage implementation of 6to4.  It says so explicitly.  Of course so…

I would absolutely agree that the document would be improved if this pointless recommendation were removed.  I expect some perfectly reasonable people will still oppose it with understandable concerns.  Nevertheless, I do think this particular recommendation is inconsistent with the consensus in IETF that a phase-out plan for 6to4 is unwarranted.