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