Shannon -jj Behrens wrote: > Please forgive my rough tone (in fact, I have great respect > for you as an engineer), I try to avoid taking any IETF discussions personally, one way or the other. > but it would be much more > interesting if you wrote a document that provided solutions > for all of the problems that people have claimed site-locals > cause. I understand that is what some people want, but I think we need to first agree on the problems that need solving. We have many opinions on why SL creates problems, but a blatant lack of recognition of the problems that need to be solved. > While I hear you saying that the wg should replace > all of the features that site-locals provide before removing > them from the architecture, I challenge you to instead take > the impetus of fully specifying site-locals. I believe the first step to doing that is to agree on the problems that need solving, then see if there are alternative approaches. > I do believe, > based on other comments on the list, that such a challenge > has existed for five years and has yet to be answered. > Having fully specified site-locals, I do believe the wg would > be much more willing to accept them into the architecture. I thought we were going there with the scoped arch document, but lacking agreement on the problems to be solved, it became easier to spread FUD and give up on addressing the issues than to sit down and work them through. > Although I clearly am not capable of providing the full list > of questions that you must answer, perhaps the following > questions are helpful: > > o In light of the fact that not every host has a DNS name, > how do you propose multi-party P2P applications should do > referrals? It would be helpful if you established the normal > mode of operation for such situations. As I said in the note to JCK, I have been imprecise about 'name' so whatever the app uses to get a handle from the local stack is what it needs to pass around. Doing otherwise ignores the reality that the network does not look the same from all points. > > o Should site-locals be put in DNS? Should multiple views of > DNS be used? If > so, how do you address the apparent apprehension in the DNS > community toward multiple views (I don't know about this > first-hand--I've only read about it > from this list)? Should zone information be kept in DNS? Implementation details of a multi-faced DNS are best addressed by those that already ship them. Any service that provides topology specific information has to do that with an understanding of the topology being described by that information. > > o Do you foresee all nodes being multi-site nodes? Certainly not all, my light switch should not be in any site except my house. At the same time I may want it to be in multiple scopes, so I can get to it and turn on the driveway light from the car as I approach. > If I'm at > work and wish to > use both my work network *and* my home network via a VPN > connection, I expect I would want my laptop to be a > multi-site node. If this is the case, do I > need to use %interface_name at the end of all IP's I give to > applications I > use? How would DNS lookups work on a multi-site node if > site-locals are stored in DNS? The name resolver would have to track which interface / site it got answers from because any limited scope resolution is only applicable in that interface / site context. > > o If, as you say, we should provide site-locals because, "we > need to meet the network manager at his comfort zone and > provide a familiar tool," how do we > convince the network manager not to use NAT since this is > also a familiar tool in most people's comfort zone. I'm not > willing to argue that site-locals > necessarily lead to NAT, but many people are, so you should > probably have some answer. Leading people away from something comfortable requires providing something that meets the same basic need and is easier/cheaper/more comfortable. Many use NAT because they can't get STABLE addresses otherwise, and NAT is simply the cost of getting that. Providing STABLE local use prefixes simultaneously with global prefixes that may change over time is a cheaper way to meet the need for STABLE addresses. * I emphasize STABLE because that is a invariant requirement by many managers of large networks. > > o Do you envision support for Margaret's idea of multiple > concentric rings of security (possibly using site-locals)? > If a node in the outermost ring is not able to talk to a node > in the innermost ring using a site-local address because of > filtering, but is permitted to use a global address, how > shall applications react when the site-local "hint" is > actually misleading? Personally I consider those security zones as different sites. This gets into the poor definition of 'site', but we were intentionally vague there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill flag prefix in how one would solve this problem. The fact that SL does not provide multiple concentric security zones is not a failure of SL, because that was not a design requirement (again we need to agree on the problems to be solved). > > Again, I'm sure there are many more such questions, and I > think it would be > helpful (and in fact requisite) that you answer such > questions in an Internet Draft in order to achieve your goal > of restoring site-locals to the > architecture. I thank you for your time and *patience* if > you have made it all the way through this message. I agree that we need answers to all these issues, and that was the intent of the scoped arch doc. Once people realize that they continue to exist for any local use prefix, we will stop the nonsense about SL is the evil that causes the problems and get back to developing the needed documents. Tony