Margaret, I am not trying to twist words, I am reflecting what I hear as it applies to the reality of the deployed network. Our primary disagreement is over process. Forgive me but I can't figure out the technical differences that exist, because at this point it is not clear to me what you believe, or if you believe the problems that many network managers would use SL for are real.
One thing that is clear is that there is no consensus in the WG as to what 'deprecate SL' means. Is it 1) remove ambiguity, 2) remove the definition as a well-known prefix to filter at the border of a site, 3) change the architecture to remove address scoping, 4) reduce routing complexity, 5) remove requirements on applications to deal with differences between prefixes, 6) pacify fear of change 4/2 AD - The ambiguity of the current site-local addresses will impact applications. We still need to solve the other problems (renumbering and disconnected sites) but we should do this using an addressing format which can be made transparent to applications. 4/2 JB - Ambiguous addresses are a nightmare... 4/2 MT - Scoped addresses as have been pretty well demonstrated take us down some pretty scary paths. 4/3 AZ - reasons += adds complexity to routing, forwarding, and network operations; 4/4 ER - It is important to simplify IPv6 DNS, routers and source address selection. 4/5 RB - i.e. let's solve a routing problem with an address model hack. pfui! 4/3 MW - This is actually a pretty good match for "deprecation" by my definition. We'd keep the prefix in the spec, but mark it as "deprecated, do not use", or something like that. 4/4 HA - Note: By "Deprecate Site-Local", I mean "Do not require any application, host, router, protocol or IETF practice to have to make special consideration for the idea that an IPv6 unicast address outside of the link-local range can refer to two different hosts". 4/5 DL - I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. Another thing that is not clear is how many of those who are saying 'Yes - depreciate' are actually motivated to solve the problems that will be created by whatever 'deprecate' means. I am not alone in that concern: 4/6 DL - Or are you saying that once site-locals are gone the IETF will be unwilling to allow any additional changes to the architecture to solve the renumbering, PI, etc. problems because these problems are not ``enough of a problem'' to warrant fundamental changes in the architecture? --> explicitly unanswered >From my perspective, if they really want a change they must participate in providing an alternative first. It is too easy to be destructive and walk away, which is exactly what this consensus call is setting up. Most of the 'Yes' comments are littered with value judgments (bad unnecessary dubious marginal scary) and show the commenter has no appreciation for the breadth of the real underlying requirements. Even your messages on the subject show you don't believe all the problems of the person fighting the day-to-day battles are real. Given the track record of this WG, and the lack of wide scale participation by those most effected (end site network managers), this call is a disaster in process. Whenever the I-D editor gets it processed, I have a draft that intends to identify the requirements for the alternative solutions to work from. Highlights: We need address space that is freely available for use by the network manager. Requiring them to get space from an ISP, or even continually pay a registry is not a viable plan. While this space might be declared 'unroutable', we need to design it on the assumption that parts of it may become routed and the routing table needs to stay at a manageable size. This implies some form of aggregation must be possible. Stable, local use prefixes are required. There are claims from the ISP perspective that a disconnected site will need to renumber when it connects. Renumbering in an IPv6 context means adding a prefix, and unlike IPv4 it does not mean removing the existing one. There is no reason for a site that connects to have to renumber nodes that are not going to use the external connection. In particular there is a need for existing internal applications to continue working as networks connect via different prefixes, so a site managed persistent prefix is required. One example of this type of network is a vehicle that attaches to local networks when stopped, and wireless networks while mobile. Site scoped addresses exist. We must recognize that route filtering == scoped addresses, and route filtering will exist despite idealistic hopes for a single flat routing space. We must also recognize that network managers want the ability to manage the scope of their name space and express a comparable policy to what they have for routing. This will not be easy, and the current round of comments show people prefer to make it someone else's problem. Also, awhile back you suggested a partitioned network example as a reason to use global rather than local addresses, because the partition could be healed through the Internet. That concept ignores the reality that almost all network managers would not want file mounts of proprietary content to suddenly traverse the Internet in the event of an internal partition. There are very valid reasons for local scope addresses. The idea that applications can blindly ignore that reality and treat the world as a single space has to be put behind us. Once we have the requirements collected, solutions can be proposed. I expect we will end up with multiple solutions, and it is not clear we will be able to meet them all without keeping the current SL. That does not mean we have failed, just that we have work to do. I do believe we can build a PI that deals with the majority of the ambiguity concerns, and I suspect that the remaining demands for ambiguous addresses won't expect or want to be interconnected. We are supposed to be working on technical approaches to problems, not reacting with fear to what bad things might happen. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
