Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt

From: Tim Hartrick <[email-masked]>
Date: Tue, 9 Nov 1999 14:34:26 -0800 (PST)

Sam, Brian,

> 
> Brian Zill wrote:
> > What I think the definition of a scope_id is: A scope_id is an *instance* of
> > a scope (it's not a scope -- a scope is link-local, site-local, global,
> > interplanetary, whatever).  By an instance, I mean it is an identifier
> > denoting a specific link (for link-local addresses), a specific site (for
> > site-local addresses), a specific planet (for global addresses), etc.  And
> > it is node-specific -- that is, it can have different values denoting the
> > same thing on different nodes (at least for link-local and site-local, we
> > seem to be treating zero as the universal scope_id value for Earth when
> > we're dealing with global addresses :-).
> 
> Yes, this is also my understanding of scope-id, very nicely explained
> again.
>

Indeed.  A nice encapsulation of the intent.  I wish I had written it myself
when I first proposed the idea of adding the scope identifier to the sockaddr-
in6.  If the rhetoric had not been so thick in that initial discussion we
may well have not missed the details that we are causing us some pain.
 
> > Because of the node-specific property of scope_ids, I think the idea
> > (floated from time to time) of putting scope_id information into the DNS, is
> > very problematic and shouldn't be allowed/persued.  
> 
> I agree that scope_id information should not be _in_ the DNS, _but_ it
> should be added by the resolver.  Before looking at DNS, what about
> <draft-ietf-ipngwg-icmp-name-lookups-05.txt> based name resolution?
> I would suppose that for link-local addresses name resolution should
> proceed as follows:
> 
>     1	send name lookup ICMP packets on each attached link
> 
>     2	interface on which the reply is received determines the
> 	scope-id to be associated with the link-local address
> 
>     3	libc name resolution function (e.g. getaddrinfo) returns
> 	this scope-id to application along with the link-local
> 	address.
> 
> I would like getipnodebyname() to be able to do this too.  As for
> DNS, I belive that the same technique can be applied; i.e. the 
> scope-id to be associated with a link-local or site-local address
> is that of the interface through which the DNS server was reached.
> 

I agree with Sam.  It is difficult to conceive of a circumstance that
would lead to link-local addresses appearing in the DNS.  It is not difficult
to conceive of a time when a "two faced DNS" scheme would be in place for
some organization that was the merge of two organizations that both used
site-local addresses.  In this case, site-local addresses would appear in
the DNS but it would be up to the resolver, by some as yet undefined means,
to apply appropriate scope qualification to addresses returned from the
DNS server.

In addition, as much as we may scream and cry about it, the /etc/hosts file
or equivalent is not going away as a "database" of address to name mappings.
We need to think in terms beyond just what the DNS will store if we want to
do this in a way that satisfies the operational requirements of the environ-
ment in which IPv6 aware applications will be running.  That includes database
systems other than DNS.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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, 09 Nov 1999 17:52:43 -0500

tim, brian, sam,

this is a good discussion.. I too like brian's description and its short
and to the point.

one item we need to decide is when does the scope-id need to be set?

before dns access?  if DNS don't know about them then why?

after dns access?  Seems yes?

but why can't this happen after getipnodename gets back to the app?

My impression is that scope-id can apply to any scope address..so a
link-local, site, and global could all be valid for a particular
scope-id?  Then src addr selects which address is appropriate.

so this tells me that the scope-id has to be set before getipnodebyname
returns?

SAM:  I would like to avoid icmp traffic being necessary to do this in
my resolver...seems like a definite performance hit>??????

??????

/jim

---

From: [email-masked] (Sam Manthorpe)
Date: Tue, 9 Nov 1999 15:39:47 -0800 (PST)

Jim, Brian, Tim,

> before dns access?  if DNS don't know about them then why?

I would say no, not before, _unless_ the app explicitly asks for
that using something like s1:<domainname> passed into the resolution
function.

> after dns access?  Seems yes?

Yes, I would say so.  In the absence of any knowledge of what site
or link the address may be found on, it may be advantageous to do
simultaneous DNS quieres on each site/link (I really hate all the ugliness
scoped addresses introduce).  We determine the scope-id to add to
the IPv6 address by the interface on which the first reply arrives.

> but why can't this happen after getipnodename gets back to the app?

Because then the app must know something about how the name
resolution was performed in order to determine which scope-id to
use.  This kind of stuff should be hidden in libc and kernel IMHO.

> my resolver...seems like a definite performance hit>??????

Absolutely, I wasn't talking about ICMP being necessary, I was just
giving an example of how I imagine the mechanism working with ICMP
name resolution.  In IRIX, for example, the name resolution mechanisms
are `hot-pluggable' specified in /etc/nsswitch.conf

Incidentally, I have implemented an alternative mechanism to ICMP
name lookups for link-locals using UDP instead of ICMP.  It's called
PNRP (Plug-n-play Name Resolution Protocol) and keeps local tables
of peers, populated through address advertisements, rather than 
sending ICMP messages upon demand.  In the Oslo meeting Alain convinced 
me that the ICMP mechanism was a better scheme, but I'm no longer 
convinced of this, particularly in light of the scope-id complications.
If there is interest, I would be happy to write up the scheme.

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

---

From: Jim Bound <[email-masked]>
Date: Wed, 10 Nov 1999 16:40:29 -0500

Sam,

>use.  This kind of stuff should be hidden in libc and kernel IMHO.

I thought of this after I sent the mail.  Yes it should be hidden.

>are `hot-pluggable' specified in /etc/nsswitch.conf

Oh OK.

>If there is interest, I would be happy to write up the scheme.

Well at IPng I heard today that we may move icmp lookups to standards
track.  If you have an alternative we need to hear more about this now
on the list.

/jim

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 10 Nov 1999 15:48:46 -0800 (PST)

Jim,

> track.  If you have an alternative we need to hear more about this now

Yes, I have an alternative, but I don't think it has any impact of
the icmp lookup draft; it's just an alternative.

The main design goal behind PNRP was a scenario where several
name resolution mechanisms may need to be employed to find the
address for a name.  If we try, for example, to use the following,
in this order:

    1	icmp name lookups
    2	DNS
    3	files

then the problem I have with icmp name lookups is that there is no
negative feedback mechanism so the only way to know if the resolution
fails is to wait for a timeout.  How long should this timeout be?
The longer it is, the longer I wait before doing a DNS query
(which can also be slow).

PNRP solves this problem by keeping a local list of peers' name-address 
pairs.  This list is constructed by peers periodically advertising their
names and corresponding link-local addresses via multicast.  When a name
request is made, the resolver knows very quickly if it corresponds to
the link-local address of a peer. The disadvantage of this approach is 
the potential size of this local list.

I have a prototype that runs on IRIX and it runs well, but we do
have a small number of IPv6 nodes in the lab.

-- Sam

---

From: [email-masked]
Date: Thu, 11 Nov 1999 10:25:09 +0900

>> track.  If you have an alternative we need to hear more about this now

	My take is that you can't really rely upon icmp namelookup.
	It works fine for "two machine connected by cross-cable" situation
	(as they talked in zeroconf meeting), but not good for general use.
	The way I use is for diagnosis.  KAME ping6 has a option to do
	icmp name lookup.  This works great for debugging purposes.

	I suggest adding text fragment that says "icmp hostname lookup is
	for debugging purposes, not for general daily use like resolvers".

	To share my feeling, please consider the following cases:
	1. what do you do if you see two or more nodes with the same name.
	2. most of novice users leave hostname unconfigured.  default value
	   would be like "myhost.mynet" or "myhost.netbsd".  it makes
	   situation 1 to happen more frequently.
	3. many configures hostname as FQDN (like "lychee.itojun.org"), many
	   configures as non-FQDN (like "lychee").  what if you are looking
	   for "lychee.itojun.org" and got a reply from "lychee" (or other way
	   around).

itojun

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 10 Nov 1999 21:29:34 -0800 (PST)

> 	1. what do you do if you see two or more nodes with the same name.

We're talking about a plug-n-play scenario right?  I don't think ICMP
(or PNRP) name lookups is a general solution for name resoltution, but I think
it does add value in certain situations.  For example, a home network,
where one user is configuring names for all nodes (still talking about
link-local addresses) but doesn't want a special server for name resolution.

> 	   situation 1 to happen more frequently.

In the conceptual model I have in my head of the plug-n-play, dentist's
office scenario, there will rarely by any '.' in the name, rather
names like `printer' and `toaster'.  Far from unique, but unique locally.
As for the `novice users leave hostname unconfigured'; users will 
configure their hostnames after having read the manual after trying to
do any kind of networking with their node.

> 	   for "lychee.itojun.org" and got a reply from "lychee" (or other way

Again, I don't think this is the kind of scenario that ICMP name lookup
tries to address; this is more DNS's job.  The problem you describe exists
already with IPv4 and isn't really a valid point against ICMP name lookups.

Summary: I think the ICMP name lookup mechanism addresses a scenario
that doesn't currently exist with IPv4; that of the plug-n-play
network.  For the kind of unique name resolution you are talking about
there are always other mechanisms such as DNS, which will co-exist with
ICMP name lookup.

When I think of ICMP namelookup I think of Appletalk...

Cheers,
-- Sam