Hans Kruse wrote: > ... > and in draft-hain-templin-ipv6-limitedrange-00.txt > In the simple case, hosts that are allowed external access have a > policy that allows them to configure both global and limited range > prefixes, while those that are not allowed global access have a > policy that only allows limited range. ***Address > selection rules will > prefer the smallest range***, so internal communications > are forced to > stay internal by the hard filter at the border. > > (Emphasis added by me). > > draft-hain-templin-ipv6-limitedrange-00 does a good job > outlining scenarios > that may require the use of local addressing, but I think it > errs in the > statement above. The local addressing requirement is real > enough, but > these are still corner cases. Aside from ambiguity, > enforcing the concept > of scope or range _in every application_ seems to be one > that folks really > want to get rid of. > > Hence, lets revisit the question of _default_ address > selection. What if: > > "Unless an application explicitly requests otherwise, an IPv6 > node must use > its unique, globally routable address if one is configured. > If no such > address is configured, the node shall use its limited range > local address, > if configured." > > Along with: > > "An IPv6 node must allow an application to explicitly request > the use of > the limited range local address, if such an address has been > configured, > even if a unique globally routable address is available." > > What I am trying to get to is: > > - Application designers who want to work in the "end-to-end > clean" Internet > and who do not care to support the corner cases should be > able to do so. > > - The default address selection rules should favor solutions based on > global addressing, I think we all agree that if such a solution is > reasonably possible, it should be used.
No, we do not all agree. See below. > With the defaults above, the > "path of least resistance" is not to use limited range, > which is good. While I appreciate your goal of compromise here, the insistance of avoiding the local prefix is short-sighted. In particular it overlooks the point that during an ISP prefix change local application stability is only possible using the local prefix. If the default is to avoid the local prefix, every local app will break on a prefix change, which is directly contradictory to the goal of a smooth transition between ISPs. I think we should explicitly disallow a mismatch between local & global. In addition, to achieve the use of globally routed in the non-local cases the name resolution system needs to provide contextually appropriate answers. > > - Finally, if a solution requires local addressing, and > application writers > want to support it, there needs to be a standardized way to > do this (which > is why local addresses must be defined and recognizable). I agree there should be a way for apps to specify a preference for one or the other. > > In draft-hain-templin-ipv6-limitedrange-00, scenarios where > all machines > either have only local addresses, or where all of them (albeit > intermittently) acquire global addresses along with the > local ones, will > work with the default behaviour suggested above. No, if applications in an intermittently connected network selected the non-local prefix, and it went away or changed, they would need to drop and reestablish the connection. Yes they could keep using the prefix as long as it was still valid, but from a diagnostics and management perspective you don't want a bunch of deprecated-but-still-valid prefixes running around for communications that should always stay internal to this network. Also, in some cases the application will want to run for longer than the valid time, so even if that approach is taken local apps will break for no good reason. > > Cases where networks contain a mixture of nodes (some local > only, some > local and global), and very long-lived connections in intermittently > connected networks, need special handling. In both cases it seems > reasonable that applications will be written or at least > configured to be > aware of the local/global address issue. Why? Are you suggesting that a ship can't run a stock database implementation? Yes specialty applications should be aware, but there is no reason to preclude use of off-the-shelf configurations. > > Along with safeguards against address translation in the > nodes requirement, > and routing restrictions in the address format document, > this should work. > > I know I left out plenty of detail, but I hope the general > idea is clear > enough. Comment/Flame away..... > Not a flame, but one other issue; there is a security argument to be made for defaulting to limited range addresses. If the default stance is limited range, people would not be automatically exposing their system just by installing an app. Of course the counter argument to security is configuration simplicity, and making Joe-sixpack explicitly select the exposure range is not particularly viable either. Getting back to your point about api selection, should the default api be don't-care, or limited-only? Using the current address selection rules for the don't-care case, the behavior would be more stable for local apps but still exposed for global reachability. If the default were local-only, the app, or sys-admin would have to explicitly select when exposure happens. This is really a question about how much we really want to see hosts and applications protect themselves ... Tony > > > > Hans Kruse, Associate Professor > J. Warren McClure School of Communication Systems Management > Adjunct Associate Professor of Electrical Engineering and > Computer Science Ohio University, Athens, OH, 45701 > 740-593-4891 voice, 740-593-4889 fax > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
