128 = 64*2
Whats surprising to me is that nobody has mentioned that V6 addresses are well known to be 128 bits, which is also 2 x 64 bits, so with modern CPU's and with some great foresight on network addressing and segmentation around a /64, thats exactly one instruction to compare addresses, in a CPU (or other hardware such as FPGA's), meaning that routing, at the core of the Internet, on the Tier 1 ISP routers, becomes much simpler which in turn means much less computational overhead and much less RAM requirements - as the other 64 bits are irellevant for routing. This has the big benefit of faster routing, which means lower latency for everyone as their packets arrive faster.
There is the benefit for all users, since the local LAN part is generally a /64, then the same sort of higher speed routing or switching can be done, again improving performance at customer sites, where hardware will generally be lower power, compared to service provider kit.
Obviously the middle layer of routers, between Tier1 and customers, where masks will be variable, but generally on /48 or /56 or similar. will need to handle the whole address, but thats the price of flexibility and exactly as it is in v4 (through the whole stack, Tier1 to customer). Now though, the intermediate routers won't have to worry about upstream or downstream, again allowing routing information to be stored more efficiently in the hardware and again reducing routing table sizes.
Its also clear from the posts, that there are two camps on v4/v6, mostly around those that don't understand it well enough vs those that understand it better.
All the "invent a new protocol called Vx.y, where things are magically fixed" always glosses over the massive problem that you can't put more than 32 bits in a 32 bit address, without breaking everything, all software of the day allocated exactly 32 bits for storage of addresses, so any hypothetical expansion (irrespective of what you call it) will need a bigger buffer in RAM on every app that use IP addresses - meaning ALL network enabled applications on ALL devices will need their software (hardware for network devices) updating to have the larger buffer size and operate correctly on it, then recompiling, testing and re-installing.
Untul this is "fixed" in some magical way, across all global devices, then nothing would work. It should be crystal clear that this is not a viable way to "fix" things, so the v6 approach of parallel run removed that massive hurdle, allowing soft take up and transition, which is still happening, even with people trying to deny it.
@Nanashi clearly understands his stuff, so thanks for the high quality and accurate posts.
Biting the hand that feeds IT
