> 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').
For the disconnected site I think the site-locals work just fine, and I haven't seen any strong arguments against using site-locals for a disconnected site. As many others have pointed out the complexity is not associated with the case of the disconnected site. > 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. True for IP packets which is not my concern; the leakage is likely to happen in higher-level protocols. We don't want the router to filter or modify those. > 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. The scope-id makes it possible, which is very good, but it doesn't make it easy IMHO. As an example of what every application needs to do you can talk to the folks that did the work for SCTP (not that SCTP is an application, but it does pass IP addresses around when establishing connections to be able to use alternate paths). My understand is that understanding what needs to be done with limited scope IPv6 addresses was a major complicating factor in this work. We can get such things to be done well for work done in the IETF even if it is extra work. But for applications developped all over the planet I'm far from convinced that they will provide robust solutions when there is a combination of site-local and global addresses. > 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. Nor will they be happy is the download of the move in the afternoon didn't happen because the L2 link dropped and got restablished with different IPv6 addresses. If the ISP provide the disservice of unstable IP addresses I think we have a large class of problems. The fact that site-local addresses might ameliorate some of those problems doesn't magically make such ISP disservice useful. > 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 think it is fine to use IP technology outside the global Internet. It might even be fine to subset the IP technology to do this. But what doesn't make sense in my mind is to have the desire to use IP technology outside of the global Internet cause significant additional complexity in the technology. > 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). Time to agree that we disagree on this point. (Unless you are talking about site-locals being restricted to the disconnected site case.) > 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, but I'm not certain, that most of the large sites that do this have completely different DNS content in the two-faces i.e. it is more like two separate DNS services than two-faces of the same DNS database. That is, the DNS outside the firewall contain a subset of the RRs and names, and there isn't necessarily a dynamic update path between the two DNSes. Do you have examples of folks that have small setups of two-faced DNS where e.g. dynamic DNS update works while still keeping site-locals on the inside and global addresses visible through both faces? > > 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 must have missed the proof. Do you have a pointer to something which captures normal users, dynamic DNS update, application development handling multiple concurrent scopes, etc? Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
