15 ms·
We'll be having the same post 20 years from now. NAT, for all its problems, has more or less solved the IP address problem. As a geek, one who has put the ne
by luckydude 9y ago
We'll be having the same post 20 years from now. NAT, for all its problems, has more or less solved the IP address problem.
As a geek, one who has put the networking stack into the ETA-10 (yeah, I know, nobody knows that machine, CDC spinoff super computer) and SCO's unix (yeah, I know, it sucked), so as a geek who gets the stack pretty well, I've never warmed up to IPv6.
To me, it seems like it went too far. 64 bits not enough? Really? Unless I'm doing the math wrong 64 bits is enough for 2635249153 addresses for every human on the planet.
slovax ~/p bc
2^64
18446744073709551616
./(7*1000^3)
2635249153.38707880228571428571
So 128 bits is needed why? I get that people used to say that 16 bits would be enough and they were wrong and the 32 bit people were wrong. I just don't see how we run out of 64 bits in the next $BIG_PILE of years.
I don't get it. Seems over engineered. IPv4 works pretty well, seems like a slight improvement would have been enough.
- colanderman 9y ago"IPv6 addresses have 64 bits too many in them" is not a very strong argument, especially not in 2017.
- throwaway2048 9y agoIts amazing people still wanna bike-shed what is essentially a 20+ year old protocol at this point. Its time to give up on the nitpicking guys, ipv6 is the future regardless of if you like it or not.
- cm2187 9y agoHa ha. Like javascript! The thought alone depresses me (javascript, not IPv6).
- nine_k 9y agoJS is certainly not going to disappear. But with WebAssembly, you'll not be locked into it, or into transpilers that produce it. Chances are, we'll see other reasonable languages being compiled to WebAssembly and getting mass adoption. (WebAssembly is a stack machine with a bytecode interpreter, running in the browser, with code downloaded from the net. Java tried to be basically the same thing, only 25 years too early.)
- floatboth 9y agoWhen direct DOM access from WASM happens. For now, it's designed for performance-sensitive stuff like game engines, codecs, crypto libraries, etc.
- nine_k 9y agoI wonder how hard it is to write a proxy from the JS side, and how large the performance penalty would be. Also, with a relative clean slate, they have a chance to make DOM manipulation transactional finally.
- floatboth 9y agoPeople already trying to do this. It does not accomplish the "replacing JS" goal :)
- seanp2k2 9y agoJava also did it with 25x worse VM start times, 25x more security vulns, and a 25x more greedy and terrible company behind it (eventually). The legendary GC pause never helped. "Write once, run anywhere" then ironically becomes the specialty of Java...script.
- nine_k 9y agoIt was when 4 MB RAM was what a typical desktop had. Sun was inept in many regards, but not terribly greedy. I don't see how JS doesn't magically have GC pauses. WebAssembly doesn't have a GC built-in, so it may host a pauseless process.
- octalmage 9y agohttp://javascriptisnotjava.io http://javascriptisnotjava.io
- cm2187 9y agoYeah I am really excited with Webassembly as the new JVM/CLR. But I was told this wasn't going to happen. As the downvote illustrates, there are many javascript militants who probably think we do not need any other language.
- dingo_bat 9y agoYou're right that ipv6 is the future. However that does not mean it is impossible to find flaws in it. For some people, having 128 bits instead of 64 is a flaw.
- throwaway2048 9y agoIts about as relevant at this point as arguing that traffic lights shouldn't be red and green, sure maybe, but its not a very useful discussion because its both a trivial aesthetic concern and never ever going to change.
- konschubert 9y agoHaving a discussion about it is still allowed and in good style.
- askvictor 9y agoColour blind folks might disagree with you. Just because we've always done it that way doesn't mean we shouldn't have a discussion about it.
- cm2187 9y agoWhat would a 64bit address space solve that a 128bit would break?
- scbrg 9y agoThe possibility of remembering addresses.
- tomschlick 9y agoDNS. You're not supposed to remember ip addresses.
- paulddraper 9y agoI remember 8.8.8.8
- tomschlick 9y agoLonger, but still memorable. 2001:4860:4860::8888
- therein 9y agoI remember 208.67.222.222 and 208.67.220.220 being someone who grew up in a country with DNS-level censorship way before Google announced their Public DNS.
- deleted 9y ago[deleted]
- nikanj 9y agoWe are the sorry sods working on your VPNs, LANs and the like. There's no DNS for routable blocks yet.
- zurn 9y agoConfiguration systems for those typically do support symbolic prefixes for easy renumbering and deployment of sibling networks. Also, most people dealing with rfc1918 networks would much rather get rid of addressing conflicts and other problems resulting from non-unique addresses, like security problems arising from ambiguous addressing. (Or don't know what they're missing...)
- ealexhudson 9y agoIt's only too big if you consider they would all be used. The large tracts of open unused space allow you to subdivide networks many times over - simplifying routing. If you just made the space bigger and expected to pack it very full, the routing would be very complex - worse than now.
- zkms 9y ago> NAT, for all its problems, has more or less solved the IP address problem. A bunch of very large-scale network operators (like Comcast, T-Mobile USA, Verizon, and Facebook) seem to strongly disagree with that, given how eagerly they've deployed IPv6 to get away from the hell that is IPv4 NAT and CGN. Yes, IPv6 has lots of complexity/flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, prettyprinting / the colons, extension headers, etc.) that mostly only look good through the rose-tinted glasses of the 90s and significantly slowed down deployment -- and in the end mostly ended up as "difference for difference's sake". 128 bits of addressing space and getting away from IPv4 NAT were unambiguously good. 128 bits is a lot, but memory/bandwidth is just going to get cheaper (for slow links you should use header-compression anyway), and it was better to go whole hog and skip 64 and go to 128 to avoid a future 64->128 transition. Given how the 32->128 transition is going, this seems like it was an excellent decision.
- nazgul17 9y agoCould you expand on the flaws and why are they problematic?
- zkms 9y agohttps://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_Snijders_IPv6_Panel-1.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG4_Job_S... and https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Why_IPv6_Security_is_so_hard-Structural_Deficits_of_IPv6_and_their_Implications-Enno_Rey.pdf https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS1... and https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-Keynote2_Ole.pdf https://www.sinog.si/wp-content/uploads/2017/05/SINOG-IPv6-K... are worth reading. TL;DR: * Multicast and mobility are shits * NDP an overcomplicated shit * The SLAAC / DCHPv6 thing is a ripe mess * getting IPv6 provider-independent space is too hard * extension headers are tricky, slow to parse, a source of tricky security issues, and thus are almost completely unused on the Internet in general Basically almost all the moving parts in ipv6 (beyond the wire format and its 128-bit addresses) that aren't dangerously convoluted / mostly unused are pretty much just NIH'd reimplementations of the corresponding IPv4 protocols (like ARP, say).
- api 9y agoNAT is pure evil. It adds huge complexity to anything wanting to do any kind of end-to-end or peer-to-peer connectivity, and it does not scale at carrier sizes very well. Even for regular client-server stuff it introduces performance and stability problems when you try to do it for millions of clients. Don't even get me started on the complexity it adds on the devops front. Layers and layers of cruft go away when everything can have an actual address. It's a nasty hack to keep the net running until we can sunset IPv4. That's it. 64-bit IP would have been fine. If I were asked to extend IPv4 that's what I would do. I've ranted about the annoyance of 128-bit address lengths, but it's not a show stopper and it's something that could be fixed at the UI level and with better DNS management systems. There are cool things about 128-bit addresses like SLAAC and cryptographically meaningful addressing. We have IPv6. It works. It's getting deployed. There's absolutely nothing to be gained and a lot to be lost by bikeshedding about why 64-bit would have been veryveryslightly better. It's like arguing in 2017 about how PCs would be 0.5% faster if we were using the DEC Alpha instruction set instead of x86_64 or what the world would be like if Apple had stuck with PPC. Just deploy IPv6. Please.
- crazy2be 9y agoNAT has not solved the IP address problem, it has merely postponed it slightly. Multi-level NATs are a hell far beyond the single-level NATs that most consumers see (and single-level NATs already cause all sorts of problems for even moderately advanced network usage). So most people only have single-level NATs, which practically only extends the address space by a small multiple - 8 bits at most, in practice ~2-3 bits. 128 bits allows routing tables to be super small and fast. While RAM has gotten cheaper, it is still slow, and smaller routing tables are way more important than smaller addresses. However, I agree with your central point - IPv4 was "good enough" that IPv6 is going to be a tougher battle than it ought to be. However, IPv6 is winning that battle already. 15% of google's users use IPv6, and it's increasing sigmoidally. [1] [1] https://en.wikipedia.org/wiki/IPv6_deployment https://en.wikipedia.org/wiki/IPv6_deployment
- rpcope1 9y ago> NAT, for all its problems, has more or less solved the IP address problem. This is only kind of true if you can fit your network completely into the RFC1918 space (which many large companies, for example, can not). Again, given the aggressiveness many of the providers, like Verizon, have taken in their IPv6 roll-out, including internally, and given how much of a complete mess NAT is at scale (with CGN and statefulness), I am personally dubious that IPv4 has the capability to carry us much further forward.
- deleted 9y ago[deleted]
- codyb 9y agoI was actually curious if it might not have been designed not for the number of addresses but for the average distance between any two addresses in use. Won't this make scanning the address space nigh on untenable for the foreseeable future? The big thing is to retire IPv4 then.
- nikanj 9y agoPutting in 128 enables them to waste the address space the same way IPv4 was treated decades ago. "Oh, you want to hook up a classroom? Here's a /16 <-> /64". If address space is so plentiful the default home isp allocation is /64, there's something wrong here. I can somewhat easily remember a bunch of IPv4 addresses. I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above.
- zAy0LfpBZLC8mAC 9y ago> the default home isp allocation is /64 If it is, then your ISP is incompetent. You should get a /48 by default, at the very least a /56. > there's something wrong here. Why? > I'll probably never memorize an IPv6 one, unless it's one of the 0xface cafe babe 0000 ones. Which waste address space even more, see above. Why would you want to? Except for a few special ones (routers and DNS servers, mostly), which you probably should configure to use easy to remember addresses, what's the point of remembering addresses when there is DNS?
- lmm 9y ago64 bits isn't enough for classful (pre-CIDR-style) routing. Remember that IP addresses aren't just arbitrary numbers, they're addresses. Note also that there's a fixed divide at 64 bits, so IPv6 is "really" only 64 bits of global routing, the last 64 bits are reserved for site-local routing.
- zAy0LfpBZLC8mAC 9y ago> the last 64 bits are reserved for site-local routing. No, the last 64 bits should never be involved in routing, /64 is the prefix length for a single ethernet segment. A site should by default have at least a /48.
- sortthingsout 9y agoYour math is wrong, yes. IPv4 addresses do not contain 64 bits, but 32 bits. 2^(8*4) = 4294967296, which is less than the amount of humans on Earth.
- rkangel 9y agoStop thinking about 64 bits as an address space that might get filled (like it did in IPv4). The 128 bit length of IPv6 allows them to be used differently - more like a UUID that can be randomly generated with low probability of collision (similar to Git hashes). This allows a number of features like self-assigning random IP addresses on private networks that would be infeasible with a smaller address space.