My comments inline.
-- Nir Arad
> 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.
<narad>
I disagree. I think that there are several consensus that were reached:
1. Site-local addresses, as currently defined, are bad.
Hence the WG concensus to deprecate.
2. Many people think that scoped addresses are required.
I conclude this from the fact that draft-hinden was accepted as a WG item.
Indeed, some people think they are not, but even they can't claim that no-one thinks
it is required.
As Voltaire said, "I may disagree with what you have to say, but I shall defend, to
the death, your right to say it."
</narad>
>
> 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.)
>
<narad>
At this point I completely agree with you.
However, I still beleive that we can reach a better definition.
My personal opinion is to have link-local, global, and keep all other scopes as
administrative.
If you return to my suggestion, that the source and destination addresses MUST belong
to the same scope,
it is clear that a DMZ must have a global address to communicate with the rest of the
world.
</narad>
> 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.
>
<narad>
This is a very good point.
I think that for each definition of scope you will give, there will be 5 or more
people in this WG to embrace it, and 20
against.
My personal stand is that we should not take a stand.
Let administrators define this as they wish.
</narad>
> 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.
>
<narad>
Again, only my 2 cents:
Those overlaps and extensions are The source of all evil.
Per my suggestion, when two sites merge, instead of routing from one scope to another,
I would like to see all hosts in
the merged network get a second address, in a new, shared scope. The old scopes of
both networks can be kept for a long
time, or even forever, so existing applications/session are not broken.
I think we (the WG) should work to make sure that the allocation of additional
addresses is made simple, and not shout
right away that this is an administrative nightmare and thus is not acceptable.
</narad>
> 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.
>
<narad>
This is correct in IPv4.
IPv6 can still be a whole new world. Scopes should become explicit.
As one of my co-workers always say: "Keep it simple!"
</narad>
> 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.
>
<narad>
Trying to fully respond to that here would be hasty of me, so I'll avoid that.
Nevertheless, it seems that there is some level of concensus that applications should
permit a minimal level of
selection between global addresses and "other" addresses (whatever those end up to be).
I think this would be enough to come up with a solution according to my suggestion.
But this is work to be done, and not a reason to dismiss an idea.
</narad>
> 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.
>
<narad>
Thanks for the detailed response - no flames from my side...
</narad>
> 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]
--------------------------------------------------------------------
