Date: Tue, 11 Jun 2002 11:05:25 -0400
From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think this is the key point. Regardless of the possible benefits of
| site-local addresses -- and I'm willing to withhold judgment on that
| point -- we don't know in detail how to make them work.
That's true. Te question is really should we go ahead and figure
out the answer, or should be just decide that we don't know the answer
today, and consequently, we will delete the mechanism, so even if someone
does work out the answer tomorrow, it is all irrelevant, because there's
no way to use it left in the protocols any more.
There is way too much of the latter in all areas of the IETF these days.
I don't know the answer to this today, so I will forbid it forever.
| At a minimum, we need changes in routing and the DNS.
No. At a minimum we need changes to nothing at all. Not changing
routing might alter the way SL addresses get used - effectively imposing
DMZ's between sites. With that, a SL address (to routing) is simply
the same as any other address, scopes are irrelevant (as there's never
two different ones touching any node). The most we need is a way to
filter routing information passed around - and that we already have.
The DNS needs no changes whatever we do. We simply never put SL addresses
in the DNS, no matter what. There seems to be this fixation that the
DNS is the only thing that can ever be used to translate between names and
addresses (some of the side discussion on addr->name translations is
showing that). People, the DNS didn't always exist, and we still managed
name to address translations! While I wouldn't advocate going back to
host tables as a translation method - the fact that there was once a world
with no DNS shows that it is possible to do things other ways.
I still believe that the right way to use SL addresses (other than in
disconnected sites, where SL is all that exists, and they can go in the
local private disconnected DNS with no problems at all), is for an app
for which use of a SL address makes sense, to indicate that to the
resolver when it does its name lookup. The resolver then looks up the
DNS (the normal way) and gets back global addresses (and only global
addresses). Then using (one of the) node's local site local addresses,
the resolver sends a packet to the global address(es) received - a ICMP
node information, asking for the node's site local addresses (on the
interface the packet arrives). If there is no site border in the way
it will get a reply with the relevant site local addresses included.
It then simply places those addresses in the information it returns to
the application (most likely inserting them ahead of the globals in the
list returned, but an API option could indicate to return only the
site locals when any are available, suppressing global addreses).
>From this we get site local addresses to use, and there's none of them
at all in the DNS - the cost is a couple of extra packets when the
application translates its names. And only for applications that have
indicated that using SL addresses makes sense. That really means only
for long lived apps, as the main reason for using SL addresses (disconnected
sites aside) is so a renumbering event wouldn't affect the connection.
If the connection isn't likely to last longer than old addresses would be
in deprecated state, then using SL addresses instead of globals makes no
sense. Hence apps that have short lived connections typically (which
means less than multiple hours - perhaps even mode) would never do this.
No extra overhead at all for http, smtp, ...
The other implication from this, of course, is that all nodes on the
global internet (that are ever to be reached based upon their names)
would be required to have global addresses, as that's all the DNS ever
returns. That's fine - let's get rid of the absurd notions that
having only a private address (1918, SL, anything else) has any benefits
at all - they don't - all they do is provide restrictions (not beneficial
ones, they can't be relied upon). Nodes that are never to be named
could have SL addresses only, though personally I don't see the point.
| We may need new global
| namespaces as well, with all that implies for co-ordination and
| administrative overhead.
Not for SL addresses as defined now. Some proposed modifications of SL
addresses might need such things (or might not, NUSLA's didn't), but this
part is certainly irrelevant for now.
SL addresses are just fine. More work is needed on them for sure, to
make them even more useful, and suggesting to people that until the
implementations better support them, they should consider very carefully
before enabling the things, is all just fine. But there's no reason at
all to be even considering deleting them.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
