Thus spake "Keith Moore" <moore@cs.utk.edu>Nit2Nit :>
| 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.
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@sunroof.eng.sun.com --------------------------------------------------------------------
-- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone)