Margaret Wasserman wrote: > ... > I realize that the IETF cannot enforce such a restriction. > But, we can write a standard that says "these addresses are > intended for use on isolated networks and must not be used on > non-isolated networks" (or equivalent).
My concern is the choice of 'must' rather than 'should'. SL works perfectly fine for networks attached to the Internet when used by 2-party apps following addr selection rules. Stating 'must not' is silly when there is a clear case where they work. > We can also document > the problems that are likely to occur (presumably in a > companion Info or BCP document) if site-local addresses are > used on connected networks. I am working on a document that > outlines the problems and recommends placing limits on the > IETF-advocated/supported use of site-locals, and I believe > that others are working on alternative proposals. Just be careful not to legislate against the 2-party case that most people will find useful and works just fine. > > >2) It is not a requirement that a connected network not use them. > > I'm not sure what you mean... Claiming that they must not be used on a connected network means we know they will always fail, or the problems are significantly greater than the value. We have a couple of examples of great value with no cost. These don't impact the greater Internet, so we shouldn't be telling people 'must not'. > > >The only reasonable argument here is that the IETF may > choose to leave > >the details of such use undocumented, and not spend time > addressing the > >DNS issues. > > Actually, I think it would be quite reasonable for the IETF > to provide a strong recommendation against using site-locals > on connected networks, and to document the problems that they cause. I agree that a BCP about the issues caused to multi-party apps is needed, and have said so several times. That does not translate into a need for a strong recommendation not to use them on connected networks. > > >We might provide an informational document that provides guidance to > >sites to randomize the upper 38 bits to avoid potential > problems with > >mergers later. We don't need to specify a standard > mechansim, but might > >suggest a couple of reasonable stratigies. > > I wouldn't try to stop this sort of approach if others think > it is valuable. I just don't think that it solves the larger > problems caused by site-local addresses, and I'm not sure > that its benefits are worth the effort. Real PI independent > addresses are the only real solution to this problem, IMO. > So, I'd like to see if we can find a way to provide PI > addresses in IPv6. > > I have been thinking about this topic a lot lately, and I > have been refining my thinking... > > In order to provide real PI addresses, we have both a policy > issue and a technical issue, both of which need to be solved. > > The policy issues is that registries are currently set-up to > provide addresses to service providers for further delegation > to customers (enterprises, homes, etc.). In order to supply > PI addresses, this would have to change. I don't know what > type of difficulties would arise in making this change -- > address allocaton policy isn't something I know very much > about, but I guess I'll have to learn. It depends on the mechanism we end up with. My approach does not require the registries to be involved in general, but does have a database role for them if that proves to be useful. > > The technical issue is that we don't want to allocate > non-aggregable addresses that will show up in the global > routing table. Tony, you seem to have a good start on one > approach to solving this problem. Are there other > well-developed proposals? What are the current > issues/weaknesses to your approach that will need to be > resolved before it is workable, if any? The only non-FUD comment I have heard is that the current business relationship between the exchange points and transit providers does not fit with the plan. While I am not trying to mandate a change in business practice, business relationships do evolve over time. I believe it is reasonable to expect that with a supporting techincal approach, the motivation will exist for that issue to take care of itself. The other significant issue with the approach had been the less-than-elegant handling of Europe through prefix pairs (east & west of 0). With the last pass, that was fixed so that the problem moved to Alaska & Hawaii (which are now more closely associated with Tokyo than Chicago). Since dealing with this is just a couple of exception prefixes rather than the set necessary to fix Europe, it should be more acceptable. I haven't received any comments on the current state of the update, but wouldn't expect too many until it goes out as the -04 ID, probably in Jan. There are other proposals in varying states of completeness, so we could have a lively debate about the trade-off's of each next year. 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] --------------------------------------------------------------------
