Date: Tue, 22 Oct 2002 13:41:57 -0400
From: Keith Moore <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| if an app has multiple addresses to choose from, and some work better
| than others, and the ability of the app to function effectively
| involves choosing an address, the app essentially needs routing
| information in order to make that choice.
Not really, it needs something similar perhaps, but it isn't routing
information. And in any case, this is true any time there are multiple
possible addresses, scoping of some addresses has nothing to do with it.
| yes, this possibility always exists. but we used to have a clean
| separation of function between the apps and the network
We still do, nothing has really changed.
| these days we are starting to expect the app (or more naively
| the host) to make decisions that require routing information, but without
| giving them the routing information.
Once again, it is not routing. Routing information isn't required.
| that was a fine strategy when a host had only a couple of addresses, and
| they were global, and all of the addresses worked most of the time.
| it doesn't work well when hosts have several addresses of varying
| scope, especially when combined with very ephemeral address-to-host
| bindings.
Much of that is just the same for v6, except that hosts might have
lots more addresses, and v4 or v6, name to address bindings don't last
forever any more.
| and once you start trying to figure how to describe scopes you
| find that what you really need is a global address space and routing
| information.
Global address space yes, routing information no. And the former
assumes that we actually want to deal with limited scope addresses
at a global level, which we almost certainly don't. Dealing with
them at a local level is sufficient.
| otherwise, what you're essentially saying is that having limited-scope
| addresses causes no problems that aren't addressed as soon as we have
| a solution to this other unsolved problem...
no, we don't need to solve the hard problem to make them useful.
| > I know you're concerned about apps (protocols) which pass around addresses
| > in the data (and consequently which aren't limited by the normal scope
| > control measures). Where that happens the apps just need to take care not
| > to pass an address to a node where it isn't known to be meaningful.
|
| there's no way for the app to know that.
Which is ...
| > Since that's hard to determine, a simpler rule that works, is simply never
| > to pass an address of a lesser scope (more restricted scope) than the
| > address being used for the peer in the communications over which the
| > address is to be sent.
what I just said.
| no, this isn't sufficient either because the app has no idea of the peer's
| scope, much less the scope of the eventual users of those addresses.
No, you didn't read what I wrote, I suspect. If A and B are communicating
using global addresses, then A sends B only global addresses. If A and
B are communicating using SL addresses (zone x) then A sends B only global
addresses, and SL addresses in zone x, which must be meaningful. If B
wants to send on the addresses to somewhere else (C) then it follows exactly
the same rule (and drops any SL zone x addresses if the would have to go
somewhere that isn't known to be in SL zone x).
If it turns out that there is no address left to send, then A & C can't
communicate, but that's evidently what was desired when the addresses were
assigned in the first place. If the administrators actually desire to
prevent hosts communicating, then that's what should be done.
In most cases, there will be global addresses, they'll work, and the issue
of whether some SL or even LL address might also work won't be terribly
relevant.
The info that an app needs to make these particular choices is trivially
easily available, and while it is extra work that apps haven't done before,
it is by no means difficult to manage.
What is needed is that we get beyond the "here is THE address you must
use" methedology, and always allow a set of addresses to be communicated
(either directly, or by sending a name and having the recipient do name
to address translation).
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]
--------------------------------------------------------------------
