Subject: RE: Implementing the architectural principles of Scope-IDs

From: Brian Zill <[email-masked]>
Date: Tue, 16 Nov 1999 01:18:20 -0800

Hi Jim,

> >The use of the scope_id field with link-local 
> >addresses seems to be very well understood and
> >implemented widely.  The use of scope_ids with
> >site-local addresses is fairly well understood,
> >although not widely implemented at the moment.
> 
> I agree for link-local addresses and said that below.

Okay, glad we agree on that at least.

> If we believe the concept is well defined and want
> to point to Erik's draft that is fine but that draft
> needs much more WG review and discussion then.

Absolutely.  My point was only that one method for name to site-local
address resolution exists.  It may not be the method the working group
decides upon in the long run, but its existence shows that this is not an
unsolvable problem.  As an aside, I expect that there will be multiple
possible methods for site administrators to choose from, depending upon
whether or not they want to run a private address server of some sort.

> My point is that site-local addresses will not work
> without "something" else being defined and we all agree to.

To be pedantic, I think you mean that name to address resolution for
site-local addresses needs to be defined.  The numerical addresses
themselves will work even in the absence of a method for performing name to
site-local address resolution.

> We have not all agreed to Erik's draft and that is
> a work item for this WG.  Ergo the use of site-local
> addresses are not well understood or implemented.

I don't think that follows.  They are two different issues; the lack of one
doesn't imply the other.  We have not all agreed on how to perform name to
address resolution for link-local addresses either (Matt's draft is one
possibility), but that doesn't mean that the use of link-local addresses is
not well understood or implemented.

> >I first want to say that I think both link-local
> >and site-local addresses are wonderful concepts
> >and perfectly useable for some applications
> >without ever attaching names to them.
> 
> Not.

Care to elaborate?  I can certainly use link-local and site-local addresses
without having them correspond to some name in a database somewhere.

> I agree with you they are good "concepts".
> I think link-local is wonderful and was there in
> the beginnning when we defined them and have put
> them into a product stack.  Site-Local is a
> different matter and needs more discussion
> for "unicast".   

Okay, this appears to be the core issue, or at least a core issue.  I don't
understand why you think site-local is a "different matter" than link-local.
You mentioned name to address resolution, but we don't have working group
approval of a method for doing that with link-local either.  What makes
link-local "wonderful", but site-local a pariah?

In the interest of brevity, and because I don't believe it's one of the core
issues in contention, I'm going to skip over the back-and-forth on the
site-local address name resolution discussion.  If someone really wants me
to launch into this, let me know.  Otherwise, I'll just summarize my
position: I think Erik's draft will work if you want to put site-local
addresses in the global DNS.  I can imagine other mechanisms which will work
if you want to have a "two-faced DNS" or private name service of some sort
-- there just needs to be some method for the resolver to determine which
site any site-specific name services it may access belongs.  I don't think
this is rocket science.

Onward to the other core issue:

> >I agree we don't have to revisit the entire notion
> >of scope ids.  It's the current specification of the
> >getxx APIs which I think we need to revisit.
> 
> I completely disagree.  If anyone tells me we can
> change the API because a draft exists that does not
> IMO have wide consensus and not a lot of input and
> review is a corner stone to change the existing 
> user interface to IPv6 for existing customers then
> I will tell them this is not a wise decision, until
> we have the discussion I have asked to start on this
> mail thread.

I think we need to revisit the API.  But not because of Erik's draft or any
other draft.  And not just because of site-local addresses either, although
that's part of it.  We need to revisit it because even link-local addresses
do not work with the getxx APIs as they are currently specified.

Now what to do about the API is an open issue.  Carl Williams (hope I have
his name right) rounded up a bunch of us last Thursday to have dinner and
discuss the subject.  But the appropriate place to reach resolution is on
this list.  So I hope Carl will post his notes from that discussion as a
starting point.

--Brian

P.S. To answer an earlier question:

> >> Robert Elz's suggestion is looking
> >> pretty good to me right now!!!!
> 
> >It's a cute hack.  However, I think it's dangerous
> >from the standpoint that these things which aren't
> >really addresses are being exposed at user-level.
> >They would inevitably end up being passed around 
> >as data, at which point programs would start
> >breaking.  It's also kind of ugly and could be
> >confusing to programmers.  I'd rather the API was
> >as clean and easy to understand as possible.
> 
> What???  Please state why and how this would break user data?

My concern is that if the API presents to the programmer this thing which is
usually an address, but in the case of scoped addresses isn't really an
address since it hides a scope id in there, then programs will end up being
written which treat it as an address and thus break upon encountering scoped
addresses.  The classic example is a program that passes an IP address to
another node in the application data portion of the packet.  It'll work just
fine for global addresses, but not scoped addresses because the hidden bits
are node specific.  I think it is far better to make it explicit to
programmers what is going on, so they can understand it and make proper
decisions, rather than hide things like this from them that can bite them
later.

Besides, this would also mean changing the API from what is specified now
(RFC 2553 includes the sin6_scope_id field in a sockaddr_in6), so what's the
win?
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Tue, 16 Nov 1999 12:41:28 -0500

hi brian,

>whether or not they want to run a private address server of some sort.

Well I don't know about multiple possible ways.  Erik's draft is a
significant addition to ND and our implementations even before src addr
selection.  I am about ready to start a thread on Erik's draft.

>site-local address resolution.

Well Erik's draft solves my problem by saying when a site only has
site-local addresses addresses for sites with site-local addresses must
be in the site where the DNS exists.  This is an operational restriction
for DNS.  I will discuss this on the other thread I will begat.

>not well understood or implemented.

The use of of site-local addresses is in the process of being defined.

OK............

>without having them correspond to some name in a database somewhere.

Link-Local I agree with.  I don't believe they should exist in the DNS.
In that sense names are unimportant for link-local addresses.  They are
known by the ND processes and btw adjacent router links.  

Site-Local are different. They will be used by applications off link.
I think any address of this nature needs names.

Sure it can be done without them but I don't consider that useful,.

>link-local "wonderful", but site-local a pariah?

The link-local address is used to get things started for IPv6 via ND or
DHCPv6.  It is also used for routers to communicate to adjacent links.
Its an address for the IPv6 Architecture to get the node up and running
and learn about its link neighbors.  If folks want to telnet et al to it
we can't stop them but I think that is fiat rather than by design. Also
for testing. Except in the Dentist office scenario.

For link-local addresses they should be key'd in via a user when used by
apps or in a config file (this is OK for link-local as they are not
renumbered but if privacy stuff is on then they may need to be
refreshed).

So I view link-local as step 1 and for the Dentist office but after that
a greater address should be used for DST and SRC always for apps.

Site-Local brings into the picture communicating within a site offlink
instead of global addresses.  It creates an addition need for scope-ids.

I don't believe in private addresses - but we are stuck with them now
for IPv6.
I don't believe renumbering will be as frequent as Erik's draft alludes
and the draft can't use them for some mobile node and home based mobile
node communications either.
I suggest we continue this discussion when I start the thread on Erik's
latest draft.

>site any site-specific name services it may access belongs.  I don't think

It requires operational rules.  Any such rules must be optional.  The
IETF cannot mandate how we run our networks only provide the standards.
We can pick this up in the thread on Eriks draft.

>do not work with the getxx APIs as they are currently specified.

Well I don't agree.  They do work.  But are they working in an elegant
manner.

>this list.  So I hope Carl will post his notes from that discussion as a

Name is right.  I will be sending API issues thread too.  I heard about
the meeting and await the notes.  Erik and I were not there and need to
see the results.

As it appears we have to update rfc2553 I am wondering how it will look
when we are done.  But that is another thread.

>decisions, rather than hide things like this from them that can bite them

I think this is a thin argument against Roberts proposal.

upon return from getipnodebyname().

  If site-local or link-local address 
     sockaddr_in6.sin6_scope_id = scope-id-within-address returned

This is pretty simple and leaves the existing API for getipnodebyname 
in tact.  

It also permits us to do what I relayed in my example.  Now:

www.one.com IN A6  fec0::FUZZY::EUI
www.two.com IN A6  fec0::CLEAR::EUI

An app can now take advantage of the scope-id right in the address for
link-local and site-local.  This would also work with Erik's draft with
some tweaking.

>(RFC 2553 includes the sin6_scope_id field in a sockaddr_in6), so what's the

I show you that above.  It now becomes just a clarification to
getipnodebyname and getaddrinfo.  No change to the API.

/jim