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

From: Brian Zill <[email-masked]>
Date: Mon, 15 Nov 1999 01:19:27 -0800

Hi Jim,

> I changed the subject to another thread [...]

Yes, we've gotten way off the subject of textual representation of scoped
addresses.

> Right now the use of scope-ids (zone-id, or region-ids)
> is at best a concept and principal within the addressing
> architecture for IPv6.

Is it?  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.

Most of what you appear to be arguing in this message is that name to
address translation isn't well defined for scoped addresses.  I disagree, as
I'll get to below.  However, 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.

> Before we all go off and change things I would like
> to hear some real implementation ideas presented to
> see how scope-ids will work in practice within IPv6.

Okay.

> It is my bias right now that they will not work without 
> affecting other systems within the IP protocol suite if
> they are to be implemented in addition to them
> being architected.

I disagree.  I think they are fairly straight-forward to implement.  Most of
the issues that are being discussed in this thread are not protocol issues
(that is, they don't affect the behavior of the protocol or
interoperability).  They are host issues that we're trying to agree upon to
avoid confusing users (i.e. the textual representation issue) and to make
code easier to port between platforms (i.e. the API issue).

> Here is one way I thought of them being implemented:
> 
> 1.  When an ip-name is looked-up to DNS and a response
> comes back the scope-id is attached to the api caller
> based on the scope-id the interface is within.  So if a
> dns query goes out over le0 and le0 is within scope-id
> of FUZZY then the address that comes back would be
> assigned sin6-scope-id of FUZZY.

Determination of the scope_id value based on the interface used to access
the name service only works for zone/region/district specific name
resolution systems.  For this reason, I think we need to talk about
link-local and site-local addresses separately since I expect them to be
handled differently.

For link-local addresses, I can imagine a resolver determining the scope_id
based on what link it performed the name resolution on.  I don't expect the
name resolution to be the DNS in that case, but rather a link-specific
lookup mechanism like Matt Crawford's icmp-name-lookups.

For site-local addresses, Erik Nordmark's site-prefixes draft specifies a
method for handling name to address translation via the global DNS.  A
resolving node can determine whether or not one (or more) of its interfaces
are in the same site as the target node based on whether the target node's
global addresses have a prefix that is in the interface's site prefix list.
I think Erik's draft is pretty good at explaining how to do this.

> 2.  Likewise when the name for an ip-address is looked
> up the scope-id if going over le0 would be given FUZZY.

Again, for zone/region/district specific lookups, sure.  Otherwise, no.

> But what if the DNS server is the server for all
> scope-ids for this node but the only interface to
> the DNS server happens to be within the scope-id FUZZY.

If the DNS server contains records for multiple sites than you are
describing a lookup mechanism which isn't zone/region/district specific.
Erik's draft specifies how multi-sited nodes that are looking up
fully-qualified domain names in the global DNS can determine the site-local
addresses corresponding to those names (assuming they have any).

> And there is another scope-id called CLEAR on another
> set of interfaces for the node.
>
> For example the DNS at sin-scope-id FUZZY :
> 
> www.one.com  A6 fec0::234 (node is within FUZZY scope-id)
> 
> www.two.com  A6 fec0::234 (node is within CLEAR scope-id)
> 
> If the node sends out a DNS request for www.two.com on
> FUZZY scope-id region/zone it will get back an address
> and assign it the sin6_scope_id of FUZZY.  But the
> packet will in fact go to www.once.com not www.two.com.

Not if you implement Erik's draft.  It doesn't matter how you reach the
global DNS.  If you look up www.two.com, you'll get back both global and
site-local addresses.  If any of the global addresses has a prefix which
matches a prefix in one of your interface's site prefix list than the
site-local addresses can be used with a scope_id taken from the site id of
the interface with the matching prefix.  

> So my search for an implementation absract for
> sin6-scope-id will not work with the assignment
> of the scope-id based on the interface on which
> the query/response takes place for DNS, in the
> above example.

I suspect that's why Erik's draft details a different method :-)

> I think we need to nail down the use of this
> architecture precept of scoped addresses except
> for link-local and multicast in the present Ipv6
> aggr and addr specs (rfc 2373/2374).

Personally, I only have questions about scoped multicast addresses.  Unicast
node-local, link-local and site-local all seem pretty straight-forward to
me.

> We don't have to revisit the entire notion of
> scope-ids for the purposes of getxx APIs but we do
> need to prove it can work abstractly, and certainly
> before we adopt any changes to the existing and
> deployed APIs.

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.

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

> And if we can figure this out a strong "health warning"
> needs to be attached to the solutions that there is
> even much pain with IPv6 when you don't use
> Global Addresses.

I'm having trouble parsing this.

--Brian

> /jim
--------------------------------------------------------------------
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: Mon, 15 Nov 1999 11:10:28 -0500

Brian,

>implemented at the moment.

I agree for link-local addresses and said that below.  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.  My point
is that site-local addresses will not work without "something" else
being defined and we all agree to.  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.  So I will focus the
dicussion further.

>useable for some applications without ever attaching names to them.

Not.  This is just one bit of pain from the entire use of site-local
addresses and I think Erik's draft has some assumptions (all thru the
draft there are assumptions) we all better discuss if we agree with.
But they are just one set of assumptions.  

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.

Good.

>code easier to port between platforms (i.e. the API issue).

I disagree with you.  If we all agree with Erik's enhancements to ND and
the assumptions about the use of Global and Site-Local addresses we can
avoid the DNS problem (2 faced DNS), but those assumptions I think must
be part of the operational parts of DNS when site-local addresses are
used.  This IMO affects DNS which is part of IP indirectly.  And if you
re-read my statement above I did not use the word protocol in the
context you state above.  I consider DNS to be part of the IP protocol
suite.

>link-local and site-local addresses separately since I expect them to be

I agree 100%.  They are completely different issues.

>lookup mechanism like Matt Crawford's icmp-name-lookups.

I agree and will hold my comments on Matts draft till later as I am
re-looking a that draft now.  Erik's draft also has a means to handle
the link-local case I think too.  

I don't think link-local addresses should be permitted in the DNS!!!

>I think Erik's draft is pretty good at explaining how to do this.

My discussion below assumed no global addresses are being used at all by
the site in the normal case.  Sure if global addresses are present as an
A6/AAAAA record they will help differentiate my case below if a
site-prefix is advertised as Erik suggests.  But I am presenting one
case right now and assuming the site DNS only has names and sitelocal
addresses.

>Again, for zone/region/district specific lookups, sure.  Otherwise, no.

DNS does not differentiate btw lookups being zone/region/district at
all?

>describing a lookup mechanism which isn't zone/region/district specific.

Sure I am.  It can have servers on each site so the 1-N number of
servers are not relevant.  What is returned is the issue.

>addresses corresponding to those names (assuming they have any).

I know. I am late with it but I need to send input on this draft when
the site is not using Global addresses for most nodes cause they want to
use the idea of private addresses.  I will get this thread out this week
if I can.

I think Erik's draft does not handle the case below.

>the interface with the matching prefix.  

You changed my example.  There are no global addresses for www.one or
www.two.  

>I suspect that's why Erik's draft details a different method :-)

I don't believe Erik solves the problem case above but that is part of
the input I owe Erik on that spec.

>node-local, link-local and site-local all seem pretty straight-forward to

Funny.  Multicast is crystal clear to me ....---)...........
And link-local............

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

>confusing to programmers.  I'd rather the API was as clean and easy to

What???  Please state why and how this would break user data?  

>I'm having trouble parsing this.

Using scope-ids:

 1) requires additional specification
 2) requires more processing at each node
 3) requires parsing and sorting DNS records
 4) has all the limitations of any private addresses
 5) and renumbering will not occur anymore with IPv6 than IPv4

It has overhead and overhead needs health warnings.  And as I said we
still do not have a crystal clear vision of how site-locals can be used
and deployed.

/jim

--Brian

---

From: [email-masked] (Sam Manthorpe)
Date: Mon, 15 Nov 1999 16:02:29 -0800 (PST)

I think the concepts are not widely understood.  Or maybe they are
widely understood but everybody understands their own personal concept :-)

Jim Bound wrote:
> the site in the normal case.  

I agree with Jim.  I don't see why the set of nodes encompassed by a
particular site-prefix should be the same as those encompassed by
a `site' in the site-local meaning of the word.  I agree that this
will me the norm, but don't see a need for making this a requirement.

Cheers,
Sam.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------