Margaret Wasserman <[EMAIL PROTECTED]> wrote:
|>I realize that there
|>have been suggestions recently that you should always use a global address if
|>one is available, but that's not a problem with scoped addressing--it's a
|>way to deliberately break scoped addressing.
|
|It is also a way to avoid breaking Mobile IP.
In a killing-ants-with-cannons sort of way...
|>It is true that site-locals do not by their mere existence automatically
|>protect a site against renumbering, but that is a straw man. Site-locals
|>allow a site that cares to protect connections that it cares about. This
|>is an important capability. Do not be so quick to dismiss it.
|
|Do you really need site-local addresses as currently defined
|(ambiguous, scoped address) to achieve this?
It is clear to me that nothing I would want from site-locals requires
ambiguity. The scoping question is more difficult to answer. You need
to be able to be sure that both ends of the internal connection use the
stable addresses. You can control the destination address by using different
name for different addresses; however, without scoping and without access
to the application source code you may not be able to control the source
address. The intuitively obvious choice of source address (closest match
to destination) works, of course, but I would be concerned that this might
not happen exactly because of thinking like yours above. That is, someone
will do something ``to avoid breaking Mobile IP'' or such and in the process
break local connections.
|Or would it be
|better to have your own globally-unique, provider-independent
|prefix (perhaps assigned by a registry) that wouldn't require
|any special treatment from hosts, applications, etc. and that
|you could choose to filter at your firewalls?
Give me that prefix and tell me how source address selection works and
I'll let you know. In the meantime, site-local addresses as currently
defined are the only solution that is currently defined...
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
