RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Ronald Bonica]

Folks,

After an active discussion, it is clear that there is no consensus. So, I will 
transition draft-ietf-v6ops-6to4-to-historic to the DEAD state.

Ron


> -Original Message-
> From: Ronald Bonica
> Sent: Monday, July 25, 2011 10:31 AM
> To: ietf@ietf.org
> Subject: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> Folks,
> 
> After some discussion, the IESG is attempting to determine whether
> there is IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. It will also contain a new section
> describing what it means for RFCs 3056 and 3068 to be classified as
> HISTORIC. The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation
> (hosts, cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from
> implementations. Likewise, operators will decide whether/when 6-to-4
> relays will be removed from their networks. The status of RFCs 3056 and
> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
> any particular time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies the meaning of "HISTORIC" in this particular case, it does
> not set a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>Ron
> Bonica
> 
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Rémi Després]

Le 27 juil. 2011 à 08:10, Tore Anderson a écrit :

> * Ronald Bonica
> 
>> After some discussion, the IESG is attempting to determine whether there is 
>> IETF consensus to do the following:
>> 
>> - add a new section to draft-ietf-v6ops-6to4-to-historic
>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>> 
>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
>> convert their status to HISTORIC. It will also contain a new section 
>> describing what it means for RFCs 3056 and 3068 to be classified as 
>> HISTORIC. The new section will say that:
>> 
>> - 6-to-4 should not be configured by default on any implementation (hosts, 
>> cpe routers, other)
>> - vendors will decide whether/when 6-to-4 will be removed from 
>> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
>> will be removed from their networks. The status of RFCs 3056 and 3068 should 
>> not be interpreted as a recommendation to remove 6-to-4 at any particular 
>> time.
>> 
>> 
>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
>> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
>> a precedent for any future case.
> 
> I support this approach.

Suggestion to make the two RFC Experimental has been made, and received some 
support.
I haven't seen objections tho this compromise approach.
Are there some?

RD

> 
> Best regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

Philip Homburg wrote:

>> which means an end system should have a full routing table, IGP
>> metrics in which tell the end system what is the best address of
>> its multihomed peer. Full routing table should and can, of course,
>> be small.
> 
> Even in the unlikely case that it would be feasible to give every host a
> complete copy of the DFZ routing table...

With RFC2374, DFZ of IPv6 has at most 8192 entries.

> That still would leave a lot of issues open...
> 1) End-to-end latency. Maybe some future generation BGP provides that, but
> that doesn't help now.

Your requirement can be fair, only with a routing protocol
supporting latency based routing for *an* address with
*multiple* paths to its destination.

There is no point to have a latency based selection of
multiple paths to the destination, only if the destination
has multiple addresses.

> 2) For 6to4, the use of anycase. You probably need a link-state routing
> protocol to allow a host to figure out which relays are going to be used 
> on
> a give path.

With anycast, you can use only a single relay. Instead, you can
compare metrics between IPv4 and IPv6 addresses of a host.

> 3) Filters in firewalls. I'd love to see a routing protocol that reports the
> settings of all firewalls in the world :-)

Are you saying filtering of firewalls can be disabled by proper
address selection?

> 4) Other performance metrics, like jitter, packets loss, etc.

See 1).

> Maybe you can do some experiments and report on how well your draft works for
> deciding when to prefer a 6to4 address over IPv4.

A problem is that there is no point to stick to IPv6 broken
so much.

But, it's not my problem.

Masataka Ohta

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

In your letter dated Thu, 28 Jul 2011 17:08:01 +0900 you wrote:
>Philip Homburg wrote:
>> I think the problem is that we don't know how to do 'proper' address
>> selection.
>
>I know and it's trivially easy.
>
>11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:
>
>   End systems (hosts) are end systems. To make the end to end principle
>   effectively work, the end systems must have all the available
>   knowledge to make decisions by the end systems themselves.
>
>   With regard to multihoming, when an end system want to communicate
>   with a multihomed end system, the end system must be able to select
>   most appropriate (based on the local information) destination address
>   of the multihomed end system.
>
>which means an end system should have a full routing table, IGP
>metrics in which tell the end system what is the best address of
>its multihomed peer. Full routing table should and can, of course,
>be small.

Even in the unlikely case that it would be feasible to give every host a
complete copy of the DFZ routing table... That still would leave a lot of
issues open...
1) End-to-end latency. Maybe some future generation BGP provides that, but
   that doesn't help now.
2) For 6to4, the use of anycase. You probably need a link-state routing 
   protocol to allow a host to figure out which relays are going to be used on
   a give path.
3) Filters in firewalls. I'd love to see a routing protocol that reports the
   settings of all firewalls in the world :-)
4) Other performance metrics, like jitter, packets loss, etc.

Maybe you can do some experiments and report on how well your draft works for
deciding when to prefer a 6to4 address over IPv4.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

In your letter dated Thu, 28 Jul 2011 07:50:38 -0400 you wrote:
> In general, all of a host's addresses (at least, those in the same
> preference class in the address selection algorithm) need to work
> equally well from everywhere.
> 
> But even that might not be sufficient.   Fred Baker has recently
> been citing a different example of the same problem:  Imagine a
> future where hosts on a network have both v6 and legacy v4 through
> stateful NAT.  Because the v6 connection works well most of the
> time, hosts tend to choose v6 destinations, and sites reduce the
> capacity of their NATs over time.  Then the v6 connection fails,
> and suddenly everything falls back to v4, and the connections
> through NAT also fail for lack of sufficient capacity to handle
> the load.

I'm sure some manager will just require this to work. But I would say that
this is just supposed to fail.

If you had in the past just an IPv4 connection and it went down, there would
be no Internet access. Same thing in the future. If your IPv6 connection goes
down you don't have an Internet conenction.

It would be different if the NAT was there just to connect to a very specific
collection of legacy IPv4 sites. But that can be solved easily but just
routing those IPv4 prefixes to the NAT. 

If you want the NAT to provide full redundancy, then it has to be scaled to
accept full load. Otherwise, no IPv6 just means no Internet. Very simple.

> > We want large scale deployment of IPv6 today not some time in the future
> > when we finally figured out address selection. And that means that today we
> > have to make sure that users don't end up with unreliable IPv6 connections.
> 
> If you make the constraint that nobody can use IPv6 at all until
> the IPv6 connections work as well in all cases as the IPv4 connections,
> that creates a huge barrier to the universal deployment of IPv6 -
> which already has enough barriers as it is.

To some extent that is exactly the way it is. 

Suppose that a significant fraction of popular websites would have IPv6
addresses that don't actually work. Then essentially no ISP would enable IPv6
for their customers because their customers would suffer.

At the moment, most servers that do have IPv6 addresses seem to actually
support IPv6 so this doesn't seem to be a big problem.

But we don't know what the future might bring. If there would be a sudden
rush of servers that have PMTU problems, then we could have a very serious
problem. 

> A less onerous constraint is that less reliable IPv6 connections
> don't get used in preference to more reliable IPv4 connections.
> We're lucky in the case of 6to4 in that it has a well-known prefix
> that allows the traffic to be distinguished from other v6 traffic.
> But it's still necessary to manage expectations about IPv4 as a
> fallback path.

Happy Eyeballs can solve a lot of problems where a connection will fail
completely or have a high latency. But HE support is far from universal and
so far experience is limited to TCP.

But it doesn't do anything for PMTU problems. 

It also doesn't do anything for real-time streaming applications.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Keith Moore]

On Jul 28, 2011, at 3:50 AM, Philip Homburg wrote:

> In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote:
>> PS - And in those cases, proper address selection is a much better solution
>> (IMHO) than hitting this screw with a hammer.
> 
> I think the problem is that we don't know how to do 'proper' address
> selection. It would be nice if 5 or 10 years ago there would have been a good
> standard to do address selection. Today, we are just in the stage of doing
> more experiments.
> 
> There is one thing that works well. And that is, you only assign global
> IPv6 addresses to a host if global IPv6 connectivity is at least as good as
> IPv4 connectivity.

In general, all of a host's addresses (at least, those in the same preference 
class in the address selection algorithm) need to work equally well from 
everywhere.

But even that might not be sufficient.   Fred Baker has recently been citing a 
different example of the same problem:  Imagine a future where hosts on a 
network have both v6 and legacy v4 through stateful NAT.  Because the v6 
connection works well most of the time, hosts tend to choose v6 destinations, 
and sites reduce the capacity of their NATs over time.  Then the v6 connection 
fails, and suddenly everything falls back to v4, and the connections through 
NAT also fail for lack of sufficient capacity to handle the load.

Note that in some sense this is a perceptual problem.   If instead of a v4 and 
a v6 address, each of those hosts had two v6 addresses and two different egress 
paths, the network engineers would be more likely to understand that both 
external connections needed to be of equal capacity - just like multihomed v4 
networks with a single prefix now.   And in some sense there's nothing wrong 
with having a v6 connection for most things and a small v4 NAT for connecting 
to legacy v4 services, as long as you don't think of the v4 path as a fallback 
- you're willing to accept that loss of the v6 connection is for practical 
purposes loss of external connectivity.   The problem is that if you think of 
the v4 NAT as a fallback for the v6 service, AND you don't drastically 
overprovision the NAT.

> We want large scale deployment of IPv6 today not some time in the future
> when we finally figured out address selection. And that means that today we
> have to make sure that users don't end up with unreliable IPv6 connections.

If you make the constraint that nobody can use IPv6 at all until the IPv6 
connections work as well in all cases as the IPv4 connections, that creates a 
huge barrier to the universal deployment of IPv6 - which already has enough 
barriers as it is.  

A less onerous constraint is that less reliable IPv6 connections don't get used 
in preference to more reliable IPv4 connections.  We're lucky in the case of 
6to4 in that it has a well-known prefix that allows the traffic to be 
distinguished from other v6 traffic.   But it's still necessary to manage 
expectations about IPv4 as a fallback path.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

Philip Homburg wrote:

> I think the problem is that we don't know how to do 'proper' address
> selection.

I know and it's trivially easy.

> It would be nice if 5 or 10 years ago there would have been a good
> standard to do address selection.

11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote:

   End systems (hosts) are end systems. To make the end to end principle
   effectively work, the end systems must have all the available
   knowledge to make decisions by the end systems themselves.

   With regard to multihoming, when an end system want to communicate
   with a multihomed end system, the end system must be able to select
   most appropriate (based on the local information) destination address
   of the multihomed end system.

which means an end system should have a full routing table, IGP
metrics in which tell the end system what is the best address of
its multihomed peer. Full routing table should and can, of course,
be small.

The approach is totally against node/router separation of IPv6 to
make routers, the intermediate systems, a lot more intelligent
than nodes, the end systems, which is partly why IPv6 is hopeless.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Philip Homburg]

In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote:
>PS - And in those cases, proper address selection is a much better solution
>(IMHO) than hitting this screw with a hammer.

I think the problem is that we don't know how to do 'proper' address
selection. It would be nice if 5 or 10 years ago there would have been a good
standard to do address selection. Today, we are just in the stage of doing
more experiments.

There is one thing that works well. And that is, you only assign global
IPv6 addresses to a host if global IPv6 connectivity is at least as good as
IPv4 connectivity.

We want large scale deployment of IPv6 today not some time in the future
when we finally figured out address selection. And that means that today we
have to make sure that users don't end up with unreliable IPv6 connections.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[TJ]

To be fair - I don't think anyone is saying "We should totally encourage
6to4!", even in the short-term ... or any other auto-tunneling transition
mechanism, really.

In fact, I think the debate here largely stems from a valid desire to
discourage 6to4.
Note: That goal, I am in favor of (recommending that 6to4 be disabled by
default on client platforms).


However, the proposals on the table seek to reclassify 6to4 as historic -
something that has raised a noticeable amount of debate about 1) what
historic really means and/or 2) what impact that re-classification may have
on currently-functional 6to4 usage today.


/TJ ... who wishes to note that 6to4 works *just fine* ... except when it
doesn't.
PS - And in those cases, proper address selection is a much better solution
(IMHO) than hitting this screw with a hammer.


On Wed, Jul 27, 2011 at 23:15, Brzozowski, John <
john_brzozow...@cable.comcast.com> wrote:

> From an operators point of view, specifically one that has deployed 6to4
> relays, use of the same should not be encouraged.
>
> I fully hope and expect the use of 6to4 to systematically decrease over
> time so the associated infrastructure can be decommissioned.
>
> While we have seen issues related to 6to4 decrease recently the deployment
> of the same over the years, in particular open relays, has grossly
> complicated deploying 6to4 in a reliable manner.
>
> I have not been able to keep up with all the emails and threads related to
> this topic, I apologize for this.
>
> The bottom line from my point of view is that we (the IETF) should do
> something to discourage the use of the same.
>
> John
> =
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozow...@cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =
>
>
>
>
> On 7/27/11 2:18 PM, "Keith Moore"  wrote:
>
> >On Jul 27, 2011, at 3:32 AM, t.petch wrote:
> >
> >
> >I oppose this action.
> >
> >I see clear evidence that 6to4 is damaging the Internet and although
> >there are
> >those who can use it without causing damage, I believe that the principle
> >is
> >'First, do no harm'
> >so the IETF has a responsibility to discourage its use.  [...]
> >
> >
> >
> >
> >
> >I'd like to address the point that "6to4 damages the Internet".
> >
> >I do understand the content providers' argument - if 6to4 is turned on at
> >the originator's host or network, the destination is advertising both A
> >and  records, and the  record is chosen in preference to the A
> >record, the user's experience is degraded.  Sometimes the performance is
> >degraded marginally (but the cumulative effect of lots of small delays on
> >a web page that loads dozens of images is large).  Sometimes it's
> >degraded significantly because the 6to4 address doesn't work at all. Both
> >cases matter, and they do provide a disincentive to content providers to
> >just slap  records onto their sites and be done with it.  (There are
> >other ways of a web site utilizing v6, but they require more work.)
> >
> >A lot of the arguments that I hear about 6to4 being "bad" in a universal
> >sense seem to be based on the assumption that it's only access to
> >"content" in the public Internet that matters.  But anyone who has
> >followed IPv6 development should know better than that.   If access to
> >"content" in the public Internet were all that mattered, there would have
> >been no interest in ULAs.   It remains the case that many enterprise
> >networks have all kinds of "internal" resources that are useful to them
> >even if they're not publicly addressable, and are only usable from within
> >that network or from other networks with which they have made explicit
> >arrangements.
> >
> >For better or worse, an explicit design "feature" of IPv6 is that hosts
> >can have multiple addresses, and that different addresses might be needed
> >in different contexts.  A host's public address might be used when
> >contacting a public web server, but when communicating within an
> >enterprise network or between networks each using ULA space, the host
> >might need to use its ULA address as a source address (the other host
> >might not have a public address or the ability to send traffic to the
> >public IPv6 network).
> >
> >I put the word "feature" in quotes because this can be a pain in the a**
> >for applications and users.   The default address selection rules don't
> >really handle this case very well, nor can any set of static default
> >rules handle this case.  Essentially what having multiple addresses per
> >host implies is that hosts or applications need to do routing in the
> >absence of routing information.  It shouldn't surprise anybody that the
> >use of addresses that only work well (or at all) within a limited scope
> >creates situations where a host will try to send traffic down a path that
> >will never get it there, even when a different path would have wor

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Brzozowski, John]

>From an operators point of view, specifically one that has deployed 6to4
relays, use of the same should not be encouraged.

I fully hope and expect the use of 6to4 to systematically decrease over
time so the associated infrastructure can be decommissioned.

While we have seen issues related to 6to4 decrease recently the deployment
of the same over the years, in particular open relays, has grossly
complicated deploying 6to4 in a reliable manner.

I have not been able to keep up with all the emails and threads related to
this topic, I apologize for this.

The bottom line from my point of view is that we (the IETF) should do
something to discourage the use of the same.

John
=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=




On 7/27/11 2:18 PM, "Keith Moore"  wrote:

>On Jul 27, 2011, at 3:32 AM, t.petch wrote:
>
>
>I oppose this action.
>
>I see clear evidence that 6to4 is damaging the Internet and although
>there are
>those who can use it without causing damage, I believe that the principle
>is
>'First, do no harm'
>so the IETF has a responsibility to discourage its use.  [...]
>
>
>
>
>
>I'd like to address the point that "6to4 damages the Internet".
>
>I do understand the content providers' argument - if 6to4 is turned on at
>the originator's host or network, the destination is advertising both A
>and  records, and the  record is chosen in preference to the A
>record, the user's experience is degraded.  Sometimes the performance is
>degraded marginally (but the cumulative effect of lots of small delays on
>a web page that loads dozens of images is large).  Sometimes it's
>degraded significantly because the 6to4 address doesn't work at all. Both
>cases matter, and they do provide a disincentive to content providers to
>just slap  records onto their sites and be done with it.  (There are
>other ways of a web site utilizing v6, but they require more work.)
>
>A lot of the arguments that I hear about 6to4 being "bad" in a universal
>sense seem to be based on the assumption that it's only access to
>"content" in the public Internet that matters.  But anyone who has
>followed IPv6 development should know better than that.   If access to
>"content" in the public Internet were all that mattered, there would have
>been no interest in ULAs.   It remains the case that many enterprise
>networks have all kinds of "internal" resources that are useful to them
>even if they're not publicly addressable, and are only usable from within
>that network or from other networks with which they have made explicit
>arrangements.
>
>For better or worse, an explicit design "feature" of IPv6 is that hosts
>can have multiple addresses, and that different addresses might be needed
>in different contexts.  A host's public address might be used when
>contacting a public web server, but when communicating within an
>enterprise network or between networks each using ULA space, the host
>might need to use its ULA address as a source address (the other host
>might not have a public address or the ability to send traffic to the
>public IPv6 network).
>
>I put the word "feature" in quotes because this can be a pain in the a**
>for applications and users.   The default address selection rules don't
>really handle this case very well, nor can any set of static default
>rules handle this case.  Essentially what having multiple addresses per
>host implies is that hosts or applications need to do routing in the
>absence of routing information.  It shouldn't surprise anybody that the
>use of addresses that only work well (or at all) within a limited scope
>creates situations where a host will try to send traffic down a path that
>will never get it there, even when a different path would have worked.
>
>Introducing IPv6 - any kind of IPv6 - into a world of hosts that already
>support IPv4, creates exactly this situation.
>
>Nothing in IPv4 prohibited hosts from having multiple addresses and from
>advertising multiple addresses in DNS.But this "feature" was rarely
>used, except in cases where all of the addresses were approximately
>equivalent in performance, because it didn't work well if some addresses
>performed better than others.  Then, as now, hosts and applications had
>no good way of reliably choosing which source and destination address to
>use.   But unlike IPv4, IPv6 deliberately chose to not only support the
>ability to have multiple addresses per host, but to actually expect it in
>a number of cases.
>
>One way to look at the content providers' complaint against 6to4, is that
>6to4 addresses are not "approximately equivalent in performance" to IPv4
>addresses.  So when hosts or applications happen to choose the 6to4
>address over an IPv4 address for the same resource, sometimes that choice
>ends up not working, or being suboptimal.  This is nothing 

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Michael Richardson]

At dinner today it was suggested that the right course of action is:
   leave rfc3056 (6to4) as it is.
   mark rfc3068-only (anycast) as historic.

It is the availability of anycast that permits 6to4 to be on by default.
Turn off the anycast, and now 6to4 is simply a useful tool for people
who know it's limitations to use. 

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Alexandru Petrescu]

After reading your text, let me share my experience:

I struggled hard to get a class C w/o NAT.  As hard as that was it was
still easier than obtaining native IPv6.  I wont struggle to get native
ipv6 too.

We use 6to4 on a frontend machine, and we use native IPv6 out of that
6to4 on several subnets behind, hence end machines are native ipv6 if i
can say so.

This is not much for content browsing, but for proudly ping6 an ipv6
node across the globe.

In the past year_s_ we have set up and down several kinds of 6-4 tunnels
manually, brokered, agreed.  We required vendors to include this and
that kind of tunnel in their sw/hw.

We have moved physically and we will move again soon.  We are guaranteed
continuity of this class C no nat, and yet still no IPv6 tunnel up and
downs.  The only thing that was stable during this time was 6to4, and
improved support appeared more and more.

I would also add as information only, that the environment where this
happens, and where i have no control, is where an ethernet seting with
many office-type users, where dhcp is not used, if you can imagine that.
There are many reasons technical and human for that being so.  And
manual assignment (vs dhcp) is not historical - its there in every pc.

Alex

Le 26/07/2011 16:14, Tim Chown a écrit :


On 25 Jul 2011, at 15:30, Ronald Bonica wrote:


Please post your views on this course of action by August 8, 2011.


Some observations.

Our own users made use of 6to4 maybe 8+ years ago, and at the time
it was handy to have.  Today though we're not aware of any of our
users running 6to4 intentionally. We have IPv6 native on site, and
anyone who wants home IPv6 connectivity either goes to an ISP that
provides it, e.g. A&A in the UK, or they use a tunnel broker. Brokers
have the additional benefit of working through NATs and with dynamic
IPv4 endpoints.

Our site sees about 1-2% of all inbound traffic being IPv6, and of
that less than 1% is 6to4, and this is only likely to fall further
with rfc3484-bis. What 6to4 we do see is probably reasonably robust
in that our return path uses the JANET-provided 6to4 relay.

Most operating systems either already, or before long will, support
rfc3484-bis, which means hosts should use IPv4 in preference to 6to4
where both are available.  To choose to use 6to4, the user would need
to consciously change their 3484 policy table, assuming their OS
supports that (Linux and Windows do, MacOS X Lion appears not to).

Geoff Huston has presented data at IETF80 showing 6to4 brokenness
and performance. We now have 'Happy Eyeballs Lite' implemented in
Chrome and (I believe, not tested it yet) Firefox, which means the
browser can adapt to broken IPv6, whether caused by 6to4 or other
factors.

The 6to4-advisory draft suggests off-by-default, which I agree with,
and use of relays to improve user experience. The problem is we can't
expect every site/ISP to run a relay (or multi-address with 6to4) so
there will inevitably always be problems with the 3068 mode of 6to4.

We measured rogue RAs over a two year period on our wireless
network. About 60% of the time at least one host was emitting a
rogue 6to4-based RA. While these were mitigated by ramond, it would
be good to see vendors fix this; it's not just MS ICS.  Happy
Eyeballs is a mitigation for such rogue RAs also.

So in summary, in practice 3484-bis and the 6to4-advisory
off-by-default will further reduce what little use there is of 6to4
now, and happy eyeballs will mitigate any remaining instances of its
use that are bad. So whether 6to4 is tagged Historic or not, it
should be causing significantly less harm.

Tim ___ Ietf mailing list
Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

Keith Moore wrote:

>> It means it's IPv6 which is damaging the Internet.
> 
> Except that the (v4) Internet is already doing its best to damage
> itself.   So the choice is between a thoroughly brain-damaged
> v4 Internet that is continually getting worse, and a somewhat
> less brain-damaged v6 Internet that has at least some chance
>  of having a few things fixed

You are wrong. While IPv4 is demonstratively usable, IPv6 along
with ND is too bloated that it is totally unusable.

For example, packet too big for multicast PMTUD causes ICMPv6
implosions which may be used for DoS.

While IPv4 guarantees that 516B payload receivable by any host,
IPv6 can't. Because of indefinitely length header options, some
of which (e.g. options for mobility) are inserted without
trasnport/application control, there is no room, not even 1B,
reserved for payload.

And, the worst problem is that 16B address, thanks to poor
estimation of RFC1715, is impossible to remember.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Warren Kumari]

Support, A+++, would by from again, etc.

On Jul 26, 2011, at 7:54 PM, Randy Bush wrote:

> i do not care what the draft is called.
> i do not care whether it is info, experimental, or an IEN
> i do care that is says 6to4 MUST be off by default
> 

Arguing about the label feels like rearranging deckchairs, but if having tidy 
deckchairs is what's needed get 6to4 off by default, so be it…

W


> randy
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Keith Moore]

On Jul 27, 2011, at 2:42 PM, Masataka Ohta wrote:

> Keith Moore wrote:
> 
>>> I see clear evidence that 6to4 is damaging the Internet and although there 
>>> are
>>> those who can use it without causing damage, I believe that the principle is
>>> 'First, do no harm'
> 
>> I put the word "feature" in quotes because this can be a pain in the a** 
> 
> It means it's IPv6 which is damaging the Internet.

Except that the (v4) Internet is already doing its best to damage itself.   So 
the choice is between a thoroughly brain-damaged v4 Internet that is 
continually getting worse, and a somewhat less brain-damaged v6 Internet that 
has at least some chance of having a few things fixed - though all of the 
existing successful "content" and services are optimized for the v4 Internet.

But again, fixing the 6to4 version of this problem is relatively easy, and 
pretty much everybody agrees on mechanisms that will fix the problem.  The only 
disagreement is how to make the message as clear and effective as possible, and 
there are glimmers of hope in that area.

People just shouldn't get lulled into thinking that the problem will go away 
once 6to4 is fixed.

Keith


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Lorenzo Colitti]

On Wed, Jul 27, 2011 at 14:18, Keith Moore wrote:

> So essentially, the argument that "6to4 damages the Internet", is
> tantamount to "having multiple addresses for hosts damages the Internet".
>
> *And this is an explicitly chosen architectural "feature" of IPv6.*
>

Having multiple addresses for hosts damages the Internet
Multiple addresses for hosts damages the Internet
-> IPv6 damages the Internet

I give up. I wish you a productive discussion from here on.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Michael Richardson]

Thank you Keith for restating the problem.

> "Keith" == Keith Moore  writes:
Keith> So essentially, the argument that "6to4 damages the
Keith> Internet", is tantamount to "having multiple addresses for
Keith> hosts damages the Internet". 

+1

...

Keith> People who are entirely engaged in providing content may have
Keith> a hard time seeing any utility in 6to4.   They may ask, "if
Keith> it doesn't deliver content as well as IPv4 does, what good is
Keith> it?".   My answer to that question is, "what good are private
Keith> networks and ULAs? " 

And, we need to remember that the IETF is the stewart of the IP protocol
suite, not the stewart of the Internet.

Perhaps we actually need Klensin's Internet Standard series, not as a
two-level or something else, but as agreement as to what happens on the
public Internet, vs what might happen behind closed doors.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Masataka Ohta]

Keith Moore wrote:

>> I see clear evidence that 6to4 is damaging the Internet and although there 
>> are
>> those who can use it without causing damage, I believe that the principle is
>> 'First, do no harm'

> I put the word "feature" in quotes because this can be a pain in the a** 

It means it's IPv6 which is damaging the Internet.

> Introducing IPv6 - any kind of IPv6 - into a world of hosts that 

A revised IPv6 and transport which can properly handle multiple
addresses can happily coexist with IPv4.

However, as IPv6 is totally broken, it is better to start with
a clean slate than to revise it. Or, more practically, just stick
to IPv4.

> Nothing in IPv4 prohibited hosts from having multiple addresses

IPv4 with revised transport is far better than the current IPv6
and transport.

> And this is an explicitly chosen architectural "feature" of IPv6.

which is partly why IPv6 is broken and harmful. Proper support
of multihoming can be done only at the transport layer and above.

Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

"6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))

[Keith Moore]

On Jul 27, 2011, at 3:32 AM, t.petch wrote:

> I oppose this action.
> 
> I see clear evidence that 6to4 is damaging the Internet and although there are
> those who can use it without causing damage, I believe that the principle is
> 'First, do no harm'
> so the IETF has a responsibility to discourage its use.  [...]

I'd like to address the point that "6to4 damages the Internet".

I do understand the content providers' argument - if 6to4 is turned on at the 
originator's host or network, the destination is advertising both A and  
records, and the  record is chosen in preference to the A record, the 
user's experience is degraded.  Sometimes the performance is degraded 
marginally (but the cumulative effect of lots of small delays on a web page 
that loads dozens of images is large).  Sometimes it's degraded significantly 
because the 6to4 address doesn't work at all. Both cases matter, and they do 
provide a disincentive to content providers to just slap  records onto 
their sites and be done with it.  (There are other ways of a web site utilizing 
v6, but they require more work.)

A lot of the arguments that I hear about 6to4 being "bad" in a universal sense 
seem to be based on the assumption that it's only access to "content" in the 
public Internet that matters.  But anyone who has followed IPv6 development 
should know better than that.   If access to "content" in the public Internet 
were all that mattered, there would have been no interest in ULAs.   It remains 
the case that many enterprise networks have all kinds of "internal" resources 
that are useful to them even if they're not publicly addressable, and are only 
usable from within that network or from other networks with which they have 
made explicit arrangements.

For better or worse, an explicit design "feature" of IPv6 is that hosts can 
have multiple addresses, and that different addresses might be needed in 
different contexts.  A host's public address might be used when contacting a 
public web server, but when communicating within an enterprise network or 
between networks each using ULA space, the host might need to use its ULA 
address as a source address (the other host might not have a public address or 
the ability to send traffic to the public IPv6 network).  

I put the word "feature" in quotes because this can be a pain in the a** for 
applications and users.   The default address selection rules don't really 
handle this case very well, nor can any set of static default rules handle this 
case.  Essentially what having multiple addresses per host implies is that 
hosts or applications need to do routing in the absence of routing information. 
 It shouldn't surprise anybody that the use of addresses that only work well 
(or at all) within a limited scope creates situations where a host will try to 
send traffic down a path that will never get it there, even when a different 
path would have worked.

Introducing IPv6 - any kind of IPv6 - into a world of hosts that already 
support IPv4, creates exactly this situation.

Nothing in IPv4 prohibited hosts from having multiple addresses and from 
advertising multiple addresses in DNS.But this "feature" was rarely used, 
except in cases where all of the addresses were approximately equivalent in 
performance, because it didn't work well if some addresses performed better 
than others.  Then, as now, hosts and applications had no good way of reliably 
choosing which source and destination address to use.   But unlike IPv4, IPv6 
deliberately chose to not only support the ability to have multiple addresses 
per host, but to actually expect it in a number of cases.

One way to look at the content providers' complaint against 6to4, is that 6to4 
addresses are not "approximately equivalent in performance" to IPv4 addresses.  
So when hosts or applications happen to choose the 6to4 address over an IPv4 
address for the same resource, sometimes that choice ends up not working, or 
being suboptimal.  This is nothing new with 6to4.  It's inherently the case 
that having multiple addresses for a host that aren't equivalent in performance 
leads to suboptimal choices in some cases.

So essentially, the argument that "6to4 damages the Internet", is tantamount to 
"having multiple addresses for hosts damages the Internet".

And this is an explicitly chosen architectural "feature" of IPv6.   Blaming 
6to4 for the problems caused by this "feature" is like blaming the canary 
carried by a coal miner for ceasing to chirp.  

(Though as it turns out, in the case of 6to4 the fix is relatively easy - just 
make 6to4 lower preference than either IPv4 or native IPv6 addresses except 
when the source and destination are both 6to4. )

--

People who are entirely engaged in providing content may have a hard time 
seeing any utility in 6to4.   They may ask, "if it doesn't deliver content as 
well as IPv4 does, what good is it?".   My answer to that question is, "what 
good are private network

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Tore Anderson]

* Ronald Bonica

> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.

I support this approach.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[George Michaelson]

I have considered the issues I had facing 6to4 deprecation, and in the light of 
what you propose here, and other discussions, I support this course of action.

-George

On 25/07/2011, at 10:30 AM, Ronald Bonica wrote:

> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>   Ron Bonica
>as OPS Area AD>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Rémi Després]

Le 27 juil. 2011 à 01:54, Randy Bush a écrit :

> i do not care what the draft is called.
> i do not care whether it is info, experimental, or an IEN


> i do care that is says 6to4 MUST be off by default

+1
This is really what IETF has to say.

Everything else should better be limited to explanations.

RD

> 
> randy
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[t.petch]

I oppose this action.

I see clear evidence that 6to4 is damaging the Internet and although there are
those who can use it without causing damage, I believe that the principle is
'First, do no harm'
so the IETF has a responsibility to discourage its use.  For me, classifying it
as 'Historic' is the best way of doing this but I see that there are those dead
set against it.

Redefining 'Historic', as proposed here, can only confuse given the previous and
successful widespread use of this technical term.

Several have suggested that an alternative would be to recast this I-D as an
Applicability Statement and, while I would not see this as good as 'Historic',
since I think that  it carries less weight, I would still see that as strong
enough to get across the message - '6to4 damages the Internet - don't do it'
leaving those who know better to know better.

Tom Petch

- Original Message -
From: "Ronald Bonica" 
To: 
Sent: Monday, July 25, 2011 4:30 PM
Subject: draft-ietf-v6ops-6to4-to-historic (yet again)


> Folks,
>
> After some discussion, the IESG is attempting to determine whether there is
IETF consensus to do the following:
>
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert
their status to HISTORIC. It will also contain a new section describing what it
means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will
say that:
>
> - 6-to-4 should not be configured by default on any implementation (hosts, cpe
routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from
implementations. Likewise, operators will decide whether/when 6-to-4 relays will
be removed from their networks. The status of RFCs 3056 and 3068 should not be
interpreted as a recommendation to remove 6-to-4 at any particular time.
>
>
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies
the meaning of "HISTORIC" in this particular case, it does not set a precedent
for any future case.
>
> Please post your views on this course of action by August 8, 2011.
>
>
>Ron Bonica
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Rémi Després]

Le 27 juil. 2011 à 00:11, james woodyatt a écrit :

> On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote:
>> 
>> Please post your views on this course of action by August 8, 2011.
> 
> I remain convinced that this document is unnecessary and publishing it would 
> be silly, at best, and at worst, the simultaneous publication of 
> 6to4-to-historic alongside 6to4-advisory, which implicitly contradict one 
> another-- the latter says that 6to4 has an indefinite future and here's how 
> to keep everything operational in its presence on the Internet; the former 
> says 6to4 has no future, and it should not be used by anyone for any 
> purpose-- may turn out to be an embarrassment for IETF.

>  IESG should feel very nervous about claiming there is consensus to publish 
> this draft.  It does not appear to me like there is a rough consensus for it.

+1


> 
> That said, I won't complain too loudly if this draft is published.  It would 
> give me cover to ask my employers for 6to4 capability to be removed from 
> forthcoming products that I mainly work to support.  I don't like taking 
> features away from users when there isn't a suitable upgrade path for them, 
> but the truth is that fielding problems from the field resulting from 6to4 
> failure can be pretty tiresome, and I would welcome the cover from IETF to be 
> able to say, "Oh, you're still using 6to4?  You should turn that off.  It's 
> deprecated by IETF now, and accordingly, we no longer support it.  Get native 
> IPv6 service."
> 
> In other words, whether IESG means to convey this message or not, publishing 
> 6to4-to-historic alongside the existing 6to4-advisory-- without any clear 
> phase-out plan-- will pretty clearly imply to people like me that the 
> official phase-out plan is to remove 6to4 from the Internet, starting as soon 
> as vendors and operators are independently able to do so.  "Start the engines 
> of destruction."
> 
> 
> --
> james woodyatt 
> member of technical staff, core os networking
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Sabahattin Gucukoglu]

On 25 Jul 2011, at 17:30, Ronald Bonica wrote:
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.

This scares me.  I was on the point of saying, "But none of that stuff makes it 
historic!" but you then change what "Historic" means, so that I can no longer 
be certain ...

I'd like to see the text, but my feeling is that, no, I will not approve.  That 
document is too loaded with dubious claims and 6to4 hate for my liking.  And 
the advisory document is already perfect for expressing the _real_ problems, 
that really _do_ exist, for (current) 6to4 deployment.  Once again, "Historic" 
(in whatever sense meant) is just too strong an applied label to something 
which _can_ be used.  I have a very hard time seeing the sense in this document.

But let's see the text.  Perhaps you can redefine the word "Historic" in a new 
and interesting way.

Cheers,
Sabahattin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[GT RAMIREZ, Medel G.]

I say "Vow"...

Medel
+
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Noel Chiappa
Sent: Wednesday, July 27, 2011 4:14 AM
To: ietf@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)


> From: "t.petch"  

> I realise that ... you are seeking IETF consensus but what is that
> if the WG is dead set against it?

If the entire WG is against it, that's enough people to (IMO) prevent
IETF
consensus -> no IETF rough consensus for this statement.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

This e-mail message (including attachments, if any) is intended for the use of 
the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify the 
sender and delete this E-mail message immediately.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Randy Bush]

i do not care what the draft is called.
i do not care whether it is info, experimental, or an IEN
i do care that is says 6to4 MUST be off by default

randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Brian E Carpenter]

Ron,

The normal typography is 6to4, not 6-to-4. I assume the draft will
still refer to [I-D.ietf-v6ops-6to4-advisory]. Given that, I believe
the draft should proceed.

I definitely disagree with those who say this would be a misuse of
"Historic"; the words in RFC 2026 certainly cover this case
("for any other reason considered to be obsolete").

Regards
   Brian Carpenter

On 2011-07-27 01:47, Ronald Bonica wrote:
> Brian,
> 
> Does the following text work for you?
> 
>  Ron
> 
> 
> N. Meaning of HISTORIC
> 
> For the purposes of this document, the term HISTORIC means:
> 
> - 6-to-4 should not be configured by default on any implementation (host, cpe 
> router, other)
> 
> - Vendors will decide which future versions of their products will support 
> 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) 
> they are no longer economically incented to do so and b) they are 
> economically incented to remove unused features from their products.
> 
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is 
> assumed that operators will continue to operate 6-to-4 relays as long as they 
> are economically incented to do so. When 6-to-4 traffic levels reach zero, 
> operators will probably begin to consider decommissioning.
> 
> The status of RFCs 3056 and 3068 should not be interpreted as a 
> recommendation to remove 6-to-4 at any particular time.
> 
> 
>> -Original Message-
>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Monday, July 25, 2011 11:09 PM
>> To: Ronald Bonica
>> Cc: ietf@ietf.org
>> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
>>
>> To be clear, I'd like to see exact proposed text before expressing
>> support for the proposal. The trick is to get 6to4 disabled by default
>> at the user end, without disabling it for users who are getting good
>> service from it.
>>
>> Regards
>>Brian
>>
>> On 2011-07-26 09:49, Brian E Carpenter wrote:
>>>>  Likewise, operators will decide whether/when 6-to-4 relays will be
>> removed from their networks.
>>> This is, of course, an undeniable statement of fact (as it is for any
>> other feature
>>> of the Internet). However, it needs to be made clear that doing so
>> *prematurely*
>>> would penalise existing successful users of those relays, and
>> therefore it should
>>> only be done when there is no successful traffic through them. Which
>> is when any
>>> operator would remove them anyway.
>>>
>>> Therefore, I don't see much value in this statement, and possible
>> harm to users.
>>> The ways to avoid such harm as far as possible are already in the RFC
>> Editor
>>> queue.
>>>
>>> Regards
>>>Brian Carpenter
>>>
>>> On 2011-07-26 02:30, Ronald Bonica wrote:
>>>> Folks,
>>>>
>>>> After some discussion, the IESG is attempting to determine whether
>> there is IETF consensus to do the following:
>>>> - add a new section to draft-ietf-v6ops-6to4-to-historic
>>>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>>>>
>>>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
>> and convert their status to HISTORIC. It will also contain a new
>> section describing what it means for RFCs 3056 and 3068 to be
>> classified as HISTORIC. The new section will say that:
>>>> - 6-to-4 should not be configured by default on any implementation
>> (hosts, cpe routers, other)
>>>> - vendors will decide whether/when 6-to-4 will be removed from
>> implementations. Likewise, operators will decide whether/when 6-to-4
>> relays will be removed from their networks. The status of RFCs 3056 and
>> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
>> any particular time.
>>>>
>>>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
>> clarifies the meaning of "HISTORIC" in this particular case, it does
>> not set a precedent for any future case.
>>>> Please post your views on this course of action by August 8, 2011.
>>>>
>>>>
>>>>
>> Ron Bonica
>> 
>>>> ___
>>>> Ietf mailing list
>>>> Ietf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf
>>>>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[james woodyatt]

On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote:
> 
> Please post your views on this course of action by August 8, 2011.

I remain convinced that this document is unnecessary and publishing it would be 
silly, at best, and at worst, the simultaneous publication of 6to4-to-historic 
alongside 6to4-advisory, which implicitly contradict one another-- the latter 
says that 6to4 has an indefinite future and here's how to keep everything 
operational in its presence on the Internet; the former says 6to4 has no 
future, and it should not be used by anyone for any purpose-- may turn out to 
be an embarrassment for IETF.  IESG should feel very nervous about claiming 
there is consensus to publish this draft.  It does not appear to me like there 
is a rough consensus for it.

That said, I won't complain too loudly if this draft is published.  It would 
give me cover to ask my employers for 6to4 capability to be removed from 
forthcoming products that I mainly work to support.  I don't like taking 
features away from users when there isn't a suitable upgrade path for them, but 
the truth is that fielding problems from the field resulting from 6to4 failure 
can be pretty tiresome, and I would welcome the cover from IETF to be able to 
say, "Oh, you're still using 6to4?  You should turn that off.  It's deprecated 
by IETF now, and accordingly, we no longer support it.  Get native IPv6 
service."

In other words, whether IESG means to convey this message or not, publishing 
6to4-to-historic alongside the existing 6to4-advisory-- without any clear 
phase-out plan-- will pretty clearly imply to people like me that the official 
phase-out plan is to remove 6to4 from the Internet, starting as soon as vendors 
and operators are independently able to do so.  "Start the engines of 
destruction."


--
james woodyatt 
member of technical staff, core os networking



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Templin, Fred L]

Ron,

I believe 'draft-ietf-v6ops-6to4-advisory' is both
necessary and sufficient regardless of whether
"historic" is an appropriate characterization. So,
I don't think we need this document.

Thanks - Fred
fred.l.temp...@boeing.com  

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Ronald Bonica
> Sent: Monday, July 25, 2011 7:31 AM
> To: ietf@ietf.org
> Subject: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> Folks,
> 
> After some discussion, the IESG is attempting to determine 
> whether there is IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 
> 3068 and convert their status to HISTORIC. It will also 
> contain a new section describing what it means for RFCs 3056 
> and 3068 to be classified as HISTORIC. The new section will say that:
> 
> - 6-to-4 should not be configured by default on any 
> implementation (hosts, cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed 
> from implementations. Likewise, operators will decide 
> whether/when 6-to-4 relays will be removed from their 
> networks. The status of RFCs 3056 and 3068 should not be 
> interpreted as a recommendation to remove 6-to-4 at any 
> particular time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. 
> While it clarifies the meaning of "HISTORIC" in this 
> particular case, it does not set a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>   
>  Ron Bonica
>   
>  
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Ronald Bonica]

Tom,

Sorry. I meant to copy both lists. They are both copied now.

Ron


> -Original Message-
> From: t.petch [mailto:daedu...@btconnect.com]
> Sent: Tuesday, July 26, 2011 2:36 PM
> To: Ronald Bonica; ietf@ietf.org
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> It seems strange that this e-mail is not copied to the v6ops list.
> 
> I would have expected this first to have been hammered out on the v6ops
> list
> and, if and only if consensus was reached there, the new text be then
> brought to
> the
> IETF list.
> 
> I realise that, as you spell out, you are seeking IETF consensus but
> what is
> that if the
> WG is dead set against it?
> 
> Tom Petch
> 
> 
> - Original Message -
> From: "Ronald Bonica" 
> To: 
> Sent: Monday, July 25, 2011 4:30 PM
> 
> > After some discussion, the IESG is attempting to determine whether
> there is
> IETF consensus to do the following:
> >
> > - add a new section to draft-ietf-v6ops-6to4-to-historic
> > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> >
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> and convert
> their status to HISTORIC. It will also contain a new section describing
> what it
> means for RFCs 3056 and 3068 to be classified as HISTORIC. The new
> section will
> say that:
> >
> > - 6-to-4 should not be configured by default on any implementation
> (hosts, cpe
> routers, other)
> > - vendors will decide whether/when 6-to-4 will be removed from
> implementations. Likewise, operators will decide whether/when 6-to-4
> relays will
> be removed from their networks. The status of RFCs 3056 and 3068 should
> not be
> interpreted as a recommendation to remove 6-to-4 at any particular
> time.
> >
> >
> > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies
> the meaning of "HISTORIC" in this particular case, it does not set a
> precedent
> for any future case.
> >
> > Please post your views on this course of action by August 8, 2011.
> >
> >
> >
> Ron Bonica
> >
>  as OPS Area AD>
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Douglas Otis]

On 7/26/11 12:58 PM, SM wrote:

Hi Ron,
At 07:30 AM 7/25/2011, Ronald Bonica wrote:
draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 
and convert their status to HISTORIC. It will also contain a new 
section describing what it means for RFCs 3056 and 3068 to be 
classified as HISTORIC. The new section will say that:


- 6-to-4 should not be configured by default on any implementation 
(hosts, cpe routers, other)
- vendors will decide whether/when 6-to-4 will be removed from 
implementations. Likewise, operators will decide whether/when 6-to-4 
relays will be removed from their networks. The status of RFCs 3056 
and 3068 should not be interpreted as a recommendation to remove 
6-to-4 at any particular time.


draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
clarifies the meaning of "HISTORIC" in this particular case, it does 
not set a precedent for any future case.


The above conflates document labels, Historic in this case, and advice 
to vendors and operators.  Redefining the meaning of Historic in a RFC 
that is not even a BCP is a bad idea.


I am fine of 6-to-4 not to be configured on by default and obsoleting 
RFCs 3056 and 3068.   I do not support the redefinition of Historic or 
the claim that there is IETF Consensus.

Agreed.

-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[SM]

Hi Ron,
At 07:30 AM 7/25/2011, Ronald Bonica wrote:
draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 
and convert their status to HISTORIC. It will also contain a new 
section describing what it means for RFCs 3056 and 3068 to be 
classified as HISTORIC. The new section will say that:


- 6-to-4 should not be configured by default on any implementation 
(hosts, cpe routers, other)
- vendors will decide whether/when 6-to-4 will be removed from 
implementations. Likewise, operators will decide whether/when 6-to-4 
relays will be removed from their networks. The status of RFCs 3056 
and 3068 should not be interpreted as a recommendation to remove 
6-to-4 at any particular time.


draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
clarifies the meaning of "HISTORIC" in this particular case, it does 
not set a precedent for any future case.


The above conflates document labels, Historic in this case, and 
advice to vendors and operators.  Redefining the meaning of Historic 
in a RFC that is not even a BCP is a bad idea.


I am fine of 6-to-4 not to be configured on by default and obsoleting 
RFCs 3056 and 3068.   I do not support the redefinition of Historic 
or the claim that there is IETF Consensus.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Noel Chiappa]

> From: "t.petch"  

> I realise that ... you are seeking IETF consensus but what is that
> if the WG is dead set against it?

If the entire WG is against it, that's enough people to (IMO) prevent IETF
consensus -> no IETF rough consensus for this statement.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Mikael Abrahamsson]

On Tue, 26 Jul 2011, t.petch wrote:

I realise that, as you spell out, you are seeking IETF consensus but 
what is that if the WG is dead set against it?


Depending on who you ask, there was consensus, rough consensus, or no 
consensus about this document. My opinion is that rough consensus was met 
with a few very vocal people against. I support this document.


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Joel Jaeggli]

On Jul 26, 2011, at 2:35 PM, t.petch wrote:

> It seems strange that this e-mail is not copied to the v6ops list.
> 
> I would have expected this first to have been hammered out on the v6ops list
> and, if and only if consensus was reached there, the new text be then brought 
> to
> the
> IETF list.
> 
> I realise that, as you spell out, you are seeking IETF consensus but what is
> that if the
> WG is dead set against it?

The working group adopted the document without the statement. the IESG would 
presumably provide instruction as to what to do next with the draft were they 
to conclude that the compromise was considered acceptable by the community.

> Tom Petch
> 
> 
> - Original Message -
> From: "Ronald Bonica" 
> To: 
> Sent: Monday, July 25, 2011 4:30 PM
> 
>> After some discussion, the IESG is attempting to determine whether there is
> IETF consensus to do the following:
>> 
>> - add a new section to draft-ietf-v6ops-6to4-to-historic
>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>> 
>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
>> convert
> their status to HISTORIC. It will also contain a new section describing what 
> it
> means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section 
> will
> say that:
>> 
>> - 6-to-4 should not be configured by default on any implementation (hosts, 
>> cpe
> routers, other)
>> - vendors will decide whether/when 6-to-4 will be removed from
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will
> be removed from their networks. The status of RFCs 3056 and 3068 should not be
> interpreted as a recommendation to remove 6-to-4 at any particular time.
>> 
>> 
>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
>> clarifies
> the meaning of "HISTORIC" in this particular case, it does not set a precedent
> for any future case.
>> 
>> Please post your views on this course of action by August 8, 2011.
>> 
>> 
>>   Ron Bonica
>>as OPS Area AD>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[t.petch]

It seems strange that this e-mail is not copied to the v6ops list.

I would have expected this first to have been hammered out on the v6ops list
and, if and only if consensus was reached there, the new text be then brought to
the
IETF list.

I realise that, as you spell out, you are seeking IETF consensus but what is
that if the
WG is dead set against it?

Tom Petch


- Original Message -
From: "Ronald Bonica" 
To: 
Sent: Monday, July 25, 2011 4:30 PM

> After some discussion, the IESG is attempting to determine whether there is
IETF consensus to do the following:
>
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert
their status to HISTORIC. It will also contain a new section describing what it
means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will
say that:
>
> - 6-to-4 should not be configured by default on any implementation (hosts, cpe
routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from
implementations. Likewise, operators will decide whether/when 6-to-4 relays will
be removed from their networks. The status of RFCs 3056 and 3068 should not be
interpreted as a recommendation to remove 6-to-4 at any particular time.
>
>
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies
the meaning of "HISTORIC" in this particular case, it does not set a precedent
for any future case.
>
> Please post your views on this course of action by August 8, 2011.
>
>
>Ron Bonica
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Geoff Huston]

I'm in favor of the proposed action and the clarification of HISTORIC as 
proposed in the new section.

Geoff


On 26/07/2011, at 12:30 AM, Ronald Bonica wrote:

> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Tim Chown]

On 26 Jul 2011, at 15:14, Tim Chown wrote:
> 
> So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will 
> further reduce what little use there is of 6to4 now, and happy eyeballs will 
> mitigate any remaining instances of its use that are bad. So whether 6to4 is 
> tagged Historic or not, it should be causing significantly less harm.  

To clarify, I am in favour.

Tim

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Lorenzo Colitti]

I support this proposal, for the following reasons:

1. Google's public IPv6 adoption data [1] shows that from the perspective of
a website, 6to4 is a tiny and decreasing percentage of IPv6 clients.
2. Geoff Huston's data, presented at v6ops in Prague, shows that 6to4
failure rate when connecting to dual-stack destinations is approximately
20%.
3. Large website operators such as Google, Yahoo, and Facebook have data
that show that 6to4 is an important reason for a large percentage of
dual-stack brokenness, and that dual-stack brokenness is the main reason why
their websites do not have IPv6 records today. Lack of IPv6 content is one
of the reasons most often cited by access networks when explaining the lack
of IPv6 deployment to end users.
4. A number of home gateway manufacturers are still coming out with new
devices that support 6to4 and even enable it by default when IPv6 is
enabled. Declaring 6to4 it to be historic would help ensure that those
manufacturers disable 6to4 in future products.
5. The advent of large-scale NAT will decrease the applicability of 6to4.
6. The advent of ISPs assigning bogon address space to users will
substantially
7. For those who want to do application development using IPv6, there are
alternatives to 6to4, such as manually configured tunnels. These are readily
available, work behind NATs, and in many cases offer lower latency and
higher reliability.

[1] http://www.google.com/intl/en/ipv6/statistics/

On Tue, Jul 26, 2011 at 09:47, Ronald Bonica  wrote:

> Brian,
>
> Does the following text work for you?
>
> Ron
>
>
> N. Meaning of HISTORIC
>
> For the purposes of this document, the term HISTORIC means:
>
> - 6-to-4 should not be configured by default on any implementation (host,
> cpe router, other)
>
> - Vendors will decide which future versions of their products will support
> 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a)
> they are no longer economically incented to do so and b) they are
> economically incented to remove unused features from their products.
>
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is
> assumed that operators will continue to operate 6-to-4 relays as long as
> they are economically incented to do so. When 6-to-4 traffic levels reach
> zero, operators will probably begin to consider decommissioning.
>
> The status of RFCs 3056 and 3068 should not be interpreted as a
> recommendation to remove 6-to-4 at any particular time.
>
>
> > -Original Message-
> > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> > Sent: Monday, July 25, 2011 11:09 PM
> > To: Ronald Bonica
> > Cc: ietf@ietf.org
> > Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> >
> > To be clear, I'd like to see exact proposed text before expressing
> > support for the proposal. The trick is to get 6to4 disabled by default
> > at the user end, without disabling it for users who are getting good
> > service from it.
> >
> > Regards
> >Brian
> >
> > On 2011-07-26 09:49, Brian E Carpenter wrote:
> > >>  Likewise, operators will decide whether/when 6-to-4 relays will be
> > removed from their networks.
> > >
> > > This is, of course, an undeniable statement of fact (as it is for any
> > other feature
> > > of the Internet). However, it needs to be made clear that doing so
> > *prematurely*
> > > would penalise existing successful users of those relays, and
> > therefore it should
> > > only be done when there is no successful traffic through them. Which
> > is when any
> > > operator would remove them anyway.
> > >
> > > Therefore, I don't see much value in this statement, and possible
> > harm to users.
> > > The ways to avoid such harm as far as possible are already in the RFC
> > Editor
> > > queue.
> > >
> > > Regards
> > >Brian Carpenter
> > >
> > > On 2011-07-26 02:30, Ronald Bonica wrote:
> > >> Folks,
> > >>
> > >> After some discussion, the IESG is attempting to determine whether
> > there is IETF consensus to do the following:
> > >>
> > >> - add a new section to draft-ietf-v6ops-6to4-to-historic
> > >> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> > >>
> > >> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> > and convert their status to HISTORIC. It will also contain a new
> > section describing what it means for RFCs 3056 and 3068 to be
> > classified as HISTORIC. The new section will say that:
> > >>
> > &

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Tim Chown]

On 25 Jul 2011, at 15:30, Ronald Bonica wrote:
> 
> Please post your views on this course of action by August 8, 2011.

Some observations.

Our own users made use of 6to4 maybe 8+ years ago, and at the time it was handy 
to have.  Today though we're not aware of any of our users running 6to4 
intentionally. We have IPv6 native on site, and anyone who wants home IPv6 
connectivity either goes to an ISP that provides it, e.g. A&A in the UK, or 
they use a tunnel broker.  Brokers have the additional benefit of working 
through NATs and with dynamic IPv4 endpoints.

Our site sees about 1-2% of all inbound traffic being IPv6, and of that less 
than 1% is 6to4, and this is only likely to fall further with rfc3484-bis. What 
6to4 we do see is probably reasonably robust in that our return path uses the 
JANET-provided 6to4 relay.  

Most operating systems either already, or before long will, support 
rfc3484-bis, which means hosts should use IPv4 in preference to 6to4 where both 
are available.  To choose to use 6to4, the user would need to consciously 
change their 3484 policy table, assuming their OS supports that (Linux and 
Windows do, MacOS X Lion appears not to).

Geoff Huston has presented data at IETF80 showing 6to4 brokenness and 
performance. We now have 'Happy Eyeballs Lite' implemented in Chrome and (I 
believe, not tested it yet) Firefox, which means the browser can adapt to 
broken IPv6, whether caused by 6to4 or other factors.

The 6to4-advisory draft suggests off-by-default, which I agree with, and use of 
relays to improve user experience. The problem is we can't expect every 
site/ISP to run a relay (or multi-address with 6to4) so there will inevitably 
always be problems with the 3068 mode of 6to4.

We measured rogue RAs over a two year period on our wireless network.  About 
60% of the time at least one host was emitting a rogue 6to4-based RA. While 
these were mitigated by ramond, it would be good to see vendors fix this; it's 
not just MS ICS.  Happy Eyeballs is a mitigation for such rogue RAs also.

So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will 
further reduce what little use there is of 6to4 now, and happy eyeballs will 
mitigate any remaining instances of its use that are bad. So whether 6to4 is 
tagged Historic or not, it should be causing significantly less harm.  

Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Ronald Bonica]

Brian,

Does the following text work for you?

 Ron


N. Meaning of HISTORIC

For the purposes of this document, the term HISTORIC means:

- 6-to-4 should not be configured by default on any implementation (host, cpe 
router, other)

- Vendors will decide which future versions of their products will support 
6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) 
they are no longer economically incented to do so and b) they are economically 
incented to remove unused features from their products.

- Operators will decide when to decommission 6-to-4 relays, if ever. It is 
assumed that operators will continue to operate 6-to-4 relays as long as they 
are economically incented to do so. When 6-to-4 traffic levels reach zero, 
operators will probably begin to consider decommissioning.

The status of RFCs 3056 and 3068 should not be interpreted as a recommendation 
to remove 6-to-4 at any particular time.


> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Monday, July 25, 2011 11:09 PM
> To: Ronald Bonica
> Cc: ietf@ietf.org
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> 
> To be clear, I'd like to see exact proposed text before expressing
> support for the proposal. The trick is to get 6to4 disabled by default
> at the user end, without disabling it for users who are getting good
> service from it.
> 
> Regards
>Brian
> 
> On 2011-07-26 09:49, Brian E Carpenter wrote:
> >>  Likewise, operators will decide whether/when 6-to-4 relays will be
> removed from their networks.
> >
> > This is, of course, an undeniable statement of fact (as it is for any
> other feature
> > of the Internet). However, it needs to be made clear that doing so
> *prematurely*
> > would penalise existing successful users of those relays, and
> therefore it should
> > only be done when there is no successful traffic through them. Which
> is when any
> > operator would remove them anyway.
> >
> > Therefore, I don't see much value in this statement, and possible
> harm to users.
> > The ways to avoid such harm as far as possible are already in the RFC
> Editor
> > queue.
> >
> > Regards
> >Brian Carpenter
> >
> > On 2011-07-26 02:30, Ronald Bonica wrote:
> >> Folks,
> >>
> >> After some discussion, the IESG is attempting to determine whether
> there is IETF consensus to do the following:
> >>
> >> - add a new section to draft-ietf-v6ops-6to4-to-historic
> >> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> >>
> >> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> and convert their status to HISTORIC. It will also contain a new
> section describing what it means for RFCs 3056 and 3068 to be
> classified as HISTORIC. The new section will say that:
> >>
> >> - 6-to-4 should not be configured by default on any implementation
> (hosts, cpe routers, other)
> >> - vendors will decide whether/when 6-to-4 will be removed from
> implementations. Likewise, operators will decide whether/when 6-to-4
> relays will be removed from their networks. The status of RFCs 3056 and
> 3068 should not be interpreted as a recommendation to remove 6-to-4 at
> any particular time.
> >>
> >>
> >> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies the meaning of "HISTORIC" in this particular case, it does
> not set a precedent for any future case.
> >>
> >> Please post your views on this course of action by August 8, 2011.
> >>
> >>
> >>
> Ron Bonica
> >>
> 
> >> ___
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Philip Homburg]

In your letter dated Mon, 25 Jul 2011 20:25:53 -0700 you wrote:
>Maybe I'm reading the list wrong,
>but I think the sticky point here is the "historic" thing, and nothing
>short of removing that part will significantly change the mindset of
>people who oppose it.
>
>Have you considered a newer revision of the 6-to-4 RFCs that would
>obsolete the current ones and add that 6-to-4 should be disabled by
>default? That could reach consensus.

Hmm, I never bothered to really study RFC-2026. But now I found this:

[Section 6.2:]
"When a standards-track specification has not reached the Internet
"Standard level but has remained at the same maturity level for
"twenty-four (24) months, and every twelve (12) months thereafter
"until the status is changed, the IESG shall review the viability of
"the standardization effort responsible for that specification and the
"usefulness of the technology. Following each such review, the IESG
"shall approve termination or continuation of the development effort,
"at the same time the IESG shall decide to maintain the specification
"at the same maturity level or to move it to Historic status.  This
"decision shall be communicated to the IETF by electronic mail to the
"IETF Announce mailing list to allow the Internet community an
"opportunity to comment. This provision is not intended to threaten a
"legitimate and active Working Group effort, but rather to provide an
"administrative mechanism for terminating a moribund effort.

I think it is safe to say that 6to4 is a standard track protocol that is
going nowhere. So why can't the IESG just decide to move 6to4 to historic?


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Roger Jørgensen]

On Mon, Jul 25, 2011 at 4:30 PM, Ronald Bonica  wrote:
> Folks,
>
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
>
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
>
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
>
>
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
>
> Please post your views on this course of action by August 8, 2011.

Supported.
Guess there are so many against for whatever reason so the consensus
part will be hard.
The archive have probably all of the arguments.





But whatever happen with this one, can we please move on and focus on
the one and only important thing, native IPv6. All the other are work
around.



-- 

Roger Jorgensen           |
rog...@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Mykyta Yevstifeyev]

Hello,

I am not an expert in the questions of 6to4, but unless there are strong 
arguments claiming that this technology is not used any more, 
reclassification isn't appropriate.  Discouraging implementation/use of 
the protocol is not a purpose of Historic, it is to mark what already 
no-one uses.  It is only possible to determine when the obvious absence 
of previous and current interest in the technology is determined by the 
community, such as eg. SiFTP, RFC 913.  I don't see such community's 
vision on 6to4, and therefore the document may not progress further 
unless strong community consensus is built.


Mykyta Yevstifeyev

25.07.2011 17:30, Ronald Bonica wrote:

Folks,

After some discussion, the IESG is attempting to determine whether there is 
IETF consensus to do the following:

- add a new section to draft-ietf-v6ops-6to4-to-historic
- publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL

draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert 
their status to HISTORIC. It will also contain a new section describing what it 
means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will 
say that:

- 6-to-4 should not be configured by default on any implementation (hosts, cpe 
routers, other)
- vendors will decide whether/when 6-to-4 will be removed from implementations. 
Likewise, operators will decide whether/when 6-to-4 relays will be removed from 
their networks. The status of RFCs 3056 and 3068 should not be interpreted as a 
recommendation to remove 6-to-4 at any particular time.


draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the 
meaning of "HISTORIC" in this particular case, it does not set a precedent for 
any future case.

Please post your views on this course of action by August 8, 2011.


Ron Bonica

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Mykyta Yevstifeyev]

26.07.2011 1:05, Noel Chiappa wrote:

 >  From: Ronald Bonica
 >  While it clarifies the meaning of "HISTORIC" in this particular case, it
 >  does not set a precedent for any future case.

In other words, this document is doing something with "HISTORIC" that isn't the
normal, this is a special case. I think this is a bad idea.
+1.  Should Historic status definition be clarified, it should be done 
in a separate document, or in the revision of RFC 2026.  See my previous 
message.


Mykyta


Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Randy Presuhn]

Hi -

> From: "Noel Chiappa" 
> To: 
> Cc: 
> Sent: Monday, July 25, 2011 3:05 PM
> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
...
> I think we should only mark things as HISTORIC as a recognition of _what has
> already happened_ out in the world, not as an attempt to _make something
> happen_.
...

Though I think this is a reasonable position, there are examples from
history, such as the "historicization" of RFC 1227, that clearly demonstrate
that the IETF has historically not consistently maintained this position.

Randy

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Michel Py]

Brian,

> Brian E Carpenter wrote:
> To be clear, I'd like to see exact proposed text before
> expressing support for the proposal. The trick is to get
> 6to4 disabled by default at the user end, without disabling
> it for users who are getting good service from it.

Although I commend Ron from trying "something else", I think this
particular approach is doomed to fail. Maybe I'm reading the list wrong,
but I think the sticky point here is the "historic" thing, and nothing
short of removing that part will significantly change the mindset of
people who oppose it.

Have you considered a newer revision of the 6-to-4 RFCs that would
obsolete the current ones and add that 6-to-4 should be disabled by
default? That could reach consensus.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Brian E Carpenter]

To be clear, I'd like to see exact proposed text before expressing
support for the proposal. The trick is to get 6to4 disabled by default
at the user end, without disabling it for users who are getting good
service from it.

Regards
   Brian

On 2011-07-26 09:49, Brian E Carpenter wrote:
>>  Likewise, operators will decide whether/when 6-to-4 relays will be removed 
>> from their networks.
> 
> This is, of course, an undeniable statement of fact (as it is for any other 
> feature
> of the Internet). However, it needs to be made clear that doing so 
> *prematurely*
> would penalise existing successful users of those relays, and therefore it 
> should
> only be done when there is no successful traffic through them. Which is when 
> any
> operator would remove them anyway.
> 
> Therefore, I don't see much value in this statement, and possible harm to 
> users.
> The ways to avoid such harm as far as possible are already in the RFC Editor
> queue.
> 
> Regards
>Brian Carpenter
> 
> On 2011-07-26 02:30, Ronald Bonica wrote:
>> Folks,
>>
>> After some discussion, the IESG is attempting to determine whether there is 
>> IETF consensus to do the following:
>>
>> - add a new section to draft-ietf-v6ops-6to4-to-historic
>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>>
>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
>> convert their status to HISTORIC. It will also contain a new section 
>> describing what it means for RFCs 3056 and 3068 to be classified as 
>> HISTORIC. The new section will say that:
>>
>> - 6-to-4 should not be configured by default on any implementation (hosts, 
>> cpe routers, other)
>> - vendors will decide whether/when 6-to-4 will be removed from 
>> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
>> will be removed from their networks. The status of RFCs 3056 and 3068 should 
>> not be interpreted as a recommendation to remove 6-to-4 at any particular 
>> time.
>>
>>
>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
>> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
>> a precedent for any future case.
>>
>> Please post your views on this course of action by August 8, 2011.
>>
>>
>>Ron Bonica
>>> as OPS Area AD>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>>
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Ted Faber]

On Mon, Jul 25, 2011 at 06:05:12PM -0400, Noel Chiappa wrote:
> > From: Ronald Bonica 
> 
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> > convert their status to HISTORIC. 
> 
> I think we should only mark things as HISTORIC as a recognition of _what has
> already happened_ out in the world, not as an attempt to _make something
> happen_.

What he said.
-- 
Ted Faber
http://www.isi.edu/~faber   PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


signature.asc
Description: Digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Cameron Byrne]

I approve of this approach.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Mark Andrews]

In message 
<22f6318e46e26b498abc828879b08d4f1d2...@tk5ex14mbxw651.wingroup.windeploy.ntdev.microsoft.com>,
 Christian Huitema writes
:
> > After some discussion, the IESG is attempting to determine whether there is 
> > IETF consensus to do the following:
> >
> > - add a new section to draft-ietf-v6ops-6to4-to-historic
> > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> >
> > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> > convert their status to HISTORIC. It will also contain >
>  a new section describing what it means for RFCs 3056 and 3068 to be 
> classified as HISTORIC. The new section will say that:
> 
> I do not think this is a good idea, and I am certainly not part of the 
> "consensus."

Seconded.
 
> -- Christian Huitema
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Christian Huitema]

> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
>
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
>
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain > a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:

I do not think this is a good idea, and I am certainly not part of the 
"consensus."

-- Christian Huitema


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Martin Rex]

Ronald Bonica wrote:
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. It will also contain a new section
> describing what it means for RFCs 3056 and 3068 to be classified
> as HISTORIC.

I'm strongly opposed.  Discussion is in the archives.

-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[John Leslie]

Ronald Bonica  wrote:
> 
> After some discussion, the IESG is attempting to determine whether
> there is IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL

   Clearly, this is an honest effort to make 6to4-to-historic closer to
where you think a consensus might be. I do appreciate the attempt...

   ... but it feels like wandering in the weeds. :^(

   We are suffering from many differing views of what "IETF consensus"
is. IMHO, any useful definition includes that anyone who disagrees with
the "consensus" statement agrees to shut up. They may shut up almost
immediately; they may shut up after some painful appeals process; or
worst, they may only pretend to shut up and keep bringing the issue
to mind again. This last, IMHO, doesn't deserve the name "consensus".

> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. It will also contain a new section
> describing what it means for RFCs 3056 and 3068 to be classified as
> HISTORIC. The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation
>   (hosts, cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from
>   implementations. Likewise, operators will decide whether/when
>   6-to-4 relays will be removed from their networks. The status of
>   RFCs 3056 and 3068 should not be interpreted as a recommendation
>   to remove 6-to-4 at any particular time.

   That's a funny definition of "historic"...
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> clarifies the meaning of "HISTORIC" in this particular case, it does
> not set a precedent for any future case.

   This _is_ reminiscent of what courts do when faced with a bad law.
But courts _don't_ have the option to not enact the law in the first
place. It _is_ for them the least-worst option.

> Please post your views on this course of action by August 8, 2011.

   Speaking for myself, this proposal accomplishes nothing useful.

   I actually have no particularly strong opinion on whether RFCs
3056 and 3068 deserve to be labeled "historic" at this time. I expect
they will deserve that label within a few years; but the label feels
"optimistic" at this time.

   What I _do_ have a strong opinion on is claiming in a published
RFC that we have IETF consensus to re-classify them. I do not believe
we have such consensus. I do not believe the IESG has followed a process
reasonably aimed at judging such consensus. I don't believe the IESG
even has consensus among themselves -- though if that were what the
boilerplate would claim, I wouldn't interfere.

   At some point, we need to be willing to say, "there is no consensus
at this time," and move on.

   I absolutely do not believe that reclassifying the two RFCs as
"historic" will accomplish what the proponents claim. (Neither do I
believe it would cause world-shattering harm.)

   As a general rule, I think reclassification of _anything_ to
"historic" shouldn't gate on IETF consensus -- it's just too hard.
Instead, I'd recommend some group like the IAB make the call, with
no claim to represent "consensus" of a body so large as the IETF.

   I am probably willing to shut up in any case; but I'd be a whole
lot happier if re-classification were an IAB decision. Barring that,
perhaps the RFC calling for re-classification could follow some path
which doesn't require boilerplate which claims to represent "IETF
Consensus"

   Or, the IESG could just let this document die.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Noel Chiappa]

> From: Ronald Bonica 

> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and
> convert their status to HISTORIC. 

I think we should only mark things as HISTORIC as a recognition of _what has
already happened_ out in the world, not as an attempt to _make something
happen_.

If we want to tell people to stop using a protocol, we should be direct and
produce a document that says 'this protocol should always be off by default',
or 'stop using this protocol', or 'remove this protocol from your products', or
whatever.

> While it clarifies the meaning of "HISTORIC" in this particular case, it
> does not set a precedent for any future case.

In other words, this document is doing something with "HISTORIC" that isn't the
normal, this is a special case. I think this is a bad idea.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Brian E Carpenter]

>  Likewise, operators will decide whether/when 6-to-4 relays will be removed 
> from their networks.

This is, of course, an undeniable statement of fact (as it is for any other 
feature
of the Internet). However, it needs to be made clear that doing so *prematurely*
would penalise existing successful users of those relays, and therefore it 
should
only be done when there is no successful traffic through them. Which is when any
operator would remove them anyway.

Therefore, I don't see much value in this statement, and possible harm to users.
The ways to avoid such harm as far as possible are already in the RFC Editor
queue.

Regards
   Brian Carpenter

On 2011-07-26 02:30, Ronald Bonica wrote:
> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>Ron Bonica
> as OPS Area AD>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic (yet again)

[Michel Py]

> Ronald Bonica wrote:
> After some discussion, the IESG is attempting to determine whether
> there is IETF consensus to do the following:
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL

Opposed. I will pass on details, as I don't think I have any wording to
contribute that has not already been discussed and re-discussed.

Michel.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Ole Troan]

I'm in favor of the proposed action and the clarification of historic, 
suggested in the new section.
(I could be in _strong_ favour to nullify Keith's 'vote', although I hope we're 
not counting. ;-)), .

cheers,
Ole

On Jul 25, 2011, at 10:30 , Ronald Bonica wrote:

> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>   Ron Bonica
>as OPS Area AD>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Michael Richardson]

> "Keith" == Keith Moore  writes:
Keith> I remain strongly opposed to reclassifying 6to4 as Historic
Keith> unless/until a better alternative appears.  Putting an
Keith> explanation inside an informational document doesn't change
Keith> that opposition.

+1
I note that multicast basically died when the mbone6 got decommissioned
too early.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Keith Moore]

I remain strongly opposed to reclassifying 6to4 as Historic unless/until a 
better alternative appears.  Putting an explanation inside an informational 
document doesn't change that opposition.

I also continue to believe that the -historic draft has too many misstatements 
and misleading statements in it, that the entire motivation for the draft is 
seriously flawed, and that it should not be published in anything like its 
current form.

But I agree that 6to4 should be off by default, mostly because there's no good 
off-the-shelf way to have 6to4 automatically disabled when a host or router 
connects to a network that is using NAT but not using RFC 1918 addresses.

Keith

On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote:

> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>   Ron Bonica
>as OPS Area AD>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic)

[Mohacsi Janos]

On Fri, 8 Jul 2011, Ole Troan wrote:


Keith,


The alternative that I proposed to IESG and to the chairs (and never received 
any feedback about) was to reclassify 6to4 as Experimental.   Experimental 
seems completely appropriate for a protocol that is useful, but only in corner 
cases.  And I think it's also appropriate and useful to try to learn from the 
experience with 6to4, even if we realize that 6to4 will never be a generally 
applicable IPv6 transition solution again.

And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 to mollify the 
"kill it yesterday" crowd.  For one thing, it clearly indicates that 6to4 is no longer a 
standard.

But in order to quieten down the discussion here, I suggest that people reply 
to me privately if they can't live with this.   If I get lots of those replies, 
I'll know that it's not worth pursuing.


"Experimental" is certainly better than:
- nothing
- spending months on hold as appeals are processed.


I proposed experimental also when discussion started about future of 6to4. 
I support the idea.

Best Regards,
Janos Mohacsi

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic)

[Turchanyi Geza]

+1

On Fri, Jul 8, 2011 at 11:13 AM, Mohacsi Janos  wrote:

>
>
>
> On Fri, 8 Jul 2011, Ole Troan wrote:
>
>  Keith,
>>
>>  The alternative that I proposed to IESG and to the chairs (and never
>>> received any feedback about) was to reclassify 6to4 as Experimental.
>>> Experimental seems completely appropriate for a protocol that is useful, but
>>> only in corner cases.  And I think it's also appropriate and useful to try
>>> to learn from the experience with 6to4, even if we realize that 6to4 will
>>> never be a generally applicable IPv6 transition solution again.
>>>
>>> And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 to
>>> mollify the "kill it yesterday" crowd.  For one thing, it clearly indicates
>>> that 6to4 is no longer a standard.
>>>
>>> But in order to quieten down the discussion here, I suggest that people
>>> reply to me privately if they can't live with this.   If I get lots of those
>>> replies, I'll know that it's not worth pursuing.
>>>
>>
>> "Experimental" is certainly better than:
>> - nothing
>> - spending months on hold as appeals are processed.
>>
>
> I proposed experimental also when discussion started about future of 6to4.
> I support the idea.
>Best Regards,
>Janos Mohacsi
>
>
> __**_
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/**listinfo/v6ops
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic

[Ole Troan]

Roger,

> Guess I should clearify something, the thing I am considering are to
> drop all 2002::/16 addresses hard, of course preferable return a
> correct error messages to.
> 
> wonder how many find 6to4 usable when ISPs start doing that? Nuclear
> winter or not may follow.

took me a while to warm up to PMT, but now I think that's a perfectly valid 
solution to rescue the set of innocent victims of 6to4.
http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

wouldn't be surprised if there already are commercial products that can do that.

cheers,
Ole


> 
> 
> 
> --- Roger J ---
> 
> On Sun, Jul 3, 2011 at 9:32 PM, Roger Jørgensen  wrote:
>> A bit late since this threat will be moderated soon. But I strongly object
>> to this delay of needed action.
>> 
>> I guess the other way the problem, which will hurt muchmuch more is maybe to
>> considering a filter of 6to4 on isp level?
>> I will suggest it when we start deploying native ipv6.
>> 
>> --- Roger J. ---
>> 
>> On Jul 2, 2011 6:39 PM, "Ronald Bonica"  wrote:
>>> Folks,
>>> 
>>> Whereas there has been considerable controversy regarding
>>> draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have
>>> agreed to the following course of action:
>>> 
>>> - the V6OPS WG will withdraw its request to publish
>>> draft-ietf-v6ops-6to4-to-historic
>>> - The author will introduce a new draft, intended for standards track
>>> publication. The new draft will update RFCs 3056 and 3068. It will say that
>>> if 6-to-4 is implemented, it must be turned off by default.
>>> - In order for the new draft to be published, it must achieve both V6OPS
>>> WG and IETF consensus
>>> 
>>> If anyone objects to this course of action, please speak up soon.
>>> 
>>> Ron
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 
> 
> 
> -- 
> 
> Roger Jorgensen   |
> rog...@gmail.com  | - IPv6 is The Key!
> http://www.jorgensen.no   | ro...@jorgensen.no
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic

[Roger Jørgensen]

Guess I should clearify something, the thing I am considering are to
drop all 2002::/16 addresses hard, of course preferable return a
correct error messages to.

wonder how many find 6to4 usable when ISPs start doing that? Nuclear
winter or not may follow.



--- Roger J ---

On Sun, Jul 3, 2011 at 9:32 PM, Roger Jørgensen  wrote:
> A bit late since this threat will be moderated soon. But I strongly object
> to this delay of needed action.
>
> I guess the other way the problem, which will hurt muchmuch more is maybe to
> considering a filter of 6to4 on isp level?
> I will suggest it when we start deploying native ipv6.
>
> --- Roger J. ---
>
> On Jul 2, 2011 6:39 PM, "Ronald Bonica"  wrote:
>> Folks,
>>
>> Whereas there has been considerable controversy regarding
>> draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have
>> agreed to the following course of action:
>>
>> - the V6OPS WG will withdraw its request to publish
>> draft-ietf-v6ops-6to4-to-historic
>> - The author will introduce a new draft, intended for standards track
>> publication. The new draft will update RFCs 3056 and 3068. It will say that
>> if 6-to-4 is implemented, it must be turned off by default.
>> - In order for the new draft to be published, it must achieve both V6OPS
>> WG and IETF consensus
>>
>> If anyone objects to this course of action, please speak up soon.
>>
>> Ron
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>



-- 

Roger Jorgensen           |
rog...@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Ronald Bonica]

Noel,

I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through 
without running the process. I said that draft-ietf-v6ops-6to4-to-historic has 
made it all the way past IESG approval. There is an appeal on the table (at the 
WG level) questioning whether draft-ietf-v6ops-6to4-to-historic ever had WG 
consensus. We will run the appeal process. If the WG chairs cannot justify WG 
consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its tracks. If they 
can justify WG consensus, the appellant can escalate the appeal to the IESG 
(and to the IAB after that). If the appeal succeeds at any level, 
draft-ietf-v6ops-6to4-to-historic is not published.

   Ron


-Original Message-
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] 
Sent: Tuesday, July 05, 2011 10:44 AM
To: ietf@ietf.org; v6...@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: draft-ietf-v6ops-6to4-to-historic

> From: Ronald Bonica 

>>> I think that I get it. There is no IETF consensus regarding the
>>> compromise proposed below. ...

>> But there is no rough consensus to do that either.

> That is the claim of an appeal on the table. Let's run the appeal
> process and figure out whether that claim is valid.

Sorry, this makes no sense.

You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no
basic consensus in the IETF as a whole to do so - and your previous
declaration (on Saturday) basically accepted that there was no such basic
consensus (otherwise why withdraw the ID).

So now there is going to be a reversal, and the document is going to go ahead
- i.e. you must now be taking the position that there _is_ basic consensus in
the IETF (without which you could not proceed the ID).

The effect of this sort of thing on the reputation of I* should be obvious
to all.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Noel Chiappa]

> From: Ronald Bonica 

>>> I think that I get it. There is no IETF consensus regarding the
>>> compromise proposed below. ...

>> But there is no rough consensus to do that either.

> That is the claim of an appeal on the table. Let's run the appeal
> process and figure out whether that claim is valid.

Sorry, this makes no sense.

You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no
basic consensus in the IETF as a whole to do so - and your previous
declaration (on Saturday) basically accepted that there was no such basic
consensus (otherwise why withdraw the ID).

So now there is going to be a reversal, and the document is going to go ahead
- i.e. you must now be taking the position that there _is_ basic consensus in
the IETF (without which you could not proceed the ID).

The effect of this sort of thing on the reputation of I* should be obvious
to all.

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Ronald Bonica]

Comments inline

-Original Message-
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] 
Sent: Sunday, July 03, 2011 5:29 PM
To: ietf@ietf.org; v6...@ietf.org
Cc: j...@mercury.lcs.mit.edu
Subject: RE: draft-ietf-v6ops-6to4-to-historic

> From: Ronald Bonica 

> I think that I get it. There is no IETF consensus regarding the
> compromise proposed below. ...
> Right now, the only alternative that I see is to reintroduce
> draft-ietf-v6ops-6to4-to-historic 

But there is no rough consensus to do that either.

RB> That is the claim of an appeal on the table. Let's run the appeal process
RB> and figure out whether that claim is valid. We certainly aren't having any
RB> success reaching a decision on the mailing list.
RB>
RB>  Ron

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Noel Chiappa]

> From: Ronald Bonica 

> I think that I get it. There is no IETF consensus regarding the
> compromise proposed below. ...
> Right now, the only alternative that I see is to reintroduce
> draft-ietf-v6ops-6to4-to-historic 

But there is no rough consensus to do that either.

There is simply no IETF-wide agreement on _any_ action with regard to killing
off 6to4.

So the only possible response is the IETF's normal response when there is no
rough consensus on what to do, which is to defer any action.

At least, as has been pointed out, we have draft-ietf-v6ops-6to4-advisory,
which has already been OKs, and which, _if folllowed_, would alleviate most
of the problems.

Noel

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Ronald Bonica]

Folks,

I think that I get it. There is no IETF consensus regarding the compromise 
proposed below. So, at very least, we will have to abandon the compromise.

Right now, the only alternative that I see is to reintroduce 
draft-ietf-v6ops-6to4-to-historic and let the appeal process run its course. I 
hate to do this, because the appeals process can be an incredible time sync and 
distraction. If anybody sees another alternative, please propose it.

  Ron
  

P.S. This thread has generated over 100 messages in the last 28 hours. Let's 
all take two days to cool off and spend some time with our families.

-Original Message-
From: Ronald Bonica 
Sent: Saturday, July 02, 2011 12:36 PM
To: v6...@ietf.org; IETF Discussion
Subject: draft-ietf-v6ops-6to4-to-historic

Folks,

Whereas there has been considerable controversy regarding 
draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have 
agreed to the following course of action:

- the V6OPS WG will withdraw its request to publish 
draft-ietf-v6ops-6to4-to-historic
- The author will introduce a new draft, intended for standards track 
publication. The new draft will update RFCs 3056 and 3068. It will say that if 
6-to-4 is implemented, it must be turned off by default. 
- In order for the new draft to be published, it must achieve both V6OPS WG and 
IETF consensus

If anyone objects to this course of action, please speak up soon.

Ron

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-ietf-v6ops-6to4-to-historic

[Michel Py]

Subject to reading the not-available-yet text, I support this approach.
It appears to be reasonable political compromise.

Michel.


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Ronald Bonica
Sent: Saturday, July 02, 2011 9:36 AM
To: v6...@ietf.org; IETF Discussion
Subject: draft-ietf-v6ops-6to4-to-historic

Folks,

Whereas there has been considerable controversy regarding
draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author
have agreed to the following course of action:

- the V6OPS WG will withdraw its request to publish
draft-ietf-v6ops-6to4-to-historic
- The author will introduce a new draft, intended for standards track
publication. The new draft will update RFCs 3056 and 3068. It will say
that if 6-to-4 is implemented, it must be turned off by default. 
- In order for the new draft to be published, it must achieve both V6OPS
WG and IETF consensus

If anyone objects to this course of action, please speak up soon.

Ron

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic-05 (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

[Joel Jaeggli]

On Jun 26, 2011, at 10:49 AM, SM wrote:

> Hello,
> 
> The IANA IPv4/IPv6 Address Space registries currently have the following 
> status: RESERVED, LEGACY, ALLOCATED and UNALLOCATED.  Is IANA marking the 
> 192.88.99.0/24 prefix and 2002::/16 prefix as "deprecated" or is it using an 
> existing status?
> 
> BCP 153 lists 192.88.99.0/24 as allocated.  The IANA registry lists it as 
> "reserved".

The assumption (vis--a-vis the discussion in the wg on a or lack of sunset 
period (and there's a longish port of the thread on this)) is that the prefixs 
would remain in use for the for the forseeable future. there would therefore be 
no change required to the status of the  prefixes.

> According to the Writeup:
> 
> "This draft represents the intersection of those views -
>  rough consensus in the best possible meaning of the phrase."
> 
> Will the IESG be using the following text:
> 
>  "It has been approved for publication by the Internet
>   Engineering Steering Group (IESG)."
> 
> for the second paragraph of the "Status of This Memo"?
> 
> Regards,
> -sm
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf