we need to get rid of site-locals. merely renaming them as
private use addresses wouldn't solve any of their problems.
there's no advantage to moving to IPv6 if it repeats the RFC
1918 mistake.
Hyperbole does not serve either the community, or one's own
position, well in this situation or others like it.
John,
If I understand what you are calling hyperbole I would instead call it
the 10,000 meter view. That is, I don't see a significant market for
IPv6 if it doesn't support applications that cannot be run on NATted
IPv4. Yes, there may still be some small advantage of IPv6 for some
groups of users if this doesn't happen, but not for the Internet
community as a whole. So "no advantage" can be taken as an
exaggeration, but the intent was to avoid getting bogged down in
detail about exactly what minor advantages there might be and why
they're unlikely to create enough incentive for any widespread adoption
of IPv6.
And no, I don't think that reducing the number of NATs by 25-50% would
create a significant advantage to moving to IPv6. In order to create a
significant advantage, there need to be so few NATs in IPv6 that
application developers can write applications that will fail in the
presence of NATs without fear of losing a significant number of
customers.
I agree that there's a requirement for PI addresses, and perhaps, for PI
addresses that don't require RIR allocation. Various solutions have
been proposed, but we seem to be unable to evaluate them or choose
between them because we're too busy arguing about whether the v6 network
should be saddled with the baggage from v4.
The discussion about SL also seems to be couched in those terms, as well
as being confused by efforts to conflate different notions of scope that
are better understood separately. IMHO, those who think that hosts or
apps should have to bear the burden of picking which address or
interface to use in order to get packets to their destination need to
explain (a) where the hosts or apps get the information necessary to
make those choices in a reliable and timely fashion, and probably (b)
how to provide a usable endpoint identifier under those conditions that
can be passed between hosts at arbitrary locations. Until then, I'm not
convinced that the v6 assumptions about multihoming are workable. Which
further leads me to conclude that we still haven't figured out a way to
make IP routing scale in a practical sense.
Keith