This seems like a good start. 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. 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. 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. I think it needs to be explained that site-locals don't really provide a security benefit. What did I miss? > 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] --------------------------------------------------------------------
