[ppml] Legacy /24s

[Paul Vixie]

> > of the three, i like #4.
> 
> I like option #29: IP extra large. If IP option header #29 is present
> starting at the sixth word in the IPv4 header then the "source" part of the
> IP header actually contains the four high-order bytes of the 64-bit IP
> destination address while the seventh and eighth words contain the 64-bit
> source address.

that wouldn't've been unambiguous.  what several of us were hoping for was
where the IP version number went to 6 and the addresses got larger and that
was all.  but because this would not have enabled all of the many things
promised for IPng in the document you referenced earlier (most of which
weren't delivered and are now undeliverable), the IETF intelligensia ruled
against this approach.  note that with either your option-29 approach or my
described IPVx approach, the ethertype would still be 0800.  that in itself
explains that IPv6 is really a "new internet" not an "internet extension".
(and it leads to IPv6's lack of backward compatibility with IPv4, which is
one of the now-undeliverable promises made in the document you cited before.)

> I guess it would have been too easy to let us grow incrementally with
> only changes on the software side of the house.

IPv6 has made more than a few careers.  someone early on called it the "full
employment act for programmers", and so it's been.  but nobody i know has
said that it was made difficult just to build careers or employ programmers.
more like, it is the product of an extensive committee process.

> >  of the three we actually have, though, i pick #3.
> 
> Yeah, I can live with that. But I will gripe about it now and then.

and i don't mind griping, either, even though at the end of the day we're all
going to have to deploy it, no matter how we feel, warts and all.  perhaps
DRC would choose "vastly increased NATism" now that IPv6's warts are really
showing, but from an industry standpoint, that's just sooooo not an option.

note: i am not speaking as an ARIN trustee in this message.