Brian E Carpenter wrote:
> 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.)
We intentionally don't define the boundaries of an area in an IGP, so why do
we need to do so here? Of all the arguments about scope, this one is the
most bogus.
>
> 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.
That is because these are all local decisions, and the IETF can't dictate
where any one of them might be. All we can do is provide the tools for the
implementers of those boundaries to make the job easier.
>
> 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.
Well, I have to disagree with this.
> Scopes overlap and extend into one another.
No, a link must be wholly contained within a site, and by definition
anything that is less than global fits wholly within global. Yes multiple
local regions can overlap, but that does not invalidate the overall model.
> The scope relationship between two hosts may even be
> different for different protocols.
There is nothing inherently wrong with that. The file mount on likely wants
to be restricted, while a 3party conf app on the same hosts would likely
want to avoid being restricted. From an improving the overall Internet
security perspective, I think the default case should be restricted, then
provide a hook to get around that when appropriate.
>
> 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.
The logical endpoint of your argument is to abolish 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.
I agree with the last sentence, but not the premise about defining an API.
One way to describe a desired outcome would be, bind to a limited range
address associated with ibm.com.
>
> 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 assume you mean a way to identify > link but < global. While there might
not be clear contiguous boundaries for each of the values in that space,
they can all be described as a single value for 'something inbetween'.
>
> I think we'd be better off to simply forget about address scope.
We could choose to ignore the most commonly deployed segment of the existing
Internet, but how useful would the results be.
Tony
>
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
