3 ms·

I actually think that a minimally extended v4, with no changes other than a different version number and 64-bit addresses, would have gone a long way towards in

I actually think that a minimally extended v4, with no changes other than a different version number and 64-bit addresses, would have gone a long way towards increasing adoption. Having IPv6 as an entirely new protocol has lead to all kinds of misery. And I'm not even talking about application layer stuff, I'm talking about OSes and hardware. Hardware vendors hate it, because it is another protocol they have to deal with, which doubles ASIC testing matrixes. And don't even get me started on how evil extension headers are from a hardware point of view. The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). This lead to hardware vendors delaying support for V6. V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), and changes are applied unequally. Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I've always said that if I had a time machine, rather than shooting Hilter or John Wilkes Booth, I'd concentrate on trying to make the ethernet header 16 bytes and trying to argue for an IPv5 that was just an extended v4 without all this added complexity.

catdog 10y ago
> And don't even get me started on how evil extension headers are from a hardware point of view. > trying to argue for an IPv5 that was just an extended v4 without all this added complexity. > V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), On the other hand that flexibility may save us from going through that "we have to upgrade the whole Internet at once" pain again. In the end widespread v6 adoption is driven mostly by v4 address space exhaustion. At the time this got really severe some years ago the implementations in both hard and software were already pretty reasonable and widespread. Would we really be at a higher adoption rate right now with no additional reason to upgrade? (also IPv5 was already used in RFC 1819 for sth. different, that's why they jumped to 6 ;)) > The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). What about fragmentation which is entirely left to the hosts in v6? > Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I don't think such optimizations coming a bit later had a significant negative impact in v6 adoption (and if v6 adoption would have been higher it would have been implemented more equally). Also bugs get found and sorted out a lot faster if someone is actually using the code.
belorn 10y ago
When it comes to adaption, we should ask why some technology can succesfully change while others don't. For example, we have flash vs html5. Many site current have dual stack in that area, and most Innovation seems to go the new html5 rather than flash. With html features, we also have the extreme end with websites that support ten or even twenty different OS, Browser and hardware configuration for the same site. That is 20 different test system, 20 different code paths, 20 support "version" of the same live system. So long there is enough users for one version that can pay for it a programmer will be paid to support it. Maybe the issue with v6 is that it allow dual stack on the client side. If it was v4 or v6 exclusive we would be in the situation that a website could not afford not to support both versions based on the fear that customers would go to a shop where their OS + Browser + hardware are supported.

catdog 10y ago

> And don't even get me started on how evil extension headers are from a hardware point of view. > trying to argue for an IPv5 that was just an extended v4 without all this added complexity. > V6 is miserable in OSes because everything has to be done twice because you have two stacks (see my other post here regarding the PMTU locking issue in FreeBSD), On the other hand that flexibility may save us from going through that "we have to upgrade the whole Internet at once" pain again. In the end widespread v6 adoption is driven mostly by v4 address space exhaustion. At the time this got really severe some years ago the implementations in both hard and software were already pretty reasonable and widespread. Would we really be at a higher adoption rate right now with no additional reason to upgrade? (also IPv5 was already used in RFC 1819 for sth. different, that's why they jumped to 6 ;)) > The only good thing about the new V6 proto from a hardware perspective is the elimination of the header checksum (which was trivial anyway). What about fragmentation which is entirely left to the hosts in v6? > Even if you want to say that FreeBSD sucks, pretty much every innovation has some to V6 later than V4 on every OS I can think of. From simple things like TSO and checksum offload to RSS. There are examples of this on Linux, OSX and Windows. I don't think such optimizations coming a bit later had a significant negative impact in v6 adoption (and if v6 adoption would have been higher it would have been implemented more equally). Also bugs get found and sorted out a lot faster if someone is actually using the code.

belorn 10y ago

When it comes to adaption, we should ask why some technology can succesfully change while others don't. For example, we have flash vs html5. Many site current have dual stack in that area, and most Innovation seems to go the new html5 rather than flash. With html features, we also have the extreme end with websites that support ten or even twenty different OS, Browser and hardware configuration for the same site. That is 20 different test system, 20 different code paths, 20 support "version" of the same live system. So long there is enough users for one version that can pay for it a programmer will be paid to support it. Maybe the issue with v6 is that it allow dual stack on the client side. If it was v4 or v6 exclusive we would be in the situation that a website could not afford not to support both versions based on the fear that customers would go to a shop where their OS + Browser + hardware are supported.