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. > 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. 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. 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). > 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(!). We may find that site-locals offer some use in future renumbering, multihoming or other service solutions, that have not been foreseen yet. > 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? If it is not coordinated and unique, do you really buy much over site locals which are only unique to the site? Or are you suggesting to go to an ISP for a /48 and a 0Mbps link? :) Site locals can allow more than /48's to be used for a "super site". What size allocations would you advocate for "site-local globals"? Maybe this is a service an exchange can offer, on a regional basis, to cater for the bulk of (non-international) cases. > I think it needs to be explained that site-locals don't really provide > a security benefit. I think this is very important. But people will be free to > What did I miss? I think you've been quite thorough :) Pekka's concerns are also very valid. Tim > > So, lets summarise again: > > > > - In isolated and unconnected networks, site locals work fine. > > > > - If a stable global prefix is available, we strongly recommend using that > > and not using site locals. > > > > - Site locals and global addresses can exist in parallel on the same > > network, but this is likely to cause address selection problems for > > applications. > > > > - A site is demarcated by the presence of routers that will not forward > > packets using site-local addresses (in source or destination). Routers that > > are not part of a site should not forward such packets. > > > > - If multiple networks are to be connected using site local addresses, they > > must be configured to be a single site. > > > > - Site local addresses are explicitly invalid outside their site. > > Connectivity external to a site MUST NOT be done with site local addresses. > > Sites MUST NOT route packets with site local addresses outside the site. > > > > - Proxying or otherwise attempting to connect site local addresses to the > > global internet (eg NAT) is explicitly discouraged. > > > > Note: It might be possible to have site local traffic sent over a tunnel (eg > > a VPN). In such a situation, the VPN should be treated virtually as part of > > the site. Site local addresses must not leak outside the tunnel. Though > > there are probably better ways to do this than using site locals. > > > > > > Does this seem a fair summary of principles thus far? > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
