Subject: Re: Scope ID secret Cabal (minutes)

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 1999 23:15:48 +0100

In your previous mail you wrote:

   APIs that are effected by the scope id issue
   --------------------------------------------
   
   o getipnodebyname(), getipnodebyaddr()
   o inet_ntop(), inet_pton()
   o INET6_ADDRSTRLEN
   o ifindex APIs
   
=> in fact only getipnodebyname() has a real problem.
inet_ntop() and inet_pton() can be (ie. should be!) replaced
by higher level/more powerful functions (as in your recommendations),
INET6_ADDRSTRLEN is bound to inet_ntop() (ie. same point applies).
An ifindex() clone for sites will be useful (ie. I'd like to get this ASAP).

   The group identified possible options to
   dealing with scope addresses and the
   getipnodebyname()/getipnodebyaddr() APIs:
   
   (a) Extend the getipnodebyname() interface to
   work with scoped addresses.
   (b) Standard compile flag fix
   (c) Deprecate getipnodebyname()/getipnodebyaddr()
   (d) Define function to cut out scope id and pass it
   into a yet to be defined function.  The other address
   portion would be passed into getipnodebyaddress()
   (e) Simply use getaddrinfo()/getnameinfo() as scopes
   are transparent to these interfaces.
   
=> I think (e) and (c) are in fact the same thing...
The only exception I can see is the URL stuff where it was so hard
to get a syntax for textual addresses than we wouldn't like to extend it
for scopes (:-)!

   		NI_NUMREICHOST	   host is numeric (46 digits maximum)
   		NI_NUMREICSCOPE    scope is numeric (2^32 => 10 max digits)
   		NI_NUMREICPORT	   port is numeric (2^16 => 5 digits)

=> NI_NUMERICxxx, isn't it?

Thanks

[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: Erik Nordmark <[email-masked]>
Date: Thu, 9 Dec 1999 17:03:03 -0800 (PST)

> An ifindex() clone for sites will be useful (ie. I'd like to get this ASAP).

I agree. One question is whether we need a clone for link ids as well.
(It is becoming more and more common to have multiple NICs connected
to a subnet for high availability and load balancing.)

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Dec 1999 10:44:04 +0100

=> in such case it is very common to have a virtual interface which
hides all the (nasty) details and brings us back to the one link-one
interface case.
Carl, I believe Sun has such things, can you help us?

Regards

[email-masked]

PS: the textual address thread has not yet reached a concensus about
the exact syntax...

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 10 Dec 1999 20:13:29 +0900

>>>>> On Fri, 10 Dec 1999 10:44:04 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

> PS: the textual address thread has not yet reached a concensus about

I know. Sorry for the delay, but we're now locally discussing the
syntax in KAME and will soon propose a (new) one in this list.

					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, 16 Dec 1999 16:04:43 +0900

>>>>> On Fri, 10 Dec 1999 20:13:29 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> syntax in KAME and will soon propose a (new) one in this list.

Here is our current consensus.

(Note: in the following text, I'll use the term "a zone ID" as the
 identifier of a specific instance of a scope. But I don't have a
 strong opinion about the name of the ID. Maybe we should define an
 appropriate standard term in another place.)

1. Should the delimiter be placed before an address or after an
   address?

We prefer "after an address", because
- we'd like to allow a user to omit a zone ID (and the delimiter) if
  it is obvious (e.g. in a single-interface host). If this makes
  sense, a textual address would be more readable if the address
  always begins with "address part".
  (But we may be biassed in this point due to our own implementation
   experience.)

- As I said in my earlier mail, I'm not sure if zone IDs should be
  considered as the most significant part of scoped addresses. I'll
  cite the mail.

>>>>> On Thu, 28 Oct 1999 01:26:49 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> Is it so obvious that the scope_id part is the most significant part?
> I'm not sure. It seems to me that we could recognize (for example) a
> link-local address as follows:

> 1. Look at the 1st 16 (or at least 10) bits of the address (fe80) and
>    recognize that this is a link-local address. i.e. this is the most
>    significant part.
> 2. Then look at the scope identifier and recognize to which link the
>    address should belong. (In this scenario, the scope id is the 2nd
>    significant part)
> 3. Finally use the host id part of the address (i.e. the last 64 bits)
>    to identify the node that the address specifies in the link.

> So I feel the appropriate portion for the scope_id is subtle. However,
> I don't stick to the idea that the scope id should be after an
> address. I'd respect others' opinions.

Though I stated our opinion, we won't stick to the idea. We're willing
to follow a consensus when we implementors get one.

2. Which charater (or strings) is the best as the delimiter?

We prefer a symbol character (i.e. not an alphabet character or a word)
for readability, and have considered several characters. However, (as
you can easily imagine:-), we've not got a consensus on a specific
character or a strings suitable to the delimiter. Each character has its
pros and cons. So I'll just show our current consideration.

The following characters may need be escaped, especially in UNIX-like
systems (so they're not suitable as the delimiter).
!$&*(){}[];'\"<>?`

As for other characters...
#: used as the start symbol of a comment line in some script
   languages and configuration files (e.g. /etc/hosts in UNIX-like
   systems).
=: used as the reserved symbol for variable substitution in some
   script languages.
@: used as the delimiter in contexts like "user_name@host_name".
   used to show source routing in the (traditional) telnet command.
.^+: maybe used in a regular expression.
-: used in DNS labels (but Do we have to care about DNS labels?).
%: used in an e-mail address to specifiy source-routing.
   (But it would be very rare...do we have to care about such cases?)
_~,: maybe safe to avoid conflicts, but does not look "like the
      delimiter"(?)
:(itself): used in IPv6 textual addresses.

I personally feel "%" is not so bad, but I'd like to know other
implementors' opinions for now. Maybe we need a compromise on this
point; there'll be no "perfect" character.

3. What is the appropriate synatx for zone IDs?

Numeric identifiers must be provided. Also, if the system provide
interface names (like `le0' or `etherne1'), the names may be used as
(non-numeric) identifiers. Interface names 
In any case, zone IDs should be composed by numbers and alphabetical
characters only (i.e. without special characters).

So for example, my current preferred format is as follows:
fe80::1234%1 (which specifies a link-local address whose link identifier is 1.)
fe80::abcd%ne0 (which specifies a link-local address whose link
                identifer is designated by the interface "ne0".)

That's all. I'd appreciate any comments or suggestions and be glad if
we'd be able to make a consensus and define a standard (unified) format.

Thanks,

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Dec 1999 14:51:11 +0100

We prefer "after an address", because ...

=> I agree

   I personally feel "%" is not so bad, but I'd like to know other
   implementors' opinions for now.

=> % is used by Cshell for job control and must be quoted...
My favorite list is in order ~ (no known problem), % then @
(@ is the more "natural" but is too overloaded yet: @ is too good :-).

   Maybe we need a compromise on this point; there'll be no
   "perfect" character.

=> none is the ASCII character set (:-).

   Numeric identifiers must be provided. Also, if the system provide
   interface names (like `le0' or `etherne1'), the names may be used as
   (non-numeric) identifiers.

=> I agree. We should have a standard name for the name to value tool
(function(s), DB file, ...) if we add other names than interface names
(which will be a good thing for links or sites).

=> we should have one soon (your Christmas gift?)

Thanks

[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Thu, 16 Dec 1999 09:07:41 -0800

At 4:04 PM +0900 12/16/99, JINMEI Tatuya wrote:
>We prefer "after an address", because...

That is my preference too, but not a strongly held one.

>2. Which charater (or strings) is the best as the delimiter?

Of the single character. non-alphanumeric choices you listed,
I think I prefer "-" or "_".

How about a double-character approach, like:

	fe80::1234//3  or  fe80::1234//ether1

It's too bad all the bracketing characters are off limits, because
something like:

	fe80::1234(3)  or  fe80::1234(ether1)
or

	fe80::1234<3>  or  fe80::1234<ether1>

would be a nice way to add the zone number/name qualifier.  Are "<"
and ">" really a problem if they appear within a token and not at the
beginning of a token?

Or maybe the "/" character could be used in a bracketing way, like:

	fe80::1234/3/  or  fe80::1234/ether1/

>characters only (i.e. without special characters).

Sounds right, though you may want to allow ".", "-", and/or "_" as part
of the zone name.

Steve

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 20 Dec 1999 11:50:42 +0900

>>>>> On Thu, 16 Dec 1999 09:07:41 -0800, 
>>>>> Steve Deering <[email-masked]> said:

> I think I prefer "-" or "_".

Okay.

> 	fe80::1234//3  or  fe80::1234//ether1

It would be a possible way. In fact, we discussed possibility of using
":::" or ".." as delimiter. I didn't mentioned them in my previous
mail just for simplicity, but we may have to consider them as well.
(However, I don't think '/' is a good character even if it was used as
 a double-character, since '/' is used for a preifix.)

> and ">" really a problem if they appear within a token and not at the

Okay, there is no reason to eliminate bracketing characters.

> 	fe80::1234/3/  or  fe80::1234/ether1/

Yes, it could, though I still suspect '/' isn't a good character for
this purpose.

> Sounds right, though you may want to allow ".", "-", and/or "_" as part

Okay, it seems reasonable.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 20 Dec 1999 11:56:32 +0900

>>>>> On Thu, 16 Dec 1999 14:51:11 +0100, 

> => % is used by Cshell for job control and must be quoted...

Yes, but only few commands use the character for job control
(e.g. 'fg', 'bg' and 'kill'). I don't think it practically matters...

Okay.

> => we should have one soon (your Christmas gift?)

I hope so.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 20 Dec 1999 14:39:29 +0900

>>>>> On Mon, 20 Dec 1999 11:50:42 +0900, 

> Okay, there is no reason to eliminate bracketing characters.

I'd like to supplement the above line, since a colleague of mine
cares. I just meant that we could consider the notion of bracketing
characters as the delimiter.

As for specific pairs, "()" or "<>" might not be suitable, because
they have special meaning in UNIX shells.

					JINMEI, Tatuya