Brian E Carpenter wrote: > Well, that was fun: send one message and receive a few hundred. Peace. > > I'm very sensitive to the argument about intermittently > connected networks needing a stable prefix. So I would > finally prefer the > addressing architecture to contain yet another version of the > text in question: > > Site-local addresses are designed to be used for > addressing inside of > a site which is not permanently 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 of > subnet management. > > Why? Because we don't have consensus, and this text carries > less baggage than the others, which seems appropriate for an > architecture document. > > However, it may be that this change is not enough for the WG > to recall the draft from the RFC Editor. I think we should > hum on that in Atlanta.
I still believe this is a fundemental change in the architecture. In an attempt to provide a constructive alternative, leave the architecture document alone, then in the 'scoped' document change the definition text to: Site-local scope, for uniquely identifying interfaces within a single site only. Site-local addresses are designed to provide stable addresses for use inside a site. A "site" is, by intent, not rigorously defined (just as Areas are not rigorously defined in an IGP), but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. As such, one common use instance of a site border might be the boundary between the IGP and EGP. Use of site-local addresses for connections external to a site is strongly discouraged, because they will usually be ambiguous values outside their domain of reference. When applications are expected to work across the site boundary, care should be taken to ensure all participating nodes have global scope addresses available. Tony > > Brian > > Brian E Carpenter wrote: > > > > 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] --------------------------------------------------------------------
