Re: Number of Firewall/NAT Users
In message <[EMAIL PROTECTED]>, Keith Moore typed: >>> The IETF has done it's job with 6to4, but like you said we can't force >>> people to deploy it. But let's stop and think about 6to4. Aren't some of >>> the same "tricks" or ALG's that are planned to make applications work >>> with IPv4 NAT, applicable to 6to4? If so, then we must find solutions >>> now since 6to4 could be with us for many years. >>Given that the whole point of 6to4 is to allow IPv6 packets to be >>passed end-to-end without modification, I don't see how ALGs apply at >>all. NAT-PT of course has similar issues to v4 NAT, but NAT-PT and >>6to4 are different things. Keith 2 ways forward are 1/ what you propose - provide clean, alternate complete solutions for today's ISPs - 6to4 is only part of a big system deployment- it would be nice to come up with smaller stageing posts along the waysomething i've wondered about: NAT is predicated at least partly on the observation that a lot of internet users don't appear to need to be "always on" (i.e. like temporal locality (not spatial locality) of telephone nets, there's a distribution of use and it means that we can get away with far less address allocated than users. I would suggest that if an ISP asks for address space based on a number of users but then uses NATs they are misrepresenting the number of users and should be given less address space:-) (i think this is doubly fair since they make less use of addreses, AND less applications are able to run to and from their users) 2/ make a clear business for ISPs to offer NAT free access as a competetive advantage 3/ here's a silly idea - take some of the address space and make it client only. (i.e declare half the remaining address space to be assymetric - truth in advertising... since there's then no servers, you can use port expanders on the low 1024 bits of the tcp or udp port to get more addresses(yes, port nats, but as part of the official address allocation plan...) cheers jon
New Internet Service
Welcome to the premiere edition of the "Get2Nic News" Newsletter! In this edition we will introduce you to "The NIC"-A new internet computer that uses an easy system to get you online as soon as you open the box! You will discover new products, a trustworthy ISP, Marketing opportunities, and Family Safe links! Welcome to Get2NIC! Discover NIC-The New Internet Computer! The New Internet Computer (NIC) is a simple, inexpensive Internet computer that brings users easy email and Internet access. NIC uses a simple process to get you online as soon as you open the box! The system includes all the necessities to enjoy the net. It also includes 6 months of internet service! For more information on this new and exciting product please click here! Click on NicSir Surfing Links! Tired of all the confusion with search engines? Try NicSir! NicSir has 1000s of links divided by category for your surfing pleasure. To go directly to NicSir Surfing click here! ZiplogMail-Free Spam & Virus-Proof E-mail Accounts. Visit get2nic.com and discover ZiplogMail! ZiplogMail is the world's first Virus & Spam proof Online e-mail protection technology. ZiplogMail was developed by InterKidnet Technologies and sponsored by mothersofamerica.com and other corporations promoting family-safe Internet technologies. It is accessible world wide. An additional advantage of ZiplogMail is that members are not required to install any new software. ZiplogMail brings you personal and password protected e-mail communication in a globally-retrievable format. Click here to sign up today! It's fast, easy and it's free! Come travel with Get2nic.com! To book one of these exciting offers now or for further details you can call Jimmy Brent at 757-563-2020 or click here! Get2nic.com Organization and Group Fundraising! Raising capital is an ongoing process for most organizations. The reason is that most fundraisers only provide temporary funds. This makes achieving goals a bit more challenging. Your organization has probably spent a great deal of time, money and energy developing different types of fundraising events each year. But as you know, once the event is over, the revenue stops and the cycle must start again. get2nic.com is happy to offer a program that provides continuous revenue long after the end of the initial campaign. Associations, groups and non-profit organizations can earn thousands of dollars through sponsorship of our long distance and internet services to its members. This is truly a win-win situation! The concept of collective buying to obtain volume discounts is certainly not unique. Neither is the idea of sponsors providing benefits to members and associates that they could not acquire alone. Such ideas are the backbone of franchise businesses, chambers of commerce, credit unions, buying groups, consortiums or other organizations that form in order to achieve stronger positioning, improved service or better pricing. As you know, fundraising is becoming more and more difficult every day. Our Fundraiser program addresses this difficulty by providing residual income to your organization. The central theme for our Affinity program is to provide the members of your organization with real cost reductions on their long distance and internet services, while providing the organization with an effective revenue generating vehicle. Every month we will pay you 8% of every long distance call your members and supporters make as well as 8% on their get2nic internet service. Your organization can earn substantial revenue with the get2nic Fundraiser Program. Additional benefits of the program are: 1. Significant long-term residual revenue for your organization. 2. Strengthens the allegiance of current members and reduces the cost of long distance and internet services to all members. 3. Provides value-added services for prospective members, attracting new membership. 4. No inventory, deliveries or collections. 5. Long Distance for 5.5 cents per minute. Unlimited Internet Access for $17.95 per month. With our Fundraiser Program, the above objectives can be accomplished with as little diversion of the organization's management time as possible. Additionally, the program is simple for the organization to give away. Your organization will acquire additional funds by showing people how to save money! For more information on the get2nic Fundraiser Program, call Jimmy Brent at 757-563-2020. Thank you for reading our Newsletter! For further information pertaining to this newsletter please visit www.get2nic.com or email [EMAIL PROTECTED]. To unsubscribe to this publication, just reply to this message and put "unsubscribe" somewhere in the subject line. You can also unsubscribe by clicking here. Th
Re: New Internet Service
Get2NIC wrote: >ZiplogMail-Free Spam & Virus-Proof E-mail Accounts. ROFL PS: - if Major Domo knew how to cope this, he would be General Domo by now :^) -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org Gong Xi Fa Cai - Hong Bao Na Lai
Re: New Internet Service
On Mon, 22 Jan 2001 20:34:59 +0700, "Rahmat M. Samik-Ibrahim" <[EMAIL PROTECTED]> said: > Get2NIC wrote: > > >ZiplogMail-Free Spam & Virus-Proof E-mail Accounts. > > ROFL I admit I encountered a parse error on that. Is it: ZiplogMail - providing free spam or "spam containing no ZiplogMail". And of course, the e-mail account never catches a virus - it's the PC that downloads e-mail from the mailbox that catches the virus. Somebody should mention to those guys that the dot-com bubble is bursting, and you actually will need a kloo to survive. Or one can dream, anyhow. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Number of Firewall/NAT Users
Joel Jaeggli wrote: > > you might check out the rather sprited discussion during the plenary at > ietf49... > > the official proceeding will be up shortly on the ietf website, video of > the event is at: > > http://videolab.uoregon.edu/events/ietf/ietf49.html What can be heard on the audio (some of the question microphones were not connected to the video capture system) showed a rather less "spirited" discussion than I thought I'd find based on your message. I took the opportunity to watch some of the presentations, which helped provide context (especially Randy's presentation on DNS, and the comments within on architectural restraint). The "spirited discussion" consisted of a limited number of people saying things that either they or others have said before. Perry, for example, talked about the costs of multiple, overlapping NAT stuffs and the huge amounts of money that's costing folks. He's made the same point in other plenaries and in other meetings. What he said is certainly a problem, and one we'd all like to see disappear. Keith expressed concern (starting the discussion) that the IETF should be working on a better architecture to deal with replacing NAT. To do so, we'd have to solve the customer needs which are driving folks to NAT, of course. So, in reviewing the video, I saw people generating plenty of heat, but little light. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: Number of Firewall/NAT Users
Keith Moore wrote: > > > The IETF has done it's job with 6to4, but like you said we can't force > > people to deploy it. But let's stop and think about 6to4. Aren't some of > > the same "tricks" or ALG's that are planned to make applications work > > with IPv4 NAT, applicable to 6to4? If so, then we must find solutions > > now since 6to4 could be with us for many years. > > Given that the whole point of 6to4 is to allow IPv6 packets to be > passed end-to-end without modification, I don't see how ALGs apply at > all. NAT-PT of course has similar issues to v4 NAT, but NAT-PT and > 6to4 are different things. Indeed. 6to4 is a solution for IPv6 islands to talk to other IPv6 islands. No ALG issues at all. (The "to" represents the address mapping trick used.) NAT-PT solves a different problem - how can IPv6-only devices communicate with the IPv4 legacy? And that does call for ALG support. Brian
Re: Number of Firewall/NAT Users
Henning Schulzrinne wrote: ... > However, I think it's high time to establish a "Good Housekeeping" seal > for "real" (pure, unadultared, GM-free, ...) Internet service, i.e., > > - without "transparent" caches Do you mean interception proxies, in WREC terminology? > - no port restrictions And no protocol type restrictions > - no NATs How about adding IPv6 support? > > (and whatever other abominations one might want to add to this list). > Seems like a good role for ISOC, for example :-) The ISOC isn't a trade association, which is where such seals of approval (and the associated b*ke-offs) tend to come from. Brian
Re: Number of Firewall/NAT Users
Brian E Carpenter wrote: > > > - without "transparent" caches > > Do you mean interception proxies, in WREC terminology? Yes. > > > - no port restrictions > > And no protocol type restrictions > > > - no NATs > > How about adding IPv6 support? Good idea. > > > > (and whatever other abominations one might want to add to this list). > > Seems like a good role for ISOC, for example :-) > > The ISOC isn't a trade association, which is where such seals > of approval (and the associated b*ke-offs) tend to come from. Maybe the IPv6 consortium or whatever they call themselves could do this, since IPv6 is a (the only?) realistic alternative to NATs. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Re: Number of Firewall/NAT Users
Keith Moore wrote: > I remember when the email > network was a heterogeneous network consisting of UUCP, BITNET, DECnet, > SMTP, X.400, and a few other things thrown in. It "worked", sort of, > but we had all kinds of problems with the translations at the boundaries, > with addresses from one network leaking past the gateways into another > network, with addresses being "translated" in such a way that they > were no longer usable in the destination network. There was even an analogy to NAT's "addresses embedded in the application data stream" problem: if you had an address in your .signature, the gateway couldn't translate it, so the person receiving your message saw an address they couldn't use. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |Go not to the Vorlons for advice, for they will| |[EMAIL PROTECTED]|say both no and sherbert. | \/
BGP AS
Hi all, What do I need to get an AS on the Internet? Money, a certain number of IP's, the right ISP? Does anyone have specifics? Thanks, Dave
Re: Number of Firewall/NAT Users
At 08:53 AM 1/22/2001, Henning G. Schulzrinne wrote: >Brian E Carpenter wrote: > > The ISOC isn't a trade association, which is where such seals > > of approval (and the associated b*ke-offs) tend to come from. > >Maybe the IPv6 consortium or whatever they call themselves could do >this, since IPv6 is a (the only?) realistic alternative to NATs. Long term, yes. But Class A addresses for all the always-on users today would eliminate a heck of a lot of NAT out there. And I wasn't referring to a "seal-of-approval". Just some sort of formal recognition.
Re: Number of Firewall/NAT Users
> > I remember when the email > > network was a heterogeneous network consisting of UUCP, BITNET, DECnet, > > SMTP, X.400, and a few other things thrown in. It "worked", sort of, > > but we had all kinds of problems with the translations at the boundaries, > > with addresses from one network leaking past the gateways into another > > network, with addresses being "translated" in such a way that they > > were no longer usable in the destination network. > > There was even an analogy to NAT's "addresses embedded in the application > data stream" problem: if you had an address in your .signature, the gateway > couldn't translate it, so the person receiving your message saw an address > they couldn't use. at least in those days, gateway proponents didn't insist that people shouldn't include email addresses in the bodies of their messages. Keith
Re: Number of Firewall/NAT Users
Keith Moore writes: | at least in those days, gateway proponents didn't insist that people | shouldn't include email addresses in the bodies of their messages. You miss the point that including "GRECO::MARYK" as an email address in a USENET message is about as useful as including 10.0.0.26 in an IP header -- the local meaning is essentially unusable to a non-local recipient. Nobody really constrains protocols from carrying a local IP address around any more than anyone constrains from putting local addresses into a text message. It's just that communicating by naively replying to such an embedded address is unlikely to work. RFC-822 was a great leap forward for embedding a global namespace into text messages, and I am pleased to say that even my own RFC-822 address works fine at UKY, despite my NAT stance. :-) There needs to be an RFC-822 for identifying IP-packet-receivers independtly from actual network topology analogous to the way that identified mailboxes independtly from actual network topology (hey, consider that you even may have had your mail cross different types of small-i internet when sending mail to places like [EMAIL PROTECTED]!). Sean.
Re: Number of Firewall/NAT Users
> | at least in those days, gateway proponents didn't insist that people > | shouldn't include email addresses in the bodies of their messages. > > You miss the point that including "GRECO::MARYK" as an email address > in a USENET message is about as useful as including 10.0.0.26 in an > IP header -- the local meaning is essentially unusable to a non-local > recipient. Actually it was sort of useful, if you knew how to translate. (or could find a local mail expert that did) But you missed the point I was trying to make. in those days, the inability of the mail network (or at least parts of it) to support a single global address space was correctly recognized as a deficiency in the network - and people took action to solve the problem (notably deployng MX records). Nowadays people often act as if NATs were the way the Internet was supposed to work, and that it's the applications and the users of those applications who are broken if they want a network that supports a global address space. Actually it's the other way around, and people are taking action to increase the brokenness. > RFC-822 was a great leap forward for embedding a global namespace into > text messages, and I am pleased to say that even my own RFC-822 address > works fine at UKY, despite my NAT stance. :-) Yes, and IP was a great leap forward for having a singal global namespace and a single message format to send over all manner of transmission media. It worked quite well at this until NATs came along. Now you're suggesting that we need yet another layer, presumably something that runs over NATs. Given the current state of NAT deployment, it's hard to fault that reasoning. But it really does seem that we've solved that problem before, and to solve it again in a less efficient way seems like taking one tiny step forward to try to counteract a huge step backward. Keith
Re: Number of Firewall/NAT Users
On Mon, 22 Jan 2001 23:53:30 +0100, Sean Doran said: > Nobody really constrains protocols from carrying a local IP address > around any more than anyone constrains from putting local addresses > into a text message. It's just that communicating by naively replying > to such an embedded address is unlikely to work. Actually, NAT *does* constrain protocols from carrying around a local IP address if it's emitted out into the world. Remember that if it's a LOCAL address, it's used *only* behind the NAT, and nobody cares about that case. The problem with NAT is the same problem as people who put locally usable addresses in their .signature files - the NAT *doesnt* fix those up when it becomes a non-local address BY VIRTUE OF PASSING THROUGH THE NAT. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Number of Firewall/NAT Users
Valdis Kletnieks writes: | On Mon, 22 Jan 2001 23:53:30 +0100, Sean Doran said: | > Nobody really constrains protocols from carrying a local IP address | > around any more than anyone constrains from putting local addresses | > into a text message. It's just that communicating by naively replying | > to such an embedded address is unlikely to work. | | The problem with NAT is the same problem as people who put locally usable | addresses in their .signature files - the NAT *doesnt* fix those up when | it becomes a non-local address BY VIRTUE OF PASSING THROUGH THE NAT. Is it just me, or do these two message fragments have identical semantics? If so, I'm having major trouble with the idea of constraining something by letting it pass through in an un-rewritten form... Maybe the problem here is that "protocols" is too large; I meant things that ride around as a client of the IP network layer. In any event, the solution is a standard representation of "who" that is readily convertible into "where" in many different types of transport networks. IP addresses no longer qualify on that front, no matter what your NAT politics are like. Sean.
Re: Number of Firewall/NAT Users
| Nowadays people often act as if NATs were the way the Internet was supposed | to work, and that it's the applications and the users of those applications | who are broken if they want a network that supports a global address space. Well, the genie is out of the bottle, and if NAT is winning the fight against NAT-hostile applications, I'd think that applications writers would be better off taking the existence of NAT into account, no matter what their NAT politics are. If a compelling application comes along that is NAT-hostile, that will be interesting, but I can't imagine it's in anyone's interest to provoke such a conflict when there are well-known NAT-friendly ways of replacing embedded IP addresses in most higher-level protocols that use them... For those that are unremittingly unable to use things like the DNS, perhaps the NSRG will cough up an RFC-822 someday soon, and that will let you sleep better at night. :-) | Now you're suggesting that we need yet another layer, presumably something | that runs over NATs. No, something that runs over a catenet of every conceivable type of network, including ones which are IP or v6 based. Why should you care whether routers are making decisions based on tags, 32-bit addresses, 128-bit addresses (or only 64 bits of a 128 bit address), or fully variable-length addresses, or even whether some routers along the way are using one of these and other routers are doing something completely different? Surely you're happy as long as your TCP segment or UDP datagram gets to the right host with a destination address which can be used to get a TCP segment or UDP datagram back to you? IPv4ever ultimately is a UNI philosophy; the NNI is totally up in the air. For now, it's pretty clearly IPv4. Sean.
Re: Number of Firewall/NAT Users
At 12:42 22/01/2001 -0500, John Stracke wrote: >There was even an analogy to NAT's "addresses embedded in the application data >stream" problem: if you had an address in your .signature, the gateway >couldn't >translate it, so the person receiving your message saw an address they >couldn't >use. I liked even better the horror story of the gateway that tried. until someone wrote "this gateway translates [EMAIL PROTECTED] into [EMAIL PROTECTED]", and it came out to the recipient as "this gateway translates [EMAIL PROTECTED] into [EMAIL PROTECTED]".which somehow failed to get the point across -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: Number of Firewall/NAT Users
On Tue, 23 Jan 2001 01:11:12 +0100, Harald Alvestrand <[EMAIL PROTECTED]> said: > I liked even better the horror story of the gateway that tried. > until someone wrote "this gateway translates [EMAIL PROTECTED] into > [EMAIL PROTECTED]", and it came out to the recipient as > "this gateway translates [EMAIL PROTECTED] into > [EMAIL PROTECTED]".which somehow failed to get the point > across The best one-paragraph summary of RFC2993 I've seen yet. /V
Re: Number of Firewall/NAT Users
> | Nowadays people often act as if NATs were the way the Internet was supposed > | to work, and that it's the applications and the users of those applications > | who are broken if they want a network that supports a global address space. > > Well, the genie is out of the bottle, and if NAT is winning the > fight against NAT-hostile applications, I'd think that applications > writers would be better off taking the existence of NAT into account, > no matter what their NAT politics are. If you can make your application work as well or nearly as well in the presense of NATs, you'd be silly not to take the existence of NAT into account. However this isn't always feasible. > If a compelling application comes along that is NAT-hostile, that > will be interesting, Several of them already exist, and it is indeed "interesting"... in the sense of the "may you live in interesting times" curse. > but I can't imagine it's in anyone's interest > to provoke such a conflict when there are well-known NAT-friendly > ways of replacing embedded IP addresses in most higher-level protocols > that use them... First of all, this is so off the mark as to be completely false. Second, you're grossly understating the nature of the NAT problem, because inability to embed IP addresses are only one facet of that problem. Look at http://www.cs.utk.edu/~moore/what-nats-break.html > For those that are unremittingly unable to use things like the DNS, > perhaps the NSRG will cough up an RFC-822 someday soon, and that will > let you sleep better at night. :-) I'm on NSRG, and that's not what it's working on. And RFC 822 for networks already exists; it's called IP. > | Now you're suggesting that we need yet another layer, presumably something > | that runs over NATs. > > No, something that runs over a catenet of every conceivable type of > network, including ones which are IP or v6 based. To do that you would need yet another name space, and while it might be useful to separate endpoint names from names for attachment points in the network topology, you would still need efficient ways to map between the two...and DNS-like technology isn't even close to being adequate. > Why should you care > whether routers are making decisions based on tags, 32-bit addresses, > 128-bit addresses (or only 64 bits of a 128 bit address), or > fully variable-length addresses, or even whether some routers along > the way are using one of these and other routers are doing something > completely different? As an application writer, I don't care so much (though it is sometimes useful for applications to be able to know about the network topology). However, as a network administrator, I absolutely want to be able to set up my own links between arbitrary points in the network, and having a variety of network-layer protocols (as opposed to a variety of link-layer protocols) doesn't help that in the least. What you are proposing sounds like a useless extra layer. We've already solved that problem with IP; we don't need to solve it again to try to accomodate an arbitrary number of network-layer protocols. > Surely you're happy as long as your TCP segment > or UDP datagram gets to the right host with a destination address > which can be used to get a TCP segment or UDP datagram back to you? No, that's not even close to enough to support distributed applications. I also need a global address space, at least from the application's point of view...and for various reasons applications often need to be able to look into the network topology (think logging, and diagnostics, in addition to location-sensitive selection of resources). Keith
Re: Number of Firewall/NAT Users
Keith Moore wrote: > > | at least in those days, gateway proponents didn't insist that people > > | shouldn't include email addresses in the bodies of their messages. > > > > You miss the point that including "GRECO::MARYK" as an email address > > in a USENET message is about as useful as including 10.0.0.26 in an > > IP header -- the local meaning is essentially unusable to a non-local > > recipient. > > Actually it was sort of useful, if you knew how to translate. > (or could find a local mail expert that did) > > But you missed the point I was trying to make. in those days, the inability > of the mail network (or at least parts of it) to support a single global > address space was correctly recognized as a deficiency in the network - > and people took action to solve the problem (notably deployng MX records). Which broke DNS. We can no longer send an email to an IP number, mainly due to this myopic choice. This choice also broke layer independency. So, even though there is no reason why one needs to use DNS in order to send an email, people must use it nowadays for this purpose. What was a convenience became a limitation because of a bad design choice in MX records. So much for a "single global address space" that does not respect local flexibility. NAT boxes are thus just IMO a healthy rebound of the very principles that created the Internet -- and we must be careful, otherwise pretty soon we are going to have other things to "solve the problem" (notably as it happened with MX records). It is time IMO for some at the IETF to stop pretending that the Internet can made into a homogeneous network. It wasn't and it won't. Cooperation is not a bunch of people doing the same things at the same time, but different people doing different things at different times and places, for the same objective. Likewise, standardization is not having the same rules for all at all places but having different rules that interoperate for the same objective. Interoperation should be the defining factor for an Internet standard, and the same applies to NAT boxes. If they interoperate, what else should be required? Nothing. Cheers, Ed Gerck
