3 ms·

You still haven't answered my question - how can I, sitting behind one NAT, receive a connection from my friend behind another NAT, if neither allows direct inc

You still haven't answered my question - how can I, sitting behind one NAT, receive a connection from my friend behind another NAT, if neither allows direct incoming connections? All your multicast, peer-to-peer, etc. buzzwords don't mean a damn thing if the connection can't be made in the first place. No matter how you twist around and cloud the issue, the fact is somebody has got to have a public IP to make the rendesvouz work, and if those public IPs are not available to ordinary people who might be entrepreneurs prototyping new kinds of ways to use the internet, then those prototypes will not get off the ground. Edit: BTW, IPv6 is not an "experimental" protocol as you allude to it.

tptacek 18y ago
IPv6 hasn't been scaled in the same way that IPv4 has. The operations community knows how to handle IPv4. The rest of your comment? You're arguing a straw man. Nobody is arguing that IPv4 addresses will be impossible to obtain; any such argument would be moronic. But if address allocation tracks application development rather than end user population, I could see that as a positive development. I don't think you're following my point. When I sent an AIM message to a friend, IPv4 isn't routing it; AIM is. IPv4 is just a detail. This is the future. The overhead of app-layer routing is small --- tiny compared to the overhead of running rich client apps in Javascript over HTTP. If IPv4 matters in 10 years, that's a huge failure. Which future would you rather put your energy into? The one where we can address realtime content to groups of people by name, or the one where we run basically the same apps we do now but with a bigger address space? Caring about IPv4 addresses is like caring about Ethernet addresses.
- ovi256 18y ago
  > IPv4 isn't routing it; AIM is. Yeah, but that breaks the principle of encapsulation. The IP layer has routing that works great, the app layer can take it for granted. Why should each app re-implement routing? This would raise the cost of entry, again.
  - xirium 18y ago
    > Why should each app re-implement routing? The same was said of Internet Protocol. Why would you want to send packets over a public network with no guarantee of throughput? Well, it greatly increases the connectivity between hosts and it significantly reduces costs. However, it is less secure. Likewise, why would you want to send data via application-level multicasting? Again, it greatly increases connectivity between hosts, some of which may be behind firewalls. Furthermore, it greatly improves the efficiency of data distribution because the reduces the significance of the bandwidth of the initial host. At present, there is some duplication of effort. Some duplication is to avoid proprietary interests. Some duplication allows specific types of data to be handled. Finding and promoting a more general solution would be desirable.
  - tptacek 18y ago
    There is no principal of encapsulation! There is no such thing as a "layering violation". TCP/IP isn't an OSI-modeled protocol. You had it right earlier with the End-to-End Argument. E2E is very meaningful. We shouldn't push functionality into the network that can be handled by the endpoints, because doing that constricts applications and makes the network less useful. Which is why, if applications can shoulder app-layer routing and multicasting, we should embrace that and let them do it. The alternative means getting Verizon, Sprint, and AT&T to buy in to whatever our next-generation app is. Look how well that's worked out so far.
ovi256 18y ago
> You still haven't answered my question - how can I, sitting behind one NAT, receive a connection from my friend behind another NAT, if neither allows direct incoming connections? This is exactly the problem that STUN solves. But you need a third party server, most of the time application-specific, and yet another layer of complexity.

tptacek 18y ago

IPv6 hasn't been scaled in the same way that IPv4 has. The operations community knows how to handle IPv4. The rest of your comment? You're arguing a straw man. Nobody is arguing that IPv4 addresses will be impossible to obtain; any such argument would be moronic. But if address allocation tracks application development rather than end user population, I could see that as a positive development. I don't think you're following my point. When I sent an AIM message to a friend, IPv4 isn't routing it; AIM is. IPv4 is just a detail. This is the future. The overhead of app-layer routing is small --- tiny compared to the overhead of running rich client apps in Javascript over HTTP. If IPv4 matters in 10 years, that's a huge failure. Which future would you rather put your energy into? The one where we can address realtime content to groups of people by name, or the one where we run basically the same apps we do now but with a bigger address space? Caring about IPv4 addresses is like caring about Ethernet addresses.

ovi256 18y ago
> IPv4 isn't routing it; AIM is. Yeah, but that breaks the principle of encapsulation. The IP layer has routing that works great, the app layer can take it for granted. Why should each app re-implement routing? This would raise the cost of entry, again.
- xirium 18y ago
  > Why should each app re-implement routing? The same was said of Internet Protocol. Why would you want to send packets over a public network with no guarantee of throughput? Well, it greatly increases the connectivity between hosts and it significantly reduces costs. However, it is less secure. Likewise, why would you want to send data via application-level multicasting? Again, it greatly increases connectivity between hosts, some of which may be behind firewalls. Furthermore, it greatly improves the efficiency of data distribution because the reduces the significance of the bandwidth of the initial host. At present, there is some duplication of effort. Some duplication is to avoid proprietary interests. Some duplication allows specific types of data to be handled. Finding and promoting a more general solution would be desirable.
- tptacek 18y ago
  There is no principal of encapsulation! There is no such thing as a "layering violation". TCP/IP isn't an OSI-modeled protocol. You had it right earlier with the End-to-End Argument. E2E is very meaningful. We shouldn't push functionality into the network that can be handled by the endpoints, because doing that constricts applications and makes the network less useful. Which is why, if applications can shoulder app-layer routing and multicasting, we should embrace that and let them do it. The alternative means getting Verizon, Sprint, and AT&T to buy in to whatever our next-generation app is. Look how well that's worked out so far.

ovi256 18y ago

> You still haven't answered my question - how can I, sitting behind one NAT, receive a connection from my friend behind another NAT, if neither allows direct incoming connections? This is exactly the problem that STUN solves. But you need a third party server, most of the time application-specific, and yet another layer of complexity.