Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!op.net!news.mathworks.com!nntp.primenet.com!ddsw1!news.mcs.net!not-for-mail From: les@MCS.COM (Leslie Mikesell) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: IP Masqerading? Date: 21 Aug 1996 22:59:33 -0500 Organization: /usr/lib/news/organi[sz]ation Lines: 106 Message-ID: <4vglv5$nq4@Mercury.mcs.com> References: <jfortes-1307951117380001@10.0.2.15> <3218B774.3D2754EF@lambert.org> <4vb8r8$lc1@Mercury.mcs.com> <321A058E.7209A8FD@lambert.org> NNTP-Posting-Host: mercury.mcs.com In article <321A058E.7209A8FD@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >] >It's a silly question to ask. We both know that the market >] >niche for NAT exists because of an arbitrary economic distinction >] >by ISP's in the first place, and making other arbitrary >] >distinctions does not somehow ennoble the niche. >] >] But the economics aren't arbitrary - it takes considerably more >] effort to obtain/assign/delegate networks of addresses than >] single addresses. > >Sounds like a one-time charge, not a per-month charge, to me. Maybe, if you knew exactly how many you'd ever need. >The work on the ISP side should be nothing more than making >a single Sybase (or similar) database entry, if the ISP is >competent at all. Like the phone company, the person you >call to have you phone "installed" need only modify data >tables to activate your phone line. The same is true of >routes. Call up your phone company and see if they'll give you a block of 500 numbers for a one-time charge. >An ISP who plans on doing this sort of deal more than once >would have the task automated. They still have to maintain the database, and as you need more numbers it adds to the memory needed for the routing tables unless you renumber everything to keep the range contiguous. If you lived in the Chicago area where we've had 2 area code splits in the last few years you would realize that this sort of thing is painful even for phone companies, and there are good reasons for those PBX systems where you can dial out but you need an extension number to connect to most inbound calls. >] These days it is fairly hard to get enough addresses to >] connect everything let alone put in the subnetting you >] want for security/traffic management. > >The inability to get/not-get address assignments is an ISP >lock-in issue. As is the fact that many ISPs purposely >structure their domain acquisition such that they own the >domain instead of their customers. At a minimum, they can >charge a fee to release the domain SOA to another ISP; at >maximum, they can lock you into their services if you want >to keep the domain. I've been turned down twice trying to get enough numbers to connect up about 600 offices that currently have a satellite link using SNA only. >] It seems rather wasteful not to nat things that are behind >] firewalls and generally unreachable anyway. > >It may be useful, if the site is large enough, to implement >block translation using NAT. > >This is *very* different than the typical usage to which NAT >is applied (to subvert billing practices). > >Using block translation, each machine has a unique internal >(usually non-routed) network address, and a unique external >address corresponding to the internal address and translated >based on IP block assignment through the ISP. Assuming you don't want inbound connections to most machines, I don't see any particular advantage over translating to a single external addres. Why should the difference between a single machine with many users and many machines with one user be visible outside of an organization? >There is no real shortage of address space; the recent reorgs >and class D breakups of ranges have seen to that. IPV6 will >in wide use before it becomes an issue again. What about router memory usage? Is it my imagination or have some of the backbone routers become less stable in the last few months? >] Actually I think 'slirp' is pretty elegant, but it only works >] where you control the inbound side of a dial-up link. What >] we need is your 'router-tunnel' connected to the equivalent of >] a slirp nat/proxy possibly over an encrypted channel like >] ssh uses. > >Yes, this would resolve the problem. So would replacing that >SLIrP with a socks client (my actual suggestion for the tunnel); >it's now a matter of no incentive toward "better" now that we >have "good enough" in most peoples minds. That, more than >anything else, causes misused NAT to offend me. SLirP is elegant because it is transparent - you can route any addresses through it on the client side without any setup. To the rest of the world it looks (correctly) as though you are a user on the host machine. However it needs an interface to associate with the client side of the route. I'm not sure how it would be different from socks if you could map an interface instead of a port for the client side of socks (either a real separate interface or an alias address on an existing interface where you could point the default route of the clients). Les Mikesell les@mcs.com