Thomas Narten writes:
> If the real feeling here is that site locals are bad if they end up
> reproducing some of the same problems as private addresses, then we
> should produce documents that explain when site-locals can safely be
> used (i.e., an applicability statement that describes when the IETF
> recommends their use). For other uses that people imagine (or that we
> expect they will imagine), but for which we think is a bad idea, we
> should say *why* its a bad idea *and* we should suggest a better way
> of doing it, so that folks who have a particular problem can choose an
> appropriate solution.
To my mind, one of the key failure modes of
overlay addressing is collisions when the original
assumptions of the overlay cease to be true --
like when you get two companies who merge, say,
and their net 10 address spaces collide. This
drives integration attempts to a great deal of
distraction and a Quick Fix NAT(tm) is almost
certainly the result.
What you'd really like in that situation is to
renumber, but color me skeptical that renumbering
will ever be "easy" or "automatic", especially
when you consider the widespread conflation of
addresses as routing tags and as identity. Thus,
I think site locals will still beg the Quick
Fix NAT(tm). Badness.
If we instead say that you should just blackhole
otherwise globally routed prefixes at the site
boundary, we don't run into this problem. If you
have a change of policy, you just change some or
all of the prefix that gets blackholed instead of
renumbering. Just as easy, if not easier than
setting up NAT's, IMHO.
Mike
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
