Sorry for the delayed response - didn't see me in the to: or cc: fields. > |In terms of the stability of the addresses one has to take into account > |both stability as it relates to local communication and stability for > |global communication. > > We have always been told that stable global v6 addresses will not be > available to end users, or at least will not be available to end users at a > low cost. Unless you are proposing to revise the whole address allocation > architecture *and* have a way to force ISPs to change their business models > I think we must accept this as a given.
The temporal stability of addresses have a temporary component - it isn't black and white. Crystal ball: I wouldn't be surprised if small sites renumber the IPv6 addresses once a year with an overlap (both new and old working for a week perhaps). I see no reason why one would ever want to change them once a day. Taking together globally things means that there will be lots of renumbering in progress at any given time (given millions of sites and a reasonably long overlap). Thus I'm not too worried about e.g. my home site changing IPv6 prefixes all the time. Of course, there is a concern for applications which keep a connection open for a long time (weeks), but I suspect that such applications are, or need to be, capable of reconnecting since they need to be able to deal with peer failure. > I think you have made an unreasonable leap by dropping the "stable" > qualifier. The value/importance of _stable_ local communication is almost > certainly much higher than the value/importance of _stable_ global > communication. Even with the "stable" qualifier my opinion is the same. You are welcome to disagree. > But my NFS client is simply not prepared to have its server's > address renumbered out from under it. My multi-hour build will fail unless > I notice the problem and fire up adb on the kernel in a hurry. Similarly my > print job will fail if the printer and/or client is/are renumbered in the > middle of a tcp session. You seem to be assuming flash renumbering without overlap. With a one week overlap when a site gets renumbered by its ISP your two week long build might require a umount -f for NFS, and your petabyte print job (that takes > 1 week to send to the printer) might fail. > My distributed home automation system, while quite tolerant > of temporary lost connections and machine reboots, can not deal with > addresses changing out from under it. This is hardly unreasonable because > the tools to deal gracefully with such situations have not yet been > invented. To make such things work now each application would have to > implement its own procedures to deal with unstable addresses. This is > obviously not acceptable to application writers. And the tools to deal in a robust manner with multiple-scopes of addresses have not been applied to your home automation system either. To be it makes more sense to get applications to - not cache DNS answers forever - be prepared to restart connections after redoing a DNS lookup if the connections are open for a long time (days or more). I think this is less work, since many applications can get away with doing nothing, than having all applications handle different scope addresses. > We understand that sites are administrative. Section 4 in draft-ietf-ipngwg-scoping-arch seems to say something differnet. A site doesn't span multiple administrations, but it is limited to a single geographic location, such as an office, an office complex, or a campus. > |So let's not loose sight of the fact that the goal is a robust network. > > I think that the goal is a useful network--useful not only for ISPs and > application vendors but for consumers. Agreed. I don't think I was saying anything different. 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] --------------------------------------------------------------------
