* Jeroen Massar:
1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match.
What about the organizations that have say a /19, want them to inject all their more specific /32's?
You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used. At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are.
2. Drop the Flow Label and Next Header fields from the IPv6 header.
Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc).
IPv6 was designed for ACL-free software forwarding. This is not what we need today. Real routers must be able to access some layer 4 information. A better header would do away with any layer 3 options or option replacement. It would consist of 7 64-bit words. The first word contains the IP protocol version number, a hop counter (not a TTL, because it can be spoofed), and a bidirectional next-layer protocol identifier (protocol number plus some optional data that is indepedent of the direction of the packet flow and constant for a given "connection"). You can include some bits for QoS if you want, but I'm not sure if this makes sense. This is the first word. After that, the source and destination address follow (two words each). The remaining two remaining words are the next-layer source and destination address identifier (think port number, but you can put some additional cookie in there to make blind spoofing harder). In order to create a reflexive ACL entry, a router would zap the header flags and the hop count (which are ignored during matching anyway) and swap the source and destination addresses. No more upgrades so that you can filter still-a-bit=obscure protocols such as SCTP. Of course, a discussion about header layout is a bit pointless. But it is still a bit unfortunate that a protocol header explicitly designed for efficient forwarding does not come anywhere near that goal.
3. Reinsert packet fragmentation into the IPv6 header. Path MTU discovery just ain't cutting it.
And then have routers do fragmentation again? Nah. IMHO fragmentations at endhosts was one of the best things introduced in IPv6.
Sure, makes sesnse. But signaling that fragmentation is needed must be completely in-line. What about this: Truncate the packet, set a bit in the header, and forward it to the destination? The destination can request retransmission from the source and specify the exact packet size that went through.
Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine.
The market has spoken. Dropping ICMP is fine, I'm afraid.
4. Drop 64 bits from the IPv6 address. The lower 64 bit are just pointless as host indentifier. Very poor overhead ratio.
Maybe you would like to see something like IPv8/IPv16 then, which according to the fortunately vanished mr Fla^Heming used a "StarGate" model. Something like:
This is indeed a bit drastic. I'd rather see this attacked from the other angle, wasting less then 64 bits for access networks. The main problem I see with the /64 approach is that the remaining number of bits (< 64, may less than 60) is not sufficient to stuff two unique identifiers into the address (provider identifier and globally unique customer site identifier).