Stephen Sprunk wrote:
Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
| To assign more than one address to every host means the host
| must have an intelligent means of deciding which address to use.
Yes, but the amount of intelligence actually needed is pretty minimal.
(It is actually harder to decide between multiple available global
prefixes, than to decide between global and site local - the former is
a difficult problem, the latter is almost trivial).
disagree. the app can choose any global prefix and reasonably expect
it to work, modulo link failures.
Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6
equivalent), so it's really the OS which is choosing the source address. If
the app binds a specific source address, it is invariably user-configurable
and thus not an application problem.
Nit2Nit :>
That may be.. but it sure does not help us poor kernel developers any
:-<
but when choosing between a global and a site local the app needs to
know whether the site local address will be valid for the hosts that need
to use it, and it has no way to know this.
Well, since one can easily determine whether the destination address is SL
or not, picking a source address of the correct class is trivial.
I don't know if that is true.. if a host has multiple sites
on it and each site is multi-homed... aka
-------Intf-A---+----------+----Intf-D------
| |
-------Intf-B---+----------+----Intf-C------
Say Intf-A/Intf-B are on one site
and
Intf-C/Intf-D are on another site..
Then if the SCTP stack is told to send a INIT -> out to a SL
address on Intf-A selecting the source address is somewhat ok
if the routing is set up.. but what other addresses do I list
in my INIT?
Ideally I would like to list the address for A and B. This way
my peer could take advantage of my multi-homing.. but instead
I can't... since when the peer receives the INIT it would have
no way of knowing the scope for the address and what interface
the address went with...
Other more complicated scenario's can also be imagined with
the above.. multiple sites on each host.. some shared some
not.. aakk... yuck...
It seems to me that with all the available address space having
a SL is just a waste.. If an enterprise is worried about
security put up something that is real aka a firewall.. not a
NAT...It does not really add anything but it does drag
along an ugly abomination that was needed as a stop-gap measure
for the address shortfall.. Now we have the solution we are
dragging the old junk along.. how silly...
This SL thing seems to me like a un-needed complication..
the app may also have to choose which interface to use with the site-
local prefix, and it has no good way to know this either.
Ah, but it'll have a different SL address on each interface, so that's no
worse than having multiple global addresses. The truly interesting case is
connecting to a LL address with multiple interfaces.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--------------------------------------------------------------------
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
majordomo(_at_)sunroof(_dot_)eng(_dot_)sun(_dot_)com
--------------------------------------------------------------------
--
Randall R. Stewart
randall(_at_)stewart(_dot_)chicago(_dot_)il(_dot_)us 815-342-5222 (cell phone)