Re: Another look at 6to4 (and other IPv6 transition issues)
On 07/20/11 01:24, Sabahattin Gucukoglu wrote: On 20 Jul 2011, at 00:34, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. The idea that moving a standard to Historic would take away the ability of people to use it reminds me of the story from the Norwegian army, approx 1939: - If the enemy invades, how will you prevent them from using the train network? - Burn all the tickets, sir! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
--On Thursday, July 21, 2011 11:40 +0200 Harald Alvestrand har...@alvestrand.no wrote: ... Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. The idea that moving a standard to Historic would take away the ability of people to use it reminds me of the story from the Norwegian army, approx 1939: - If the enemy invades, how will you prevent them from using the train network? - Burn all the tickets, sir! I like this analogy. The proposed action would have no effect whatsoever on the behavior that one is trying to discourage. But the move makes the party recommending the action look ridiculous, ridiculous enough that the story of the recommendation is still being told move than 70 years later. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
In message c125cd63e1264e518a4c7...@pst.jck.com, John C Klensin writes: --On Thursday, July 21, 2011 11:40 +0200 Harald Alvestrand har...@alvestrand.no wrote: ... Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. The idea that moving a standard to Historic would take away the ability of people to use it reminds me of the story from the Norwegian army, approx 1939: - If the enemy invades, how will you prevent them from using the train network? - Burn all the tickets, sir! I like this analogy. The proposed action would have no effect whatsoever on the behavior that one is trying to discourage. But the move makes the party recommending the action look ridiculous, ridiculous enough that the story of the recommendation is still being told move than 70 years later. john Except there are vendors who have already threatened to remove the 6to4 code if it is declared historic then you are left between a rock and a hard place if you need to upgrade the software on the 6to4 router for other reasons and still want to use 6to4. Not everyone is in the position to just board the train they want by force to take the analogy a little further. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
yes, but if I'm not mistaken, you already had RIPv2 then. Keith On Jul 19, 2011, at 7:38 PM, Joel M. Halpern wrote: After all, we moved RIPv1 to Historic when it was still widely implemented, and used in many networks. Yours, Joel On 7/19/2011 5:34 PM, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. ___ 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: Another look at 6to4 (and other IPv6 transition issues)
- Original Message - From: Ronald Bonica rbon...@juniper.net To: Noel Chiappa j...@mercury.lcs.mit.edu; ietf@ietf.org Cc: v6...@ietf.org Sent: Monday, July 18, 2011 10:20 PM Noel, Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? No. What is needed is some lateral thinking, such as the proposal that instead of trying to shoehorn an RFC into an inappropriate, closed set of maturity levels, we use a completely different option, namely an Appplicability Statement that spells out that this magnificent standards track, non-historic piece of technology now has an extremely limited applicability, and unless you really know what you are doing, forget it. Tom Petch. Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Monday, July 18, 2011 11:34 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu; v6...@ietf.org Subject: RE: Another look at 6to4 (and other IPv6 transition issues) From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 19, 2011, at 3:21 AM, t.petch wrote: What is needed is some lateral thinking, such as the proposal that instead of trying to shoehorn an RFC into an inappropriate, closed set of maturity levels, we use a completely different option, namely an Appplicability Statement that spells out that this magnificent standards track, non-historic piece of technology now has an extremely limited applicability, and unless you really know what you are doing, forget it. An Applicability Statement was my first suggestion for how to address the problem, and it's still acceptable to me. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 17 Jul 2011, at 01:52, John C Klensin wrote: --On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica rbon...@juniper.net wrote: A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. Noting in passing that these sorts of statements are quite close to the uses 2026 prescribes for Applicability Statements (and for which we have even more precedent and oral tradition), if the first of those is an adequate reason for identifying something as historic, I recommend that we immediately move RFC 791 to Historic. Certainly we are likely to invest more effort in the development of the technology. Now, some people would read such a move as either an indication, as you suggest above, that the IETF thought no one was using it any more, or that there were no remaining valid use cases, etc., immediately turning us into a laughingstock. But, by logic that suggests moving 6to4 to Historic on the grounds that the IETF is not going to invest effort in the technology. Quite so. And with that, you've just ruined the best April 1 gag the IETF could have hoped for, you. :-) I stopped to consider, and do again, what exactly would prevent us from taking such a radical course of action. Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. On the other hand, as you've shown, case-by-case analysis is a good thing for document action on historic (or any other status), and there are a body of cases where the merits of documents have not shown to be sufficient for the IETF to consider it worthwhile improving. I wasn't about in the early days of the IETF so I don't know anything about these oral traditions you speak of, except to say that this is a case to be made for the force of the written word. BTW, I am among those not exactly thrilled about the idea of moving of 6to4 to historic. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. -- 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: Another look at 6to4 (and other IPv6 transition issues)
On Jul 19, 2011, at 2:34 PM, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism? The number of drafts, I've seen over the course of the last decade and a half with the title foo considered harmful woulkd tend to indicate otherwise. Define active use. If in fact no-one were using it there would be little point in engaging in the activity. rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 20 Jul 2011, at 00:34, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. But none of us like IPv4 and that's a fact. Last one to sign the action to move it to historic's a yellow-belly. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
After all, we moved RIPv1 to Historic when it was still widely implemented, and used in many networks. Yours, Joel On 7/19/2011 5:34 PM, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 20 Jul 2011, at 01:41, Joel Jaeggli wrote: On Jul 19, 2011, at 2:34 PM, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism? No. But if it's in active use, we have something of an obligation to the users. The fact that it's in use is a fairly clear indication, regardless of technical quality (the review process being meant as an aid to identifying the more obvious problems before publication) that it is or can be made to be useful. That's an argument in favour. I don't dispute that protocols can turn out to be harmful, and there's a good vs bad benefit analysis to be made for lots of different reasons, but as has already been said before, the historic label is an *extremely* blunt instrument that is almost always reserved for specifications that have actually come to rest, following the logical English definition of Historic or Historical. Better for the community to be informed about the good and bad of protocols with troublesome aspects. The number of drafts, I've seen over the course of the last decade and a half with the title foo considered harmful woulkd tend to indicate otherwise. Define active use. If in fact no-one were using it there would be little point in engaging in the activity. Right, precisely. If the call weren't made, or it were made but happily ignored by everyone, I think we can take it as red that nobody minds too much. rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world... Well, FWIW, NAT-PT is still implemented and in use, most recently for evil purposes. But once again, the designation means that the protocol has reached the end of its useful service life; there is no further use that can't be better served with our newer, shinier standards. That is something we explicitly indicate, so implementers can get on and implement the better solution. And in every case, we have Applicability statements or Reasons to move documents, so the community understands. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Sun, Jul 17, 2011 at 6:59 AM, Doug Barton do...@dougbarton.us wrote: On 07/16/2011 07:02, John C Klensin wrote: --On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: snip But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. That do sum it up pretty good. snip Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy records. My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... and _yes_ that will hurt bad but it will force a hard error on the whole 6to4 issue. It's so much better with one hard error than lots of possible errors. snip But I don't recall seeing the sort of venom that is directed toward 6to4 being focused on them. Perhaps there weren't enough complaints or you have solid data that 6to4 has caused even more damage. Once again repeating myself ... I have no venom towards 6to4. This isn't a personal attack. And yes, various people and organizations that have vested interests in seeing IPv6 deployed have posted the data about why 6to4 causes way more problems than it solves, and I believe them. I dare to say the content providers want 6to4 gone because it _can_ be pointed at as a risk when enabling IPv6. And I do think the ISP see this as a quite black/white problem _if_ they have to deal with it. Either 6to4 are on and working all the time without them doing much, or it's gone. And this will be my last post on the subject at all, see no point in using more time on it. Lets move on :) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
--On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: To address your concern about whether or not vendors are paying attention to this discussion, and why historic status is substantively different than off by default, no really, OFF BY DEFAULT, I'll put my FreeBSD developer hat on for a minute and tell you that we definitely do pay attention to stuff like this, and whereas we already have it off by default (and have for some time) moving it to historic gives us the cover we need to remove the code at some point down the road when that's appropriate. That's an extremely important distinction, and one of the reasons that as a member of v6ops I ultimately came down in support of the 2-document strategy. Doug, And that is exactly where we agree on the effect and disagree about whether it is desirable. I think there is consensus that 6to4 is dangerous unless carefully and intelligently configured and that is certainly should not be turned on by default. If anyone has argued against that position, they are in a tiny minority. Similarly, I think there is consensus that following the advice in the advice document makes 6to4 much safer to use, even if not entirely risk-free (I contend that there is no risk-free, perhaps as a corollary to the principle that, if we invent something idiot-proof, someone will invent a better idiot). So there should be no question about the desirability about publishing the content of that document. The question, as far as the advice document is concerned, is how to get the message out most effectively, most clearly, and on as timely a basis as possible. I think that having it update the base 6to4 specs is important because that is how the RFC Series is threaded. Without that, there is an increased risk of people finding the 6to4 specs and implementing them without ever seeing the advice piece (just as, even with the updates/updated by pointers, we still hear about new TCP implementations based on RFC 793 alone). For the reasons discussed above, I don't think anyone would find that outcome desirable. As to whether there should be a single document or a separate Applicability Statement that points to both the base specifications and the advice document, I'm really pretty agnostic even though I don't see many advantages in two documents. A separate Applicability Statement that does update the base documents but points to the advice one would accomplish much the same purpose and eliminate the requirement that the advice document explicitly update the base ones. While I think publishing a separate document just to avoid that linkage would waste time, I'm actually pretty agnostic about that option too. But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option -- for FreeBSD users, the exact effect of your removing the code -- I haven't seen nearly as strong as case, or anything even close to consensus, for that position. If it was actually what the community believed, then the advice document would be a complete waste of time except possibly as a retrospective on how 6to4 might have been better specified (a retrospective that we would want to publish as (immediately) Historic). If the thing is still useful, even in limited circumstances and used correctly, then the IETF should not provide you with cover to remove the code because it is not in the best interest of the community for you to remove the code. Might both your removing the code and moving 6to4 to Historic in the future be appropriate? Sure. I also look forward to the day when we can move IPv4 to Historic (just as the various specifications that make up NCP should have been moved years ago if we paid attention to that sort of housekeeping). Summary: we should not move something to Historic that is still in use, useful, and that can be used correctly. We explain how to use it or the circumstances under which is should or should not be used, narrowing those descriptions as much as needed. And/or we explain all of the situations in which it should not be used. Simply reclassifying it as Historic is problematic to the use cases that actually do work and doesn't provide nearly enough information as what people should actually do, especially people who already have the protocol deployed in some form. Using Historic, rather than, e.g., NOT RECOMMENDED [any more] as a sort of super-deprecation mechanism depends too much on our assumption that people with working deployments will simply ignore us. While the assumption is right, it puts the whole situation into one in which the IETF is publicly operating on the assumption that its advice won't be followed. If we do that very often, we might as well just go home. FWIW, I note that there are at least a few other things that shipped for years with FreeBSD that could cause a lot of
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 3:36 AM, Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... and _yes_ that will hurt bad but it will force a hard error on the whole 6to4 issue. It's so much better with one hard error than lots of possible errors. Actually, no. It will cause a significant increase in the number of service calls that will last for years. And those will be the fault of the ISPs blocking the traffic. It must be re-iterated that the vast majority of problems associated with 6to4 appear to be caused by operators, not by 6to4 itself. 6to4 does have some real problems, and some of us are looking for ways to fix them. But that's no excuse for operators to deliberately make things worse. I dare to say the content providers want 6to4 gone because it _can_ be pointed at as a risk when enabling IPv6. And I do think the ISP see this as a quite black/white problem _if_ they have to deal with it. Either 6to4 are on and working all the time without them doing much, or it's gone. Part of the problem seems to be that operators want a quick solution that is under their control, when it appears that no such solution can exist. - Changes to the default address selection rules, already implemented or being implemented, should help significantly, but it will take some time for hosts to get updated to reflect those changes. (Asking Microsoft, Apple, and Linux vendors to include those changes in incremental updates - if they haven't already done so - might help speed that process along.) - The changes in -advisory will help somewhat, but it will take time for operators and vendors to learn about them and implement them, and the effect will be gradual. - The changes in -experimental will also help somewhat, if those changes are published in some form, but the effect will also be gradual. - Improvements to the 6to4 protocol (especially where relay routers are concerned) might help, but again will require updates to hosts and/or routers. (it's conceivable that fixes could be implemented in hosts that don't require the routers to be upgrade in order for those changes to be helpful) - As I said yesterday, there are ways that content providers can use IPv6 to distribute content to their customers over HTTP, as well as monitor the percentage of their users that are IPv6 capable, though they're a tad trickier than simply adding records to the DNS and turning on v6 in their servers. All of the above can help. However, - Yelling 6to4 is Evil as loudly as possible, e.g. declaring it Historic and publishing -historic, - Filtering protocol 41 packets, - Blocking 2002::/16 traffic or routing advertisements, or - Blocking 192.88.99.0/24 traffic or routing advertisements, will all make the situation worse for users, operators, and content providers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action. Why not just sign up for a standard phase-out plan? Don't we want 6to4 users to have any advanced notice that we plan to break their Internet? Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them? -- 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: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 3:30 PM, james woodyatt wrote: On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action. Why not just sign up for a standard phase-out plan? Don't we want 6to4 users to have any advanced notice that we plan to break their Internet? Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them? I don't understand the desire for a phase out plan when there's nothing better to phase in that's generally available. Preferring IPv4 to 6to4 makes sense. But filtering 6to4 traffic or its routing advertisements is a denial-of-service attack. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Noel, Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? Ron -Original Message- From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu] Sent: Monday, July 18, 2011 11:34 AM To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu; v6...@ietf.org Subject: RE: Another look at 6to4 (and other IPv6 transition issues) From: Ronald Bonica rbon...@juniper.net RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. ... A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: Anything more is read into it.? To me, Historic has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is Based on or concerned with events in history.) I think obsolete is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not historic - historic actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 17, 2011, at 12:59 AM, Doug Barton wrote: But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. It doesn't follow. Nor would declaring 6to4 Historic (or any other label) have that effect. It could easily make things worse for both users and content providers, by giving people the mistaken impression that remedial actions like filtering protocol 41 or advertisements for 6to4 relay routers are good ideas. The fixes for unintentional users of 6to4 are already in the pipeline. Everybody agrees that the default address selection preferences should be changed to prefer native IPv4 over 6to4, and host platforms (including FreeBSD I assume) have already changed these preferences or are in the process of doing so.Most platforms have ways of pushing urgent updates to their users, and IMO this change in the address selection preference list should qualify for such updates. (As for the users who don't make use of that feature and/or turn automatic updating off, declaring 6to4 Historic would not make them more likely to use such updates.) To summarize my main points once again (since you seem determined to reopen the debate on 6to4's utility): 1. There is next to zero IPv6-only content at this time. 2. Therefore the number of people who actually *need* IPv6 is so close to zero as to not be a factor. #2 does not follow from #1, for various reasons. One reason is that the Internet is highly diverse, and people use it for many other things than to download content from content providers. 3. Of the tiny number of people that actually do need IPv6, there are plenty of other tunnel options. ...which are often worse than 6to4, for some meaning of worse (more overhead, longer delay, greater likelihood of path congestion, single point of failure, reduced probability of getting a connection established). 4. By the time that there *is* IPv6-only content the market will have sorted out access for the average user. The market hasn't sorted out IPv6 access in the past 15+ years, mostly because of the lack of any new v6-only applications or usage scenarios that would drive IPv6 deployment. Under current conditions, there is zero incentive to produce IPv6-only content because would block 99.99% of the potential market for said content. HTTP and SMTP will be the last protocols to migrate to IPv6, not the first ones. Prior to widespread deployment of IPv6 access, any use of HTTP-over-IPv6 to serve content to the public, or SMTP-over-IPv6 to exchange mail between arbitrary administrative mail domains, is either a proof-of-concept or a publicity stunt. So the idea of waiting until there is IPv6-only content to drive the market to provide IPv6 access for the average user, is a nonstarter. Thus, 6to4 hurts way more than it helps at this point. It doesn't follow even if one accepts the premise of #4 (which is not a reasonable premise). And again, nobody disputes that unintentional use of 6to4 is harmful. But that fix is already in the pipeline, via much more effective means than any label that could be put on 6to4. Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy records. Blocking tunnels makes the situation worse both for users (who will experience even more connection failures) and for operators (who will experience even more support calls). We need to get that message out as loudly and as clearly as possible. As for content providers, there are lots of ways for them to provide content over HTTP-over-IPv6 without exposing that content to 6to4 users, or (better) without exposing that content to users with poor IPv6 connections. One way is this: make the initial connection - the advertised URL - use a domain name which only has A records. This is safe to do because for the foreseeable future, everybody will have some kind of IPv4 HTTP access. Have the initial connection provide referrals to the real content using one of two different domain names, based on whether the source address is within 2002::/16: ipv4.example.com only returns A records, ipv6.example.com returns both and A records. A lot of content is using referrals for various reasons anyway, so it might be possible to do this without any additional overhead. Offhand this seems a lot
RE: Another look at 6to4 (and other IPv6 transition issues)
--On Saturday, July 16, 2011 20:27 -0700 Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, July 15, 2011 2:02 PM To: Brian E Carpenter Cc: v6...@ietf.org; IETF Discussion Subject: Re: Another look at 6to4 (and other IPv6 transition issues) Position #2: How the IETF classifies things makes very little difference in this space because people will follow advice that seems sensible and ignore everything else. If so, it makes little difference how your document is approved or where it is published. For example, it could have come through the Independent Stream or been pushed into CCR. No problem. And the Historic effort is a huge waste of the community's time, no matter how it comes out. Well, if this is the prevailing opinion, we can certainly simplify our procedures substantially by eliminating about half of the document states we maintain now, including reducing the standards track down to a single state. I certainly would not claim it is the prevailing opinion. I believe it is true and have seen it in action many times but, beyond that, have no idea. Also remember that the Standards Track (including BCP or not), Experimmental, Informational, Historic breakdown is somewhat orthogonal to the maturity levels within Standards Track. That said, I believe, based in part on consensus in at least one WG that focused on the topic, that, as our standards have become more complex, with more features, options, and interactions, the embodiment of the maturity level idea as a single set of category-identifiers has outlived its usefulness. The reality is that some features of a particular specification may be well-tested and very mature while others may still be a bit questionable and that some specifications may be more appropriate to some environments and less appropriate to others. From that point of view, forcing entire protocols or specifications into one category or another does both the IETF community and the users of the specs a disservice: we should be telling people what we think of a spec, how mature things are, and what the issues are, if necessary on a characteristic-by-characteristic basis, not pretending that assignment of a label communicates significant information. From that point of view, reducing the number of categories increases the odds of classifications being misleading and communicating little real information, if only from very likely to near-certain. But, again, that is just IMO. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Hi John, I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. Granted, the phrase for any other reason considered to be obsolete is pretty subjective. In this thread, I have seen people interpret that phrase as follows: the IETF thinks that there are no longer any valid use cases for this technology the IETF recommends that you remove this technology from your network the IETF believes that nobody is using this technology I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel Jaeggli Sent: Friday, July 15, 2011 3:17 PM To: John C Klensin Cc: v6...@ietf.org; IETF Discussion Subject: Re: Another look at 6to4 (and other IPv6 transition issues) On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli joe...@bogus.com wrote: So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. And there are people that disagree with you on that. Recategorizing set of documents as Historic is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along with the base documents because giving advice about a piece of ancient history is meaningless. That is not what most people who like the advice document intended, at least as I understood the consensus on that Last Call. SNIP Finally, if we had a wonderful transition model that would work well in all situations, then it would make sense to recommend it and depreciate everything else. You missed the boat about a decade back I guess. Transition technologies (none of them) are a substitute for actual deployment. They should naturally decline in popularity and in fact in the portions of the internet where we can measure them they are. Right now if we try and fit a story to the evidence that is happening because of host changes, and not because of deployment. ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. We don't. What we have are a bunch of mechanisms, each with advantages and disadvantages, some much better adapted to particular situations than others. It would be easier if we had a good single solution, but we don't... that is life, or at least engineering. Given that, we serve the community much better with analyses and explanations of tradeoffs (and RFC 6180 is, IMO, a really good start) than we do by going through exercises of figuring out what to denounce. IMO, the _only_ thing we should be categorically denouncing are tactics and strategies that encourage people to put off getting serious about IPv6. Unfortunately, trying to slap a Historic label on one particular transition strategy, or to rank transition strategies that have proven useful to some actors on the basis of how much various of us loathe them, are about denunciation and, however unintentionally, with the risk of encouraging people to sit and wait, not about progress or network engineering. back to lurking... john ___ 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: Another look at 6to4 (and other IPv6 transition issues)
On Jul 16, 2011, at 4:03 PM, Ronald Bonica wrote: Hi John, I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. Granted, the phrase for any other reason considered to be obsolete is pretty subjective. In this thread, I have seen people interpret that phrase as follows: the IETF thinks that there are no longer any valid use cases for this technology the IETF recommends that you remove this technology from your network the IETF believes that nobody is using this technology I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future Such a determination seems premature. There are some ideas floating around for protocol fixes to deal with some of the operational problems associated with 6to4. It's too early to know whether there are significant flaws with them or whether they can get traction. Admittedly, v4 address space exhaustion along with the introduction of LSN means that 6to4 has diminishing applicability. But for those nets and hosts that still have access to the public IPv4 internet, it's conceivable that the reliability of 6to4 can be considerably improved. (Though of course it will never be as good as be as a well-run native v6 service.) At some point, some evaluation of cost vs. benefit needs to be made; and the cost of not fixing 6to4 needs to consider the consequences of using other tunneled transition mechanisms besides 6to4. Put another way: Given that there are admittedly several operational issues associated with 6to4, there are at least four strategies that might be employed: 1. Encourage changes to the operational practices that are causing problems that are associated with 6to4. 2. Discourage all use of 6to4 in the strongest possible terms. 3. Discourage use of 6to4 except in the cases where it is believed it can work well. 4. Improve the 6to4 protocol to address some of the issues. IMO, -advisory tries to do #1; -historic tries to do #2; -experimental tries to do #3. #4 is something I hope can be discussed, informally, in Quebec. We should have a better idea after the meeting how workable this is. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica rbon...@juniper.net wrote: Hi John, I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's very terse definition of HISTORIC. According to RFC 2026, 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. That's the entire definition. Anything more is read into it. If you include a certain amount of oral tradition that predates and surrounds 2026 in read into it, I agree. It may be worth remembering that 2026, like most similar documents, didn't invent anything but was intended to reflect a community consensus that existed about what should be done. Documents like 2026 never capture that consensus exactly or comprehensively. Whether that informal consensus means anything once we write something down is a question that we rarely ask ourselves, probably for good reason. Granted, the phrase for any other reason considered to be obsolete is pretty subjective. In this thread, I have seen people interpret that phrase as follows: the IETF thinks that there are no longer any valid use cases for this technology the IETF recommends that you remove this technology from your network the IETF believes that nobody is using this technology I doubt if any of these interpretations are valid, because the IETF is not in a good position to evaluate what is in use or tell an operator how to run a network. I think the first interpretation can be valid although it must be used with great caution. For example, I think we might all agree that there are no remaining valid use cases for NCP, despite the fact that TCP/IP could be argued to have replaced it rather than precisely superceding it. Another, perhaps better, example is that Novell IPX is almost certainly dead (proprietary protocol abandoned by its owner is a pretty good predictor of no valid use cases). We wouldn't think using it for anything in a contemporary network would be useful even if, e.g., it has better scaling properties. Interestingly, while RFC 1234 and 1553 were were moved to Historic, we have one Full Standard (RFC 1123, STD 49), an Informational document (RFC 1634), a Proposed Standard (RFC 1420), and a some Experimental documents (RFC 1791, RFC 1792). That pretty much covers the whole range of possibilities. If I didn't have the view that housekeeping exercises that require community review and consensus were usually a poor use of resources (see other note today), getting this whole pack swept into Historic on the no valid remaining use cases principle would be entirely appropriate. One could still not prove that no one is using it: I have every reason to believe that someone out there is still running Netware and happy about it. A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. Noting in passing that these sorts of statements are quite close to the uses 2026 prescribes for Applicability Statements (and for which we have even more precedent and oral tradition), if the first of those is an adequate reason for identifying something as historic, I recommend that we immediately move RFC 791 to Historic. Certainly we are likely to invest more effort in the development of the technology. Now, some people would read such a move as either an indication, as you suggest above, that the IETF thought no one was using it any more, or that there were no remaining valid use cases, etc., immediately turning us into a laughingstock. But, by logic that suggests moving 6to4 to Historic on the grounds that the IETF is not going to invest effort in the technology. So I think we disagree. best, john Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel Jaeggli Sent: Friday, July 15, 2011 3:17 PM To: John C Klensin Cc: v6...@ietf.org; IETF Discussion Subject: Re: Another look at 6to4 (and other IPv6 transition issues) On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli joe...@bogus.com wrote: So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. And there are people that disagree with you on that. Recategorizing set of documents as Historic is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along
Re: Another look at 6to4 (and other IPv6 transition issues)
On 07/16/2011 07:02, John C Klensin wrote: --On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: To address your concern about whether or not vendors are paying attention to this discussion, and why historic status is substantively different than off by default, no really, OFF BY DEFAULT, I'll put my FreeBSD developer hat on for a minute and tell you that we definitely do pay attention to stuff like this, and whereas we already have it off by default (and have for some time) moving it to historic gives us the cover we need to remove the code at some point down the road when that's appropriate. That's an extremely important distinction, and one of the reasons that as a member of v6ops I ultimately came down in support of the 2-document strategy. Doug, And that is exactly where we agree on the effect and disagree about whether it is desirable. Right. I think there is consensus that 6to4 is dangerous unless carefully and intelligently configured and that is certainly should not be turned on by default. If anyone has argued against that position, they are in a tiny minority. Similarly, I think there is consensus that following the advice in the advice document makes 6to4 much safer to use, even if not entirely risk-free (I contend that there is no risk-free, perhaps as a corollary to the principle that, if we invent something idiot-proof, someone will invent a better idiot). So there should be no question about the desirability about publishing the content of that document. Agreed so far, especially about the idiots. :) The question, as far as the advice document is concerned, is how to get the message out most effectively, most clearly, and on as timely a basis as possible. I think that having it update the base 6to4 specs is important because that is how the RFC Series is threaded. Without that, there is an increased risk of people finding the 6to4 specs and implementing them without ever seeing the advice piece (just as, even with the updates/updated by pointers, we still hear about new TCP implementations based on RFC 793 alone). For the reasons discussed above, I don't think anyone would find that outcome desirable. You know the subtleties of the various document tracks infinitely better than I do, so I'm not even going to try and debate you on that. OTOH, I find the idea of someone implementing 6to4 from scratch at this point highly unlikely. I also think that declaring it historic would make the scenario you describe that much more unlikely. [snip] But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. To summarize my main points once again (since you seem determined to reopen the debate on 6to4's utility): 1. There is next to zero IPv6-only content at this time. 2. Therefore the number of people who actually *need* IPv6 is so close to zero as to not be a factor. 3. Of the tiny number of people that actually do need IPv6, there are plenty of other tunnel options. 4. By the time that there *is* IPv6-only content the market will have sorted out access for the average user. Thus, 6to4 hurts way more than it helps at this point. Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy records. I do think that the -advice document is a good thing, and for those that care I think it's great that the IETF is going to help them out. But all statements of the form all we need to do to fix 6to4 is X are non-starters because the people with the ability to actually fix it are not going to. -- for FreeBSD users, the exact effect of your removing the code -- To be clear, I didn't say that we *will* remove it, only that making it historic gives us that opportunity at some point down the road *if* that becomes appropriate. I haven't seen nearly as strong as case, or anything even close to consensus, for that position. If it was actually what the community believed, then the advice document would be a complete waste of time except possibly as a retrospective on how 6to4 might have been better specified (a retrospective that we would want to publish as (immediately) Historic). Once again repeating myself, but I disagree. The idea of publishing both documents represents a fine compromise between the 2 extreme positions, and allows those who
Re: Another look at 6to4 (and other IPv6 transition issues)
So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. On Jul 15, 2011, at 8:55 AM, John C Klensin wrote: Hi. I've been thinking about this and having a few off-list conversations and want to make a suggestion that draws together a few others. Since many people don't like my long notes with the conclusion at the end, this one is suggestion-first. If the suggestion offends you sufficiently, you can just stop reading there. Recommendation: (1) Abandon the effort to classify the specifications as Historic. It is at best a symbolic act that few people outside the IETF community will even notice, much less act differently because we have done it. Instead, let's try to focus on what is actually important, not classification and name-called (curse you, you Historic protocol :-( ). (2) Pull the -advice document back from the RFC Editor queue and fold the actual substantive content of the -historic document into it, preferably as a very clear and very prominent Applicability Statement. If this is what v6ops believes, the statement might reasonably say something like: (2a) This protocol, if not used very carefully, leads to bad operational situations in which things get lost and the problems are hard to diagnose. We strongly recommend that it not ever be a default and that it not be used except under special circumstances and with great care. (2b) Even then, we recommend that it not be used unless all of those configuring routing information and all the systems along the routing path are run by experts who both understanding the issues and are willing to accept responsibility. (2c) If you do decide to use the thing, the advice recommendations in the rest of this document are mandatory and MUST be followed to avoid serious operational problems. I haven't included either Randy's colorful language or mine in the example above, but the intent should be clear. Depending on how much detail the community thinks is useful, there is a good deal of potentially-useful text in draft-moore-6to4-experimental as well as in the -historic draft. The resulting document should explicitly update RFC3056 and RFC3068. Taking that action will send a much stronger you need to read that document before doing anything with this one message to most of the people who are familiar with how things work than a reclassification of the base documents. For those who aren't familiar with how things work, all of these approaches, including moving 6to4 to Historic, are pointless. That is all. This can and should be made to sound like mature engineering advice, which it presumably is, and not like small children throwing mud at each other. Explanation and Rants: (ii) I think moving _this_ protocol to Experimental is just silly. We use Experimental for things that are pre-standardization or not sufficiently mature to be standardized. Although the bar is higher, there are elements of experiment in every Proposed Standard --that is why we have a multiple-step standardization process. If there is really something to be learned from 6to4 operated in a different way, then the right action to take would be to propose a 6to4bis that outlines the characteristics of the protocol, eliminates anything we have concluded should not be done, and outlines the desired experiment. That document might reasonably be listed as updating RFC3056 and RFC3068 as well. (i) rant Presumably our goal is to get IPv6 deployed and provide advice useful to its deployment, independent of any particular piece of protocol or transition arrangement. At least one of the many reasons we haven't seen more deployment is that we keep sending messages to the broader community that, however unintentionally, discourage that deployment. In the early days of IPv6, we did that by advertising (or letting others who were presumed to be speaking for us advertise) that IPv6 was completely ready and that transition was going to be easy, cheap, and seamless. For those who had to make decisions as to when to deploy IPv6, sufficient investigation tp discover that some of that story was untrue became sufficient motivation to back away from IPv6 entirely until we got our acts together. In more recent years, we have continued to deliver the message that the IETF (and, to a lesser extent the RIRs) are simply confused about what advice to give and therefore that IPv6 isn't ready for someone to deploy who suffers from limited resources and a strong desire to do it only when all of the ducks are lined up. Every time we propose a new transition model or denounce an old one without what seems to be an
Re: Another look at 6to4 (and other IPv6 transition issues)
--On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli joe...@bogus.com wrote: So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. Recategorizing set of documents as Historic is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along with the base documents because giving advice about a piece of ancient history is meaningless. That is not what most people who like the advice document intended, at least as I understood the consensus on that Last Call. Worse, for those who are successfully operating 6to4 and finding it useful, reclassifying the specifications to Historic sends a clear message that, from their perspective at least, the IETF is clueless (since Historic essentially says the thing is useless and/or that no one is using it... and they know better because they are a counterexample). The consequence of that, in turn, is that they either simply ignore the advice or conclude that they should postpone IPv6 deployment until the IETF gives advice that is both coherent and believable. I think there are probably a dozen right ways to do this, with the differences depending on issues that I haven't followed v6ops or 6to4 deployment closely enough to have opinions about. What they have in common is a real analysis of issues and some meaningful recommendations (-advice seems to do much of that) and the used of updates to effectively incorporate that advice and guidance into the base spec. If that is better done with a standalone document that references the base spec and the advice document, updating all of them, I'm fine with it (although, under that scenario, I'd prefer to have the advice document on standards track). Finally, if we had a wonderful transition model that would work well in all situations, then it would make sense to recommend it and depreciate everything else. We don't. What we have are a bunch of mechanisms, each with advantages and disadvantages, some much better adapted to particular situations than others. It would be easier if we had a good single solution, but we don't... that is life, or at least engineering. Given that, we serve the community much better with analyses and explanations of tradeoffs (and RFC 6180 is, IMO, a really good start) than we do by going through exercises of figuring out what to denounce. IMO, the _only_ thing we should be categorically denouncing are tactics and strategies that encourage people to put off getting serious about IPv6. Unfortunately, trying to slap a Historic label on one particular transition strategy, or to rank transition strategies that have proven useful to some actors on the basis of how much various of us loathe them, are about denunciation and, however unintentionally, with the risk of encouraging people to sit and wait, not about progress or network engineering. back to lurking... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli joe...@bogus.com wrote: So the rational for the advice document not being combined with the standards action in it is that the later has some polarizing impact, the advice document does not. the advice document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. And there are people that disagree with you on that. Recategorizing set of documents as Historic is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along with the base documents because giving advice about a piece of ancient history is meaningless. That is not what most people who like the advice document intended, at least as I understood the consensus on that Last Call. SNIP Finally, if we had a wonderful transition model that would work well in all situations, then it would make sense to recommend it and depreciate everything else. You missed the boat about a decade back I guess. Transition technologies (none of them) are a substitute for actual deployment. They should naturally decline in popularity and in fact in the portions of the internet where we can measure them they are. Right now if we try and fit a story to the evidence that is happening because of host changes, and not because of deployment. ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. We don't. What we have are a bunch of mechanisms, each with advantages and disadvantages, some much better adapted to particular situations than others. It would be easier if we had a good single solution, but we don't... that is life, or at least engineering. Given that, we serve the community much better with analyses and explanations of tradeoffs (and RFC 6180 is, IMO, a really good start) than we do by going through exercises of figuring out what to denounce. IMO, the _only_ thing we should be categorically denouncing are tactics and strategies that encourage people to put off getting serious about IPv6. Unfortunately, trying to slap a Historic label on one particular transition strategy, or to rank transition strategies that have proven useful to some actors on the basis of how much various of us loathe them, are about denunciation and, however unintentionally, with the risk of encouraging people to sit and wait, not about progress or network engineering. back to lurking... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Another look at 6to4 (and other IPv6 transition issues)
Hi Joel, ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. As far as I can tell, IPv4 is not becoming less usable within my organization's network. Thanks - Fred fred.l.temp...@boeing.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 2011-07-16 03:55, John C Klensin wrote: (2) Pull the -advice document back from the RFC Editor queue and fold the actual substantive content of the -historic document into it, preferably as a very clear and very prominent Applicability Statement. I am very strongly against this. The advisory document received extremely strong support and excellent technical input from a wide cross section of the IPv-anything operational community and has been fully approved and is ready to go. I originally hoped it could be published for World IPv6 Day, but having missed that date, it remains urgent to get it out there, and to publicise it to operators who are not aware of the issues. We can spend another few months debating the exact form of words for a normative document advising implementors to do what most of them are now doing; I don't care and it basically doesn't matter except in the IETF's tiny world. That isn't what's important. What's important is to get as many operators as possible doing what they can to ameliorate the situation. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
--On Saturday, July 16, 2011 08:34 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... We can spend another few months debating the exact form of words for a normative document advising implementors to do what most of them are now doing; I don't care and it basically doesn't matter except in the IETF's tiny world. That isn't what's important. What's important is to get as many operators as possible doing what they can to ameliorate the situation. Brian, It seems to me that you can take two positions here, but not both as the same time. Position #1: What the IETF does, and how it classifies things, actually make a difference. If that is true then the advice document should look a lot more mandatory and should certainly be shown as updating the 6to4 base documents (I note that the latter decision could be made without reopening the document in any significant way). Whether it is part of the advice document or not, an applicability statement that discusses what is really going on is important and reclassification to Historic would be stupid. If nothing else, unless it reclassifies your advice doc to Historic as well, reclassification to Historic would be appeal-bait. And classifying your document as Historic also would rather dilute the message. Position #2: How the IETF classifies things makes very little difference in this space because people will follow advice that seems sensible and ignore everything else. If so, it makes little difference how your document is approved or where it is published. For example, it could have come through the Independent Stream or been pushed into CCR. No problem. And the Historic effort is a huge waste of the community's time, no matter how it comes out. Just my opinion -- you will probably continue to disagree. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
John, I think Brian and Joel both made excellent points about why this suggestion is probably sub-optimal, and I won't presume to add to the elegance of their arguments on those points other than to say that I agree with them. To address your concern about whether or not vendors are paying attention to this discussion, and why historic status is substantively different than off by default, no really, OFF BY DEFAULT, I'll put my FreeBSD developer hat on for a minute and tell you that we definitely do pay attention to stuff like this, and whereas we already have it off by default (and have for some time) moving it to historic gives us the cover we need to remove the code at some point down the road when that's appropriate. That's an extremely important distinction, and one of the reasons that as a member of v6ops I ultimately came down in support of the 2-document strategy. hth, 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: Another look at 6to4 (and other IPv6 transition issues)
Joel's widget number 2 On Jul 15, 2011, at 12:37, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Joel, ipv4 is becoming less usable and it's taking autotunnels with it, nobody here has a proposal that changes that. As far as I can tell, IPv4 is not becoming less usable within my organization's network. Stasis is great if you can get it... There are two drafts proposing the use of shared address space space to be assigned by ARIN for LSN that will probably turn up in opsawg. Whether the get it or not the LSNs will be deployed. And yeah I think Boeing probably has enough v4 addresses for a while. Joel Thanks - Fred fred.l.temp...@boeing.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
