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] --------------------------------------------------------------------
