Andre Oppermann wrote:
I've posted my proposals under "Andre's guide to fix IPv6". When do you with yours?
Ripped from: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01166....
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 currently already do a perfect match on the first 32bits and then check if there are more specifics for this block or not. But I guess that theory is much better known to you than to me ;)
Perfect match scales better and is way more economically to implement in hard- and soft- ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix up to /64. 32 bit in the DFZ give us 4 billion routable entities. See "Scalability issues in the Internet routing system" thread on NANOG, starting 18. October 2005.
Should indeed work pretty well. This is also one of the many reasons for me to say that when there will be any "IPv6 PI" introduced it should either be of size /32 or come out of a globally single /20 or something large that should accommodate all these prefixes, so that routing engines can be configured to support longer prefixes in that prefix.
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).
They are architectually broken and do not belong to this layer. Just encapsulate the packet in another layer like MPLS.
Then why not drop IP and just route with MPLS? :)
Next Header is broken because it's just source routing again. Dead for a long time. Nobody in their right mind will allow header popping through their firewall/network.
That is only one of the many possibilities to use Next Header for. I guess what you wanted to state here is that you don't see a need for "Hop by Hop Options" and other such headers so that routers don't have to parse through the next header because they don't have to expect anything there. Next Header in itself is the same as the IPv4 protocol field stating that TCP/UDP/etc is following it.
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. Especially for routers. Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine.
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: +----------------------------------------------+ | Ethernet macsrc+dst next=IPv16_SG | +----------------------------------------------+ | IPv16 StarGate = 3ffe::1 next=IPv16_Planet | +----------------------------------------------+ | IPv16 Planet = 4526::1 next=TCP | +----------------------------------------------+ | TCP | +----------------------------------------------+
6. Do away with those stupid ':' separators in IPv6 addresses.
That is just representation, if you want you can drop those, just don't expect any (afaik) tool to parse it for you. Most human brains will not like you dropping it though, they are quite comfortable reading hex nicely grouped in clusters of 16bits but would not like to read something that is not nicely clustered, YMMV. You can always easily patch your kernel to support it if you want. The whole idea with IP addresses is that you stick them in DNS in the first place, so you would not see them anyway. (Or are you mailing address-policy-wg@<hmmm what shall we fill in here, gee so many options>...) Greets, Jeroen