On Mon, 10 Jun 2002, Robert Elz wrote: > Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST) > From: Pekka Savola <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | Bit pattern is not relevant of course (except how it is handled by > | "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the > | air). > > But how is the handling by legacy implementations any different than > what you would require anyway?
I don't know what assumptions different implementations might have glued in to fec0::/8, but selecting a different one would mean it would be treated as global no matter what. (I don't think there would really be problems even if fec0::/8 was used.) > | What I'd like is that there wouldn't need to be special handling for > | site-local addresses. > > How can there not be? By limiting the applicability of the addresses. > | If you really wanted to have Site Border Routers, > | you would just be shooting in your own foot (like with 10.0.0.0/8 etc. > | today). > > If there are to be uses of non-unique addressing (site locals, 1918's > or anything else) then there has to be borders. And if there are > borders, then there has to be border routers. Something has to keep > one use of the addresses separate from others. Sure. > Perhaps what you want to discourage is multi-site nodes ? > (Usually would be a router, but doesn't have to be). Yes. RFC1918 model has not required changes to routing protocols, partially because we acknowledge "you can always shoot in your foot". Now with IPv6 site-locals, it seems we want to add features to e.g. routing protocols to (try to) prevent that, which leads more complexity. > Two was to have only single site nodes, only single site links, and > non-site links (DMZs) between sites. This seems the best to me IMO. > However, upon reflection, there is comparatively little to be gained > by that choice over the third one (some things get simpler to explain > while the lack of regularity makes others harder to fathom, and some > stuff becomes simply impossible to manage - like if two sites are > connected via a router that has LANS for each site connected to it, > there's no convenient link to make be the DMZ). In more complex topologies, one could always just enforce globals and be done with it. > Scoping has to exist for link locals to work anyway, and so routers need > to deal with that (and link locals, and their properties, are too deeply > ingrained now to possibly contemplate their removal). By their very > nature, link locals require multi-scope nodes to exist, or we could not > have routers at all. Sure, but the link scope is rather easily defined, and the addresses of link scope are meaningless outside of the link (ie. no need to carry them in routing protocols). > The only real difference between 2 & 3 above for implementations, given > that apps can run on "routers" and that apps need to be able to use link > local addressing if necessary (for the unconnected dentist's office nets) I'm not sure if link-locals is the right way to go in this particular case. > so all the scoping architecture needs to exist - all that would be gained > is that in (2) a router would have a different decision to make before > forwarding site local addresses - rather than "is this link in the same > site?" it would need to ask "is this link in a DMZ?" A question is, is the scoping architecture required for only link-local addresses more lightweigh than one for both LL's and e.g. site-locals. > In IPv4 we just ignore the question mostly - a node with two global > addresses we just toss a coin. And nodes with private addresses mostly > just don't get given global addresses (and/or the two are treated for > essentially all purposes as if they belonged to two different nodes). > > For IPv6 we're being asked to actually attempt to provide some answers > to this question - as essentially all nodes (certainly the vast majority) > with private addresses will also have global ones. The thing is, how usable is it to try to solve this problem, at least in its most generic form? I'm not all that certain it's all that beneficial. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
