Andre's guide to fix IPv6 (Was: Re: [address-policy-wg] Re: [ipv6-wg]IPv6 PI)

[Jeroen Massar <]

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.html

> 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@localhosthmmm what shall we fill in here, gee so many options>...)

Greets,
 Jeroen

Attachment: signature.asc
Description: OpenPGP digital signature