Since you consider yourself an expert, would you care to explain why you think that IPv6 is especially routable?
Sure. There are a lot of things that will make IPv6 easier to route:
- - Simplified packet processing: there are a variety of features in the IPv6 packet header that simplifies processing by routers. Included here are:
- - Fixed header size: unlike IPv4, IPv6 has a fixed packet size of 40 octets, whereas IPv4 packets can vary between 20 and 60 octets,
- - Lack of header checksum: IPv6 has no header checksum (thus removing the need to either compute or verify the checksum). This is actually pretty big, as each router hop needs to recompute the checksum as the TTL value is decremented in order to remain valid,
- - TTL replaced by Hop Limit: this one is a bit complex. In IPv4, Time-to-Live is specified in the header as the total number of seconds the packet should be routed before it is dropped. This is tricky to compute, so even in IPv4 many nodes simply decrement it by one regardless of how long it has taken to process. In IPv6, this is changed to be a straight hop count; the value in the header basically specifies how many times a packet can hit a router before it is dropped.
- - Gets rid of unused fields: IPv6 gets rid of a lot of header fields present in IPv4, such as the IHL, DSCP, ECN, and everything related to fragmentation.
- - Lack of fragmentation: IPv6 packets can't be fragmented. Routers don't have to fragment or defragment packets. This can also mean fewer overall packets, and also means the router doesn't have to parse or generate a pile of fragmentation fields and information from the packets being sent/received.
- - Traffic Class header field: IPv6 has a field that can be used to differentiate services, and can be used for QoS, allowing the router to more easily prioritize and arrange traffic.
- - Flow labelling: IPv6 has a header field for flow labelling, that can be used to do things such as ensure stable routes for packets, such that packets aren't received out-of-order at a destination. This is intended to make streaming data (such as video) more stable, and can replace custom heuristic algorithms at the router layer with something much simpler,
- - Jumbogram support: IPv6 packets can be up to (2**32)-1 octets in size (1 byte less than 4GB). While not practical today on the public internet, bigger packets can mean fewer (albeit bigger) packets that need routing,
- - CIDR and smarter address allocation: CIDR was invented for IPv4 of course, however IPv4 didn't use CIDR until ten years after Flag Day. Pre-CIDR address allocations were ad-hoc; address blocks were classful (A, B, C). Many of these classful allocations still exist, however because of they way they were assigned, it was (and is) difficult to aggregate these routes. IPv6 came about long after these lessons were learned the hard way, and thus the IANA is being much smarter about what addresses are allocated where in order to better aggregate routes. Thus, a given /32 will be doled out only to a single RIR, who can break it up into smaller units to LIR's, to eventually be broken into /48, /64, and /56's for destination routers. IPv4 also works this way, but with the much bigger address space (and the lack of legacy pre-CIDR allocations), and with smarter allocation policies in place, route aggregation will make the possible mess that is the current state of the IPv4 routing tables significantly saner. From a processing perspective, this means that next hop lookups should be significantly quicker and easier. IPv4 currently has over 610000 prefixes; way more than should be needed. This is partly due to, as addresses have run out, large CIDR blocks being broken up into smaller blocks that are then allocated to different routing regions, requiring more prefixes.
Second thing is, have you seen any IPv4 successor proposals? Link please.
I've seen a few, although I don't have links for all of them. The most significant example that has come up is IPv4.1; one example of a class of proposals that basically suffer from the same "problems" IPv6 has. In particular, it changes the number of octets in the address from four to five. This breaks IPv4; no existing IPv4 applications will actually work on it. It also doesn't fix any of the existing IPv4 routing problems, either in terms of route aggregation or processing power required per packet. It necessitates new protocol stacks on every layer to work. They "claim" backward compatibility by allowing IPv4 addresses to be encapsulated in the packet by setting the high-order address octets to zero; however you can do the same thing with IPv6 (just with more zero octets; this was actually proposed in RFC 4291, but has been dropped/ignored in recent years as the scheme is highly problematic). In terms of aggregation, it basically inherits the mess that is the existing IPv4 global routing table, and then adds even more routes to it. It also ignores that many processors use fewer cycles to read an even number of words than an odd number of words; 5 octets per address can actually be harder for some hardware to handle. I also find it funny they call it "IPv4.1", however the Version field is still four bit long; they don't even propose what they are going to set this value to (0100, 0101, and 0110 are already out). Thus, it has all of the problems of both IPv4 and IPv6, without any of the benefits.
I've also seen a proposal that tries to maintain the integrity of the basic IPv4 packet structure by adding extra addressing bits to the end of the packet header, in the options field, called IPv4+. Thus, the relative offsets of the starts of the source and destination address stay the same (unlike in IPv4.1, where the offset to the destination address differs by one octet). The problem with this scheme is that now the addresses are broken into two parts in different parts of the packet header, requiring more effort on the router end to generate, parse, and reconstitute. Again, it has all of the faults of the existing IPv4 global routing table, adds to it, and doesn't provide any real backward compatibility (as an IPv4-only aware router is going to parse the options data incorrectly, producing unexpected results at best. The packet certainly won't reach its destination.).
Lastly, there are proposals such as this one, which can be categorized as "I've come up with an amazing solution that solves every problem everywhere -- I'll tell you about it later!"...and later simply never comes. Oh well.
Effectively, every time someone comes up with a "backward compatible" solution, all they ever generally try to do is add more addressing bits. They don't bother to consider how packets will be routed, or how their proposal will affect the global routing tables. They also ignore how fast you can actually process a packet (when you're dealing in the range of 3+ million packets per second, even a small sub-millisecond additional packet processing time adds up substantially quickly). And they all get decimated by people who are experts in this field.
There is a whole lot more broken about "the Internet" under IPv4 than just the number of bits in the address. Routing is very key here, and any proposal that ignores that (and so far, they all have) is doomed to fail. The design behind IPv6 has a lot more to do with just adding more addressing bits; rout ability was a key factor here, with lessons learned based on all of the complex, crufty code and overly huge global routing tables currently needed to keep IPv4 going.