Brian Z, I don't see what that has to do with our failed attempts to design explicit scope *within* IPv6 unicast addresses.
Brian C Brian Zill wrote: > > As I thought I pointed out in a message last night, IPv4 and IPv6 > address spaces are different scopes. For a reasonable mainstream > deployment of IPv6 to occur, mainstream applications need to be able to > deal with a mix of IPv4-only, IPv6-only, and dual protocol nodes. > > We can't just poke our heads in the sand and "legislate" scoping issues > away. This working group should be focusing on finding solutions for > problems, rather than killing off solutions for other problems in the > misguided belief it is actually improving something. > > --Brian > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter > > Sent: Thursday, 07 August, 2003 04:58 > > To: [EMAIL PROTECTED] > > Subject: Let's abolish scope [Re: Unicast scope field (was: > > Moving forward on Site-Local and Local Addressing)] > > > > > > Well, here's my attempt at becoming flame bait :-) > > > > I'm close to concluding that address scope is simply a bogus concept. > > > > 1. We've been arguing about it for years and have reached no > > sort of consensus. That suggests to me that there is in fact > > no consensus to be reached. > > > > 2. Apart from link-local, scope boundaries are ill-defined. > > (What's a site? Is the whole of a corporate network a site? > > Is the DMZ inside or outside the site? etc.) > > > > 3. We aren't clear whether we want scope because it maps > > security boundaries, reachability boundaries, routing > > boundaries, QOS boundaries, administrative > > boundaries, funding boundaries, some other kinds of boundaries, or a > > combination. > > > > 4. There are some well known and important scope-breaking > > phenomena, such as intermittently connected networks, mobile > > nodes, mobile networks, > > inter-domain VPNs, hosted networks, network merges and > > splits, etc. Specifically, this means that scope *cannot* be > > mapped into concentric circles such as a naive > > link/local/global model. Scopes overlap and extend into one > > another. The scope relationship between two hosts may even be > > different for different protocols. > > > > 5. In practice, scope is not explicit; it's implicit in > > firewall rules, VPN setup, static routes, DNS entries, > > application level trickery, > > configuration files, and brains. > > > > 6. Middleware (a.k.a. Apps) has no idea how to handle scope anyway. > > In fact, given the above, I don't see how a useful API to > > express scope > > concepts could be defined. If we can't define such an API, we > > can forget about expecting middleware to do anything sensible > > about scope. > > > > So I don't believe that a scope field as part of the address > > format is a meaningful idea, because I don't think scope is a > > single- valued function in the first place. > > > > I think we'd be better off to simply forget about address scope. > > > > Brian > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK > > > > > > Nir Arad wrote: > > > > > > Hi, > > > > > > I was thinking to bring this suggestion myself, and I'm > > glad Yibo did. > > > Having a Scope field in unicast addresses seems (to me) to solve > > > all-so-many problems. I would go further to allow nodes to > > only send, > > > receive and forward packets from- and to- the same scope. > > > > > > Being still on the IPv6 learning curve I might well be > > wrong, but it > > > seems to me the silver bullet for: > > > - Killing NAT ("site local" interfaces, whether globally > > unique or not, may never communicate with global unicast > > > interfaces) > > > - Simplifying address selection > > > - Cleaning the routing tables > > > - Simplifying router design and setup > > > > > > Coming from a router design point-of-view, the current address > > > architecture, and more important, the forseeable and unforseeable > > > changes within it, make it difficult to desgin a mechanism that > > > identifies the source/destination address scopes. > > > > > > OK - now I'm ready to take the flames... > > > > > > Regards, > > > > > > -- Nir Arad > > > > > > ----- Original Message ----- > > > From: "Yibo Zhang" <[EMAIL PROTECTED]> > > > To: "Alain Durand" <[EMAIL PROTECTED]> > > > Cc: "Bob Hinden" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > Sent: Wednesday, August 06, 2003 12:38 PM > > > Subject: Re: Moving forward on Site-Local and Local Addressing > > > > > > > Alain Durand wrote: > > > > > > > > > IMHO, what need to happen is the following: > > > > > > > > > > -1. Make an in-depth study of the consequences of introducing > > > > > addresses with different ranges. > > > > > > > > That's definitely a good idea because that way we might > > be able to > > > > replace all current local addresses with a single type of local > > > > addresses with a Range or Scope field like the multicast > > addresses. > > > > It would looks more consistent, more flexible, more scalable, and > > > > could even help the WG move the current situation forward more > > > > smoothly and smartly. > > > > > > -------------------------------------------------------------------- > > 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] > > -------------------------------------------------------------------- > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- 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] --------------------------------------------------------------------
