[arin-ppml] Just a reminder of some quick mathematicsfor IPv4that shows the long term impossibility of it
owen at delong.com
Fri May 13 21:41:16 EDT 2011
>>> In fact, the era of end-to-end for the Internet was the limited
>>> timeframe between popular acceptance and NAT.
>> Wrong because most people back then dialed in with a modem using
>> a terminal emulator program. The first connectivity was e-mail
>> gateways between the Internet and BBS networks like FidoNet.
>> The WWW came about later and it still wasn't that interesting until
>> pretty late in the 90's, around 96-97. And NAT came about when
>> most home users were still using dialup to connect to the Internet.
> That's what I meant to write. Things got interesting in the mid-90s.
> NAT came out shortly thereafter. NAT ended the end-to-end connectivity thing.
> And yet the Internet exploded in size.
> Dialup was not really end-to-end because there weren't fixed IP addresses, so not many were hosting servers on dialup.
> (I know there were exceptions, I once got a /24 with a dialup account back in 1995.)
This does not prove NAT is wonderful or that end-to-end is not useful
It proves that a lot of people faced with the choice between NAT and nothing
chose NAT over non-connection. This is akin to facing a choice between
food poisoning and cancer. The obvious choice is food poisoning, but,
most people would prefer to avoid both.
>>> Most people would fear to put a real IP address on a computer today, I
>>> know that I would.
>>> I use Logmein from behind NAT to address another computer behind another
>> logmein is not free for business use so your probably violating TOS.
> I don't remember saying I used the free one.
End-to-end addresses mean I don't have to pay someone else just to
provide a rendezvous server so I can reach my own stuff. It also means
I can connect to my own stuff without subjecting my access to such a
man-in-the-middle attack or the additional latency and/or risks associated
with doing so.
I really don't see any reason I would want to move from globally addressable
systems to systems behind such a rendezvous mechanism. Can you point
to any single advantage of doing so?
>> And if you paid for it why should everyone else in the world pay
>> that company? Remote Desktop is free for business and personal use
>> and does not require some wacky active x control or java applet to
>> run in a browser. So is VNC. both of these are also faster.
> I use both of these products, too.
Not with the target behind a NAT, you don't.
> I started with Carbon Copy over modems.
LoL... I remember those days. Not all that fondly.
> Full disclosure: I have done some consulting for Logmein.
Ah, so you have a somewhat vested interest in the success of this
arguably unnecessary (if we had end-to-end) business model.
> In the real world I use Logmein for instances behind NAT.
In the real world, I keep my systems globally accessible. I just
don't see any advantage to doing otherwise.
> It's especially valuable for the rapid setup of remote support because it does not require firewall changes.
> People are willing to pay for that ability, according to their success in the market.
People are willing to accept all kinds of bad engineering and pay for workarounds to
resolve the issues they create. For example, look at the number of people that
bought Windows 3.1 and then paid third parties for IP software, anti-virus software,
firewall software, shells that didn't crash all the time, memory managers, etc.
Each of those things is arguably a simple deficiency in the original Windows product
and a feature that was included in the basic expectations of virtually every other
operating system available at the time.
Just as network access services provided without a globally unique address can
be worked around through things like back2mymac and other rendezvous services.
However, those services would be utterly unnecessary with a proper globally
>>> Rendezvous servers exist for that purpose, and the market favors them.
>>> Holding on to some dream of complete end-to-end reachability leaves out
>>> the inevitable firewall application between them in any case.
>>> Juniper and Cisco have enabled CGN on their big iron boxes, do you think
>>> they are unaware of the nightmarish negative impact of CGN you ascribe?
>> They OFFER CGN on their big iron they don't "enable" it, the admin
>> has to configure it for it to be enabled. And naturally they don't mind
>> if an admin does because they get to sell them more hardware that way.
> Well, we won't have to wait too much longer to see who is correct in their appraisal of the perils of CGN.
Indeed. I suspect that carriers in Asia will be forced to implement at least some LSN very soon.
Unfortunately, users in Asia are generally used to a much lower level of service quality than
even users in the US, so, that may not be an entirely valid datapoint.
> I assume somebody paid the coders at Cisco to write the CGN code.
As near as I can tell, most of the LSN code in the Cisco gateways is the same as their standard
NAT code that's been in their routers for quite some time. Since IOS tends to be the kitchen
sink of all kinds of features anyone imagined someone might ever want, I wouldn't take
that as too much of an indication as to market demand. After all, IOS still contained support
for Banyan until not all that long ago. In fact, I don't know for sure that it has been retired yet.
> I doubt that would have happened if Cisco's research showed customers would reject it.
I'm sure, as I said, that Cisco's research showed that some carriers would need it. There is
a huge difference between needing to do something and wanting to do it or considering it
desirable. The number of IPv4-only devices in the consumer electronics product space
that will not be upgraded before IPv4 runout alone means that even consumers placed
on primarily IPv6 services are going to need some level of IPv4 connectivity solution
for some time. Those consumers will be subjected to LSN because there is literally no
other viable option.
LSN isn't a feature, it's a workaround for alack of viable options due to the constraints
of time combined with a global lack of preparedness and progress.
More information about the ARIN-PPML