> Erik Nordmark writes: > > I don't think stable addresses per se is the key > > thing - it is the robustness of the communication > > that is important. > > I agree with this. However, the minimal degree of robustness > is working at all - something which requires some address of > some sort. There needs to be a way to get an address when > you don't have a provider. This means either scoped addresses > as we have defined them already (and in multi-link locations, > this means either site-local or multi-link subnet routers and > link-local), or some sort of provider-independent address > (note there are various types of these as well, depending > upon whether we believe they should be explicity > non-routable, or privately routable between multiple > non-connected 'sites').
I cannot see anyway to route site-locals across multiple sites? Your not saying to do this are you? Now if a site is split geographically but the same site that theoretically could happen but have we thought of all the deprecated cases and that which breaks to provide routing between them? I don't think we have or had that discussion. Or do we care about the above case here in the standards group? I think we should. Part of the issue for all this mail is not to kill SLs but to make sure we understand them and how to use them and how to manage them and what their affect to users will be. > > > This robustness has at least two factors that are > > relevant in this discussion: the stability of the > > addresses, and the leakage of non-global scope > > addresses. I think the question is how to > > weigh those together. > > Regarding leakage of non-global scope addresses, I don't see > this as a major problem given the way our current scoped > addresses are defined. Having an explicit prefix makes it > straight-forward for border routers to filter them. The > scope-id in the sockaddr field makes it easy for applications > to know on which interfaces an address is usable and to whom > it is legit to pass (something that isn't true for the > 169.254.x.x "link-local" addresses in v4 today). I'd be more > worried about leakage of provider-independent addresses which > don't share an explicitly non-routable prefix. I too am more worried about PI addresses for sure. SLs are much wiser to support what I believe some want from SLs. As far as leaking the problem is also if they are tunneled too? But we need a spec that we all buy into that states they are not to forwarded beyond a router site interface until we all agree on that spec how can we ask the general public to use them. That is not wise. Until we figure that out we have to say don't use them with globally connected networks. Sure some vendor may filter them and do the right thing but I for one want a spec that says don't do that and see us all hum to that and agree. We need a spec that just does this for SLs and nothing else about scoping. > > > In any case, for a home user I suspect that the > > value/importance of local communication would > > typically be less than the value/importance of > > global communication. > > As I mentioned in my last message on this topic, I believe a > lot of the argument around site-locals is really about > expected usage models. Personally, I would expect the > opposite of what you say above. Home users watching a movie > on their IPv6-enabled television screen in the living room > (which is streaming in from the media server in their > basement) won't be happy if their movie quits because their > kid just dialed into the Internet and the resulting global > address advertisment required all site-local communication to stop. With a spec that defines the boundaries this would not happen to this user. > > More generally, I don't want IPv6 to be just for the > Internet. If we've done it right, IPv6 will be used for all > sorts of communication between lots of devices which > typically don't have network connectivity today. I'm worried > that this working group too often sees things in terms of > only traditional computers as the hosts, and the routers all > belonging to organizations which have administrators to run > them. We shouldn't try to dumb down IPv6 so that it only > works well in the environment IPv4 was conceived in. I agree 100% with this view. Good luck here. > > > Finally, an enemy to robustness is complexity. > > Site-locals add complexity in many places; > > applications, two-faced DNS configuration, etc. > > Yes, needless complexity is bad. But site-locals don't add > any significant complexity to applications (which I think > I've demonstated enough in too many emails already). Many > existing IPv4-only sites run two-faced DNS today, so there > clearly are people out there who think it is worth it for > reasons that have nothing to do with IPv6. If we think > that's not optimal, we should be thinking about figuring out > why they run their IPv4 networks that way today and come up > with a better solution for them using IPv6. I think they do add complexity but that is not the issue and no one will win that debate. Two faced-dns is complex. The issue is we have not defined the boundaries of their use and the pain they can cause well enough for them to be used without health warnings currently. > > > So let's not loose sight of the fact that the > > goal is a robust network. > > Sure. And scoped addresses have the potential to make the > network more robust (I'd say that link-locals have already > proved their worth in this regard). I agree and we understand clearly the use of LLs and their limitations, but we do not for SLs. /jim > > --Brian > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
