Subject: RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]

From: "Brian Zill" <[email-masked]>
Date: Thu, 7 Aug 2003 11:05:29 -0700

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-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, 07 August, 2003 04:58
> To: [email-masked]
> 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-masked]> 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-masked]>
> > To: "Alain Durand" <[email-masked]>
> > Cc: "Bob Hinden" <[email-masked]>; <[email-masked]>
> > 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-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Aug 2003 12:56:42 +0200

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 E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM