inline...
Tony Hain wrote:
>
> 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.
I'm not sure which way you intend this to be read. What I mean to say is that
I really cannot see a usefully defined generic category between link-local
and global; and I don't see the use of what you suggest later, i.e. such
a category with a fuzzy meaning. I don't know how to use it, since I don't
know what it contains or excludes. Point 3 is more explicit about that:
>
> >
> > 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.
Exactly. And these various boundaries will overlap in different ways
in different user networks - so the category "less than global scope"
doesn't provide any useful information.
> All we can do is provide the tools for the
> implementers of those boundaries to make the job easier.
Indeed. What I have come to believe is that a single-valued scope
function is not a useful tool for that.
>
> >
> > 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.
I think it does, because it makes "less than global" ambiguous. Does it mean
"my intranet", "my intranet plus a VPN to company X", "a VPN to company X
but not my intranet", "my VPNs to companies X and Y plus a secure subset
of my intranet", or a combinatorial number of similar choices?
>
> > 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.
Yes. I don't see how a single-valued scope function helps with that.
>
> >
> > 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 ...
Might help sometimes :-)
>
> >
> > 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.
Indeed. Good example. It turns out to be a list of about 139 IPv4 prefixes,
manually maintained. I got that from my VPN setup. That's exactly the
problem.
>
> >
> > 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'.
They can, but I've tried to argue above that this is useless.
>
> >
> > 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.
That's not what I'm suggesting. I'm suggesting that trying to solve it
with a simple concentric-circles model of scope is impossible.
Brian
>
> 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]
> > --------------------------------------------------------------------
> >
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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]
--------------------------------------------------------------------
