Re: HOMENET working group proposal
Martin Rex wrote: This means you want to make IPv6 addresses and all communications with that address direct personally identifiable information, something for which a must informed beforehand, let alone an opt opt is technically impossible? If what you want is opt out from static IP addresses, use proxies at an application layer or IP over IP at the network layer. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jul 1, 2011, at 2:55 PM, Scott Brim wrote: The IETF has several times veered away from the deep water where internet standards cross paths with regulatory requirements. http://tools.ietf.org/html/rfc2804 We are not legal experts we are not qualified to interpret the statutory requirements of various nation states, our own or others. We need to be clear on what is in vs out of scope for IETF work. Focus on what would be percieved to be in the best interests the users and the network. Nation states will do whatever they do and sovereign by definition can impose whatever mandate they find necessary on their network operations and citizens. Joel, the issue is very clear: what the IETF does must not make privacy and confidentiality impossible. It's not just some arbitrary regulation from a committee, there are whole cultures who take this very seriously. You cite the wiretapping decision -- note we didn't make wiretapping impossible, we just didn't support it. In this case it is very easy to make privacy (the right to control personal information) and confidentiality (the right to know that private information you share with one party will be kept within that scope) impossible -- that's a position you may not take as someone making the Internet work, since the ultimate stakeholders are those humans out at the edges. See also Changes to Internet Architecture Can Collide With Privacy http://www.ietf.org/proceedings/79/slides/intarea-3.pdf for a discussion of mobility. When you think oh right, I have to come up with a security considerations section, include privacy and confidentiality implications in your checklist of things to think about. Very much agree. I strongly disagree with the statement that every home network should have only ephemeral external addresses and that it should NAT to stable internal addresses. I also strongly disagree with the assertion that EU law requires IETF to make it so. But the underlying concerns are quite valid and important. I don't want to cripple all home networks and applications by imposing ephemeral addresses and/or NATs on them. But having a stable address prefix associated with every device in one's home network that communicates with the public Internet can indeed threaten the user's privacy. (Note that privacy addresses don't really solve the problem as they still all have the same prefix.) Some applications and hosts require stable addresses; others do not. So it might be that a home network needs to be able to support two prefixes - a stable one that can be used by those applications that need it, and an ephemeral one that can be used by everything else. That's not difficult to do by itself, but my next question is how to arrange these things such that ordinary consumers can understand such details and manage them? Anyway, to me it seems reasonable for the HOMENET group to consider privacy issues associated with address assignment. As to the technical issues here, higher layers don't need to use IP addresses as identifiers, they have their own. The only layer that needs to care about IP addresses is the IP layer itself. This has been demonstrated many times to be false. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-v6ops-6to4-to-historic
Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 38, Issue 6
Considering the no. Of users at every second it will not be possible to achieve direct privacy addressing system, for me IETF shld design a system which will enhance DMZ network connection detection and monitoring system. Amenawon Osa Peter Sent from my BlackBerry wireless device from SapenaNET -Original Message- From: ietf-requ...@ietf.org Sender: ietf-boun...@ietf.org Date: Sat, 02 Jul 2011 12:00:04 To: ietf@ietf.org Reply-To: ietf@ietf.org Subject: Ietf Digest, Vol 38, Issue 6 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ietf Click the 'Unsubscribe or edit options' button, log in, and set Get MIME or Plain Text Digests? to MIME. You can set this option globally for all the list digests you receive at this point. Send Ietf mailing list submissions to ietf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to ietf-requ...@ietf.org You can reach the person managing the list at ietf-ow...@ietf.org When replying, please edit your Subject line so it is more specific than Re: Contents of Ietf digest... Today's Topics: 1. Re: HOMENET working group proposal (Masataka Ohta) 2. Re: HOMENET working group proposal (Keith Moore) 3. draft-ietf-v6ops-6to4-to-historic (Ronald Bonica) -- Message: 1 Date: Sat, 02 Jul 2011 16:20:33 +0900 From: Masataka Ohta mo...@necom830.hpcl.titech.ac.jp To: ietf@ietf.org Subject: Re: HOMENET working group proposal Message-ID: 4e0ec6c1.2000...@necom830.hpcl.titech.ac.jp Content-Type: text/plain; charset=ISO-2022-JP Martin Rex wrote: This means you want to make IPv6 addresses and all communications with that address direct personally identifiable information, something for which a must informed beforehand, let alone an opt opt is technically impossible? If what you want is opt out from static IP addresses, use proxies at an application layer or IP over IP at the network layer. Masataka Ohta -- Message: 2 Date: Sat, 2 Jul 2011 10:52:08 -0400 From: Keith Moore mo...@network-heretics.com To: Scott Brim scott.b...@gmail.com Cc: ietf@ietf.org Subject: Re: HOMENET working group proposal Message-ID: 1b0e6a5d-0bf1-400b-a063-d59d8ed2c...@network-heretics.com Content-Type: text/plain; charset=us-ascii On Jul 1, 2011, at 2:55 PM, Scott Brim wrote: The IETF has several times veered away from the deep water where internet standards cross paths with regulatory requirements. http://tools.ietf.org/html/rfc2804 We are not legal experts we are not qualified to interpret the statutory requirements of various nation states, our own or others. We need to be clear on what is in vs out of scope for IETF work. Focus on what would be percieved to be in the best interests the users and the network. Nation states will do whatever they do and sovereign by definition can impose whatever mandate they find necessary on their network operations and citizens. Joel, the issue is very clear: what the IETF does must not make privacy and confidentiality impossible. It's not just some arbitrary regulation from a committee, there are whole cultures who take this very seriously. You cite the wiretapping decision -- note we didn't make wiretapping impossible, we just didn't support it. In this case it is very easy to make privacy (the right to control personal information) and confidentiality (the right to know that private information you share with one party will be kept within that scope) impossible -- that's a position you may not take as someone making the Internet work, since the ultimate stakeholders are those humans out at the edges. See also Changes to Internet Architecture Can Collide With Privacy http://www.ietf.org/proceedings/79/slides/intarea-3.pdf for a discussion of mobility. When you think oh right, I have to come up with a security considerations section, include privacy and confidentiality implications in your checklist of things to think about. Very much agree. I strongly disagree with the statement that every home network should have only ephemeral external addresses and that it should NAT to stable internal addresses. I also strongly disagree with the assertion that EU law requires IETF to make it so. But the underlying concerns are quite valid and important. I don't want to cripple all home networks and applications by imposing ephemeral addresses and/or NATs on them. But having a stable address prefix associated with every device in one's home network that communicates with the public Internet can indeed threaten the user's privacy.
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: Comments surrounding draft-iab-dns-applications-01
On Apr 28, 2011, at 10:40 AM, Edward Lewis wrote: These comments were sent to the IAB already. I was encouraged to send them to the general IETF list. This is mostly a re-posting of the comments, with one added paragraph (there's marker there). The referenced document is: http://www.ietf.org/internet-drafts/draft-iab-anycast-arch-implications-01.txt Ed et al., In collecting and attempting to accommodate reviews on the Anycast Architectural Implications ID to which the link just above references, it's clear to me (and quite possibly everyone that read your message) that you meant to reference draft-iab-dns-applications-01, to which the subject and feedback concerns, available here: http://tools.ietf.org/html/draft-iab-dns-applications-01 That said, a new revision of the Anycast document will be available in very short order, and I welcome feedback on it as well :-) Thanks, -danny It's hard to make comments on a document whose mission is not at all clear. The problem I have is that the document has a faulty baseline and incorrectly assesses extensions and variations. Having spent 15 years with the DNS and having to come to a deep architectural understanding of it in order to define DNSSEC, my view of the DNS is vastly different than that documented by the IAB. With this it is hard to tell what the document is trying to guard against. Or push towards. Starting with what the DNS is and why it exists has to recognize that a lot of work we think is native to it actually preceded it in the /etc/hosts.txt file and in similarly built systems. DNS is not principally there to translate names to numbers as the draft opens with, although that is a high-profile use case. The DNS did not define a uniform naming scheme. DNS is there principally to build on the previous solution (a text file distributed once a week from a central location). If I were asked to list the bullet points that describe the DNS core competency, they would be - availability - resilience - speed in response - speed in propagating data - distributed management - neutral Where the DNS is weak is in the data plane and the management plane. The basic lookup/search algorithm is stilted, inflexible, and hard for many to understand. The biggest dilemma that it faces is that in order to be strong it uses an unreliable transport substrate as it's primary communication mechanism, the same substrate that is the source of the protocol's chief technical challenges. In a way, DNS is a balancing act, it is all about using UDP right. To a lesser extent, the fact that the DNS is not a client-server protocol, as it is usually treated in text, but a client-cache-server protocol complicates understanding it's architecture. This is the very reason DNSSEC exists, the ingrained middle-man in the client-server exchange. Attempts to empower the middle-man are the chief obstacle to improving the overall health of the DNS and it's cooperation with other protocol systems. Over time there really hasn't been progress in the way of making the DNS support applications. Despite what is in the IAB draft, there has been just one application that is built into the DNS, done at the dawn of time and not even in a significant way. Mail is the only application with built in support in DNS. No other application has ever changed the DNS definition. To understand this we should look a chronology of changes to the DNS concept and specification. The original DNS specification is as defined in STD 13's documents. I won't bore you with repeating what's there, except to point out that a few seminal types are included in the original set. It is also important to quantify what's meant by DNS support for an application. The baseline for any type is, given a name, class, and type, the returned value will have a set of data. Any resource record type that follows this baseline is considered to have no special processing, the label put on sensitive types. Types that have no special processing include the A, , and PTR records. Some of these types do contain domain name that can be compressed and this is confused as special processing - but that is not special to the protocol, just special to the marshalling of the parameters. Surprising to some folks, SRV and NAPTR also have no special processing, in fact aren't even subject to message compression. This point is one I have to make because the draft uses SRV and NAPTR as evidence of application scope creep into the DNS. Types that do have special processing include this list (not exclusively) SOA, NS, MX, CNAME, DNAME, and the DNSSEC types. These are the types that are cause considerations for the DNS. MX is the mail application dedicated type. It's impact is that it causes additional data (address records) to be included in a response. A very lightweight action, but special
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: [homegate] HOMENET working group proposal
On 07/01/2011 14:17, Keith Moore wrote: On Jul 1, 2011, at 4:13 PM, Doug Barton wrote: On 07/01/2011 13:03, Kenneth Voort wrote: I would also add that future IPv6 capable devices should allow end users to reach the IPv6 Internet from an IPv4-only provider through some means, perhaps tunneling, with no or minimal administrator intervention. I can see many providers remaining IPv4-only long into the future. This is an area that we very clearly do not need to get involved in because it will solve itself due to market forces. Right now there is no IPv6-only content that anyone cares about. When that changes, users will start demanding that their provider give them access to it, or vote with their feet. Whenever people talk about the Internet as if it were just about access to content, I have to wonder.The Internet has always been more about conversation than content. The overwhelming majority of Internet users are consumers of content. Some of that content is stuff like Skype, instant messaging, etc. The overwhelming majority of businesses that make the Internet work are the content providers, and the ISPs that enable the consumers of that content to reach it. Failure to recognize these 2 critical facts leads to producing standards documents that have no relevance in the real world. To summarize my main point once again, there is nothing for the IETF to do here, the problem will take care of itself. Quite the contrary. We still don't have a good transition mechanism that HOMENET could specify. And as I pointed out in the bits of my message that you snipped, we don't need one. 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: draft-ietf-v6ops-6to4-to-historic
Subject to reading the not-available-yet text, I support this approach. It appears to be reasonable political compromise. Michel. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ronald Bonica Sent: Saturday, July 02, 2011 9:36 AM To: v6...@ietf.org; IETF Discussion Subject: draft-ietf-v6ops-6to4-to-historic Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [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: [homegate] HOMENET working group proposal
On Jul 2, 2011, at 9:31 PM, Doug Barton wrote: On 07/01/2011 14:17, Keith Moore wrote: Whenever people talk about the Internet as if it were just about access to content, I have to wonder.The Internet has always been more about conversation than content. The overwhelming majority of Internet users are consumers of content. Some of that content is stuff like Skype, instant messaging, etc. The point is that the Internet is not primarily about producers in the center doling out content to users at the edge. Granted, netflix uses a lot of bandwidth. But a lot of what has driven use of the Internet, and continues to drive it, is users engaging in conversation of one form or another. This was true when email and Usenet were the apps consuming the most bandwidth, and it's true today for Skype, Facebook, Youtube, IM, blogs, etc. Meanwhile, traditional producer-to-consumer media channels of all types are steadily dying. They tend to blame it on copyright violation, or free access to content on the Internet. The real problem is that most of what they produce is crap. They're stuck in an old model that says that a few people should decide what's good for everybody else, but now people are in a position to decide what's good for themselves and/or create their own content. The overwhelming majority of businesses that make the Internet work are the content providers, and the ISPs that enable the consumers of that content to reach it. Failure to recognize these 2 critical facts leads to producing standards documents that have no relevance in the real world. Insistence on sticking to anachronistic models of the real world will do the same thing. 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 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
