Re: The gaps that NAT is filling
On Fri, 2004-11-26 at 21:47 +, Greg Skinner wrote: On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote: On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Without solutions to these four problems on the horizon, I can't voice any enthusiasm that the larger address space in IPv6 will eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. That is such a odd argument. When an ISP runs out of IP space, they go to their RIR and say Hey! You! I am running out of IP space gimme a new chunk! And then they get one, usually even 3 months in advance of running out. As long as an ISP can show demand for address space they can get it. You do need to have your network documentation in order of course and fit some other rules, but you will get the space. There is *no* address shortage in IPv4 (nor IPv6), see the various very nice presentations by Geoff Huston which he gave at the RIR meetings and other places. On Sat, 2004-11-27 at 11:48 +0100, Leif Johansson wrote: Jeroen Massar wrote: On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote: For somebody administering a network of 100 machines, the hassle cost of IP renumbering would be twenty times larger. Given this, how could anyone wonder why NAT is popular? Wrong. If you administer 100's or 1000s of machines you build or buy a system for doing address management. Renumbering is only difficult if your system is called vi :-) Wrong ;) Well at least, up to 1000 is probably doable. But what if you are talking about 100s or 1000s of organizations with each a 100 or 1000 machines. My site is 10k+ addresses. Seems easy enough to manage to me :-) And how many organizational bits and how many countries are covered using in that address space? I guess, that for most organizations, especially that started early, one is plain lucky when you can even find the administrator of a certain box, let alone the admin or carekeeper of a certain prefix when the organization goes above around that number. If you _can_ manage it, then you did a very good job ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
AdminRest: an attempt at some principles
Since I and a number of other posters have been asking that the AdminRest document move up a step or two and articulate the basic principles that we want the IETF administrative functions to operate under rather than continue to focus on teh operational details I've tried to put together a set of such principles to prime discussion in these principles I have not directly addressed the feeling of some people that the IETF needs to be able to blow the bolts (as I put it a while back) with the ISOC quickly if things go bad in some way. I have not done so not because I want to dismiss or ignore such feelings but because I have not figured out a way to express it if I take into account the fact that the IETF cannot actually go it alone anytime soon because it does not have the cash flow from meeting fees that would support an independent IETF - suggestions welcomed === The following is a mixture of postings from many people (with some of my own ideas tossed in) 1/ The IETF intends to establish a structure (the IETF Administrative Support Activity (IASA)) to get IETF administrative functions managed appropriately, according to good administrative, fiscal, and management principles. The IASA includes an IETF Administrative Director (IAD) and an IETF Administrative Oversight Committee (IAOC). The IASA will be housed within the Internet Society (ISOC). 2/ The IAD, IAOC and the ISOC shall not have any authority over the IETF standards development activities. 3/ The IAD and IAOC, with advice from the ISOC President/CEO and staff, will develop an annual budget for the IASA. The budget must clearly identify all expected direct and indirect expenditures related to the IASA. The ISOC, through its normal procedures, will evaluate and adopt the IASA budget as part of the ISOC's own budget process and commit to ensuring funds to support the approved budget. 5/ The responsibility for the evaluation, review and negotiation of contracts and other IETF administrative and support agreements and other expenditures of funds under the IASA shall rest with the IAD, operating in accordance with policies and procedures set by the IAOC and consistent with ISOC operating policies. 6/ There shall be a detailed public accounting to separately identify all funds available to and all expenditures relating to the IETF and to the IASA including any donations (of funds or in-kind) received by the ISOC for IETF-related activities. In-kind donations shall only be accepted at the direction of the IAD and IAOC. 7/ The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld by the ISOC from the IETF. 8/ The IASA should establish a target for a reserve fund to cover normal operating expenses and meeting expenses in accordance with prudent planning, and ISOC should work with the IASA to build up and maintain the reserve. [note: As an initial estimate, the desired reserve should cover six months of non-meeting operational expenses plus twice the recent average for meeting contract guarantees, but this is a matter for determination by the IAOC and ISOC and is not set specifically in this BCP.) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
AdminRest: Blowing the bolts
Hi. As we try to raise other things back to the level of principles, I want to address one that seems to underlie some of the thinking that has led to what I believe to be too-specific, and probably misguided, provisions in the draft. That underlying theme is, more or less, Suppose ISOC goes crazy, gets into internal financial problems, and decides to divert all available funds into core ISOC staff support, networking on Mars, wild parties, or other non-IETF activities? How do we prevent that and/or be sure that IETF funds and other resources are safe from that process? From talking with some of the advocates of what became Scenario C, a concern like that is part of what drove them to want some structure completely separate from ISOC. And, despite the decision to proceed toward Scenario O, it appears that the theme keeps recurring, so maybe we should just take a real look at it. It seems to me that there are three issues: (1) Are there safeguards that lower the odds of a serious problem with ISOC and reduce the risk of requiring a separation to an acceptable level? (2) To the extent to which good, and clear, agreements make good relationships, what style of provisions are needed? (3) If we should be thinking about things in terms of blowing of explosive bolts, at what points should such bolts and separation points be installed? The first of these comes dangerously close to revisiting the Scenario O decision, but, since the issue doesn't seem to want to go away from I* thinking despite the community's decision, maybe it is worth opening explicitly. Let me take the three in turn: (1) Existing safeguards. At least in the conversations I have had, two themes have arisen about the need for safeguards in how ISOC deals with the IAOC (and IASA more generally). One is tied to the perception that CRNI has become non-responsive to IETF requests (the validity of that perception for different areas is a different issue) and asking what would prevent ISOC from going down a similar path. The other recalls ISOC's financial problems of a few years ago and the desire of some of the then-members of the ISOC Board to shift resources away from the IETF and toward other activities. ISOC saw that Board behavior as a problem, and instituted some major structural changes to to prevent recurrences while continuing to support IETF at requested levels. We've now got IAB-appointed members of ISOC's Board and, by contrast, have never had IETF-appointed or approved members of CRNI's Board. While the IAB-appointed members of ISOC's Board do not represent the IETF, IAB would need to turn quite stupid to appoint people who could not be reasonably assumed to consider and advocate for things that are as obviously in the IETF's interest as not diverting IETF-designed funds for other purposes. If the IAB were to turn that stupid, we have problems that no text in a BCP is going to solve. And, as I have said before, my own experience is such that I actually prefer an organization that has had problems, faced them, and dealt with them effectively than one that does not yet exist and whose behavior under stress therefore cannot be predicted. We are also structuring this arrangement so that it is basically an IETF support arrangement, rather than a service that ISOC is carrying out for the IETF at their discretion (which is probably a reasonable description of the CNRI relationship). The two situations are very different; trying to build plans that start from the assumption that they are, or might be, equivalent, just does not impress me as completely rational. (2) Agreements. Let me argue, as others have, for principles here, not micromanagement specifics. I think Margaret's outline is a little too abstract, but there is a middle ground between it and talking about bank accounts. I think Bernard's idea/ analogy to pre-nuptial agreements is probably exactly right, and I believe that we need to get competent professional advice on how one of those should be structured and what needs to be in it ... not start slipping bank account or equivalent provisions into a BCP based on the financial administration experience of the IESG and IAB. Even from the standpoint of my limited knowledge in the area, there is a huge difference between asking for separation of funds and sound accounting and administrative practices or even escrow arrangements and getting down to bank accounts and lengths of times funds can be held. I note that, in general, prenuptial agreements are arrived at by parties who like and trust each other, expect and intend to make the relationship work, and expect to put effort into making it work. When those relationships don't hold, the parties don't need prenuptial agreements; they need to not get married. FWIW, my interpretation of the Scenario O decision is that we have decided to get (a little more) married. (3)
Re: AdminRest: an attempt at some principles
in these principles I have not directly addressed the feeling of some people that the IETF needs to be able to blow the bolts (as I put it a while back) with the ISOC quickly if things go bad in some way. I have not done so not because I want to dismiss or ignore such feelings but because I have not figured out a way to express it if I take into account the fact that the IETF cannot actually go it alone anytime soon because it does not have the cash flow from meeting fees that would support an independent IETF - suggestions welcomed How about: section title=Community Consensus and Grant of Authority t The IETF is a consensus-based group and authority to act on behalf of the community is an act that requires a high degree of consensus and the continued consent of the community After a careful process of deliberation, there is a broad-based community consensus to house the IETF Administrative amp; Support Activities (IASA) within the Internet Society, which is reflected in this Best Current Practice (BCP) RFC./t t Termination and change. Any change to this agreement shall require a similar level of community consensus and deliberation and shall be reflected by a subsequent Best Current Practice (BCP) RFC. /t /section A termination clause is standard in any agreement and this one simply says if you want to change this, get another bcp through the process. This doesn't address the and we want to take our money with us issue, but I believe that could be addressed elsewhere or not addressed at all. Either way works for me. 2/ The IAD, IAOC and the ISOC shall not have any authority over the IETF standards development activities. That's almost true, but you probably need to address that the fact that ISOC does play an important role in the standards process, a role that is not changed by this document. 7/ The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld by the ISOC from the IETF. how about withheld or limited in any way? Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: an attempt at some principles
Carl asks: how about section title=Community Consensus and Grant of Authority t The IETF is a consensus-based group and authority to act on behalf of the community is an act that requires a high degree of consensus and the continued consent of the community After a careful process of deliberation, there is a broad-based community consensus to house the IETF Administrative amp; Support Activities (IASA) within the Internet Society, which is reflected in this Best Current Practice (BCP) RFC./t t Termination and change. Any change to this agreement shall require a similar level of community consensus and deliberation and shall be reflected by a subsequent Best Current Practice (BCP) RFC. /t /section I think that is fine but I don't think it addresses quite the issue I was talking about - Klensin's Blowing the bolts posting is closer to the issue - a number of people seem to want a principle that the AdminRest should structure the IASA and its accounts (such as a seperate bank account) in such a way to enable fast bolt blowing - I think that your 2nd pp is closer to mechanism than principle but I do not know how to formulate the principle (the logic in Klensin's posting aside). 2/ The IAD, IAOC and the ISOC shall not have any authority over the IETF standards development activities. That's almost true, but you probably need to address that the fact that ISOC does play an important role in the standards process, a role that is not changed by this document. note that what I'm trying to get at here is that the IAD, IAOC and the ISOC can not tell the IETF to adopt or not adopt a technology I thought about the point Carl raises and came to the conclusion that no authority of the *standards development activities* was accurate - the ISOC BoT does accept the process documents that have been developed using IETF processes but can not change such documents on its own, the boT also approves the IAB slate but that did not seem to me to be controling the standards development activities - the thing that comes closest in theory is that the ISOC BoT can act as the final step in an appeal that claims the standards process is flawed but in any such case I would expect the BoT (if the appeal were to be successful) would point out to the IETF what the problem was and leave it to the IETF to figure out how to fix it not change the process by itself in any case I think that the basic principle is that these groups have no authority of the standards development activities is a clean one to state - elsewhere in the document the details about approvals and appeals can be explained 7/ The right to use any intellectual property rights created by any IASA-related or IETF activity may not be withheld by the ISOC from the IETF. how about withheld or limited in any way? that is a better thing to say Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Finances and Accounting - principles
--On Friday, 26 November, 2004 20:08 -0500 [EMAIL PROTECTED] wrote: On Fri, 26 Nov 2004 19:16:58 EST, Sam Hartman said: Personally, I do believe that stating some details would help me evaluate whether IASA is seperable and would require the IETF's consent in order to change the details. I do think that requiring IASA keep separate bank accounts is probably desirable at the BCP level. OK - I admit I've Just Hit Delete on much of this discussion - but care has to be taken with separate bank accounts. We *do* need some way to prevent IASA from separating (either at their request or ours) and then find out all the money was in their account not ours (OK.. maybe I'm just paranoid on that one, having been on the losing end of a been there done that in my personal life. :) This is interesting. Almost all of the discussion about separate bank accounts, etc., has been focused on protection of the IASA from ISOC. But you drew the other inference, which I discussed at more length in my blowing the bolts note, i.e., that it is at least as likely that the IETF might need protection from the IASA or even, once large amounts of money are involved, from some combination of the IAB, IESG, and IASA. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: Executive Director
--On Friday, 26 November, 2004 16:40 -0500 Sam Hartman [EMAIL PROTECTED] wrote: I think the IESG's concern here is that they, rather than the IAOC would like to designate who the executive director is. The executive director is very involved in making the IESG and process functions run smoothly. It seems like significant friction would be created if the executive director was not someone the IESG was comfortable with. Sam, While I understand and sympathize with the concern you raise, the whole model so far --as developed much more by the IESG and IAB than by the community, so it presumably meets their needs -- is that we constitute an IASA and IAOC, and then let them run the details. If the IESG asserts the right to start appointing (and presumably firing) particular individuals, especially individuals who, under the current model, are contractors, we are down the slippery slope toward a level of IESG management of the administrative process that calls for a completely different model. It seems to me that it might be reasonable to expect the IAD to seek the advice, and maybe the consent, of the IESG on an Exec Dir appointment. But going much further than that requires a rather different model. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
I'm sorry to reply so long after the fact, but... On 23-nov-04, at 3:12, Hans Kruse wrote: However, most SOHO sites look for a zero-order level of protection against the random worm trying to connect to an open TCP port on the average windows machine (especially one set up for file/print sharing on the SOHO network), and NAT does that just fine. IPv6 marketing has to take this into account, with a deliberate here is why the IPv6 gateway provides the same default protection as NAT... FAQ entry. Actually in IPv6 you are well-protected against random scanning withough the need for any device in the middle: a /64 subnet is so large, that scanning it is completely infeasible. Now of course someone who knows your address doesn't have to scan, so this protection isn't complete. But for TCP it's entirely trivial to only allow sessions to be set up in one direction. Full stateful firewalling is of course also possible. However, both these options bring back some of the downsides of NAT: in order to make incoming sessions possible, there must be configuration of some sort. A default filter that rejects packets for services that are generally intended for local use only would probably be good enough for a residential IPv6 router. Other services are either not enabled and/or firewalled in the host anyway, or the user actually wants them to work. (It would be incredible helpful to have all these local-use services in a fixed range of port numbers for easy filtering...) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
The IETF is supposed to gather everyone concerned and there is here a controversy on this real life and key/vital point. So the best is to ask in here. If no one says yes, it will mean either there is no felt shortage yes, or that those suffering from shortage do not share in the IETF (why would then be another question). If some says yes, this kind of universal affirmation will be closed. At 11:07 28/11/2004, Jeroen Massar wrote: Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. That is such a odd argument. When an ISP runs out of IP space, they go to their RIR and say Hey! You! I am running out of IP space gimme a new chunk! There is *no* address shortage in IPv4 (nor IPv6), see the various very nice presentations by Geoff Huston which he gave at the RIR meetings and other places. Has anyone present on this list ever experienced a problem in getting a new chunk of IP addresses from a RIR or from an ISP? What is the average delay you experiment? Thank you. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: an attempt at some principles
An earlier comment from Brian Carpenter, to which several people agreed, indicated that we should consider the need for an IETF sunshine law separately from the IASA structure. i didn't agree but i didn't want to use everybody's time arguing about it, and i still don't. but it turns out that that's a different fishkettle. all i'm asking for at the moment is that transparency be mentioned whenever consensus is mentioned. what kind of transparency, or what kind of consensus, we mean can be defined elsewhere. changing consent to informed consent might also be a good idea but is inadequate alone -- we talk a lot about consensus (rough, after clark et al), and we have to start talking about transparency just as often. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: an attempt at some principles
all i'm asking for at the moment is that transparency be mentioned whenever consensus is mentioned. what kind of transparency, or what kind of consensus, we mean can be defined elsewhere. changing consent to informed consent might also be a good idea but is inadequate alone -- we talk a lot about consensus (rough, after clark et al), and we have to start talking about transparency just as often. I have no objection to mentioning transparency as a key attribute of the IASA structure. Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: Blowing the bolts
At 10:16 AM -0500 11/28/04, John C Klensin wrote: Hi. As we try to raise other things back to the level of principles, I want to address one that seems to underlie some of the thinking that has led to what I believe to be too-specific, and probably misguided, provisions in the draft. snip... (2) Agreements. Let me argue, as others have, for principles here, not micromanagement specifics. I think Margaret's outline is a little too abstract, but there is a middle ground between it and talking about bank accounts. I think Bernard's idea/ analogy to pre-nuptial agreements is probably exactly right, This is something ISOC believes could be quite helpful as well. and I believe that we need to get competent professional advice on how one of those should be structured and what needs to be in it ... As a way of moving forward, I'd like to suggest the pre-nuptial be something the IASA Transition Team looks into as a priority, and then reports back to the community. This would set context for the next level of discussions below. not start slipping bank account or equivalent provisions into a BCP based on the financial administration experience of the IESG and IAB. Even from the standpoint of my limited knowledge in the area, there is a huge difference between asking for separation of funds and sound accounting and administrative practices or even escrow arrangements and getting down to bank accounts and lengths of times funds can be held. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
AdminRest: IASA BCP: Trusting whom to do what
An observation, speaking as an individual (not as doc editor): As far as I can tell, the decision about whether or not the IETF is trusting ISOC as our partner in the IASA effort was settled by the apparent consensus that we should follow the Scenario O path. I'd respectfully suggest that, unless someone seriously proposes revisting that decision, it is a bit late to be deciding whether or not to trust ISOC. What we need to do now is spell out what it is that the IETF is trusting ISOC to do. Thus, my own personal opinion on the current discussion (as opposed to my confusion on what the IETF wants me and Bert as doc editors to put in the draft BCP) tends to side with the folks who suggest that: a) We don't need to nail down issues like separate bank accounts in the BCP; but b) We -do- need to specify both what we expect ISOC to do and what we expect ISOC -not- to do. There are functions we want ISOC to perform for us (fundraising, office support for the IAD, etc) and functions we don't want ISOC to perform (chosing contractors for IASA without IASA being involved, making unilateral decisions about the disposition of funds that the IETF considers to be its own, and so forth). Words in a BCP are not going to prevent a hypothetical ISOC-gone-amok from doing things that the IETF will think are wrong; in such a case, I expect that detail issues will have to be left to the folks on the ground, because we're never going to be able to cover all the possible ways that said hypothetical ISOC-gone-amok might go off the rails. Words in a BCP might, however, provide some kind of useful objective basis for figuring out whether ISOC has done and is doing what the IETF asked ISOC to do. I'll now go back to watching the discussion in progress, trying to figure out what y'all want me and Bert to put in the document. --Rob ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: do we need dedicated IASA (bank) accounts
At 12:15 AM 27/11/2004, Wijnen, Bert (Bert) wrote: In revision draft-ietf-iasa-bcp-00.txt we have text in sections 5 through 5.4 about IASA funding and where the money needs to be kept. Specifically, the current text suggests that there is/are one or more IASA specific bank accounts. Namely: - Sect 5.1 says that meeting revenues go into IASA account. When I wrote that text I meant IASA bank account, so if that is what we (IETF) want, then needs to be made more explicit. - Sect 5.2 says that designated monitary donations go to the IASA account. Again, I meant to write IASA bank account. So need clarification if that is what we (IETF) want. - Sect 5.3 I think (I/we) intended (but is not explicit) to also have the quarterly deposits go into IASA bank account. So again needs clarification if that is what we (IETF) want. - Sect 5.4 talks about reserve fund being kept in reserve for use by IASA. It is not specific how this is done. Current text leaves that up to ISOC to decide/arrange. We have seen a few people raise concern about the above. Concerns that I have seen raised and to which I would like to see the IETF community speak their preference: - should we (IETF) indeed have/request an IASA specific bank account for collecting meeting fees? yes - should we (IETF) indeed have/request an IASA specific bank account for depositing designated monetary donations? yes - should we (IETF) indeed have/request an IASA specific bank account for depositing ISOC controbutions to the IASA (as budgeted)? yes - if yes to previosu question, should we (IETF) be so prescriptive in sect 5.3 about when ISOC puts money in an IASA (bank) account (e.g. quarterly and in equal portions) ? yes - should we (IETF) request/require that the reserve fund is kept in an IASA specific bank account. yes I'll head into reasons if so requested, but as you've asked for preferences, I've provided them Geoff ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
[EMAIL PROTECTED] (Jeroen Massar) wrote on 23.11.04 in [EMAIL PROTECTED]: This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. Actually, they do - with some qualifications - at least over here, in Germany. That is, if you still use dialin over the phone network, I believe at least some still charge by time as that is what they are charged by other phone companies for transport. That's what non-packet networks are like. Then, private end users - or others who behave like them - can opt for flat rates. Pretty much everything else is by bandwidth. The unfortunate problem here is that you usually only get static or multiple IPs with bandwidth accounting, and full use of a flat rate is typically vastly cheaper than the same amount of bandwidth via bandwidth accounting. Which means there's a premium to *enter* the static IP market. Once you're there, additional IP space is often free of any cost. (Well, you need to fill out the RIPE forms so your ISP has something to point at if they get audited.) MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
[EMAIL PROTECTED] (Margaret Wasserman) wrote on 23.11.04 in [EMAIL PROTECTED]: The average Internet user (home user or enterprise administrator) does not care about the end-to-end principle or the architectural purity of the Internet. Maybe not the average usr, but a pretty large subset *does* care - because it makes it extremely hard to do what they want: to make a connection to their small business network (behind a dynamic IP) from somewhere else (also behind a dynamic IP). It's possible (using one of a large number of dynamic DNS providers), but it is neither obvious nor trivial - in fact, it is hard for them to understand even what the problem is. I just yesterday talked someone through this - a (small) business net admin wanting to access that net from home. This was someone who does database programming and at least sometimes creates networks for customers. And he *still* had a hard time with the consequences of dynamic IP and NAT. No, it's not the majority - but yes, it *is* a pretty significant subset. You don't need to be all that far apart from average to bloody your nose on this. (2) One-way connectivity could be provided via stateful firewalls instead of via NAT. You don't need all that much state for most of the protection. Just looking at TCP SYN does cover about 75% of the problem, I'd say, and that's completely stateless. (Not to say that the other 25% aren't important.) MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
[EMAIL PROTECTED] (Leif Johansson) wrote on 27.11.04 in [EMAIL PROTECTED]: Jeroen Massar wrote: On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote: For somebody administering a network of 100 machines, the hassle cost of IP renumbering would be twenty times larger. Given this, how could anyone wonder why NAT is popular? Wrong. If you administer 100's or 1000s of machines you build or buy a system for doing address management. Renumbering is only difficult if your system is called vi :-) Wrong ;) Well at least, up to 1000 is probably doable. But what if you are talking about 100s or 1000s of organizations with each a 100 or 1000 machines. My site is 10k+ addresses. Seems easy enough to manage to me :-) If you have servers on your segment, they get addresses from the X..Y pool. Otherwise, you use DHCP, or you get fired. Something like that? Seems a fairly obvious solution. MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
[EMAIL PROTECTED] (Eric S. Raymond) wrote on 22.11.04 in [EMAIL PROTECTED]: Fred Baker [EMAIL PROTECTED]: I submit that if your environment is at all like mine, you don't actually configure 192.168.whatever addresses on the equipment in your house. You run DHCP within the home and it assigns such. That being the case, you actually don't know or care what the addresses are on your equipment. You care that your SIP Proxy and etc know the relationships, and they derive them directly without your intervention. Actually, I do set up static addresses. I'd use DHCP, but if I did that I would not be able to refer to the machines on my local net by name. Until my DHCP client can update my DNS tables with name information on the fly, I'll keep doing doing it this way. Apple's zeroconf technology solves this problem, albeit in a slightly different way, but Linux doesn't deploy it yet. It doesn't? Then pray, what is it I use at the job that does exactly this? (Hint: ISC DHCP 3 ISC BIND 9, running on a Debian woody/sarge hybrid install.) Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS update. I don't think my situation is unique. It's at least rather strange. MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
[EMAIL PROTECTED] (JFC (Jefsey) Morfin) wrote on 21.11.04 in [EMAIL PROTECTED]: packet-switch networks. The internet (small i) is not even defined in the French law where the word is broadly used and understood as the generic support of the on-line public communications and the digital ecosystem of the nation. I suppose the German legal understanding is equivalent since the French law applies the European directive. I'm not aware of any German law talking specifically about the Internet (needs to be capital I in German). The RegTP (the regulators, regtp.de) talk quite a bit, and IIRC once so did the Kartellamt (our version of the Monopolies and Merger Commission), but no laws that I know of. And of course our politicians like to talk about it just as much as the US ones. I can't make much sense of the rest of your message. I see that you're passionate for *something*, but what is very unclear; you seem opposed to the IETF, but for no sensible reason I can determine. Oh, and you seem to trust the market far more than I do - you sound positively US in that respect. Do not think that Yankees will understand us ... I'm beginning to think it's the French who understand differently. (The US just often plain do not know what happens outside their borders.) Can you have an IP address associate with your ISDN? That doesn't even make sense! Can you use X.25 on your ISDN? With whom? X.25 seems to be dead as a doornail. OSI is too rigid for them In fact, *OSI* is mostly dead as a doornail. MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
[EMAIL PROTECTED] (Stephen Sprunk) wrote on 21.11.04 in [EMAIL PROTECTED]: Thus spake Kai Henningsen [EMAIL PROTECTED] [EMAIL PROTECTED] (Stephen Sprunk) wrote on 20.11.04 in [EMAIL PROTECTED]: ISTR that the local competition (the one who's laying down cables like crazy, pretty much every time a street is dug up) That's also a major difference; our local competition re-uses the cable plant of the incumbent carrier. Streets being torn up is largely due to long-haul carriers (which mostly lay their own fiber, or swap strands on different routes) putting new fiber down; nobody here lays new copper when there's old copper still available. No, the people I talk of (citykom.de) seem to lay down lines when the street is dug up for some other reason, so as to already have it when customers show up. Back from when they were started owned by city services, it seems they still have good contacts. *Other* carriers indeed tend to simply rent the last mile from the ex- monopoly (at regulated prices). (Or when we're talking DSL, just connect to the DSL endpoints customers rent from the ex-monopoly with their ciscos or whatever, and go on from there.) Caller ID, Call Waiting, Three-Way and other extra services were added to POTS lines here quickly after ISDN was available or even at the same time, so there was little incentive for non-data users to switch to ISDN at all. I have the impression some of that got added to POTS, but there was very little consumer interest (apart from being able to suppress CallerID). The general impression seems to be that people who want that want ISDN. And anyway, S2M (30 channels on one pair) means big business definitely wants ISDN. Well, ours aren't toll-free either way. Or to expand, there seem to be a few tariff experiments with free calls on weekends and stuff like that, but IIRC those aren't limited to local calls. regulates differently) across entire cities. ISDN subscribers pay tolls for data calls and sometimes even voice calls regardless of distance, though Another differentation that over here only exists in the mobile market. It was originally designed as an add-on to POTS here, and I'm not sure it's even possible to add ADSL onto an ISDN line. The latter seems pointless, as I heard - don't know if it's correct - that Deutsche Telekom actually drove the development of whatever changes were necessary to do ADSL together with ISDN. Something about frequency differences? Very few sources for DSL modems when they started, and not able to cope with demand for quite a while (both not enough modems and not enough line cards) - which sounds compatible with the previous paragraph. the only advantage of ISDN over POTS is data rate, and DSL blows both of them away. But DSL does not work (at least pre-VoIP) for end-to-end phone connections. ISDN does. Anyway, the point was that many people - mostly exactly those who would be interested in DSL - *already had* ISDN. And thus a digitally-capable copper pair. Incidentally, I suspect a lot of the drive behind ISDN was that (a) we had lots of copper pairs in use (perfectly fine to do ISDN on), and (b) using ISDN meant more channels without more copper pairs - laying new pairs is expensive. MfG Kai ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Last-Call comments on 'The Standard Hexdump Format ' draft-strombergson-shf-03.txt
Re: http://www.ietf.org/internet-drafts/draft-strombergson-shf-03.txt The Last-Call for this document caught my eye when it went past on the IETF mailing list and I'm interested (having written too many Intel-HEX and S-record parsers in the past). I'm ignorant of whether there is a deployed base of this format, so I shall assume there isn't. (Not that it matters much either way for my comments.) Firstly, some typographical detail that should be easy to fix: * In section 2 the notation 2^n for two to the n'th power is defined. However, it is almost never used; throughout, we have confusion like larger than 232 bits (presumably 2^32) and (264)-1 bits (2^64). This should be fixed before publication. * section 5, 5th para: typo receiveing * section 10, 1st para: typo exending Now on to my main problem with the document as it stands: In section 5 SHF rules and limits: | o The words inside a Dump may be in the native endianness of the |consumer, since this represents raw memory. However implementers |may choose to store also this data in a Big Endian format for ease |of reading: Big Endian values are more human-readable than Little |Endian ones. This is no good for interoperability. If you're going to allow data to be of either endianness, you should tag the block with the endianness of the contained data (and when I say should, I mean it should be required with MUST). And finally, some more handwavey comments, which can probably be ignored as you see fit. * Why is the name attribute of block mandatory? (If I'm converting from H32/Srec, I'm not going to have anything to put here. This is likely to be the case in other situations too.) * I'm not convinced that a count of blocks in the dump tag is a good idea in XML, but I can't offhand say why. I'd have thought that if you have an XML parser to hand you're unlikely to need such a thing, but I'm not that familiar with the practicalities of XML, and don't know whether there's precedent for this. What should one do if the blocks attribute turns out to be untrue? (The same question applies to the length attribute of block.) * SHA-1 seems a bit heavy for a checksum, probably ruling out verification on many embedded systems. What are we trying to protect against here? * One application of this format is for automatic conversion to/from Intel HEX / S-Records, by tools that know nothing about the intended consumer. I believe that it meets this requirement (apart from name as noted above); the endianness issue doesn't bite because these formats are always 1 byte wide. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
On Tue, 23 Nov 2004 14:11:19 +0100, Jeroen Massar wrote: On Tue, 2004-11-23 at 07:03 -0500, Margaret Wasserman wrote: Without solutions to these four problems on the horizon, I can't voice any enthusiasm that the larger address space in IPv6 will eliminate NAT in home or enterprise networks. This really isn't a problem of the IETF. The problems is at the ISP's who should charge for bandwidth usage and not for IP's. It is all a financial problem, people earn money this way, and there is not an easy way you can let them not make money. Actually, can you blame them? I can't unfortunately... Arguably, if the ISPs handed out a (static) IP to every customer, soon they'd be out of IPs, and thus unable to grow their businesses from that perspective. --gregbo ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Kai Henningsen [EMAIL PROTECTED]: Oh, sorry. Not *exactly*. It's the DHCP *server* which does the DNS update. My DHCP server is firmware in my Linksys :-). -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
WG Action: Sieve Mail Filtering (sieve)
A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Sieve Mail Filtering (sieve) Current Status: Active Working Group Chairs: Cyrus Daboo [EMAIL PROTECTED] Alexey Melnikov [EMAIL PROTECTED] Applications Area Director(s): Ted Hardie [EMAIL PROTECTED] Scott Hollenbeck [EMAIL PROTECTED] Applications Area Advisor: Ted Hardie [EMAIL PROTECTED] Mailing list: [EMAIL PROTECTED] Subscriptions: mailto:[EMAIL PROTECTED] List archive: http://www.imc.org/ietf-mta-filters/mail-archive/ The sieve mail filtering language specified in RFC 3028 has now been implemented in a wide variety of user agents (UAs), mail delivery agents (MDAs), and mail transfer agents (MTAs). Several extensions have been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely implemented. Several additional sieve extensions have been defined in various internet-drafts. All of these documents are individual submissions; up to this point work on sieve has been done informally and not under the auspices of any IETF working group. The sieve working group is being chartered to: (1) Revise the base sieve specification, RFC 3028, with the intention of moving it to draft standard. Substantive additions or revisions to the base specification are out of scope of this working group. However, the need to loosen current restrictions on side effects of tests as well as the need for a normative reference to the newly-defined comparators registry may necessitate a recycle at proposed. (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598), spamtest/virustest (RFC 3685), and copy (RFC 3894) extension specifications, again with the intention of making a move to draft standard possible. It may be necessary to recycle some or all of these documents at proposed, depending on the scope of any changes. (3) Finalize and publish the sieve extensions as proposed standards: (a) Variables (draft-homme-sieve-variables-04.txt) (b) Vacation action (draft-showalter-sieve-vacation-05.txt) (c) Message body tests (draft-degener-sieve-body-02.txt) (d) Regular expressions (draft-murchison-sieve-regex-07.txt) (e) MIME part tests (draft-daboo-sieve-mime-00.txt) (f) Notification action (draft-martin-sieve-notify-02.txt) (g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt) (h) Header editing actions (draft-degener-sieve-editheader-01.txt) (i) Reject before delivery (draft-elvey-refuse-sieve-01.txt) Additional drafts may be added this list, but only via a charter revision. There must also be demonstrable willingness in the sieve development community to actually implement a given extension before it can be added to this charter. Some aspects of sieve have complex internationalization issues; the working group will seek out internationalization expertise as needed to complete its work. Goals and milestones: (Done) Submit revised variables draft. (Oct 04) Submit revised vacation draft. (Nov 04) WG last call for variables draft. (Dec 04) Initial submission of RFC 3028bis. (Dec 04) WG last call for vacation draft. (Jan 05) WG last call for RFC 3028bis. (Jan 05) Initial submission of revised relational draft. (Jan 05) Initial submission of revised subaddress draft. (Jan 05) Initial submission of revised spamtest/virustest draft. (Jan 05) Submit variables draft to IESG. (Jan 05) Submit vacation draft to IESG. (Jan 05) Submit revised editheader draft. (Jan 05) Submit revised imapflags draft. (Feb 05) Submit RFC 3028bis to IESG. (Feb 05) WG last call of revised relational draft. (Feb 05) WG last call of revised subaddress draft. (Feb 05) WG last call of revised spamtest/virustest draft. (Feb 05) Submit revised body test draft. (Feb 05) Submit revised reject before delivery draft. (Feb 05) WG last call for editheader draft. (Feb 05) Submit revised relational draft to IESG. (Feb 05) Submit revised subaddress draft to IESG. (Feb 05) Submit revised spamtest/virustest draft to IESG. (Feb 05) WG last call for imapflags draft. (Mar 05) Submit revised notification action draft. (Mar 05) WG last call for body test draft. (Mar 05) WG last call for reject before delivery draft. (Mar 05) Submit editheader draft to IESG. (Mar 05) Submit imapflags draft to IESG. (Apr 05) Submit revised MIME part tests draft. (Apr 05) WG last call for notification action draft. (Apr 05) Submit body test draft to IESG. (Apr 05) Submit revised reject before delivery draft to IESG. (May 05) Submit notification action draft to IESG. (May 05) WG last call for MIME part tests draft. (May 05) Create list of core sieve features; collect implementation information for interoperability report. (Jun 05) Submit MIME part tests draft to IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
