4 ms·

Out of interest, what alternative solution would you prefer? Starting to use NAT and private/unrouted address spaces for everything seems like a terrible way to

Out of interest, what alternative solution would you prefer? Starting to use NAT and private/unrouted address spaces for everything seems like a terrible way to deal with the situation. (and I've had various problems with VPNs as a result of it; learnt my lesson and use "rarer" subnets like 172.16-31 and 192.168.x where x != {0, 1, 2, 10, 100} now) I'm surprised nobody seems to be suggesting we break up some of the Class A networks - IBM, HP etc. surely don't need 16-32M addresses. I admittedly know very little about the shortcomings of IPv6; I do know it handles fragmentation differently, which is apparently causing problems with tunnels, and as far as I can tell, it's a much "bigger" standard, not just IPv4 with a bigger address space, with some parts that are possibly completely pointless. (a little like multicast in IPv4 which seems to get very little practical use) As a developer, is there any particular technology other than IPv4 and IPv6 that I should be targetting?

jrockway 18y ago
I get the impression that tptacek hates everything that wasn't either invented in the 1950s, or that he didn't invent himself. IPv6 is the future of IP, regardless of its flaws. It is much farther along than anything else, and I don't see that changing. (And I don't see anyone using IPv6 until IPv4 addresses become Really Expensive, which probably won't be for 10 or 15 more years.)
- shimon 18y ago
  Exactly right. It's not painful enough to bother yet. When it does get painful enough, maybe IPv6 will still be the frontrunner, or maybe something else will emerge, but we should not expect to figure this out for a few years.
- tptacek 18y ago
  Fair enough, I misspoke. I'm not sold on the urgency of 4-to-6. I guess I don't have much a problem with IPv6 itself.
  - electromagnetic 18y ago
    I don't see the urgency being a matter of years, due to the fact that most ISPs are adopting NAT's. I guess my problem is, I don't see why ISPs won't just start deploying NAT's to convert IPv4 to IPv6. I mean with the span of IPv6 addresses, why can't they pin an IPv6 to an IPv4?
tptacek 18y ago
I think that one of the major architectural failings of the IETF over the past N years is the belief that we should be building on and extending the core Internet protocols, when what we should be doing is moving more and more logic into the application layer. So for instance, if you want to be able to address billions of people, the scheme that you use to do that should look more like email addresses (which are effectively unbounded) and less like a globally synchronized database of integers. A lot of problems that are basically intractable at the router/switch layer are much easier to solve with relay servers. Multicast is another great example; IP multicast was a failure, but multicast delivery semantics with (say) 80% of the performance improvements of IP multicast are achievable with relays. This isn't a crackpot idea; Frans Kaashoek and rtm at MIT had a project investigating it, called Reliable Overlay Networks. I did a startup in the late '90s based on overlays. The technology worked great. The pain involved in NAT and 1918 addresses would be mitigated if our applications were less tightly coupled to IP (gethostbyname -> sockaddr_in -> connect), and if we could just pick a NAT traversal / NAT rendesvouz technology and run with it. So my answer to your question is, you shouldn't worry about the alternative. Just keep building normal socket applications.

jrockway 18y ago

I get the impression that tptacek hates everything that wasn't either invented in the 1950s, or that he didn't invent himself. IPv6 is the future of IP, regardless of its flaws. It is much farther along than anything else, and I don't see that changing. (And I don't see anyone using IPv6 until IPv4 addresses become Really Expensive, which probably won't be for 10 or 15 more years.)

shimon 18y ago
Exactly right. It's not painful enough to bother yet. When it does get painful enough, maybe IPv6 will still be the frontrunner, or maybe something else will emerge, but we should not expect to figure this out for a few years.
tptacek 18y ago
Fair enough, I misspoke. I'm not sold on the urgency of 4-to-6. I guess I don't have much a problem with IPv6 itself.
- electromagnetic 18y ago
  I don't see the urgency being a matter of years, due to the fact that most ISPs are adopting NAT's. I guess my problem is, I don't see why ISPs won't just start deploying NAT's to convert IPv4 to IPv6. I mean with the span of IPv6 addresses, why can't they pin an IPv6 to an IPv4?

tptacek 18y ago

I think that one of the major architectural failings of the IETF over the past N years is the belief that we should be building on and extending the core Internet protocols, when what we should be doing is moving more and more logic into the application layer. So for instance, if you want to be able to address billions of people, the scheme that you use to do that should look more like email addresses (which are effectively unbounded) and less like a globally synchronized database of integers. A lot of problems that are basically intractable at the router/switch layer are much easier to solve with relay servers. Multicast is another great example; IP multicast was a failure, but multicast delivery semantics with (say) 80% of the performance improvements of IP multicast are achievable with relays. This isn't a crackpot idea; Frans Kaashoek and rtm at MIT had a project investigating it, called Reliable Overlay Networks. I did a startup in the late '90s based on overlays. The technology worked great. The pain involved in NAT and 1918 addresses would be mitigated if our applications were less tightly coupled to IP (gethostbyname -> sockaddr_in -> connect), and if we could just pick a NAT traversal / NAT rendesvouz technology and run with it. So my answer to your question is, you shouldn't worry about the alternative. Just keep building normal socket applications.