Keith Moore wrote: > > networks with intermittent connectivity might be a valid case for use > of site-locals, though giving such networks a non-routable global prefix > would cause fewer problems for applications.
[...] > the problem with the idea that site-locals should be favored over > globals is that this is exactly the wrong rule for some applications > and on some networks. as far as I can tell, address selection rules > need to be derived from a combination of application requirements > and local network policy. Agreed. But for the purpose of address selection, a non-routable global is functionally equivalent to a site local - it's an address whose scope is not the "global IPv6 internet". And as soon as we introduce addresses whose scopes are not all functionally equivalent, we have an address selection problem when multiple scopes are valid. We also need to consider whether our "site" prefixes are to be administratively or automatically configured. If administratively configured, I lease both prefix and connectivity from an ISP, install this into my top-level router / prefix distributor, and go from there. The prefix is valid regardless of whether I have connectivity or not. But what if: - I don't want (currently) to connect to an ISP? The site-local prefix provides a good default. Now, as soon as I get a real prefix I deprecate the current site local and initiate renumbering with the new prefix. But if it's illegal for the two to co-exist, I must kill ALL active internal connections at the point I make the switch. It would be nice to at least have a deprecated period on the SL. - I have a small, roving network (PAN, car, plane, ...), with the gateway latching to hotspots? My external address could change every 10-15 minutes. Internal nodes wanting external connectivity should be prepared to re-establish their connections frequently (ie long running tcp session on roving PAN is probably a bad idea). However, I don't really want every external switch to clobber my internal connectivity. A last thought: - Non-routable global prefixes cause more problems than they solve. The /advantage/ of fec0 is that it can be used in the total absence of external configuration information, and work. A NRGP requires all the configuration effort (both interfacing with an allocating authority and installation into the network) of a global with all the scoping issues of a site local. Why not just get a true global? -- Andrew White [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] --------------------------------------------------------------------
