4 ms·
>increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant. which is a bad thing.
by ginko 13y ago
>increasing amounts of NAT-ting are making the classic point-to-point model of the internet more and more irrelevant.
which is a bad thing.
- tptacek 13y agoIt's a bad thing now, because the only way to get assured direct connectivity to the "Internet" is via IPv4 connectivity. It would be less of a bad thing if IPv4 connectivity (specifically: what ASN was advertising the IPv4 prefixes your traffic was associated with when it traversed, say, Telecom Malaysia) wasn't the sine qua non of global connectivity, in the same sense that nobody cares what IP address you use when you connect to IRC.
- ay 13y agoYou can connect to IRC because the IRC server is not behind a NAT. Try to run an IRC server on your host which runs behind the consumer NAT which runs behind the CGN. Yes, if the gear supports it, you can use uPNP for the first, and PCP for the second, to open up a port. Unless someone is using it already. Then you need to choose another port. Which you need to communicate to the other clients behind the NATs around the world. Fine, we'll just update the DNS server with an SRV record. You probably will always have a spare public IPv4 address to map the ports 53 to something on the inside network, so this might work. Until your CGN does not have enough IPv4 addresses/ports to permanently allocate one to you. Oh, by the way this is a great way to introduce a "premium" tier service with a public IP address - if you really want to run a server then you can buy an address. So doing the PBX-style circuit switching with NATs is not really in the economic interest of the ISPs. (Not saying that they need to do all the accounting/logging). If the app is awesome enough that the users will pay extra to get the public address - great. That will help to further exhaust the IPv4 addresses and drive the prices up. Rinse, repeat. I am of course exaggerating. But this presentation from NANOG may be a less biased view (though Lee's employer does deploy IPv6, so you can argue it is biased): http://www.nanog.org/sites/default/files/wed.general.howard.gametheory.17.pdf http://www.nanog.org/sites/default/files/wed.general.howard.... Full disclosure: I am into this IPv6 thing. Before that, I spent ~10 years of my life at a random 5-letter vendor to find the bugs in the code and misconfigurations causing outages in people's NATs. It's refreshing to be able to use access-lists again. (the latter statement is only partially correct, but this is a topic for another rant, IPv6 has tons of its warts as well :-)
- wmf 13y agoWith an overlay you don't need a public IP to run a server. Look at Tor hidden services for example. Only the overlay "backbone" servers themselves need public IPs. (I am actually opposed to overlays uber alles, partly because I think it may actually happen.)
- ay 13y agoOf course. But it can't be turtles all the way down - at some level, the overlay traffic will be a TCP segment or UDP packet, sent from one node running overlay network to another node running overlay network. If both nodes in the overlay network are behind the two "cone" NAPTs like this: A --- |> --- <| --- B then getting from "A" to "B" is not easy. And the "cones" may be of varying degree of aggressiveness when it comes to filtering [1]. You can not guarantee that you can always establish connectivity between the two, even in a presence of the third party - with the addresses being more and more precious, the SPs will move from full-cone to more restricted NAPTs. Besides these hurdles, moving large volumes of traffic atop overlays is not very optimal - I heard anecdotes that when Tor is abused in this manner, it is quite slow. Skype (and I guess probably Tor as well) uses supernodes that are not behind the NAPT to establish the communication. As there is less and less places for it. So, the quality of communication over overlay degrades more and more. Meanwhile, the bigger players will just place the caches close to eyeballs or directly peer with the eyeball providers. [2] So, I think Lee's scenario is quite plausible. Pretty much the only things keeping holding IPv4 in my home network are the client device bugs [3] and Skype. The web works quite well on DNS64. I think the economics will take care of things. There are users on IPv6. A few clever interns last year made a website [4] that aggregates various IPv6-related stats. Take a look at the situation with users e.g. in Germany, Belgium, Switzerland. Yes, it is still not a whole lot but it is growing - and these three give the impression of how it might happen - sometimes steady, sometimes the switch will just turn on. I am very curious to hear some VC chime in on this matter - what do they think about the prospects of business growth in the situation of the constrained address space and uneven competition. It is not the case today because ARIN still has numbers. Give it a couple of years. [1] https://en.wikipedia.org/wiki/Network_address_translation https://en.wikipedia.org/wiki/Network_address_translation [2] http://blogs.broughturner.com/2009/04/googles-peering-and-caching-strategy.html http://blogs.broughturner.com/2009/04/googles-peering-and-ca... [3] https://ripe66.ripe.net/archives/video/1196/ https://ripe66.ripe.net/archives/video/1196/ [4] http://6lab.cisco.com/ http://6lab.cisco.com/