> On Thu, Nov 07, 2002 at 08:30:48AM -0500, Keith Moore wrote: > > This seems like a good start. > > Indeed, shame it didn't come 200 emails ago ;-) It seems some concensus > can be reached on the assumption that site locals will continue to exist, > although many of us may be happy to not use them. Darwinism may > prevail here.
aside: I realize that evolutionary theory has taken on almost axiomatic status for many people, but it's not clear to me that Darwinian selection really does select the fittest candidate for the long term in a global environment, any more than hill-climbing methods of optimization produce the best solution over an entire solution-space. > > I think it would help to provide some advice to applications regarding > > site-locals (and for that matter link-locals). e.g. > > > > - don't use site-locals in referrals unless you have no global addresses. > > - use global addresses in preference to site-locals when opening new > > connections. > > Although that removes the advantage of site local addressing allowing > long-lived connections (e.g. NFS) to survive renumbering, or temporary or > permanent removal of external connectivity. right. it would still be possible to explicitly specify SLs, though explicitly specifying any IPv6 address seems likely to be viewed as painful. > The implications on > deprecation of the global prefix differ depending on whether the site can > reconnect later with the same global prefix (ie. the ISP uses static /48 > assignments or not), but maybe that is a dangerous path to explore. right. you really want to treat stable prefixes differently from unstable ones, but how is the application to know which are which? > The applications advice also implies some note required for DNS behaviour, > in terms of what is offered in response to a remote query and how it is > handled (or not). what is a remote query? DNS needs to produce consistent results no matter where the request comes from. I don't really think that DNS should be treated any differently than any other app that performs referrals. If we find ourselves wanting/needing to make special exceptions for DNS in order to accomodate scoped addresses that is a sign that we're probably breaking other apps. > > I think there will be enough desire to use site-locals at least for > > limited-purposes in networks that also have stable globals, and that > > it will be useful to provide some advice on how to constrain such use. > > Maybe add a note that well-known site locals may be recommended or suggested > for service discovery for certain services (witness the recent DNS > discussion), so there's one use (which is in the spirit of site locals, > and where cross-site connectivity is probably not rquired). > > Many networks use private IP space for network management (in or out of > band); site locals may (will?) have a similar popular use in IPv6. Of > course at the moment IPv4 access is used for most IPv6 network management(!). they could. though again, specifying IP address literals will probably seem painful. of course, in the case of SLs, that might be a Good Thing. > We may find that site-locals offer some use in future renumbering, > multihoming or other service solutions, that have not been foreseen yet. certainly they could be useful in renumbering. > > I think there is a need for sites to acquire globals even if they do > > not connect to the public Internet. I don't think coordinating use > > of site-locals will scale. > > The question then is who maintains the "site-local global"(sic) address > space? I have several (possibly lame) ideas: - IANA and/or RIRs delegate prefix blocks to the registrars that are already qualified to sell domain names, who can then sell such prefixes. - we find some way to derive a unique 48-bit prefix from an Ethernet address which doesn't eat up all of the v6 address space and doesn't conflict with existing address allocations. then, any site can take an Ethernet address and derive a prefix from it. (I don't remember how many bits of Ethernet address space are reserved for things like global/private or unicast/multicast, so I don't know how much we can shrink down a 48 bit Ethernet address and still be assured of having a unique bit pattern. and this doesn't solve the problem for interfaces that use 64 bit hardware addresses) a site could continue to use that prefix as long as it kept the hardware with that ethernet interface in its possession. (so you could sell the router but keep the ethernet card. or you could sell the card but keep the address rom. :) - IANA delegates prefix blocks to router vendors, who assign them to their customers by means of their choosing (provided that at most one prefix is assigned per router). for instance, a prefix might be included with each router, and printed on a label on the side of the box. (the router should not expect that prefix to actually be used) a site could continue to use that prefix as long as it kept that label :) offhand, the last idea seems the most attractive, but I don't claim to be aware of all of the implications. Ideally allocations of globally-unique private addresses (GUPAs?) would be /48s, as this would simplify renumbering and having multiple prefixes when it was necessary to do so. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
