RE: draft-ietf-v6ops-6to4-to-historic (yet again)
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 speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
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))
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))
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))
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))
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))
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 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: draft-ietf-v6ops-6to4-to-historic (yet again)
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 j...@apple.com 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)
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 rbon...@juniper.net To: ietf@ietf.org 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 speaking 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)
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)
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 speaking 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)
* 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
6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
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 networks and ULAs? 6to4 as defined by
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
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
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Thank you Keith for restating the problem. Keith == Keith Moore mo...@network-heretics.com 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 http://www.youtube.com/watch?v=kzx1ycLXQSE 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))
On Wed, Jul 27, 2011 at 14:18, Keith Moore mo...@network-heretics.comwrote: 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))
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: draft-ietf-v6ops-6to4-to-historic (yet again)
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 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)
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. AA 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: draft-ietf-v6ops-6to4-to-historic (yet again)
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 http://www.youtube.com/watch?v=kzx1ycLXQSE 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))
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 mo...@network-heretics.com 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 new with 6to4. It's inherently the case that having multiple addresses
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
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 mo...@network-heretics.com 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
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On Mon, Jul 25, 2011 at 4:30 PM, Ronald Bonica rbon...@juniper.net 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)
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)
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 speaking 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)
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. AA 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)
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 rbon...@juniper.net 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
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
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)
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)
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 rbon...@juniper.net To: ietf@ietf.org 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 speaking 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)
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 rbon...@juniper.net To: ietf@ietf.org 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 speaking 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)
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)
From: t.petch daedu...@btconnect.com 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)
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)
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)
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 rbon...@juniper.net To: ietf@ietf.org 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 speaking 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)
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 speaking 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)
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 j...@apple.com 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)
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 speaking 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)
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)
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 daedu...@btconnect.com 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)
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)
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 speaking 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)
Keith == Keith Moore mo...@network-heretics.com 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 http://www.youtube.com/watch?v=kzx1ycLXQSE 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)
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 speaking 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)
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)
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 speaking 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)
From: Ronald Bonica rbon...@juniper.net 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)
Ronald Bonica rbon...@juniper.net 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 j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
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)
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)
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)
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)
On Mon, Jul 25, 2011 at 06:05:12PM -0400, Noel Chiappa wrote: From: Ronald Bonica rbon...@juniper.net 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)
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 speaking 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)
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)
Hi - From: Noel Chiappa j...@mercury.lcs.mit.edu To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu 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)
26.07.2011 1:05, Noel Chiappa wrote: From: Ronald Bonicarbon...@juniper.net 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)
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 speaking 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
