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

From: Brian Zill <[email-masked]>
Date: Tue, 9 Nov 1999 15:59:12 -0800

Steve,
> At the Tokyo interim WG meeting, I suggested
> the use of the term "zone" for a scope instance

I too prefer the term "zone" to "scope_id".  I think it would have
eliminated the confusion between scopes and scope_ids if only we'd thought
of it earlier.  However, I agree with Jim that changing the name of the
field in the sockaddr_in6 at this point isn't worth the pain.  We can still
call them zones I suppose.

Sam, Tim,

Good points about wanting to resolve scoped names without putting them in
the DNS directly.  I'll have to think about this some more, if we're going
to support this it'd be nice to find a solution for getipnodebyaddr that's
as reasonable as adding a new flag value is for getipnodebyname.

Jim,
> this is a good discussion..

Agreed.  I think we're getting somewhere.

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

Well, it only *needs* to be set before making socket calls like connect,
bind, etc which take sockaddrs.  I would expect that any name resolution (or
numeric text string to binary address conversion) functions that output
sockaddrs would fill it in along with the rest of the address.

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

As Tim and Sam have mentioned, your local resolver may know about them, even
if the DNS doesn't.  This, along with the numeric string to binary stuff, is
the motivation behind wanting the library routines to return a sockaddr_in?
instead of an in?_addr.  Francis (I think it was) also put on the table the
option of returning a new structure that contains only the in6_addr and the
scope_id, thus avoiding the overhead of the extra bytes in sockaddr_in6.  Is
this a big enough memory/performance issue to care?  I dunno.

> after dns access?  Seems yes?

Er, I'd say seems no.  Otherwise you have each app trying to do zone
(scope_id) determination on it's own.  Better to have is consistently
handled in the resolver library, I would think.
 
> 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.

Maybe some of the confusion here is that for a single-homed node, there is
only one possible value for the scope_id in each scope, so if you didn't
keep the scope_id with the rest of the address, you could always figure it
out later.  But every multi-homed node will have multiple valid scope_ids
for link-local scoped addresses (one per interface), and possibly multiple
valid scope_ids for site-local addresses (if the node is multi-sited).

Thus, a scoped address is ambiguous without an accompanying scope_id.  They
are one-for-one.  Another way to think of it is that a scoped address isn't
really an address without a scope_id.  One could even apply the term
"address" to the combination of the 128 bit part and the scope_id part (but
that would get confusing, so let's not :-)  Anyhow, this means (to me, at
any rate) that one should try to keep an address with its scope_id.
Whenever you get a scoped address from a user, or from some name resolution
method, you should get a scope_id with it (or apply some default).

BTW, as currently "defined", the namespace of scope_id values is a separate
one for each scope (this should be implementer's choice actually, the point
is that the "definition" as I understand it doesn't require scope_ids to be
unique across all scopes).  In other words, I can have a link-local address
on one interface with a scope_id of 1 and a site-local address on a
different interface with a scope_id of 1.  In the first case, the scope_id
is the interface index, in the second case, it's the site identifier.

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

I think he was talking about (Matt Crawford's?) draft on ICMP-based name
resolution?

Do people think I should write up something on this before the Thursday
meeting?  Chairs, are there extra minutes anywhere to discuss this separate
from the textual format issue?

--Brian
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Wed, 10 Nov 1999 20:59:09 +1100

Date:        Tue, 9 Nov 1999 15:59:12 -0800 
    From:        Brian Zill <[email-masked]>
    Message-ID:  <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02>

  | Thus, a scoped address is ambiguous without an accompanying scope_id.

Some of you may remember that a totally different way of handling this
was proposed before ... that is, noticing that there is only one global
scope (zone, inside of perimiter, whatever it is to be called), which
therefore needs no identification, there are a much larger number of
sites - but only a subset of those need identification from any particular
node (identifying a site address that you can't reach is kind of nice,
but practically useless), and zillions more links, but again, only those
actually connected to a node need identifying (but that number will be
no less than the number of scopes).

Then look at the IPv6 addressing formats for global, site local, and link
local, and notice that there are no (real) spare bits in global addresses,
quite a few in site locals, and lots in link locals, and wonder if perhaps
the scope_id (zone identifier, whatever) might just fit fairly nicely in the
128 available bits that we have already, and that all applications are already
passing around - and that doing so (with whatever support is needed in the
kernel or libraries to fill in the bits, and remove them again when 
appropriate) just might be a way to make the vast majority of applications
just magically work, without any specific knowledge that there are such things
as less than global addresses.

Sure, some applications are going to need to understand, and deal with the
issues that arise - they'll need to do that however the extra id is passed
around, only the details vary.

And yes, there are some issues that need to be worked out with this scheme,
there are some things that need to be dealt with (those things which really
care what is in the packets on the wire need to know what bits will be left
there, and which will be zapped for example), but I suspect those are
manageable.

I will also say that I was most pleased when I saw that the KAME IPv6
stack uses this general method for identifying its link local interface
addresses - and that all seems to work just fine (it needs some better
documentation, as it surprises some people when they first encounter it,
but aside from that, it all just works.   I'm sure there is some code in
there somewhere making it all just work of course).

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 1999 17:52:36 +0100

(This is not an answer to Brian's mail)

I believe we know what is the problem, the whole set of solutions
but we still need a way to not break the API (and keep Jim happy :-).

Then my proposal is to introduce a compilation flag, undefined by default,
which should be defined before netdb.h and arpa/inet.h includes.
If the flag is not defined current state aplies.
If the flag is defined then getipnodebyname(), inet_pton(), ...
deal with scope IDs too.

Is it a reasonable and not too uggly compromise?

Thanks

[email-masked]

PS: in order to not get extensions for flow ID, DS field, ports, ...
I believe we should keep my light structure proposal.
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 11 Nov 1999 03:07:33 +0900

(snip)
>there somewhere making it all just work of course).

	To clarify: KAME puts interface id into 4th byte of IPv6 address
	for link-local addresses and link-local multicast addresess, but
	this is FOR KERNEL INTERNALSTRUCTURES ONLY (like interface address
	structure, routing tables.
	As documented, this is only for in-kernel usage.  From userland we
	recommend users to use advanced api.  "ping6 fe80:9::1" (telnet
	to fe80::1 on interface 9) accidentaly works, but is not recommended.
	The way to go is, IMHO:
	1. ping6 -I interface9 fe80::1
	2. ping6 fe80::1@interface9	(based on scopedaddr-format-00)
		yes, ping6 uses getaddrinfo().

	This is kind of ugly but is necessary to avoid too many changes in
	BSD style function signature for ip6_output()... (where src and
	dst addr are passed in IPv6 header, no other place)

itojun

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 10 Nov 1999 13:14:37 -0800 (PST)

> as less than global addresses.

This is kind of attractive.  I think the big disadvantage of this
approach is the risk of the embedded scope-id being passed across the
net or across humans to other hosts.  This is still a problem with
<draft-ietf-ipngwg-scopedaddr-format-00.txt> but much less so since
the scope-id part is easily recognisable by humans and easily parsable.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 11 Nov 1999 12:53:49 +0900

>>>>> On Tue, 9 Nov 1999 15:59:12 -0800 , 
>>>>> Brian Zill <[email-masked]> said:

> from the textual format issue?

I agree that API issues should be separately discussed (if we can find
extra time slot), since they are not necessarility related to the
textual representation itself but are very important.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 11 Nov 1999 14:36:21 +0900

>>>>> On Wed, 10 Nov 1999 13:14:37 -0800 (PST), 
>>>>> [email-masked] (Sam Manthorpe) said:

> the scope-id part is easily recognisable by humans and easily parsable.

Exactly. In fact, this is one of the reasons that we (KAME) have
purged the embedded syntax like fe80:1::xxxx from the userland.

As itojun said, we still use the old syntax in the kernel, but it is a
hack which is a kind of a necessary evil.

					JINMEI, Tatuya