Re: 6to4 to Experimental? (was: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic)
Keith, The alternative that I proposed to IESG and to the chairs (and never received any feedback about) was to reclassify 6to4 as Experimental. Experimental seems completely appropriate for a protocol that is useful, but only in corner cases. And I think it's also appropriate and useful to try to learn from the experience with 6to4, even if we realize that 6to4 will never be a generally applicable IPv6 transition solution again. And maybe, just maybe, Experimental will be enough of a slap at 6to4 to mollify the kill it yesterday crowd. For one thing, it clearly indicates that 6to4 is no longer a standard. But in order to quieten down the discussion here, I suggest that people reply to me privately if they can't live with this. If I get lots of those replies, I'll know that it's not worth pursuing. Experimental is certainly better than: - nothing - spending months on hold as appeals are processed. cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 8, 2011, at 3:16 AM, Roger Jørgensen wrote: Guess I should clearify something, the thing I am considering are to drop all 2002::/16 addresses hard, of course preferable return a correct error messages to. wonder how many find 6to4 usable when ISPs start doing that? Nuclear winter or not may follow. seems like that just exacerbates the problem for your own customers and for other operators. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Extremist-A should be to publish a 6to4 considered dangerous draft with lots of MUST NOT language. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 06 July 2011 23:50 To: Doug Barton Cc: v6...@ietf.org; ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Doug Barton wrote: On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
... or to use Randy's language, 6to4 considered caterpillar snot, but yes, that is what I was thinking that end of the spectrum looked like. Doug On 07/07/2011 01:30, Yoav Nir wrote: Extremist-A should be to publish a 6to4 considered dangerous draft with lots of MUST NOT language. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 06 July 2011 23:50 To: Doug Barton Cc: v6...@ietf.org; ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Doug Barton wrote: On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Just remember kids, disagreeing is not attacking. accusing them of attacking when all they're doing is disagreeing is an attack on them. don't assume people have no real world experience or responsibilities if they choose not to announce to the world their job title or their affiliations in their emails. ␄ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
The pain point is really the unnecessarily aggressive kill what we don't like move-to-historic action. if we killed everything i do not like, there would be lot fewer rfcs. :) what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 5, 2011, at 6:39 PM, Randy Bush wrote: what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame. By that I mean, I wrote up and circulated an Internet Draft to specify a phase-out plan for RFC 3056 and RFC 3068. I chose not to submit it when it was made clear to me that no such plan could be adopted as a working group item. On a related note, I much prefer Keith Moore's proposal to reclassify RFC 3056 and RFC 3068 as Experimental. -- 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: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/06/2011 09:45, james woodyatt wrote: Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame. ... as well it should. :) Meanwhile I have stated several times that I'd like it to be gone, completely, yesterday. I was however willing to accept historic as a reasonable compromise. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Doug Barton wrote: Meanwhile I have stated several times that I'd like it to be gone, completely, yesterday. I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: Meanwhile I have stated several times that I'd like it to be gone, completely, yesterday. I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Doug Barton wrote: On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Wednesday, July 06, 2011 04:49:47 PM Martin Rex wrote: Doug Barton wrote: On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect I think I've read this entire thread and I don't recall anyone advocating extremist-B. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Scott Kitterman wrote: On Wednesday, July 06, 2011 04:49:47 PM Martin Rex wrote: Doug Barton wrote: On 07/06/2011 13:14, Martin Rex wrote: Doug Barton wrote: I was however willing to accept historic as a reasonable compromise. historic as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect I think I've read this entire thread and I don't recall anyone advocating extremist-B. Neither do I. The above just lists the entire spectrum of options for the IESG decision after the IETF LC for the two documents (6to4-advisory, 6to4-to-historic) had ended, and there was the unresolved procedural issue from IETF LC against 6to4-to-historic based on the protocol action of moving 3056,3068 to historic. An option to undo the past is not available to IESG, such as travelling back in time and preventing 3056 and 3068 from being developed. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Very well said Lorenzo. +1 Unless Ron describes exactly one by one real reasons to give up on draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with those reasons IMHO the document should proceed as is. It will say that if 6-to-4 is implemented, it must be turned off by default. Last ... if something is turned on or off by default is an implementation choice and last time I checked IETF was not in business to mandate any implementation choice. Thx, R. On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? Thx, R. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. Is there any summary of the IETF community consensus? I sort of can't imagine that ISPs want to continue operating 6to4 relays longer than strictly necessary. So I'm curious what the IETF community at large considers the future of 6to4 in it's default-disabled mode. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. perhaps that minority was also vocal in the back room But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) this is nutso. but this is normal. welcome to the ietf randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: We know it can operate correctly and reliably if it is configured correctly. ... and in networks where there are public IP addresses and no firewalling, and... etc. etc. But we already had this discussion on v6ops, and since the consensus of the WG was that the draft should be published, there's no point having it again. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.comwrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? that is usually determined when the iesg last calls the document after the wg has passed it to the iesg. the ipv6 heads are amazingly immune to reality. 6to4 has been measured and clearly demonstrated to have failed in the field. yes, it could work. but it doesn't. we need to get over it. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Section 1, in which the draft clarifies that 6rd supersedes 6to4,
which meets the qualification in the first paragraph of the Historic
term. With 6rd we clearly don't need to have anything built on top of
6to4 in the future, addressing the 2nd paragraph.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Yes, the Linksys E2000, E3000, E4200, WRT610N, and a small batch of Apple Airports had 6to4 on by default, but the latest firmware versions turn that off. Frank -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Saturday, July 02, 2011 3:26 PM To: rob...@raszuk.net Cc: v6...@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote: Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? I have understood that in the past there were a few routers that enabled 6to4 by default, though I don't know whether this is the case any longer. I also believe that there are currently hosts that enable 6to4 by default if there is no native v6 connectivity and the host has a public IPv4 address. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
1) as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot 2) perhaps that minority was also vocal in the back room 3) yes, but that will be a year from now. in the ietf, delay is one form of death Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. but then do we not draw the conclusion that therefore publishing draft-ietf-v6ops-6to4-to-disgusting is the correct approach? 2) While there was no back-room activity, an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. so these days people who do not get their way use the nuclear option? we raised kids. when those tactics resulted in we are so sorry you do not like the result, but that's the result they soon stopped. So, any way you look at it, there would be delays. welcome to the ietf, where process is our most important product. 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. so process this one in six weeks, please. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. the economic incentive to half-assed service providers is that it gives an excuse not to deploy ipv6. the response of these folk will be web pages instructing their users how to turn 6to4 on. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: I think there is pretty much complete consensus that i) 6to4 doesn't work in several very common environments (behind a NAT, etc, etc), and that therefore, ii) at the very least, it should be disabled by default (and therefore only turned on by knowledgeable users who know they are not in one of those situations). Given and assuming a document that makes all that formal, _what else_ does the _additional_ step of making 6to4 historic buy? Compared to the alternative of publishing 6to4-historic now, it: a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. I have personally seen this in beta home gateway products with new IPv6 firmware that aren't even released yet. b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. We have heard in the working group from real implementors like Apple, who have said that even 6to4-historic may not go far enough for them to justify actions such as removing support from their products. We have heard, also, that when implementors such as home gateway manufacturers are asked to remove 6to4 or disable it because it harms user experience, they say that they don't see why they should do work to remove a feature, in the absence of any guidance from the IETF. Time is important, because over time, 6to4's reliability will get worse, not better, as ISPs do things like use bogon IPv4 space plus carrier-grade NAT for their users, because implementations will think they have public IPv4 addresses and thus turn on 6to4 (which will never work, because it's behind a NAT). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy native IPv6, since it removes one way for users to get IPv6 if their provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to well so far.) Normal users will not get IPv6 unless their ISP gives it to them. Period, end of story. I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. For a normal user, having 6to4 is more a liability than an asset. Normal users don't rely on 6to4 to give them IPv6 connectivity, because they don't use or need IPv6; everything they do today can be done with higher performance and higher reliability using IPv4 and NAT traversal. However, if they get it for free in the form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity), they get something that only works 80% of the time, and 20% of the time breaks dual-stack websites. By users I explicitly do not include the tiny percentage of users on this list who are technical enough to know that 6to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhelming number of users who have no idea what IPv6 even is, they are so far away from the mainstream that they don't matter at all, and they are knowledgeable enough to deploy other solutions, such as managed tunnels, which in my experience are typically lower latency and higher reliability (pretty much everything is higher reliability than a 20% failure rate). The only way you can incentivize ISPs to deploy IPv6 is to provide IPv6 content that they can use to justify the investment (for example, reduce the load on the NATs that they will be deploying). ISPs have been saying for years, and are still saying, that one of the reasons tha they are not deploying IPv6 because there is no point, since so little content is available over IPv6. Now we are hearing clearly from content providers that they *do not want* 6to4, because its 80% failure rate is a concern for them, and that in fact, its existence is one of the major barriers to lack of adoption on the part of content providers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.comwrote: And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published. So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs. They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works as well as IPv4) 80% of the time. Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. An update on that data would be useful. As I said before, our data on IPv6 brokenness did not change significantly after World IPv6 Day. Can you take that as a proxy that 6to4 has not improved? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user It works for me, so there's obviously no problem. When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken. We know it can operate correctly and reliably if it is configured correctly. But we also know that it's not configured correctly, to such an extent that it does not work at all in 20% of cases (Geoff's data). And we know of no reason why that would improve, though we do know of reasons why it would get worse (e.g., due to ISPs giving bogon public space to their users). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic From: Keith Moore mo...@network-heretics.com Date: Sat, 2 Jul 2011 23:10:47 -0400 To: Cameron Byrne cb.li...@gmail.com CC: v6...@ietf.org v6...@ietf.org, IETF Discussion ietf@ietf.org Precedence: list MIME-Version: 1.0 (Apple Message framework v1084) References: 13205c286662de4387d9af3ac30ef456d3f3507...@embx01-wf.jnpr.net CAKD1Yr2Smvm0RY5iV2y06wD=rrz-uw4vbaaairnoaksr7zl...@mail.gmail.com banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com In-Reply-To: banlktimprdnqkc1xtafskkoo5dcx3gc...@mail.gmail.com Message-ID: e817a524-9db7-4553-a76f-25a9907e7...@network-heretics.com Content-Type: multipart/alternative; boundary=Apple-Mail-111-642965515 Message: 2 I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. Keith Many people have many more requirements. For example, an SLA for availability and latency, low support costs, firewall security, DSCP quality of service, ability to log end point communications, intrusion detection, WAN acceleration, a deployment model that does not rely on allocating even more IPv4 addresses (that many don't have or won't have) or the good nature of other providers to provide a working relay ... 6to4 fails to meet many of those requirements. Granted, it isn't the only transition mechanism that fails to do so. IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. Having said all that, 6to4 has also caused me issues with traffic predictability, and cost significant engineering time. Turning 6to4 off by default would not be the ideal solution in my view, but it should address many if not all of my own particular issues. If that's all that's on offer, I'll take it. regards, RayH ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? That's not how it works. You have to get consensus in IETF, not in v6ops. when it is last called. and you can dos that mailing list then, and threaten, and bluster. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: Some of them were posted to the IETF list. IESG may have received others privately. That is permitted by our process. This is a frustrating conversation. Everybody who supported the consensus in v6ops is an IETF participant, and their wishes count toward the IETF consensus. The draft is good. It encourages people to do the right things: keep 6to4 relays active, but not ship products with 6to4 enabled by default. This works for everyone—for people like me who are using 6to4 for our IPv6 connectivity, it works because the relays stay up. For people who do not have global IPv4 addresses, they do not wind up with IPv6 routes that go nowhere. It certainly serves Keith Moore's needs, no matter how vehemently, nor how often, he may insist that it does not. So this really does look like another IETF night of long knives, where a good draft gets scuttled in secret because a few very loud people manage to create enough of a fuss to make the person or persons calling the consensus feel like they're going to get fricasseed if they call the consensus in favor of the draft. Have we actually had a formal consensus call for the IETF? Who called the consensus? Can we have a summary? I haven't seen one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? regards RayH, ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Discussion isn't evidence, as people usually don't post any data to support their assertions. And yet, they did. This whole thing is getting silly, and I'm tired of repeating myself. I think Lorenzo did a great job of explaining some more of the downsides of 6to4 and I don't have anything useful to add beyond what I've already said. geoff's presos show the 6to4 train wreck pretty clearly. and it ain't pretty. yes, a few geeks such as rob austein, keith moore, ... who desperately want to test ipv6 can manage to get it working. big whoopie doo. it is a disaster for a significant percentage of the end users. it needs to be stopped. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi, On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). Gert Doering -- Operator -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. This time bomb has been defused mostly because most operating system now prefer any kind of IPv4 over a 6to4 address. So once again people can have a broken 6to4 setup without noticing it. What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. So we may end up with a sizable group people who have an IPv6 setup that completely doesn't work. And they don't know it. Which will create all kinds of headaches for IPv6-only content because you have to explain to users that yes, they have an IPv6 address and no, it is not going to work. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). -as On 3 Jul 2011, at 11:40, Keith Moore wrote: I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. why not? all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). It's clearly inappropriate for operators to be filtering protocol 41. Not only does this break 6to4, it also breaks other tunneling mechanisms. More generally, it's inappropriate for operators to be favoring one kind of traffic over another. Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4. The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. Call one not in the USA. China or India perhaps. -as ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 20:54:50 +0200 Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user and have been for many years (I just recently looked at the date in the script I wrote to bring it up, and was quite surprised it was dated 2002). Unfortunately people do judge books by their cover - if there is an RFC that says 6to4 is historic, people would likely consider it something that can't be used. We know it can operate correctly and reliably if it is configured correctly. If the criteria for declaring a technology historic is that some people can't operate it correctly and reliably, then they'll have to be plenty of other -historic RFCs. Perhaps declaring 6to4 deprecated rather than historic would have a better chance of consensus. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 12:21:36 -0700 Cameron Byrne cb.li...@gmail.com wrote: On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment Where is the evidence that 6to4 is holding back native IPv6 deployment? gets shouted down by a few people not involved in REAL ipv6 deployment. How do you know that? Welcome to the ietf indeed. Cb Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, 3 Jul 2011 10:10:03 +0900
Erik Kline e...@google.com wrote:
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 02 Jul 2011 19:44:24 -0700 Doug Barton do...@dougbarton.us wrote: On 07/02/2011 18:50, Mark Smith wrote: Where is the evidence that 6to4 is holding back native IPv6 deployment? It's been discussed ad nauseum in numerous fora. Discussion isn't evidence, as people usually don't post any data to support their assertions. Since posting that question I remembered RFC6036 - Emerging Service Provider Scenarios for IPv6 Deployment. Here's what is says about ISPs' views on 6to4. I don't think it supports the assertion that 6to4 is holding back native deployment - 2.5. IPv6 Technologies Turning to technology choices, the overwhelming choice of approach (94%) is a dual-stack routing backbone, and the reason given is simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, and 16% run or plan a Teredo server. Diffusions of Innovations discusses attributes of innovations that influence their adoption. One of those attributes is trialability, meaning how hard or easy is it to trial the innovation. If a innovation requires a high level of commitment to trial, then it is less likely to be trialed and therefore adopted. Once an residential ISP as IPv6 transit, 6to4 is a simple and much lower cost way of trialing IPv6 services and gaining experience with IPv6, before and during the development and deployment of native IPv6 services and the required supporting infrastructure, such as AAA, helpdesk training etc. Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. Bad 6to4 (which almost all of it is) results in a poor user experience when the largest content providers enable records. Thus, they are less inclined to enable them. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. So, in other words, Google now consider 6to4 to be reliable enough to continue to deliver content using it for one of their high profile content sites. I realize that there are a lot of people that dismiss both the evidence that's been put forward and the rationale, but it's been presented and discussed pretty thoroughly. In Geoff Huston's report (Dec 2010), he says that he measured a 13% failure rate with 6to4. A number of things have happened since then - IANA has run out of IPv4 addresses, and World IPv6 day. Those two events have increased the interest in IPv6 (the residential IPv6 trial I was working on gained more participants due to these events), which would have created an incentive for people to improve the quality of their 6to4 operation, or possibly deploy a trial 6to4 relay. An update on that data would be useful. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne cb.li...@gmail.com wrote: snip In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared historic, not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the pure mobile carriers that commonly don't. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, 2 Jul 2011 21:59:24 -0700 Joel Jaeggli joe...@bogus.com wrote: This line of discussion is not productive... Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... they don't have that and there's no-where to get it, then there's the rest of the world. That's now, but what about when they chose to implement IPv4 CGN, likely to be years ago. Cameron is choosing to blame 6to4 for a problem that any of the stateless and/or unidirectional Internet protocols could cause on a IPv4 CGN. His arguments to make 6to4 historic are not based on issues specific to 6to4. If 6to4 is made historic, does he then start lobbying for UDP-historic? On Jul 2, 2011, at 9:45 PM, Mark Smith wrote: On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne cb.li...@gmail.com wrote: snip In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared historic, not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the pure mobile carriers that commonly don't. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Totally agree. Regardless of my position on this specific draft, if it has been declared no consensus, now it not wise to go forward, declare consensus and accept the appeal. Credibility is first. Regards, Jordi -Mensaje original- De: Noel Chiappa j...@mercury.lcs.mit.edu Responder a: j...@mercury.lcs.mit.edu Fecha: Tue, 5 Jul 2011 10:44:29 -0400 (EDT) Para: ietf@ietf.org, v6...@ietf.org CC: j...@mercury.lcs.mit.edu Asunto: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic From: Ronald Bonica rbon...@juniper.net I think that I get it. There is no IETF consensus regarding the compromise proposed below. ... But there is no rough consensus to do that either. That is the claim of an appeal on the table. Let's run the appeal process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
I shudder to think that this is a prerequisite for declaring something Historic. If some RFC meant to solve some problem turns out not only to be a bad idea but also shows that the problem itself is essentially intractable, I don't think it's practical at all to require a replacement before declaring the RFC Historic. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Sunday, July 03, 2011 12:31 PM To: Arturo Servin Cc: IPv6 Operations; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Honestly I'd be happy to declare 6to4 Historic if we had a suitable replacement - one that could be automatically configured by hosts, used by applications, and worked better than 6to4 in most cases. I don't think it exists yet. [...] Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Gert Doering wrote: On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it There were more than two clearly opposing, and there is no need to further fuel the heated discussion by everyone becoming as vocal as Keith. The pain point is really the unnecessarily aggressive kill what we don't like move-to-historic action. This is a procedural issue, not a matter of personal taste. There was an alternative reclassification suggested, that could gather rough consensus. I'm still waiting for a *clean* resolution of the procedural issue (that means serious consideration of suggested alternatives). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Cameron Byrne wrote: That's not what it means to me. REAL IPv6 is a replacement for IPv4 and can address greater than 100s of billions of endpoint and is suitable for very large traffic loads. Then, port restricted IPv4 should be the real IPv6. Very long address of false IPv6 causes a lot of problems including performance ones. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:23 AM, Lorenzo Colitti wrote: I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. No, but they do want their applications to work well. That's constantly getting more difficult in IPv4. The workarounds for NATs and other forms of brain damage in the network keep changing, and each application requires not only its own code but also its own infrastructure to deal with that brain damage. So a solution that allows applications to use IPv6 whether or not all of the networks between the peers support native v6, is very badly needed. We can't wait for ISPs to give everybody IPv6 before applications start using it. And I agree that most users don't know what IPv6 is, at the moment. But if they learn that it will help their apps work better, they'll want it. (I also remember when most people didn't know what the Internet was. And then, almost in an instant, everybody knew, and a cartoon in the New Yorker magazine about the internet and a dog was something everybody could understand. Users will understand IPv6 also, soon enough.) Keith p.s. I often wear a t-shirt that says there's no place like ::1. Non-computer people ask me what it means, and in response, I tell them it's the address of their own machine in IPv6. So far, nobody has asked me what IPv6 means. Everyone who has asked me about the shirt has heard of IPv6 and understood at some level that it's the next version of the Internet. If anything, there seems to be a disconnect between what ordinary users know about IPv6 and what their ISPs are telling them - because for the most part, the ISPs seem to keep publicly pretending that it doesn't exist. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:53 AM, Lorenzo Colitti wrote: On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs. 6to4 allows applications to use IPv6 even when ISPs don't support it. The idea is to allow application deployment, and use of IPv6, to develop independently of ISP deployment of native IPv6. They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels. Uh, no. If you're an application developer, shipping code that requires every single user to set up a tunnel is a nonstarter. And as well all know, configured tunnels often route very suboptimally. In many cases 6to4 works better. It's not as if the only applications that matter are those that are layered over HTTP. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar. The only unfixable problem that 6to4 has is its inability to work with NATs, including LSN. Some of those fixes would require code updates to host implementations, but disabling 6to4 would also require code updates. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works as well as IPv4) 80% of the time. That figure is not based on a representative sample of all 6to4 use, so it's hard to know how much confidence to have in it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:58 AM, Lorenzo Colitti wrote: On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user It works for me, so there's obviously no problem. When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken. 6to4 used to be far less reliable than that, but has improved as additional relays were deployed. It's reasonable to expect that the publication of -advisory will improve the situation further. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 2:37 AM, Ted Lemon wrote: On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: Some of them were posted to the IETF list. IESG may have received others privately. That is permitted by our process. This is a frustrating conversation. Everybody who supported the consensus in v6ops is an IETF participant, and their wishes count toward the IETF consensus. Yes their wishes do count. But the consensus was marginal even in v6ops, and v6ops isn't representative of the breadth of interests in the entire IETF. It should hardly be surprising that a very rough consensus within a working group doesn't translate to a rough consensus within IETF as a whole. v6ops isn't special in this regard. The same is true for any other working group. Unfortunately, it's really easy for a working group that is focused on a particular set of concerns, to neglect concerns from the wider community. The draft is good. It encourages people to do the right things: keep 6to4 relays active, but not ship products with 6to4 enabled by default. This works for everyone—for people like me who are using 6to4 for our IPv6 connectivity, it works because the relays stay up. For people who do not have global IPv4 addresses, they do not wind up with IPv6 routes that go nowhere. It certainly serves Keith Moore's needs, no matter how vehemently, nor how often, he may insist that it does not. You are not in a good position to evaluate what I need. So this really does look like another IETF night of long knives, where a good draft gets scuttled in secret because a few very loud people manage to create enough of a fuss to make the person or persons calling the consensus feel like they're going to get fricasseed if they call the consensus in favor of the draft. No, it's not a good draft. It's misleading in many places. And the label of Historic is simply inappropriate for something that is still quite useful for many people and for which no good replacement yet exists. The right things that you refer to get obscured by the overall message of the Historic label. And the -advisory draft says the right things much better. Have we actually had a formal consensus call for the IETF? Who called the consensus? Can we have a summary? I haven't seen one. That's what the IETF Last Call was. IESG is supposed to evaluate consensus as well as technical merit in its balloting. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/02/2011 20:49, Mark Smith wrote: On Sat, 02 Jul 2011 19:44:24 -0700 Doug Bartondo...@dougbarton.us wrote: On 07/02/2011 18:50, Mark Smith wrote: Where is the evidence that 6to4 is holding back native IPv6 deployment? It's been discussed ad nauseum in numerous fora. Discussion isn't evidence, as people usually don't post any data to support their assertions. And yet, they did. This whole thing is getting silly, and I'm tired of repeating myself. I think Lorenzo did a great job of explaining some more of the downsides of 6to4 and I don't have anything useful to add beyond what I've already said. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
At 21:59 02-07-2011, Joel Jaeggli wrote: Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... they don't have that and there's no-where to get it, then there's the rest of the world. http://aboba.drizzlehosting.com/IAB/arin.txt Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 2:58 AM, Doug Barton wrote: On 07/02/2011 20:49, Mark Smith wrote: On Sat, 02 Jul 2011 19:44:24 -0700 Doug Bartondo...@dougbarton.us wrote: On 07/02/2011 18:50, Mark Smith wrote: Where is the evidence that 6to4 is holding back native IPv6 deployment? It's been discussed ad nauseum in numerous fora. Discussion isn't evidence, as people usually don't post any data to support their assertions. And yet, they did. I think it's been adequately supported that the interaction of 6to4 with (a) misconfigured relay routers and/or (b) protocol 41 filters, hinders one kind of native v6 deployment - i.e. providing the same content via both v4 and v6, where the client's host prefers v6 (including 6to4) destinations over v4 destinations. There's clearly a disincentive to a content provider to advertise v6 addresses for its domains, if use of those v6 addresses will result in significantly slower or less reliable access for any significant set of users. That much should be obvious. However, that's not the only kind of IPv6 deployment that matters. Meanwhile misconfigured relay routers can be fixed, or their advertisements filtered; and hosts can and should be updated to prefer IPv4 destinations over 6to4 destinations. 6to4, even when enabled, should be a last resort. All of these fixes should be implemented. But that last fix alone should address (no pun intended) the v4/v6 content providers' concerns while still preserving use of 6to4 for cases where IPv6 is really needed. And that last fix can be deployed much more quickly than the nuclear option of trying to get 6to4 support removed from products. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote: Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. Mostly. Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.Both 6to4 and NAT are things that are useful in some cases and cause harm in others. Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm. But it wan't a serious suggestion, just an analogy. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? I've already said on several occasions that I agree that 6to4 should be off by default. It's mostly the Historic label that I have the problem with. (I have other objections to the document also, but those are just places where I think the wording is misleading. The label is the big thing.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011 12:29 AM, Keith Moore mo...@network-heretics.com wrote: On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote: Keith Moore wrote: On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. Keith I'm presuming your second comment was facetious. Mostly. Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.Both 6to4 and NAT are things that are useful in some cases and cause harm in others. Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm. Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives. Cb But it wan't a serious suggestion, just an analogy. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? I've already said on several occasions that I agree that 6to4 should be off by default. It's mostly the Historic label that I have the problem with. (I have other objections to the document also, but those are just places where I think the wording is misleading. The label is the big thing.) Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 7:10 AM, Gert Doering wrote: On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. There were several people opposing it at Last Call - enough that no amount of emails in favor would result in rough consensus. What this is, is an attempt to railroad this through IETF without getting consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). In the real world, there are lots of people successfully using 6to4, and there's no good replacement for it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 8:32 AM, Cameron Byrne wrote: I'm presuming your second comment was facetious. Mostly. Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.Both 6to4 and NAT are things that are useful in some cases and cause harm in others. Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm. Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives. Note that the ONLY substantive thing we're arguing about here is the Historic label.I don't see any significant disagreement about the technical details. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 3:23 AM, Randy Bush wrote: geoff's presos show the 6to4 train wreck pretty clearly. and it ain't pretty. yes, a few geeks such as rob austein, keith moore, ... who desperately want to test ipv6 can manage to get it working. big whoopie doo. I don't understand the desire to dismiss applications developers or existing 6to4 users as a few geeks, but it's clearly a misrepresentation. it is a disaster for a significant percentage of the end users. it needs to be stopped. no, it needs to be fixed. and many of the fixes have nothing to do with 6to4 implementations, but rather, with operators. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From: Lorenzo Colitti lore...@google.com Compared to the alternative of publishing 6to4-historic now, it: a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. draft-ietf-v6ops-6to4-advisory - which already exists, and which nobody is objecting to - already contains text which tells manufacturers of both home routers and hosts to disable 6to4 by default, etc, etc. If acting ASAP is desirable, that ID could be approved just as quickly as draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated by the new document mentioned in the recent announcement). b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. First, killing 6to4 is an additional goal, above and beyond 'stop 6to4 from causing problems'. The only conceivable reason I can think of for that additional step seems to be the possibility that somehow 6to4 will cause problems anyway, even if it is normally disabled? This seems unlikely to me. Is there any reason beyond that to kill 6to4? Second, what reason is there to believe that a document that says 'remove 6to4' is going to meet with greater/faster compliance from vendors than a document that says 'disable it'? I would argue that the former takes more engineering time, and is actually marginally less likely to be timely responded to. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From: Doug Barton do...@dougbarton.us Bad 6to4 (which almost all of it is) draft-ietf-v6ops-6to4-advisory says: The experiment conducted by Aben recorded a failure rate of between 9% and 20% of all 6to4 connection attempts. The experiment conducted by Huston has recorded a failure rate of between 9% and 19% of all 6to4 clients. 20% != almost all of it. I realize that there are a lot of people that dismiss both the evidence that's been put forward This is again a complete misrepresentation of the actual situation. Please name _one_ person who thinks that automatically enabled 6to4 is not causing any problems. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote: In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 Saying that no new 6to4 installation should be deployed and that existing 6to4 users should migrate to other tunneling techniques assumes that all installations and users have the same needs, namely, to access content over IPv6 that is also available over IPv4. The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. The label broken 6to4 setup is misleading. Most of the time, the thing that breaks 6to4 is not the user's setup; it's an ISP somewhere that is either (a) advertising a bad relay or (b) filtering protocol 41. (If the problem were the users' setups, the providers could just say not our problem; fix your 6to4 setup) What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. From my understanding of bittorrent, it will just find other routes. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. You completely misunderstand both the situation, and the size and diversity of 6to4 users. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 10:07 AM, Noel Chiappa wrote: draft-ietf-v6ops-6to4-advisory - which already exists, and which nobody is objecting to - already contains text which tells manufacturers of both home routers and hosts to disable 6to4 by default, etc, etc. If acting ASAP is desirable, that ID could be approved just as quickly as draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated by the new document mentioned in the recent announcement). It's already been approved. The announcement went out on July 1. Though to be fair, the document is Informational rather than an update to a standards track document. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011 7:14 AM, Keith Moore mo...@network-heretics.com wrote: On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote: In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking on ipv4 ). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance. Thanks for your time and have a great weekend. Cb Saying that no new 6to4 installation should be deployed and that existing 6to4 users should migrate to other tunneling techniques assumes that all installations and users have the same needs, namely, to access content over IPv6 that is also available over IPv4. The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding records. In other words, it was ticking time bomb. The label broken 6to4 setup is misleading. Most of the time, the thing that breaks 6to4 is not the user's setup; it's an ISP somewhere that is either (a) advertising a bad relay or (b) filtering protocol 41. (If the problem were the users' setups, the providers could just say not our problem; fix your 6to4 setup) What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. From my understanding of bittorrent, it will just find other routes. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. You completely misunderstand both the situation, and the size and diversity of 6to4 users. Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote: I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. why not? all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges. Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking on ipv4 ). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance. and the attitude from v6ops reminds me of nothing so much as a lynch mob. it has gotten way out of hand. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 10:58 AM, Arturo Servin wrote: On 3 Jul 2011, at 11:40, Keith Moore wrote: I think this clearly illustrates why IETF should issue a strong statement that a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 You will not get consensus on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. why not? all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges. And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). It's clearly inappropriate for operators to be filtering protocol 41. Not only does this break 6to4, it also breaks other tunneling mechanisms. More generally, it's inappropriate for operators to be favoring one kind of traffic over another. The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. If the overriding concern is that imposition of LSN will break 6to4 even more and thus generate even more support calls, that's understandable. However: - LSN will break a lot more than 6to4, and generate support calls for many other reasons, and this shouldn't surprise anyone. - declaring 6to4 Historic will not reduce the number of support calls, while the above measures will. The most effective single measure that I can see to reduce the number of 6to4 support calls is to get OS vendors to patch their customers' systems to implement (e), and perhaps (d), ASAP. That shouldn't break 6to4 for anyone who is using it as a means of supporting IPv6 apps, and it should reduce the largest source of complaints both from users and content providers. (The reason I say perhaps (d) is that (d) would break those who are currently depending on 6to4. Off by default is perfectly appropriate for new installations, but not necessarily so for automatic updates.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 3 Jul 2011, at 12:10, Gert Doering wrote: On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). I'm with Gert, Lorenzo, Randy and others here. It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interest in IPv6 deployment takes part. Thus its view on IPv6 deployment practices should be given due regard. The opposition on the IETF list seemed to be a vocal minority, and of course one person seemed to post a disproportionate number of replies. The problems with 6to4 (20% minimum failure rate, and poor performance when it does connect) are well documented and have led to various 'counter measures' from the IETF, including: a) 6to4 off by default, as per 6to4-advisory b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented already) c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simplistic version is already in Chrome) Those measures indicate how bad a problem 6to4 creates. If we're going to the trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer include 6to4 support at all. I do agree however that the most important point is publishing the -advisory text. As a provider of a (not large) enterprise, I know that a fraction of 1% of connections to our site suffer a 10 second+ delay to a dual-stack web site where they suffer no delay to an IPv4-only one. There's no way to know for sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) should minimise that figure. Having said that, less than 1% of users who connect to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disappear in terms of loss of users, as those users could almost certainly still reach us over IPv4. Our own users who want IPv6 connectivity when offsite use tunnel brokers, which provide a much better (and more predictable) service, one that also works from behind a NAT, which in the reality of home, hotel, and other hotspot networks is quite important. As for operators 'fixing' 6to4, well, I'd rather see operators invest that effort in deploying IPv6, rather than making 6to4 work better, for some value of 'better'. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 12:09 PM, Tim Chown wrote: It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interest in IPv6 deployment takes part. That's simply false. For instance, both users and applications developers are drastically underrepresented in that group. The interests of operators are certainly important and should be given due regard, but they are not the only interests that need to be considered. Thus its view on IPv6 deployment practices should be given due regard. The opposition on the IETF list seemed to be a vocal minority, and of course one person seemed to post a disproportionate number of replies. One person's view should only be counted as one person's view, no matter how many messages he sends. And yet, when even one person speaks up for the interests of an under-represented group, the merit of his arguments should be considered. The reason we make decisions by consensus in IETF, rather than by voting, is that there's no way to have a representative sample of all interests. And yes, a vocal minority can be sufficient to cause IETF to fail to reach consensus. That's intentional. The problems with 6to4 (20% minimum failure rate, and poor performance when it does connect) are well documented and have led to various 'counter measures' from the IETF, including: a) 6to4 off by default, as per 6to4-advisory b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented already) c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simplistic version is already in Chrome) Those measures indicate how bad a problem 6to4 creates. False. The problems associated with 6to4 were not created by 6to4; they were created by dubious operational practices. But I note that all of the counter measures you cite are widely agreed on and well on their way to being reality.Making 6to4 Historic in addition to these will not help; it will only hurt users who are successfully using it now. If we're going to the trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer include 6to4 support at all. In other words, it's an attempt to sabotage 6to4 for those who are currently successfully using it, and without giving them a viable replacement. It's an attempt to shift the pain from the operators to the users, for problems that were mostly caused by operators. As for operators 'fixing' 6to4, well, I'd rather see operators invest that effort in deploying IPv6, rather than making 6to4 work better, for some value of 'better'. 6to4 might need fixing, but it's not up to operators to fix it.I think it's just fine if operators do things that they should normally be doing, i.e.: make a best effort to deliver all traffic (including protocol 41); make sure that routers work properly; make sure that route advertisements are accurate. Of course, if 6to4 could be replaced with something better, that would be a win for everyone. For operators, I think that means deploying some form of v6 concurrently with LSN. But I don't think the net can afford to trust that all operators will do this. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 15:21, Cameron Byrne cb.li...@gmail.com wrote: On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment. As a member of that small but vocal minority I think you are being a little unfair here; some of us are working quite hard in getting IPv6 deployed in a number of different places. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. And, FWIW, I have no objections to having it off by default. In fact, I welcome that. /TJ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 3:17 PM, Arturo Servin wrote: And b. And probably it is too much effort for something that will go away (probably sooner that we expect) with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does not work with NATs, and they are here). It's clearly inappropriate for operators to be filtering protocol 41. Not only does this break 6to4, it also breaks other tunneling mechanisms. More generally, it's inappropriate for operators to be favoring one kind of traffic over another. Many corporate networks filter them because security concerns (I am not saying that is right or wrong, it just happens and it breaks 6to4). They won't change their mind because 6to4. Fair enough. (It bothers me when ISPs filter them, but I consider it within the rights of an enterprise network to do that. What an enterprise does with its own traffic should be its own business, and they can benefit and/or suffer from the consequences of their choices. Though I do think that there are probably better ways to handle the (legitimate) security concerns than to merely filter protocol 41. e.g. ICMP unreachable.) And of course protocol 41 becomes problematic for those behind a NAT of any kind, including LSN.(I do see LSN as best effort delivery; it's just that the state of the the network has made best pretty sad these days.) So if we were able to omit or finesse considerations (b) and (c) could we get consensus around the remaining items in that list? The ISPs I've talked to tell me that they see no reason why static, public IPv4 addresses cannot continue to be given to those that request them, indefinitely, as long as they're paying for business service. Call one not in the USA. China or India perhaps. I'll take your word for it. 6to4 is only going to work in corner cases, and those corners are somewhat defined by geography. Honestly I'd be happy to declare 6to4 Historic if we had a suitable replacement - one that could be automatically configured by hosts, used by applications, and worked better than 6to4 in most cases. I don't think it exists yet. (That oft-touted 80% reliability figure needs to be compared with similar figures for other methods, along with the realization that manual configuration, lack of platform support, congestion at heavily-used tunnel endpoints, are all significant sources of failure. Note that you can't measure this by looking only at traffic in the network. And for those who insist that all v6 traffic should be native, note that from the perspective of an application developer, there is close to a 0% reliability for this at present. 80% is a huge improvement over that, though still not good enough.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
In message EMEW3|9c8bf9e7fa0e59322f84c8ec6df2b8b9n62HAg03tjc|ecs.soton.ac.uk|0 4b2cf82-78ec-4a2b-a681-7710e3efc...@ecs.soton.ac.uk, Tim Chown writes: On 3 Jul 2011, at 12:10, Gert Doering wrote: On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). I'm with Gert, Lorenzo, Randy and others here. It seemed that both the -advisory and -historic drafts had strong support in v6ops, which isn't just any WG, it's the WG that anyone with a vested interes t in IPv6 deployment takes part. Thus its view on IPv6 deployment practices should be given due regard. The opposition on the IETF list seemed to be a v ocal minority, and of course one person seemed to post a disproportionate num ber of replies. The problems with 6to4 (20% minimum failure rate, and poor performance when i t does connect) are well documented and have led to various 'counter measures ' from the IETF, including: a) 6to4 off by default, as per 6to4-advisory b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemente d already) c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simp listic version is already in Chrome) Those measures indicate how bad a problem 6to4 creates. No. The 20% connect failure rate shows how bad AUTOMATIC 6to4 is. It show NOTHING about how bad 6to4 itself is. As for longer RTT that is something people accept as part of using 6to4. I know I accept that they are there for the trans Pacific tunnel I use. As for high failure rates. EDNS (RFC 2671) had/has a similar or higher failure rates with any UDP packets that are bigger that 512 bytes or UDP packets that get fragmented or packets that have a OPT record in the additional section or have DO (RFC 3225) set in the OPT record. Firewalls are a pain in the proverbial but we don't stop attempting to use EDNS because they are there. Nameservers tailor their queries to to work around firewalls (happy eyeballs) and log that they needed to use the workarounds. If we're going to th e trouble of coming up with all these measures, there seems to be a good case for 6to4 to Historic, which would be a steer to implementors to no longer in clude 6to4 support at all. I do agree however that the most important point is publishing the -advisory text. As for the counter measures, some of them need to be there independently of 6to4. Google Chome was the only brower that could reach www.ietf.org in a timely manner from any dual stack client connecting via Hurricane Electric for half of last week. The noc @HE responded to the issue within 1/2 a hour of it being raised via email by raising a trouble ticket with ATT. It still took 2-3 days for the problem to be fixed. As a provider of a (not large) enterprise, I know that a fraction of 1% of co nnections to our site suffer a 10 second+ delay to a dual-stack web site wher e they suffer no delay to an IPv4-only one. Which for the most part wouldn't be there if 6to4 required explicit configuration. There's no way to know for sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) sh ould minimise that figure. Having said that, less than 1% of users who conne ct to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disa ppear in terms of loss of users, as those users could almost certainly still reach us over IPv4. Our own users who want IPv6 connectivity when offsite us e tunnel brokers, which provide a much better (and more predictable) service, one that also works from behind a NAT, which in the reality of home, hotel, and other hotspot networks is quite important. As for operators 'fixing' 6to4, well, I'd rather see operators invest that ef fort in deploying IPv6, rather than making 6to4 work better, for some value o f 'better'. The fixes for 6to4 are deploying suitable sized 6to4 relay boxes and removing protocol 41 filters once the isp has some IPv6 connectivity. The time and effort required to do this is minimal compared to the time and effort required to deploy IPv6 to all of its customers. Remember you don't need to bill for this as the billing is already taken care of with IPv4. You don't need to do address assignments as they are taken care of with IPv4. Tim ___ Ietf mailing list Ietf@ietf.org
6to4 to Experimental? (was: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic)
On Jul 3, 2011, at 4:57 PM, Ronald Bonica wrote: Folks, I think that I get it. There is no IETF consensus regarding the compromise proposed below. So, at very least, we will have to abandon the compromise. Right now, the only alternative that I see is to reintroduce draft-ietf-v6ops-6to4-to-historic and let the appeal process run its course. I hate to do this, because the appeals process can be an incredible time sync and distraction. If anybody sees another alternative, please propose it. Ron speaking as AD The alternative that I proposed to IESG and to the chairs (and never received any feedback about) was to reclassify 6to4 as Experimental. Experimental seems completely appropriate for a protocol that is useful, but only in corner cases. And I think it's also appropriate and useful to try to learn from the experience with 6to4, even if we realize that 6to4 will never be a generally applicable IPv6 transition solution again. And maybe, just maybe, Experimental will be enough of a slap at 6to4 to mollify the kill it yesterday crowd. For one thing, it clearly indicates that 6to4 is no longer a standard. But in order to quieten down the discussion here, I suggest that people reply to me privately if they can't live with this. If I get lots of those replies, I'll know that it's not worth pursuing. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment. Welcome to the ietf indeed. Cb Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. I hope that the author(s) of the new document and the v6ops WG will understand that their task is to craft a document that can earn community-wide consensus, not merely the approval of v6ops. As long as the document is brief and to-the-point, I don't see any problem. I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote: Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? I have understood that in the past there were a few routers that enabled 6to4 by default, though I don't know whether this is the case any longer. I also believe that there are currently hosts that enable 6to4 by default if there is no native v6 connectivity and the host has a public IPv4 address. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/02/2011 12:21, Cameron Byrne wrote: On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com mailto:lore...@google.com wrote: On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment. I can't speak to the REAL bit, but I agree that this is a very disappointing turn of events. Consensus is not the same as universal agreement, and I don't think the fact that a few people are repeating the same marginally-relevant-at-best points over and over again should have sidetracked this process. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Lorenzo, You pose very reasonable questions. I will try to reiterate them: 1) What are the criteria for determining consensus? What makes you think that there was no consensus on 6-to-4-historic? 2) What makes you think that the new draft is just as good? 3) What makes you think that the new draft will do any better than 6-to-4-historic? Responses follow: 1) Because we do not vote in the IETF, the process for determining consensus is squishy. A simple majority does not win the day. A few strongly held objections backed by even a scintilla of technical rational can increase the size of the super-majority required to declare consensus. While it was not clear that the IETF has achieved consensus regarding 6-to-4-historic, it also was not clear that the IETF had not achieved consensus. In this case, we had a choice between spending cycles arguing about consensus, or finding a solution that everybody could live with. 2) IMHO, the new draft will not be as good as 6-to-4-historic. However, it solves the operational problem by disabling 6-to-4 by default. That's much better than nothing. 3) I have been working behind the scenes with a few of those who objected to 6-to-4-historic. They didn't object to the new draft. However, I invite those people to speak for themselves. Ron From: Lorenzo Colitti [mailto:lore...@google.com] Sent: Saturday, July 02, 2011 2:55 PM To: Ronald Bonica Cc: v6...@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.netmailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/02/2011 19:22, Ronald Bonica wrote: 1)Because we do not vote in the IETF, the process for determining consensus is squishy. A simple majority does not win the day. A few strongly held objections backed by even a scintilla of technical rational can increase the size of the super-majority required to declare consensus. While it was not clear that the IETF has achieved consensus regarding 6-to-4-historic, it also was not clear that the IETF had not achieved consensus. In this case, we had a choice between spending cycles arguing about consensus, or finding a solution that everybody could live with. IMO that is the wrong goal. Consensus does not mean universal agreement. Trying to get a solution that everybody could live with all too often results in a product with no operational value. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/02/2011 18:50, Mark Smith wrote: Where is the evidence that 6to4 is holding back native IPv6 deployment? It's been discussed ad nauseum in numerous fora. Bad 6to4 (which almost all of it is) results in a poor user experience when the largest content providers enable records. Thus, they are less inclined to enable them. I realize that there are a lot of people that dismiss both the evidence that's been put forward and the rationale, but it's been presented and discussed pretty thoroughly. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From: Cameron Byrne cb.li...@gmail.com It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down So, perhaps you can explain something to me, since nobody else has been able to. I think there is pretty much complete consensus that i) 6to4 doesn't work in several very common environments (behind a NAT, etc, etc), and that therefore, ii) at the very least, it should be disabled by default (and therefore only turned on by knowledgeable users who know they are not in one of those situations). Given and assuming a document that makes all that formal, _what else_ does the _additional_ step of making 6to4 historic buy? Are you thinking that people will see this knob called '6to4' and turn it on, and cause support issues? This seems unlikely to me - e.g. they don't seem to commonly turn off DHCP on their NAT boxes (a switch most NAT boxes seem to provide). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy native IPv6, since it removes one way for users to get IPv6 if their provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to well so far.) In short, I just cannot fathom what concrete benefit the _additional_ step of marking the protocol 'historic' provides, _over and above_ just issuing the 'do not enable 6to4 automatically because it has problems' document. Can you point to such a benefit? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 7/2/11 6:39 PM, Doug Barton wrote: IMO that is the wrong goal. Consensus does not mean universal agreement. Trying to get a solution that everybody could live with all too often results in a product with no operational value. Everybody can live with is pretty much the universal operating definition of consensus in organizations that use consensus decision-making. I've got some concerns, as well, that effort is being put into technologies that there's no incentive to use, but in terms of *process* Ron is spot-on. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 9:10 PM, Lorenzo Colitti wrote: On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.com wrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 10:00 PM, Erik Kline wrote: Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being declared historic also mean that 6rd needs to become historic as well? http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 Section 1, in which the draft clarifies that 6rd supersedes 6to4, which is of course completely incorrect. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 10:39 PM, Doug Barton wrote: On 07/02/2011 19:22, Ronald Bonica wrote: 1)Because we do not vote in the IETF, the process for determining consensus is squishy. A simple majority does not win the day. A few strongly held objections backed by even a scintilla of technical rational can increase the size of the super-majority required to declare consensus. While it was not clear that the IETF has achieved consensus regarding 6-to-4-historic, it also was not clear that the IETF had not achieved consensus. In this case, we had a choice between spending cycles arguing about consensus, or finding a solution that everybody could live with. IMO that is the wrong goal. Consensus does not mean universal agreement. Trying to get a solution that everybody could live with all too often results in a product with no operational value. IMO you're thinking about this the wrong way. if a document is to be published with IETF's imprimatur, it needs to adhere to IETF's rules. Those rules require, for a standards action, at least rough community-wide consensus. When a narrowly focused working group declares consensus within itself, that clearly doesn't speak for the whole IETF. The fact that the consensus was quite rough even within the v6ops group should have been understood as a sign that the proposed action might not win consensus overall - especially given that several of the objections came from non-operators who are not well represented in v6ops. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] draft-ietf-v6ops-6to4-to-historic
Randy, You have three points that deserve to be addressed. These are: 1) as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot 2) perhaps that minority was also vocal in the back room 3) yes, but that will be a year from now. in the ietf, delay is one form of death Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. 2) While there was no back-room activity, an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays. 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. Comments? Ron -Original Message- From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Randy Bush Sent: Saturday, July 02, 2011 5:35 PM To: Lorenzo Colitti Cc: IPv6 Ops WG; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. perhaps that minority was also vocal in the back room But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) this is nutso. but this is normal. welcome to the ietf randy ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 2, 2011, at 8:14 PM, Keith Moore wrote: On Jul 2, 2011, at 10:00 PM, Erik Kline wrote: Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being declared historic also mean that 6rd needs to become historic as well? http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 Section 1, in which the draft clarifies that 6rd supersedes 6to4, which is of course completely incorrect. While 6rd shares a mechanism with 6 to 4 and can be implemented by reusing code, it is a mistake to conclude a standards action that impacts the later would impact the former, or that they are substitutable for each other. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. That's not what it means to me. REAL IPv6 is a replacement for IPv4 and can address greater than 100s of billions of endpoint and is suitable for very large traffic loads. As an access network provider, i need content on native IPv6. It does not make sense to anyone in my organization or industry to deploy IPv6 unilaterally. There is no benefit in this approach vs just doing NAT444. If there is IPv6 content on a meaningful scale ( by the numbers that means for my network: Google, Facebook, Yahoo and their CDNs ...), then i have a solid business case for IPv6 access networks. Full Stop. If the content guys say 6to4 is a pain, and they do, then i need to help them find a way to solve that pain. I operate in an address exhausted world, so NAT44 is my only IPv4 tool for growth. In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On 07/02/2011 20:31, Ronald Bonica wrote: Randy, You have three points that deserve to be addressed. These are: 1) as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot 2) perhaps that minority was also vocal in the back room 3) yes, but that will be a year from now. in the ietf, delay is one form of death Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. 2) While there was no back-room activity, You yourself mentioned that you were in private discussion with some who objected to the historic draft. There's nothing wrong with that, it's how the world works, and personally I would expect it of you. But please don't then turn around and say that it's not happening. :) an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays. 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. Speaking for myself, my goal is not to take STF off the Internet. My goal is to do everything we can to get the best possible IPv6 deployed in the most places as fast as possible. STF is a hindrance to that goal, so I'd like it to go away. As I've said in the past, I was in the extreme wing of the WG that would have preferred to that we came down on the turn it off, yesterday side. So can I accept off by default on the client side as a step in the right direction? Sure, why not. But as others have pointed out the difference between that and historic is that the latter gives vendors active DIScouragement to support it at all. IMO that would be better. Much better. Hope I answered your question, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 12:02 AM, Cameron Byrne wrote: On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs. 6to4 certainly qualifies. That's not what it means to me. REAL IPv6 is a replacement for IPv4 and can address greater than 100s of billions of endpoint and is suitable for very large traffic loads. As an access network provider, i need content on native IPv6. It does not make sense to anyone in my organization or industry to deploy IPv6 unilaterally. There is no benefit in this approach vs just doing NAT444. If there is IPv6 content on a meaningful scale ( by the numbers that means for my network: Google, Facebook, Yahoo and their CDNs ...), then i have a solid business case for IPv6 access networks. Full Stop. Chicken-and-egg. You can't justify widespread deployment of IPv6 until there are a lot of content/people/applications using it, and there won't be a lot of content/people/applications using it until it's widely available. The whole purpose of mechanisms like 6to4 is to help break that logjam. We need to fix the existing mechanisms, and/or provide better ones, rather than killing things that work... even if they only work in corner cases. (Basing the argument entirely on content, IMO, is misguided, because it neglects significant potential drivers of IPv6 adoption, and because there's still no incentive to move to v6 as long as the same content is available on v4.) If the content guys say 6to4 is a pain, and they do, then i need to help them find a way to solve that pain. So you want to help the content guys at the expense of other legitimate uses of 6to4. Frankly, I don't think that's reasonable. The net doesn't exist just for content delivery. In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. So you admit you're sabotaging the network? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 12:26 AM, Doug Barton wrote: Speaking for myself, my goal is not to take STF off the Internet. My goal is to do everything we can to get the best possible IPv6 deployed in the most places as fast as possible. STF is a hindrance to that goal, so I'd like it to go away. STF is also helping that goal. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
This line of discussion is not productive... Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... they don't have that and there's no-where to get it, then there's the rest of the world. On Jul 2, 2011, at 9:45 PM, Mark Smith wrote: On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne cb.li...@gmail.com wrote: snip In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. My next step is filtering over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared historic, not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the pure mobile carriers that commonly don't. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 I look forward to that discussion on ietf@ Cameron Keith ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 3, 2011, at 1:29 AM, Lorenzo Colitti wrote: On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.com wrote: And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? That's not how it works. You have to get consensus in IETF, not in v6ops. (And it doesn't matter what you think of other people's reasons to oppose -historic.) If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published. Your logic is flawed. When you separately sample two dissimilar groups it isn't statistically valid to combine the two samples. The correct way to think about it is that the consensus was very rough already in v6ops (even the official writeup says so), and it only moved further away from rough consensus when the comments from outside of v6ops were taken into account. I agree that the people who objected on v6ops and also objected on the ietf list shouldn't be counted twice as opposing the standards action. But when I did the tally, I found only a small amount of overlap between people opposing -historic in v6ops, and people opposing it on the ietf list. So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them? Some of them were posted to the IETF list. IESG may have received others privately. That is permitted by our process. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
