Hi Margaret,
The goals you state below are very worthy and, once there are
satisfactory solutions employing unambiguous addressing, I will
certainly be vying for the privilege to be among the first to implement
them.
However, at this point deprecating site-local addresses will simply slow
down real world deployment of IPv6 and, in a very concrete way, take the
pressure off those who are the most motivated to work on better
solutions. The fact that people feel impelled to buy time for the IPv6
WG to do this does not give me great confidence that those solutions
will be arriving any time soon.
Regards,
MikaL
On Sat, 2003-04-05 at 14:58, Margaret Wasserman wrote:
> Hi Mika,
>
> At 02:21 PM 4/5/2003 +0300, Mika Liljeberg wrote:
> >On Sat, 2003-04-05 at 13:11, Patrik F�ltstr�m wrote:
> > > Yes, of course we should. But, I think we can not get real force behind
> > > such work before we _first_ agree Site Local is not solving this
> > > problem, and we therefore agree Site Local should go away.
> >
> >Forgive me for being cynical, but another way to phrase the above is
> >that the intent is to deny an existing solution to people who are
> >content with it in order to force them to work on a new one.
>
> Or, considered another way...
>
> We'd like to deprecate the flawed solution now, before more people
> implement it or come to depend on it.
>
> And, we'd like to pursue a viable model for local addressing, without
> the flaws and limitations inherent is ambiguous site-local addresses,
> because we understand that solutions will be needed for:
>
> - Addressing for disconnected sites.
> - Addressing for intermittently connected sites.
> - Prefix-based access control.
> - Stable addressing for local connections.
>
> What we _really_ want is to achieve all three of the following
> things simultaneously:
>
> - All addresses are globally routable (note that this doesn't
> preclude filtering some addresses or address/port combos).
> - Addresses are provider-independent (stable across ISP changes
> or ISP renumbering, available when not connected, etc.).
> - Core Internet routing tables stay a manageable size.
>
> But, we have not (yet?) come up with a model for provider-independent,
> globally-routable addressing that does not result in routing table
> bloat.
>
> So, network administrators will be forced to choose between
> global-routability and provider-independence for their internal
> addressing. And, as we've learned in IPv4, there are a fairly
> large number of people who will choose provider-independence over
> global-routability.
>
> So, we do need to provide some solution for provider-independent,
> local addressing. But there is no reason why these addresses
> need to be ambiguous. And, if they are globally unique, they
> don't need to be constrained by the limitations of current
> site-local addressing that are required because of thier ambiguity
> (can't be nested, can't overlap, etc.).
>
> Deprecating site-local addressing does not immediately remove
> it from those implementations that include it, and it certainly
> doesn't remove it from current network configurations, but it
> does send a strong message to people that the current, ambiguous
> site-local addresses are not a solution that should be invested
> in further. And, it opens the door to finding new, viable
> ways to address the demand for provider-independent addresses.
>
> Margaret
>
>
>
>
>
>
>
>
>
>
> Margaret
>
>
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
