[address-policy-wg] Re: Andre's guide to fix IPv6

* 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).