RE: Diversity of IETF Leadership
I suspect that the often-subtle differences in technical perception on IETF technologies between sexes, races, and languages are much less pronounced than the substantial differences in technical orientation between vendors, ISPs, academics, governments, and end users. If we are consistently seeing individuals from the same corporation or governmental entity dominating processes then that is a Red Flag. Do we have a Red Flag? If not, then I will resume hoping that this email thread will end soon.
RE: US DoD and IPv6
On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER d...@dcrocker.netmailto:d...@dcrocker.net wrote: On 10/11/2010 8:25 AM, Joel M. Halpern wrote: Without getting into the question of whether your suggestion would have helped anything in terms of transition and interoperability, it shares one major flaw with the path we did adopt. There is no incentive to spend resources to get there. Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time. snip Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice. Mere exhortations from the great and the good have very limited effect. The elephant in the room which this discussion hasn't considered is Why would a widget maker want to spend money, thereby reducing their bottom line, to upgrade their network to IPv6? Applying traditional business risk/reward analysis, is there even one real *business advantage* to justify such an expense? If there isn't any, then IPv6 would only rationally be deployed by such an end user if it were both transparent and free. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
Gentlemen: The IPv6 deployment is what it is and nobody is to blame that it isn't greater or less than it is. It should not surprise anybody that IPv6 hasn't been more widely deployed to date, because, after all, I explained back in 1993 in RFC 1687 why that would happen. Going forward, there are many business reasons why IPv6 will increasingly become deployed and many business reasons why IPv4 use will actually grow. Thus, we can be assured that the Internet will be a mixed environment for the next many years to come. We have many existing technologies and approaches that handle such mixed environments. There is no reason to be upset -- this is the most probable result to the IPv4 address depletion problem. No surprises here. Best wishes, --Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: All these discussions about meeting venues
Dave Crocker wrote: But, Fred, the problem really is with having such a varied population of attendees and then experimenting with new venues every time. This guarantees problems, because the varied population means that there is a complex set of requirements. No, all of the issues cannot be anticipated, nevermind resolved. However a resource-rich venue that is visited repeatedly means that the choices are much greater and that a learning curve can develop. I strongly resonate with this insight. The IETF has repeatedly returned to certain sites many times. Not all of them are desirable -- note, for example, Minneapolis in winter. However, the fact that we have been to those sites many times have made them a known entity which has fostered productive work. On the other hand, novel sites are interesting, enable new people to attend, show support for different language groups, and foster memorable events (tourism). The question for the group to decide is what are we trying to accomplish and what venues best assist us attaining our goals. Best wishes, --Eric PS: For those who note that it has been a long time since I have attended an IETF, let me merely note that I attend every IETF that is in Vancouver and that remote site locations impact my ability to attend. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv4 depletion makes CNN
You articulated the view from my knothole. Thanks! -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, May 28, 2010 1:29 AM To: David Conrad Cc: IETF Discussion Subject: Re: IPv4 depletion makes CNN snip No, it means it is going to require double NAT unless providers deploy IPv6. That is the message that needs to be got across. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The internet architecture
I spent several years trying to discern what the IETF's Internet Architecture became when we abandoned our historic architecture and started growing the middle of the hour glass through middleboxes and telephony-originated techniques. For several years in the early 2000s I became convinced that we had no architecture and I lamented that fact. Recently I realized that we had stumbled upon a common architecture but hadn't yet realized it -- map-and-encaps is our current Internet architecture. I believe that the techniques described in Fred Templin's current I-D trilogy should be re-written to state that those techniques describe our current de facto Internet architecture. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [73attendees] Is USAqualifiedfor2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
Let's also not forget that Mexico is also part of North America. The percentage of IETF meetings targeted for North America could actually theoretically be hosted in any of those three countries (USA, Canada, Mexico) and still benefit from excellent worldwide air travel support. From: James Seng [mailto:[EMAIL PROTECTED] Holding meeting in Canada may not sound like a bad idea actually. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
This is a constructive and helpful posting, Tony. Thank you. Am I correct in presuming that both Noel and you believe that the possible technical solutions to this problem are currently being considered in the RRG / RAM discussions? -Original Message- From: Tony Li [mailto:[EMAIL PROTECTED] On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. This perspective is soluble, but it's not the perspective that we seem to approach the problem from. We also don't have the solution in hand today, but work towards it would be greatly accelerated by backing away from our long-standing positions, terminologies and arguments and truly focusing on the problem at hand. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Business case for IPv6 (Was: Re: one example of an unintendedconsequence of changing the /48 boundary)
From: Greg Skinner [mailto:[EMAIL PROTECTED] Hmmm ... I haven't heard much about IPv6 deployment yet from an investment standpoint from the usual business news sources, even the tech business news sources. I'll grant that may change soon. However, as has been noted, there are businesses, organizations, etc. that have migrated to, or adopted, IPv6. I hear that IPv6 has gained a foothold in Asia, for example. Perhaps the answer to all of these questions regarding pain points is to collect and document case studies on who made the migration or adoption, what problems were encountered, etc. I am sure that I am not the only person on this list who would value insight into the current status of the world's IPv6 deployment. Is there a web site that tracks that important issue? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I understand that there is an ISO MOU with the IETF- I want to see it...
John, Please remember with me back to the mid-1990s when ISO sent official liaison reps to the IETF. The way I recall (perhaps incorrectly) things working back then was that from the ISO perspective, these were official liaison reps formally sanctioned according to ISO processes but from our perspective they were technical people representing themselves just like anybody else in the IETF. We still have liaison activities happening today. For example, at the NSIS WG meeting in Montreal, individuals mentioned the actions they were personally taking to keep NSIS in synch with specific 3GPP activities. My point being that just because we don't formally recognize liaisons doesn't mean that individuals do not perform informal liaison services on their own volition. --Eric -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] I understand that there is a formal MOU between the ISO and the IETF that talks about ISO's actions with regard to the reliance on IETF Standards and RFC's. I want to physically see a copy of the document - in its entirety. To the best of my knowledge from either an IETF perspective or as a member of one or two of the mailing lists on which ISO would have needed to see comment, there is no such document or agreement. For such a thing to exist, there would almost certainly have to be a formal liaison agreement between IETF and either ISO or ISO/IEC JTC1 and that agreement doesn't exist either (although several of us have, over the years, attempted to make it happen). Where do you get these ideas? And please see my earlier comments about your rights in these issues generally and to make this type of demand, even if the agreement and documents did exist. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
I'm sorry to enter this fray, but I'd like to point out that while I respect Todd's request to know who is accusing him and why, the rest of us don't need to be copied that information. In fact, it is better that we aren't copied because to do so would be unfair to the complainer(s). Discipline is a difficult task to do fairly and because of this there are many advantages in respectfully permitting the protagonists to have privacy during key parts of the process. -Original Message- From: todd glassey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:51 PM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Yes actually you do -how does anyone complained against know who is complaining or why? - if the complaints are not public then the oversight is not real - its a paper fiction - a lie in print. Speaking of lies in print this is why IETF complaints are addressed and penalties for them assessed before the appeal can be resolved - because the IETF's oversight policy and practice model is ineffective and setup to allow the IETF to exact whatever penalties it wants from individuals without the benefit of the appeal or the appeal process. So YES I want to know specifically who complained. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, October 10, 2006 2:11 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, People got very irritated with this type of messages and actually even complain why I'm not more strict. I got at the time being already 3 new complains after this message and obviouly I don't need to justify to you who is complaining. Clearly you crossed the line once more, and it took you only a few seconds after getting my warning, so just instructed the secretariat to ban you for two weeks from now. And please, understand that I don't have anything personal, just fulfilling my mission. Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 12:42:30 -0700 Para: [EMAIL PROTECTED], ietf@ietf.org, Contreras, Jorge [EMAIL PROTECTED] Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that
RE: NOMCOM term limits... Re: Now there seems to be lack of communication here...
The view from my knot hole is that back in the 1990s, the IETF was a meritocracy in which the power of proven technical insight plus running code determined our leadership. Our community has been steadily evolving as times and membership changed. Your posting reminds me from statements from the French Revolution roughly 200 years ago. The part of your posting that confuses me is the every voice heard and counted? Certainly you don't mean every voice since most people know nothing about Internet technologies. So what do you mean? I also fail to descern why you don't think that the curent approach works. Specifically, I'd prefer NOMCOM to be populated by people who actively participate in the IETF and who have a pulse on our community (i.e., I still buy into the concept of 'meritocracy' -- it has served us well). Do you really object to this? Why? From: todd glassey [mailto:[EMAIL PROTECTED] No Stewart it doesn't. The leadership in the IETF needs to be washed clean and made pure again. That will only happen when all the smoke and mirrors' are stripped clean and the will of the proletariat actually considered instead of what is done today. NOMCOM and a non-electoral model are what need to go away - The IETF needs to be a place where EVERY VOICE is heard and counted. Todd Glassey. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Editor Function SOW Review
I spent the first many years of my professional life overseas working as a Linguist writing and speaking other people's languages. Even though my own proficiency was inadequate by their standards, I relied upon talented native speakers to enhance my publications so that they became well written in the target language. This is what the IETF also needs to do. The IETF authors needn't be very proficient in English, but they need to be proficient enough to coherently explain their technical points so that others can understand them. What is needed is to ensure that somebody, with the authors' oversight, is enlisted to improve the drafts so that the ultimate IETF documents themselves are in very good English. Because the IETF is now International, all the IETF documents must be in well-written English because we now come from so many languages and cultures. It is hard enough dealing in foreign languages without exacerbating the problem for the non-native English speaker by asking them to understand garbled versions of English. If it is difficult for the native English speaker to understand, it is much worse for the non-Native speakers (unless they happen to speak the same language as the garbler). BTW, some native English speakers also produce horrid documents because they are poor writers. These individuals also need to leverage editors who can translate their thoughts into coherent English. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
Let's not forget that the S in SNMP stands for simple. Simple is a relative term. In this case, SNMP is simple when compared to CMIP. -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 5:33 PM I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) dbh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Ever since PANA was first proposed, I did not understand why the IETF accepted it as a work item, because it seemed to me that it was duplicating existing capabilities (e.g., RADIUS, Diameter, etc.) and thereby needlessly increasing complexity system-wide. By this discussion, I surmise that you have greater insights than I. Hence this question to you: What 'bad thing' would happen should PANA not go forward? I suspect that this question has been answered many times. But could you please answer it using simple concepts for the benefit of those of us who aren't thinking deeply on a sleepy Friday evening? I am particularly interested in whether you believe end users require PANA and, if so, why? Thanks! ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ARPAnet's Problems Persist Unsolved Today
I am told during the last IETF's Social Event, Dave Clark made a presentation that again observed that all of the ARPAnet's historicly unsolved networking problems persist in the Internet today. I wasn't there, but I am seeking a paper that I could reference that makes that very point. Did Dave point to a paper during his speech? If not, can anybody point me to a published paper dealing with this topic? Thanks. --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: Fwd: TLS authorizations draft
Keynote is an Experimental RFC (see RFC 2704, RFC 2792). I failed to see the context of this discussion since I apparently deleted the emails that preceeded this. Despite my lack of context, I did want to state a few reasons why Keynote is personally interesting to me: Steve Bellovin wrote a paper in 1999 entitled Distributed Firewalls that described a mechanism to build policy-based networks by leveraging the IPsec protocol. This approach addressed most of the problems that occurred with the more ambitious Policy Based Networking (PBN) approaches proposed by entities such as the DMTF's DEN. It has been used to create distributed firewall systems (e.g., see http://www.cs.columbia.edu/~angelos/Papers/df.pdf), including the construction of discrete security zones within the network infrastructure (i.e., elements of a network deployment with heightened or specialized security requirements different than the rest of the deployment). The IETF's former IPSP working group assembled several tools that can be optionally leveraged to create PBN systems using IPsec, though I perceive that their approach has imploded in the general case due to policy complexities: * RFC 3586 describes the problem space and solution requirements for developing an IPSP configuration and management framework. * RFC 2704 describes the KeyNote policy language that can optionally be used to construct PBN systems. The KeyNote implementation functions as a compliance engine and is based on RBAC techniques as encoded within PKI attribute certificates. * Use of IPsec's ESP (see RFC 4305) in Transport Mode to provide confidentiality, data origin authentication, anti-replay attack protection, and data integrity services in order to enhance network security between communicating devices (e.g., hosts-to-hosts, routers-to-routers) at a specific integrity level. The DARPA Strong Man work originally experimented with integrating KeyNote with IPsec's Internet Key Exchange (see RFC 4306) protocol in order to create a very fine-grained authentication and access control infrastructure at the network layer. These communications are secured by using IPsec in Transport Mode between communicating devices. A public implementation of this approach is freely available and is built into the Open BSD Unix OS. This approach creates a tight knit PBN system that has not been widely deployed to date, to the best of my knowledge. Nevertheless, corporations such as Boeing remain very interested in mechanisms to Internet harden our infrastructures, particularly now that traditional perimeter defense firewalls are becoming obsoleted by modern business practices. Specifically, we need viable mechanisms to internally create distributed firewalls or security zones inside our distributed operations environments. The DARPA Strong Man, while not widely implemented to my knowledge, nevertheless is one of the more promising approaches towards doing that. -Original Message- From: Stephen Kent [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 1:02 PM To: Russ Housley Cc: ietf@ietf.org Subject: Re: Fwd: TLS authorizations draft At 10:16 AM -0400 5/18/06, Russ Housley wrote: I received this note from Angelos Keromytis regarding the draft-housley-tls-authz-extns document. I plan to accommodate this request unless someone raises an objection. Russ OK, I'll object :-). KeyNote has no IETF status, to the best of my knowledge. It is closely aligned with the SDSI/SPKI work for which the IETF created a WG, but ultimately rejected as a standards track effort. So, I find it inappropriate to extend this standards track document to include support for a technology that, via a tenuous link, never made it to standards track status in the IETF. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
How widely have the Seamoby CARD and CXTP protocols been deployed?
In July of 2005, the IESG allowed the then-existing session mobility (Seamoby) working group's Candidate Access Router Discovery (CARD; RFC 4066) and Context Router Protocol (CXTP; RFC 4067) to be published as experimental RFCs with an associated warning, RFC 4065, informing everyone that both protocols were experimental only and therefore may never see widespread deployment. The purpose of this email is to query whether or not these Seamoby protocols have been deployed within production environments? If they have, I would like to learn how widespread their deployment has been and whether the infrastructures that have deployed them believe that this approach remains promising or not? If not, then what were the problems that were encountered? If so, then do they expect the use of this protocol to grow in popularity over time or not? Thank you for your attention to this query. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Noel, Back in 1993 I predicted that what you have just stated is what us end users will actually do in regards to IPv6 (which we called IPng back then). I documented my thoughts in that regards in RFC 1687. RFC 1687 is somewhat dated now, since the example of a killer app I selected is rather quaint (to be generous), but the types of motivation underlying that identification still persist. In any case, I applaud your insight below that us end users will go to great lengths to avoid any costly network upgrade that does not contribute anything to our bottom line. Think about it: why would we spend tens of millions of dollars to get equivalent network connectivity to what we already have? It makes absolutely no sense from our point-of-view. --Eric -Original Message- From: Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Monday, April 10, 2006 7:36 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Reality (was RE: Stupid NAT tricks and how to stop them.) From: Tony Hain [EMAIL PROTECTED] The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. The best laid plans o' mice an' men gang aft agley. -- Robert Burns 'Do not put too much faith in this hairy architecture you have constructed', retorted Daemon Feature. 'All this is insignificant compared to the Hack.' -- Mark Crispin, Software Wars Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), so I have no specific prediction to make, but... Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Proposed 2008 - 2010 IETF Meeting dates
An alternative to coordinating meeting dates with a growing list of peer entities is to simply say that the IETF will meet on the second week of March, July, and November every year. Such a stance would help everyone to schedule. [Note: these weeks are suggestions only, select a permanent variant of your choice.] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, Please recall that IP addresses are currently serving two semantic functions: Locator and Identity. I interpreted Keith's posting to be speaking of the latter. (e.g., HIP) --Eric -Original Message- From: Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 11:45 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Stupid NAT tricks and how to stop them. From: Keith Moore moore@cs.utk.edu even if IP had identifiers for hosts that were independent of locators, they wouldn' t be worth very much without a way to map them to locators. and locators are a lot easier to deal with if they're location-independent. Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? If that wasn't a typo, and you really meant what you said, the whole *point* of locators is to include location information. A locator [which is] location-independent is an completely oxymoron. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: from the horse's mouth
I have enjoyed taking a break from work to read this thread. However, recent posts read like Mark Twain's observation: Everyone is always complaining about the weather but nobody does anything about it! Specifically, is this thread headed towards an actionable conclusion or is it continuing primarily for its entertainment value? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Question about the normative nature of IETF RFCs
Friends, When did we in the IETF first begin to view our standards track RFCs to be normative? Specifically, when I first became associated with you all in 1992, the RFCs of most IETF standards were incomplete and the reference implementations (i.e., running code) were what was considered to be normative. At a certain point (very late 90s??) the IETF began to reference the text of its standards track RFCs as if the RFC texts themselves were normative (e.g., in an OSI or ITU-like manner). When did that transition occur? Was there a specific event that marked that transition (e.g., a POISED WG)?? Did we formally document this evolution somewhere? Do we currently consider today the reference implementations to be more (or less??) normative than the RFC texts themselves? Thanks! --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about the normative nature of IETF RFCs
Keith, I resonate with your points except that the earliest IETF standards (i.e., IP itself, TCP itself, others) were incompletely specified by RFCs. Therefore, interoperable implementations could only occur with reference to the reference implementations. However, the actual motivation for my query is the following: the IETF didn't accept the existence of middleboxes until 2000 - 2002. Thus, I am trying to convince a middlebox implementor that they misunderstood a standards track RFC originally written in 1995 and re-published in 1998. That RFC said hosts do X and other devices (which in that era meant routers) do Y. They do Y because they are not hosts -- rather than correctly behaving as middleboxes are supposed to do. The reference implementations clearly demonstrate that their approach is non-conformant even though their non-historically accurate interpretation of that standard complies with the actual wording of that RFC. --Eric From: Keith Moore [mailto:[EMAIL PROTECTED] As far as IETF is concerned, running code should be seen as a proof-of-concept and a test vehicle, not as primary source material. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group
Ken, I appreciated your posting but I surmise that what we may have here is a divergence in world views. I suspect that many readers of your and Eliot's postings view the current Internet topology as consisting of autonomous systems linked to the Internet via BGP connections and perimeter-defense firewalls. People with this world view probably believe that the management station is always on the same side of the firewall as the managed devices. However, you and I have a different perspective in which the concept of corporate perimeter has been modified, such that there are potentially many diverse local reasons why a single policy zone may need to manage devices across firewalls. Specifically, large end users often have business relationships that cause our perimeter defense system to become porous. For perhaps the past seven years it has no longer been the case that all of the network resources for many Fortune 100 companies have been inside their firewalls. I am not talking about the mobile user who, on business trips, for example, may need to access corporate resources through Radius servers. I am rather talking about enduring business relationships that cause corporations to open up their perimeters to other entities for specific business reasons, including possibly defining joint deployments together or establishing islands of one corporation within the networks of another. In addition, it is not unknown for some intra-corporate entity to conclude that their activities are too important or too sensitive to trust other corporate entities such that they deploy firewalls internally within the corporation itself. If there is an incongruence between management responsibilities and firewall placement, a subset of devices will be managed across firewalls. Such is life in the subset of the real world with which I am familiar. --Eric Ignoring these relegates any solution to theoretical situations or very small in- home or in-group solutions. Then someone else will have to figure out some way to manage anything larger scale, which will be able to also handle small scale and so will overwhelm the non-firewalling, non-NAT-ing designs. But only after such a relatively impotent design confuses the world by adding yet one more standard to chose from. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
At 12:26 AM +0200 9/7/05, Harald Tveit Alvestrand wrote: I believe that the ISMS WG's proposal is about ADDING the possibility of SNMP over TCP, not about CHANGING SNMP to use TCP. UDP will still work. From: Margaret Wasserman [mailto:[EMAIL PROTECTED] That is correct. UDP and the current SNMPv3 USM security mechanisms will still work. They will also remain mandatory parts of SNMPv3. Whoa, now, Margaret. Your statement is technically accurate that traditional SNMPv3 USM will hopefully co-exist with ISMS indefinitely, and therefore SNMP-over-UDP will remain viable within the historic USM context. However, your statement is inaccurate within the context of this discussion, which is ISMS. I actively supported the formation of the ISMS WG through a series of BOFs because I concluded years ago that SNMPv3 USM is inadequately securable for large deployments (doesn't scale, no PFS, symmetric key distribution problems, etc.), requires us to deploy a unique SNMP-only authentication/authorization system that doesn't integrate with any enterprise wide alternative, and is therefore needlessly expensive and of dubious value within multi-vendor environments. By coupling ISMS with SSH, which currently only operates over TCP, the current ISMS solution being forwarded by the WG is TCP-dependent. TCP doesn't operate effectively in all parts of the deployments which which I am associated. That is why I have been trying to encourage the WG to enable ISMS to be flexibly designed to be deployable in a wide variety of environments on a locally-appropriate manner (i.e., use TCP where it works well and UDP where it works well). This has not happened. --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
You are correct that, in the current plan, the ISMS model would be TCP-based. That is what I meant to state by saying UDP and the current SNMPv3 USM security mechanisms will still work. ISMS will be TCP-based, but UDP/USM will still work -- in fact, it will still also be mandatory-to-implement for SNMPv3 compliance... I did not mean to imply that UDP/ISMS will work, or even that it will ever be defined. Yes, Margaret, we are tracking each other on that point. However, the nature of my objection was that I believe that this state of affairs is unacceptable. Since I have concluded, for the reasons I partially enumerated in my previous post, that historic SNMPv3 USM is unusable for very large deployments, what good is devising an ISMS supplement that is also partly/largely unusable for different reasons (i.e., transport reasons (ISMS) rather than security reasons SNMPv3 USM))? I believe that network management is too important a functionality to be designed such that it can only be usable within highly confined environmental constraints. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what is a threat analysis?
No, Jeff. Most threat analysis with which I am familiar are in regards to a specific deployment or technology within explicit boundaries (i.e., a predefined context). Even so, I would never characterize my own work as addressing all possible threats in that context, because new exploits are continually being devised. One can identify classes of threats and establish controls to address the more worrisome ones within the constraints of ones schedule, budget, personnel, and available technology. Threat analysis provides management with additional information to assist them to make hard choices regarding feature definition and allocation of resources. However, in the IETF context, I imagine that its principal function would be to identify security issues that protocol design may (or may not) seek to mitigate. If it is known during design that the protocol is inherently vulnerable to certain classes of exploits, then perhaps that protocol could be designed with hooks to leverage another technology that addresses those exploits. --Eric From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] Therefore, I fear that either the security community will become even more overworked or else a whole lot of not-very-helpful text will be produced or else non-security people will become de facto security people. I'm hoping for the third result, but I fear the first two. Are your threat analysis covering all the possible threads on the equipement as well as on the installations, processes, services, communities, persons, cultures, etc. behind them? thank you ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what is a threat analysis?
I have mixed feelings about IETF WGs doing threat analysis. On the one hand, Internet security is A Big Deal and I agree with what Steve Bellovin and Brian Carpenter and others have written concerning our need to improve. Frankly, the current status quo is quite worrisome. On the other hand, doing a viable Threat Analysis is a whole lot of work. Those of us who are CISSP certified often find ourselves doing Threat Analysis as a normal part of our job functions. However, a good study often takes weeks or months. I am very skeptical that individuals who are not security professionals will be able to do viable threat analysis studies because so many of the key issues are not obvious to our esteemed non-security brethren. To my mind, the author(s) will receive value from doing such a study. However, only valid studies would be useful to the community as a whole. Therefore, I fear that either the security community will become even more overworked or else a whole lot of not-very-helpful text will be produced or else non-security people will become de facto security people. I'm hoping for the third result, but I fear the first two. --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Voting (again)
Perhaps the IETF traditional motto, rough consensus and working code should be revised to make it clear that the rough consensus goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Is there still an appeal process on the books by which a WG can challenge an IESG AD decision/direction by appealing to the IAB? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Shuffle those deck chairs!
Well said, Joel. At one time, the Internet was a child and needed to be tended by its parent in order for it to survive. Now it is considerably bigger and stronger than its parent. Of course, the parent continues to seek how to most appropriately help its huge offspring. My own feeling is that the Internet is too big, diverse, and needy for any one group -- including its parent -- to meet its needs. The IETF is a useful forum for protocol and technology development, which is one of the important facets required by the Internet. By faithfully leveraging this strength we can assist the Internet. Other groups have other strengths which I hope they will use for the benefit of all. -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 9:01 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Shuffle those deck chairs! I think this is seriously miscontrueing the situation. Different groups participate in the success of the internet in different ways. I have no objection to Debian, Apache, Nortel, or Cisco fighting patents which they believe hurt the internet. That fight is not the job the IETF has demonstrated skill at, or interest in. It is not an end-run of the IETF for another organization to do something the IETF is not interested in doing. It is not a threat to the internet or the IETF for other organizations to help seek the best interest of the internet. In fact it is necessary. And I personally would be very unhappy if the IETF were dragged into the philosophical and legal argument as to whether patents qua patents (whether restricted to software or all inventsion) are a good idea, a bad idea, a good idea gone bad, or some other view. The IETF is not the forum for promoting or advancing such views. Yours, Joel M. Halpern At 10:59 AM 10/21/2004 -0400, Eric S. Raymond wrote: Brian E Carpenter [EMAIL PROTECTED]: I don't think we can require the IESG to negotiate anything. There are all kinds of legal issues there. To my knowledge, both WGs and the IESG do think carefully about this, but often conclude that the default IETF conditions (RAND) are realistic and acceptable. If IETF continues to believe this, groups like Apache and Debian will continue to have to end-run IETF by doing the job of defending the Internet commons that IETF is abdicating, and IETF's authority will evaporate. It is not 1982 or even 1992 any more. Conditions have changed dramatically. I would hate to see IETF dwindle into irrelevance, but that is exactly where statements like this are pointing. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about use of RSVP in Production Networks
Bob, I am interested in learning about any and all production use of the RSVP protocol. I am also interested in RSVP-TE. I am especially interested in learning the experiences of any organization which has deployed the RSVP protocol in production environments. I am interested in how well it performs, how cleanly it meets their business objectives, how well it scales, how hard (or easy) is it to manage, etc. --Eric -Original Message- From: Bob Natale [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:00 PM To: Fleischman, Eric; Dean Anderson Cc: [EMAIL PROTECTED] Subject: Re: Question about use of RSVP in Production Networks Hi, Were Eric's question and Dean's answer limited to RSVP strictly, or would RSVP-TE deployments be of interest? If the latter, then what about emerging deployments of architectures that use RSVP-TE, such as MPLS, GMPLS, and ASON? (Or are none of the news releases true? ;-) Cordially, BobN Original message Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] Subject: Re: Question about use of RSVP in Production Networks To: Fleischman, Eric [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] RSVP is a idea that doesn't cut the mustard in the real world. There are several show-stopper problems with RSVP. 1) somewhat like multicast, anyone using RSVP is vulnerable to others mis-using or mis-configuring RSVP. ISPs several AS's away can really screw up things for other ISPs. Because of this, it is unwise to deploy it because it requires too much trust in other ISPs. That relegates RSVP to the enterprise Lan, where it usually isn't needed. Remember, RSVP is only useful if you have a congestion problem and need to choose which packets to discard. If you have no congestion problem, then you have no need of RSVP. However, having a congestion problem also opens the question of the nature of the congestion and what is the best way to deal that problem. I was involved in a study done by Genuity and Cisco in which the congestion problem was found to most often involve the tail circuit--the link between the customer and the ISP. The best solution for this problem was found to be low latency queuing, not RSVP. 2) Unlike multicast, every hop end-to-end must use RSVP for it to be useful. An RSVP tunnel is useless. 3) RSVP doesn't detect certain kinds of problems that are important. For example, a mid-span failure is not visible to RSVP. While RSVP is important research, it is not a widely deployable technology. What I-D's are you encountering that depend on RSVP? --Dean On Tue, 10 Aug 2004, Fleischman, Eric wrote: I am aware of some use of RSVP in labs but I am not aware of any use of RSVP in production networks (i.e., real life networks people connect to the Internet with). Simultaneously, I am encountering I-Ds and other work planning to use RSVP. This possible disconnect concerns me. Therefore, I would appreciate being educated by anybody using RSVP in production settings. Would you please let me know how many devices, what applications, and how successful these deployments (if any) are? Thank you. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about use of RSVP in Production Networks
I am interested in learning about any production sites using RSVP-TE as well. -Original Message- From: Bob Natale [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:00 PM To: Fleischman, Eric; Dean Anderson Cc: [EMAIL PROTECTED] Subject: Re: Question about use of RSVP in Production Networks Hi, Were Eric's question and Dean's answer limited to RSVP strictly, or would RSVP-TE deployments be of interest? If the latter, then what about emerging deployments of architectures that use RSVP-TE, such as MPLS, GMPLS, and ASON? (Or are none of the news releases true? ;-) Cordially, BobN Original message Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] Subject: Re: Question about use of RSVP in Production Networks To: Fleischman, Eric [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] RSVP is a idea that doesn't cut the mustard in the real world. There are several show-stopper problems with RSVP. 1) somewhat like multicast, anyone using RSVP is vulnerable to others mis-using or mis-configuring RSVP. ISPs several AS's away can really screw up things for other ISPs. Because of this, it is unwise to deploy it because it requires too much trust in other ISPs. That relegates RSVP to the enterprise Lan, where it usually isn't needed. Remember, RSVP is only useful if you have a congestion problem and need to choose which packets to discard. If you have no congestion problem, then you have no need of RSVP. However, having a congestion problem also opens the question of the nature of the congestion and what is the best way to deal that problem. I was involved in a study done by Genuity and Cisco in which the congestion problem was found to most often involve the tail circuit--the link between the customer and the ISP. The best solution for this problem was found to be low latency queuing, not RSVP. 2) Unlike multicast, every hop end-to-end must use RSVP for it to be useful. An RSVP tunnel is useless. 3) RSVP doesn't detect certain kinds of problems that are important. For example, a mid-span failure is not visible to RSVP. While RSVP is important research, it is not a widely deployable technology. What I-D's are you encountering that depend on RSVP? --Dean On Tue, 10 Aug 2004, Fleischman, Eric wrote: I am aware of some use of RSVP in labs but I am not aware of any use of RSVP in production networks (i.e., real life networks people connect to the Internet with). Simultaneously, I am encountering I-Ds and other work planning to use RSVP. This possible disconnect concerns me. Therefore, I would appreciate being educated by anybody using RSVP in production settings. Would you please let me know how many devices, what applications, and how successful these deployments (if any) are? Thank you. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Question about use of RSVP in Production Networks
I am aware of some use of RSVP in labs but I am not aware of any use of RSVP in production networks (i.e., real life networks people connect to the Internet with). Simultaneously, I am encountering I-Ds and other work planning to use RSVP. This possible disconnect concerns me. Therefore, I would appreciate being educated by anybody using RSVP in production settings. Would you please let me know how many devices, what applications, and how successful these deployments (if any) are? Thank you. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Processing of Expired Internet-Drafts
I also concur with this suggestion. This modification would also assist us to find expired drafts containing good ideas but that were either introduced before the community became interested in the topic or else were not renewed due to procedural issues (i.e., not due to their lack of technical merit). I am sure that others in our community are interested in many drafts which we are unable to read due to more pressing local work-related pressures and then are disappointed that we can't find the draft once the work pressures permit us time to read the previously deferred drafts. There are many reasons why some drafts fail to receive resonance and this approach would increase the probability of technically viable ideas not timing out and becoming lost. -Original Message- From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 11:49 AM To: Fred Baker Cc: [EMAIL PROTECTED] Subject: Re: Processing of Expired Internet-Drafts On Wed, Jan 14, 2004 at 08:43:58AM -0800, Fred Baker wrote: It seems to me that there is a better approach to the above, at least in the context of the above. If the tombstone is literally as described, it would be far more space/search/etc efficient for us to have the tombstone consist of an added text line in a file indicating that the named draft expired on a certain date, and keep separate files for the active internet drafts. It seems to me that this makes it simpler to maintain a mirror and to find temporary documents. I would prefer this as well. - Ted
RE: Securing SNMPv3 via SSH tunnels
Uri, I don't think that this list would be well served by a debate on whether SNMPv3's security provisions are adequately secure or not, though I personally would greatly value having a private discussion with interested individuals on that topic. Suffice it to say here that I am familiar with RFC 3414 and RFC 3415 and I am skeptical that existing SNMPv3 security provisions provide adequate protections for the application I am building. I am therefore seeking to supplement SNMPv3's security provisions via mechanisms which are less subject to abuse, which is why I made my original posting to this list. I have no ax to grind in this matter -- I am only seeking after the welfare of our product. It is, of course, possible that I have overlooked something important which would justify your skepticism of my current conclusions. If so, I would value privately benefiting from the wisdom of your insights. I similarly would value learning the insights of any other reader with experience securing SNMPv3 for mission-critical devices which do not sit behind firewalls. --Eric -Original Message- From: Uri Blumenthal [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:32 AM To: Bill Strahm Cc: Fleischman, Eric; [EMAIL PROTECTED] Subject: Re: Securing SNMPv3 via SSH tunnels Bill, what is this about? Eric obviously wasn't aware that the problems he listed applied to the older versions of SNMP protocol, namely SNMPv1 and SNMPv2c. The current standard SNMPv3 (which obsoletes those) is designed specifically to address the listed vulnerabilities. So this whole notion of securing SNMPv3 with SSH is ridiculous. On 8/6/2003 12:34 PM, Bill Strahm wrote: The problem that you have with TCP (and made worse by SSH tunneling on top of it) is that the number of round trips needed to successfully get a data packet through is unreasonably high in a situation where you are attempting to diagnose a network fault. The other choice is to leave a LOT of state open (ie. TCP connections) requiring a lot of extra memory, etc. on the device. That said there is no reason why you can not create a tunnel to a secure environment and run your SNMP traffic from there. Bill On Wed, Aug 06, 2003 at 08:42:49AM -0700, Fleischman, Eric wrote: I am seeking to secure SNMPv3 communications (e.g., RFC 3414), trying to protect against its well-known vulnerabilities such as spoofing. Had SNMPv3 run over TCP, instead of UDP as it does, then I perhaps may attempt to protect it via SSH port forwarding (i.e., SSH tunneling). Coincidentally, I've just read a description in Bob Toxen's book Real World Linux Security (page 141) about an approach he has apparently used of wrapping UDP in TCP and SSH in order to accomplish SSH port forwarding for UDP-based protocols as well. This makes me wonder whether SNMPv3 may be a viable candidate for SSH tunneling after all. I am wondering whether anybody in the list has any insights as to the viability and weaknesses of this suggested approach. I am especially interested in learning how people on this list secure SNMPv3. Thank you.
Securing SNMPv3 via SSH tunnels
I am seeking to secure SNMPv3 communications (e.g., RFC 3414), trying to protect against its well-known vulnerabilities such as spoofing. Had SNMPv3 run over TCP, instead of UDP as it does, then I perhaps may attempt to protect it via SSH port forwarding (i.e., SSH tunneling). Coincidentally, I've just read a description in Bob Toxen's book Real World Linux Security (page 141) about an approach he has apparently used of wrapping UDP in TCP and SSH in order to accomplish SSH port forwarding for UDP-based protocols as well. This makes me wonder whether SNMPv3 may be a viable candidate for SSH tunneling after all. I am wondering whether anybody in the list has any insights as to the viability and weaknesses of this suggested approach. I am especially interested in learning how people on this list secure SNMPv3. Thank you.
RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)
My posting wasn't concerning what I think, it was concerning what is commonly done today in industry. I also didn't intend to imply that the NAT was being used as a firewall, rather that the NAT is commonly used today as an element within firewalls. My own thoughts (which is off-topic) is that traditional firewalls have had their day and remain valuable. However, I am actively pursuing alternatives which perform the same functions without impacting the end-to-end performance of the protocols. Research into several approaches like this have excited me. But then, I've wandered far off topic. -Original Message- From: James Seng [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 10:38 PM To: Fleischman, Eric Cc: EKR; Keith Moore; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: myth of the great transition (was US Defense Department forma lly adopts IPv6) If you need a secure zone, and you want a firewall, then should install a firewall. You should not put an NAT thinking that it is also a firewall. But I agree with you that NAT is here to stay. -James Seng Fleischman, Eric wrote: Eric Rescorla [mailto:[EMAIL PROTECTED] wrote: similarly, people who install NAT usually don't realize how much this costs them in lost functionality and reliability. Really? You have evidence of this? I don't either, but my intuition is that you're wrong. Once you have decided to have a firewall in place (which you may think is evil, but I consider pretty much a necessary evil), I suspect that most people suffer almost not at all from having a NAT. I believe that Eric is pointing out an important point: many deployments of NATs have nothing to do with IPv4 address conservation. Rather, they are firewall adjuncts implemented to hide internal networks from outside scrutiny and direct access. One point where I disagree with my IPv6-advocating friends is that I expect firewall-related NATs to continue to be deployed within Internet (including IPv6) environments until such a time as real-time-protocol and peer-to-peer-protocol friendly distributed firewall (policy zones) variants become the preferable due diligence alternative for CIOs.
RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)
Eric Rescorla [mailto:[EMAIL PROTECTED] wrote: similarly, people who install NAT usually don't realize how much this costs them in lost functionality and reliability. Really? You have evidence of this? I don't either, but my intuition is that you're wrong. Once you have decided to have a firewall in place (which you may think is evil, but I consider pretty much a necessary evil), I suspect that most people suffer almost not at all from having a NAT. I believe that Eric is pointing out an important point: many deployments of NATs have nothing to do with IPv4 address conservation. Rather, they are firewall adjuncts implemented to hide internal networks from outside scrutiny and direct access. One point where I disagree with my IPv6-advocating friends is that I expect firewall-related NATs to continue to be deployed within Internet (including IPv6) environments until such a time as real-time-protocol and peer-to-peer-protocol friendly distributed firewall (policy zones) variants become the preferable due diligence alternative for CIOs.
RE: Thinking differently about names and addresses
Egads. This list is still talking about the Identity Problem (i.e., that IP addresses are semantically overloaded in that they simultaneously indicate (network interface) routing topology and (node) identity). I just can't believe how we can continually talk about this problem and then not embrace solutions to it such as Bob Moskowitz's HIP (Host Identity Payload). All this reminds me of the famous Mark Twain quote where he said Everybody continually talks about the weather but nobody does anything about it!! -Original Message- From: J. Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 10:25 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Thinking differently about names and addresses From: Tony Hain [EMAIL PROTECTED] your general perspective highlights the problem at hand. .. the routing community believes the address is the topology locator, while your Dave's comments show the app community believes it is an identifier. To paraphrase Clint Eastwood (in 'Unforgiven'), Belief's got nothing to do with it. The address field is absolutely required in order to get the packets to where they are going. Therefore, it has to contain information that is organized in such a way as to make the routing work. If the characteristics of that information are such that it's not what the application community want, they really don't have any other choice but to find something else. (I shouldn't need to point out that unless the routing works, the packets won't get there at all, and if the packets won't get there at all, all other debates are moot.) I believe the multi6 discussion about creating a new identifier, to get the app community to stop camping on the topology locator, will end up creating a distributed database infrastructure almost identical to DNS. We don't need two of those, so we should fix DNS. This point was bounced around in the NSRG fairly extensively. I used to believe as you did, that we could use the DNS as a namespace for naming end-end entities. I got a lot of pushback on that from knowledgeable parties, which I am sure they will be happy to rehearse (I'll leave it to them, as they can do a better job of it); I have no religion about the answer. I will also note that the DNS does name things other than end-end entities; e.g. some individual names (for popular services) get translated into the addresses of many different end-end entities. I disagree with the perspective that subnetting or CIDR changed the character of the address. Absolutely - not at this level. It only had to do with how it was organized to make the routing work (see above). Noel
ping and trace route across tunnels
Apologies to the list but I was wondering what the behavior of ping and trace route are across tunnels. That is, if part of my route is an IPv4-in-IPv4 encapsulation tunnel (e.g., IPSec in tunnel mode), and I use either ping or trace route across the whole route, will the tunnel appear as zero hops, one hop, or will each hop in the tunnel appear?
RE: Meeting logistics cost, convenience and risk and RE Deja Vu
I have been reading these many excellent points for eleven days now. However, I note that similar discussions occur after most IETFs. My own preference is that these conversations not occur, since their (almost predictable) recurrence suggests that this is more "venting" than "problem solving", and I'd prefer my mailbox to fill up with material that I can do something about. I therefore suggest that we either discontinue these many threads or else we establish something like POISED to actually do something to scratch these nagging itches. Should we establish a POISED-like discussion, then I would like to introduce the following data points: 1) A coworker of mine is the IEEE Secretary. I've overhead enough of his phone calls to know that IEEE meetings and logistics are scheduled three to five years in advance. 2) The community needs to determine whether fixed locations or variable locations are preferable. Arguments for both alternatives can be made. However, the answer to this question will fundamentally shape the rest of the discussion. 3) The fundamental requirements of any IETF meeting include (increasingly large and increasingly numerous) meeting rooms, extensive terminal facilities with both IPv4 and (increasingly) IPv6 connectivity, excellent wireless connectivity, proximity to many hotels, proximity to many restaurants. It is also desirable that the location have proximity to major airport hub locations. 4) Capabilities for "virtual attendance" need to be enhanced. Remote attendees need to be able to contribute to meetings and respect needs to be shown to them by consistently using microphones. More sessions should also have facilities to enable "virtual attendance". 5) I suggest that historic meeting demographic information be used to determine where the majority of attendees come from. This demographic information should also consider where the majority of IDs and RFC authors reside. I acknowledge arguments to the contrary, however, it is my personal perspective that for the sake of continuity (which I argue is increasingly important within the IETF as it continues to grow), locations favoring continued attendance of this majority are preferable over locations encouraging attendance by new classes of attendees.
RE: [midcom] WG scope/deliverables
Taking your valuable points a bit further, NAT avoidance arguments aren't likely to sell IPv6 to us large end users, because this is a problem for which it is difficult to construct a business case that will excite the non-technical managers who are in charge of blessing large capital expenses. By contrast, what will sell IPv6 will be "Killer Applications" that require IPv6. I am optimistic that advances like the UMTS Release 2000 Cell Phone standard, which requires IPv6, will provide the impetus for us end users to eventually justify the expenses of an IPv6 deployment. Should that business case be made, then 6to4 can ease this newer infrastructure into our systems. Once that occurs, then the advantages of a NAT-less IPv6 would become relevant to us large corporations. As it is, this is a theoretical concern at best to us due to the real-life implications (time, $$$) of deploying IPv6 into our networks compared to the advantages of cheaper stop-gap "solutions" like NATs. By saying this, I don't want to imply that I have any technical disagreement with the arguments that have led many to conclude that "NATs are evil." I am only stating that such arguments alone don't make a good business case. Similarly, while the best current approximations that the H-ratio, which determines when the IPv4 Address Space will be saturated for all practical purposes, will most likely occur in 2002 (i.e., NEXT YEAR) motivates me as a technical person, conveying these concerns into a viable business case that will motivate the "guys with the bucks" is a very different proposition indeed. That is why we need the "escape hatch" which midcom will hopefully provide us with, especially in view of the difficulties which current NAT approaches will introduce as we increasingly deploy peer-to-peer applications within our infrastructures. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] Sent: Friday, February 16, 2001 8:04 AM To: Bernard Aboba Cc: Randy Bush; Melinda Shore; Michael W. Condry; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables Bernard, Exactly. That is why 6to4 came out the way it did - it offers a way for a NATted IPv4 site to introduce non-NATted IPv6 without losing anything or throwing away anything. There are RFCs explaining the issues with NAT technically and objectively. I don't see why this generates comments about anti-NAT religion. It's obvious when you read those RFCs and think about P2P computing that NAT is a problem. If we don't avoid that problem in IPv6 we will have failed as engineers. Brian Bernard Aboba wrote: i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them.
RE: [midcom] WG scope/deliverables
Would such a rendezvous service work if their were NATs between each of the participants and the service itself (regardless of whether it is hosted on a NAT or not)? If so, wouldn't such a solution alter peer-to-peer to become a hub-and-spoke service requiring ISP mediation in the Internet case as opposed to peer-to-peer? -Original Message- From: David T. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 3:41 PM To: Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
