Date: Sat, 19 Apr 2003 15:23:23 -0400
From: Valdis.Kletnieks@vt.edu
Message-ID: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu>
| 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.
More importantly ...
| 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).
For internet access, a global address is used. Sites (and hosts) have both.
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.
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, and the ability to
seemlessly add new ones.
| 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).
Some kind of global assignment policy for those 38 bits would fix this,
but adds the costs of managing such a scheme.
| Unfortunately, people seem to want to forget about those two paragraphs.
No, this is exactly the kind of thing that was considered in the SL design.
| I'm afraid that unless site-local includes a 'MUST renumber' requirement
| for *BOTH* cases, it's a complete and total non-starter in my book.
IPv6 requires renumbering when an address that has been used is no longer
appropriate (which will generally be because of changed topology, which
may be local topology changes - moving a host to a different LAN, or global
ones - connecting to a different provider). That is the only reason.
As long as prefixes remain usable, they can keep on being used, with other
prefixes added as required.
kre