4 ms·

You 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 th

by ay 13y ago

You 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 ago
With 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 ago
  Of 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&#x2F https://ripe66.ripe.net/archives/video/1196/ [4] http://6lab.cisco.com&#x2F http://6lab.cisco.com/
  - tptacek 13y ago
    I think it turns out not to be hard to resolve the A<->B rendezvous problem if you're willing to have an M that forwards packets. I think a lot of crappy 1980s protocol architecture is based on a fear of forwarding packets that (to invoke a shorthand) Moore's Law has addressed for us.
- tptacek 13y ago
  I would love to hear why "overlays uber alles" doesn't work for you (seriously, I'm interested).
  - wmf 13y ago
    Mostly because of the inefficiency. I'm concerned about who's going to pay for the servers. I'm concerned that a monopoly walled garden business model might win out and one company would take control of the servers as a strategic choke point. (I'm also concerned about who's paying for our IP routers, since we had a business model that worked fine but ISPs are starting to get greedy.)

by ay 13y ago

wmf 13y ago

With 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 ago
Of 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&#x2F https://ripe66.ripe.net/archives/video/1196/ [4] http://6lab.cisco.com&#x2F http://6lab.cisco.com/
- tptacek 13y ago
  I think it turns out not to be hard to resolve the A<->B rendezvous problem if you're willing to have an M that forwards packets. I think a lot of crappy 1980s protocol architecture is based on a fear of forwarding packets that (to invoke a shorthand) Moore's Law has addressed for us.
tptacek 13y ago
I would love to hear why "overlays uber alles" doesn't work for you (seriously, I'm interested).
- wmf 13y ago
  Mostly because of the inefficiency. I'm concerned about who's going to pay for the servers. I'm concerned that a monopoly walled garden business model might win out and one company would take control of the servers as a strategic choke point. (I'm also concerned about who's paying for our IP routers, since we had a business model that worked fine but ISPs are starting to get greedy.)