Subject: Re: Why ask for IETF Consensus on a WG document?

From: [email-masked] (Noel Chiappa)
Date: Fri, 24 Jun 2011 21:38:09 -0400 (EDT)

> From: james woodyatt <[email-masked]>

    > I supported 6to4-advisory and strenuously argued against taking up
    > 6to4-to-historic.
    > ...
    > I can see how 6to4-to-historic may divert its intended audience from
    > reading the much more important 6to4-advisory draft

I must admit, it does seem a little odd to issue two documents, one fixing a
protocol that you're about to declare obsolete with the other...

    > the [6to4-to-historic] draft is clearly written to specify something
    > other than what its authors and most of the WG were intending.

I'm afraid that was a little too Delphic for me. I can understand if you'd
said something like 'its authors clearly wrote it to specify something other
than what most of the WG were intending' - but how can a document have an
intent that its authors know nothing of (which is how I read the above)?

    > I do, however, wonder if we can finally remove 2002::/16 from the
    > default policy table in the next revision of RFC 3484 on the grounds
    > that 6to4 is Historic now, just like 3ffe::/16 is... that would be
    > *excellent*.

Umm, is this a serious suggestion, or are you just having a little fun in a
second-cousin-to-trolling way?

I mean, this is _exactly_ the sort of consequence of moving 6to4 to
'historic' that I think a lot of the people who oppose that move are worried
about: that although they are still using it (because it works in their
circumstances, and provides capabilities that other things such as 6rd do
not), people will use the existence of 6to4-to-historic to move on and do
things which negatively impact the users' ability to move packets around.

You weren't by any chance trying to show an example of the downsides of
that decision, were you?

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2011 00:11:07 +1200

> protocol that you're about to declare obsolete with the other...

Not so odd. There are hundreds of millions of hosts out there that attempt
to use 6to4 by default, and (probably) thousands of relay routers that
attempt to support such users. Those boxes will be around for years, and are
the target for the -advisory draft, regardless of the deprecation.

   Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 25 Jun 2011 12:04:14 -0700

> the target for the -advisory draft, regardless of the deprecation.

the very fact that the devices are largely unmanaged, means that if you don't want to break them worse then they already are that you have continue to support them until they age out of the network.

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 27 Jun 2011 09:09:55 +1000

In message <[email-masked]>, Joel Jaeggli writ
es:
> the very fact that the devices are largely unmanaged, means that if you don'
> t want to break them worse then they already are that you have continue to s
> upport them until they age out of the network.

And historic just told CISCO and Juniper to stop supporting 6to4 in their
big iron.  The very boxes that need to remain to the end supporting 6to4
because they are managed boxes.

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

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 27 Jun 2011 10:25:50 -0700

> because they are managed boxes.

I think this argument is somewhat orthogonal to the problem of supporting end-systems... However if your want to explore it, think the author is probably in a position to interpret the draft on behalf of his company. Juniper doesn't support 6to4 on the big iron.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Jun 2011 10:28:00 +1000

In message <[email-masked]>, Joel Jaeggli write
s:
> > In message <[email-masked]>, Joel =
> Jaeggli writ
> > es:
> >> 
> >>> Not so odd. There are hundreds of millions of hosts out there that =
> attempt
> >>> to use 6to4 by default, and (probably) thousands of relay routers =
> that
> >>> attempt to support such users. Those boxes will be around for years, =
> and a
> >> re
> >> the very fact that the devices are largely unmanaged, means that if =
> you don'
> >> t want to break them worse then they already are that you have =
> continue to s
> > And historic just told CISCO and Juniper to stop supporting 6to4 in =
> their
> > big iron.  The very boxes that need to remain to the end supporting =
> 6to4
> I think this argument is somewhat orthogonal to the problem of =
> supporting end-systems... However if your want to explore it, think the =
> author is probably in a position to interpret the draft on behalf of his =
> company. Juniper doesn't support 6to4 on the big iron.

CPE devices need to talk to something.  If you take that something
away you make the problem worse not better and don't say historic
is not going to result in product support going away as no one
believes that.

The boxes on the carrier end of the 6to4 tunnels will need to be
upgraded to deal with other issues and historic is likely to leave
the operators in the unenviable position of having to run relays
with known security flaws or kill the service.