Hi all, I would possibly agree with this change, but it must be clear that some ongoing work or considered solutions will be restricted or even totally impossible after this new statement becomes effective. For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples of a Customer site, using site-local addresses (in particular for DNS discovery), and this Customer site is connected to an ISP (thus certainly I presume to the Internet)...
Yoann -----Message d'origine----- De : Brian E Carpenter [mailto:brian@;hursley.ibm.com] Envoye : mardi 12 novembre 2002 13:53 A : [EMAIL PROTECTED] Objet : Proposal for site-local clean-up Unfortunately it's too late to catch the addressing architecture document unless we recall it from the RFC Editor and cycle it through the IESG again. But I propose that we do exactly that, in order to change the following paragraph in section 2.5.6: Current text: > Site-local addresses are designed to be used for addressing inside of > a site without the need for a global prefix. Although a subnet ID > may be up to 54-bits long, it is expected that globally-connected > sites will use the same subnet IDs for site-local and global > prefixes. Proposed new text: Site-local addresses are designed to be used for addressing inside of a site which is not connected to the Internet and therefore does not need a global prefix. They must not be used for a site that is connected to the Internet. Using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience if the site is later connected to the Internet using a global prefix. Otherwise, we will need a whole new RFC just for this paragraph. Alternatively, we could spend the next 5 years discussing the unnecessary complexities of using site-locals on connected sites. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
