> | Unbfortunately, I don't see where the biggest problems with 1918
> | addresses were cleaned up for site-local.
>
> Two aspects. First, they're clearly of local use (defined in the
> architecture), hence if they do leak, at least it is obvious what is
> happening.
right. but the anticipated use was such that if 1918 addresses leaked, this
would be treated as an indication of an error - namely that a non-isolated
network was connected to the Internet - and that the correction would be to
renumber the formerly isolated network. the intent of 1918 was to enable
correction of the error of giving a non-isolated network non-unique address
space, not to encourage that error to the point that it became common
practice (as has happened).
> | The problems with 1918 space were well understood at the time:
> |
> | A major drawback to the use of private address space is that it may
> | actually reduce an enterprise's flexibility to access the Internet.
>
> Is not true for site locals, as no-one anticpiates that a SL address is
> all an enterprise will be using (unless it is not connected to the
> internet, in which case questions of its flexibility of access don't arise).
on the contrary, having an enterprise use both SLs and globals creates
significant new problems of its own, and results in even less flexibility
than if SLs were used only by isolated networks.
> Similarly:
>
> | Once one commits to using a private address, one is committing to
> | renumber part or all of an enterprise,
>
> is not true of SL addresses, as one doesn't "renumber" them, one just
> augments with a global address.
this is a bug, not a feature.
> You may notice that it isn't *just* site locals that provide the cleanup
> here, it is the whole IPv6 architecture, considered as a whole. That
> includes having multiple prefixes announced to nodes,
multiple addresses at a node were available in IPv4, but the problems
associated with doing this have never been solved, not even in IPv6. so while
having multiple prefixes per node is clearly useful for renumbering, it's not
at all clear that this is a "cleanup" to the IP architecture. it's more
complexity that has to be dealt with.
> | Another drawback to the use of private address space is that it may
> | require renumbering when merging several private internets into a
> | single private internet.
>
> This one was certainly true of the original site local ("may require").
> (Only may because it all depends on how the merge gets done, and the
> actual subnet numbers). Now that site locals have been extended to use
> fec0::/10 instead of fec0::/48 it is much less likely (but still not
> impossible).
depends on how subnets are allocated. my guess is that sites are more likely
to allocate subnet bits from left to right, rather than allocating from the
right and picking the leftmost subnet bits at random - so that collisions are
still likely whenever sites merge.
> No, this is exactly the kind of thing that was considered in the SL design.
unfortunately, many important considerations were ignored in that design.
Keith