Subject: Wrap up and last call: sin6_scope_id semantics

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 09 Aug 2001 01:36:50 +0900

(Most of you have probably lost the context..., but)

We have discussed the semantics of the sin6_scope_id filed of the
sockaddr_in6 structure (see attached).  Here are the list of people
who have explicitly stated opinions:

A (the flat 32): Steve Deering, Erik Nordmark, YOSHIFUJI Hideaki, and I.
B (the strict 4+28 split): Francis and Vladislav Yasevich
C (the flexible 4+28 split): Dave Thaler and Markku Savela

The majority is those who support A.  However, I'm afraid we cannot
call this "consensus" (only a few people have presented opinions
anyways...)  I think we've fully discussed this and we'll not be able
to expect further information to tie-break the situation, so we should
decide it now anyway.

Possible approaches would be as follows:

1. pick the idea A as consensus
2. leave it as implementation dependent
3. just pick one randomly (by coin-toss, etc)

I would, of course, like to propose #1.  But, it would not be fair
just to do so, so please speak up if anyone of you (still) oppose to
the idea.

Then we should choose 2 or 3 (it would actually be 2, #3 is
ridiculous...).  I'd really like to avoid #2 because it would annoy
users so much, but it would even be better than not documenting it.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Subject: summary of discussions about the semantics of sin6_scope_id
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: [email-masked]
Date: Wed, 27 Jun 2001 03:07:38 +0900

The following is a summary of discussions about the semantics of
sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in the API
list.  Since some of key members of this issue are (accidentally) not
on the list, I think this list is the best place to get a consensus.

Please note that the text below is not the conclusion, but just a
memo.  I'd like to hear from others about the issues on this list
based on the memo, discuss further if necessary, and try to get a
consensus hopefully in a week or so.  Then the result will (probably)
be in the next revision of the scope architecture draft.

In the following memo, I'll first show you definitions of the
semantics, which will fall into 3 categories.  I'll then describe (a
summary of) opinions about each definition that I've heard in the
discussions.  I tried to be fair when describing them, but if I was
wrong on some points or I missed something, please point it out.

DEFINITIONS

We have seen 3 definitions of semantics.  I call them
(A) the flat 32
(B) the strict 4+28 split
(C) the flexible 4+28 split
respectively.

(A) The flat 32 uses the whole space (i.e. 32 bits) per scope.  The
uniqueness of IDs are only ensured in a single scope.

Both (B) and (C) embed a scope type (4 bits) into the ID space.  IDs
in a particular scope is specified by the remaining 28 bits.  And the
28-bit ID for a particular zone must also be unique in the scope.
We can choose the 28-bit ID for a particular zone in any way, but
Francis showed a concrete example: the interface index of a particular
interface that belongs to the zone.  I'll use this definition in the
following examples, with the smallest interface index in the zone as
the particular one.

The only difference between (B) and (C) is about the usage.  In "the
strict strip",
- if an ID is given with a (non-unspecified) address, the ID must be
  in the same scope type as the address in any context (including in a
  sockaddr_in6 structure).
- even if the accompanying address is unspecified, we do not allow a
  non-zero ID for specifying a particular (or any) zone of a particular
  scope type.

"The flexible split", on the other hand, does not have any such
restriction; we allow any combination of a (scoped) address and a zone
ID, provided that the scope type of the ID is equal to or smaller than
the scope type of the address.

Examples.

The following topology is described in the scope architecture draft.

      --------------------------------------------------------------- 
     | a node                                                        | 
     |                                                               | 
     |                                                               | 
     |                                                               | 
     |                                                               | 
     |                                                               | 
     |  /--------------------site1--------------------\ /--site2--\  | 
     |                                                               | 
     |  /--link1--\ /--------link2--------\ /--link3--\ /--link4--\  | 
     |                                                               | 
     |  /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\  | 
      --------------------------------------------------------------- 
             :           |           |           |           | 
             :           |           |           |           | 
             :           |           |           |           | 
         (imaginary    =================      a point-       a 
          loopback        an Ethernet         to-point     tunnel 
            link)                               link 

A) Using the "flat 32", the zone indices are as follows:

  ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5
  ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4
  ID(site1) = 1, ID(site2) = 2

where ID(x) means the zone identifier for the zone "x".

B&C) Using the strict/flexible 4+28 split, the zone indices are

  ID(intf1) = 0x10000001, ID(intf2) = 0x10000002, ..., ID(intf5) = 0x10000005
  ID(link1) = 0x20000001, ID(link2) = 0x20000002,
      ID(link3) = 0x20000004, ID(link4) = 0x20000005
  ID(site1) = 0x50000001, ID(site2) = 0x50000005

(assuming scope types like the "scop" field for multicast addresses.)

And, if we take (B), the strict 4+28 split, then
  if we have a sockaddr_in6 structure, whose sin6_addr member is
  "fec0::1234", then its sin6_scope_id must be in the site scope, like
  0x50000001.
  if we have a sockaddr_in6 structure, whose sin6_addr member is
  in6addr_any, then its sin6_scope_id must be 0.

If we take (C), the flexible split, then
  if we have a sockaddr_in6 structure, whose sin6_addr member is
  "fec0::1234", then the scope type of its sin6_scope_id can be any
  scope which is equal to or smaller than the site scope.
  if we have a sockaddr_in6 structure, whose sin6_addr member is
  in6addr_any, the the sin6_scope_id is in any type of scope.

Example usages of the flexibility are:

  1) binding to "any interface in a given scope zone".  This would mean,
     when sa.sin6_addr = unspecified, and sa.sin6_scope_id = 0x50000001,
     then bind(&sa) specifies the kernel to accept any packet arrived at
     the interface which belongs to the site zone 1.
  2) when sa.sin6_addr = fec0::1234, and sa.sin6_scope_id =
     0x20000002, then sendto(&sa) specifies the kernel to send the
     corresponding packet to one of the interfaces in the link zone 2.
  3) allow IPV6_MULTICAST_IF (and IPV6_JOIN_GROUP) to use a scope
     id rather than just an ifindex, to let the stack choose the
     best interface in a given scope zone, similar to passing
     0 today.  

OPINIONS

Opinions from those who support A (including Steve and I):

A-1 It provides backward compatibility to existing implementations that
    use interface indices as link indices, assuming one-to-one mapping
    between interfaces and links.
A-2 There is no chance of misusages such as specifying a site zone ID
    for a link-local address.
A-3 Since the IDs are typically specified with a (non-unspecified)
    address, like in the sockaddr_in6 structure, and the accompanying
    address itself provides the appropriate scope type, the strict
    split does not have much merit.  We'd rather keep it "simple" to
    avoid misconfiguration described in A-2.
A-4 The flexible split would make comparison of two scoped addresses
    (in a same scope type) more complicated; we may have a
    chance to compare {sin6_addr = fec0::1234, sin6_scope_id =
    0x50000001} and {sin6_addr = fec0::1234, sin6_scope_id = 0x20000002}
    which may or may not specify a same single node, and we can't just
    compare the scope ID part by a "simple" operator '='.
A-5 It would be the most readable, especially when we use digit integers
    for IDs, as specified in the current scope architecture draft.
    (e.g. recall the fact that 0x50000001 = 1342177281).  Even if we
    allow hex integers or a dotted notation like 5.1, the flat ID
    would still be the most readable, and we'll see some situations
    that we want to type the ID itself, not an alias name of the ID,
    in some configuration files or something.
A-6 We've never seen realistic examples of the flexibility that the
    flexible split would provide.  On the other hand, we will see (or
    even have seen) some situations where we just want to disambigute
    scoped addresses (with the same scope type of the address).  We
    should implement the "advanced" flexibility in a kind of advanced
    API, not using a part of the basic API; sin6_scope_id.

(Note: I'm probably biased, and might not be fair, in this section.  I
have to say that some people pointed out that some of the points were
just a matter of taste, and some points did not provide much
difference.  Also, please make additions in the items below, and
corrections to the items above.)

Opinions from those who support B (including Francis and Vlad - please
add if I miss anyone):

B-1 It provides global uniqueness.
B-2 It provides zone IDs by themselves.
B-3 It has no possible conflict with the interface index space.
B-4 As for the readability, we should change the current definition,
    so that hex integers or the dotted notation would be allowed.
B-5 It can provide the backward compatibility described in A-2 above and
    the readability in A-5, by specifying that the scope type 0 means
    the same scope type of the corresponding address (assuming a non
    unspecified address is given).
B-6 the flexibility that the flexible split would provide is a "too
    much" or "too clever" stuff, and should not be in the basic API
    (basically the same argument as A-6 above)

Opinions from those who support C (including Dave and Markku - please
add if I miss anyone):

C-1: the same benefits as B-1 to B-3 are applied to C.
C-2: the same argument as B-4 as for the readability.
C-3: the example usages described in "Example usages of the
     flexibility" above really benefits of this approach.
C-4: we should not add API knobs to implement the flexibility, because
     it would confuse the users.

					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: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 00:36:16 +0700

Date:        Thu, 09 Aug 2001 01:36:50 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

  | The majority is those who support A.

Actually, it wasn't, you had 4 supporting A, and 4 not supporting A.
A might have more support than either of the others, but not majority
support...

I'm not sure I know or care enough about this to offer an opinion, but
I would like to ask a question ....

  | A) Using the "flat 32", the zone indices are as follows:
  | 
  |   ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5
  |   ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4
  |   ID(site1) = 1, ID(site2) = 2

Would another variation of that approach result in ID(site2) == 5
and ID(link4) == 5 ?

And I don't care if ID(link2) is 2 or 3, and whether ID(site1) is
1 2 3 or 4.

That is, pick the scope identifier of a lower level object that is within
the higher level object as the identifier for that object.

That is to avoid the problem where "1" means one place in one context
and somewhere totally different in another.  Instead "2" in link context
would mean a particular link, in site context it would mean a collection
of links, but the link "2" would certainly be one of them.

With things defined that way, I think A would suit me just fine
(not that I'd count my opinion on this issue), without it, I think
I'd prefer B or C, just so the ambiguity is avoided.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 09 Aug 2001 07:15:07 +0900

>>>>> On Thu, 09 Aug 2001 00:36:16 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> A might have more support than either of the others, but not majority

You could say that, but I believe B and C should be separate.
Actually,

- Francis (who supports B) said he said he'd rather prefer A to C,
  because C would introduce too much complexity.
- Markku (or Dave? anyway who supports C) said he'd rather prefer A to
  B, because we'd not see much benefit to separate the field
  (i.e. 4+28) if we get rid of the flexibility that C provided.

> Would another variation of that approach result in ID(site2) == 5

Yes, it would.

> I'd prefer B or C, just so the ambiguity is avoided.

Hmm, I guess it would be okay to leave it as implementation dependent,
that is, "we adopt the flat 32 model, but the actual mapping from a
particular zone to a zone ID (sin6_scope_id) is implementation
dependent."  Does this make sense to you?

					JINMEI, Tatuya

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 10:28:03 +0700

Date:        Thu, 09 Aug 2001 07:15:07 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | You could say that, but I believe B and C should be separate.

This is an irrelevant point (the whole question of majorities),
but it doesn't matter whether they're separate or not, a majority
is still more than 50% of the total, not just the greatest number
of any of the possibilities.

  | Hmm, I guess it would be okay to leave it as implementation dependent,
  | that is, "we adopt the flat 32 model, but the actual mapping from a
  | particular zone to a zone ID (sin6_scope_id) is implementation
  | dependent."  Does this make sense to you?

Yes, I have no problem with that.  But again, I don't know enough about
the implications for my opinion on this to count for anything...

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 10:45:31 +0200

In your previous mail you wrote:

   anyways...)

=> we obviously need more opinions... I don 't know how to collect
them, IPv6 WG agenda for Friday is already more than full!

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 11:11:11 +0200

=> I share your concern which is the main reason I dislike option A
(i.e. use 1,2,3,... is simple but misleading).

Regards

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 09 Aug 2001 17:58:03 +0900

>>>>> On Thu, 09 Aug 2001 10:28:03 +0700, 

> of any of the possibilities.

Okay, please just read the text "relatively large number of people (or
whatever you want).

> the implications for my opinion on this to count for anything...

I see, I won't count you as a support of A.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 13:49:07 +0200

=> don't forget we need some functions to deal with zone IDs (inheritance
+ a interface index -> interface zone ID macro) and IDs <-> names tools
(file name, syntax, some functions again)...

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 12:20:53 +0200 (CEST)

> of links, but the link "2" would certainly be one of them.

I don't know if there is a requirement for the stability of ids
that has bearing on this suggestion.
For instance, when intf #2 is removed from the node while running,
then applications explicitly using intf #2 would clearly need
to handle the change to the configuration.

But your constraint seem to imply that the ID(link2) would now need to
change from 2 to be the same as the ID for some other interface in that link.
That would force applications using link ids to handle the reconfiguration
even though the node is still attached to the same set of sites - it is merely
using different interfaces to attach to the links.

I guess one could handle this type of reconfiguration by
 - never reusing the IDs at any scope for new stuff, and
 - somehow keeping the historic bindings around.

That way ID(link2) = 2 even though interface #2 is gone.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Aug 2001 13:59:04 +0200

=> I believe there should be none because the stability requirement
should be for id names, not id values. Of course, we should recommend
to use always names too.

=> the real issue is to get ID(link2) = 2 even though interface #2
is now affected to link333... Names are the solution there too!

Regards

PS: I believe our colleague Jinmei is waiting for a decision between
options A, B and C before producing a document... Please help him!
--------------------------------------------------------------------
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: Mon, 13 Aug 2001 14:20:38 +0200 (CEST)

> should be for id names, not id values. Of course, we should recommend

Notice that I did *not* talk about stability across reboots.
My issue is whether it is ok or not to have the ids change
on a whim while the machine is *running* (e.g. due to using hotplugging to
add or remove NICs).

If we allow this rate of change it seems like an application
needs to do the name to id translation each time it is using
an id for instance each time it is sending a packet.
Is that really what we want?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 13 Aug 2001 16:12:27 +0200

=> it seems we agree to say it is *not* ok.

=> no, we don't want that. Only the inheritance stuff should be called
each time. Note we don't want to change the name-id file very often too.

Regards

PS: I believe you'd like to get some freedom in the way zone ID values
are chosen. If we use a per interface list of zones which the interface
belongs to, then we can implement what we'd like... Simple schemes are
easier because they don't need the reverse map (zones to interface lists).
PPS: simple schemes can be described and simulated when the name-id file
is configured, do more complex schemes need a standard way to express
zone/interface mapping? I believe the only hairy case is the mobile node one,
so do you know what we need for such cases?
--------------------------------------------------------------------
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: Tue, 14 Aug 2001 00:21:10 +0700

Date:        Mon, 13 Aug 2001 12:20:53 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | But your constraint seem to imply that the ID(link2) would now need to
  | change from 2 to be the same as the ID for some other interface in that link.

No, that's reading more into what I said than I intended.

The important part, from my perspective, was ...

	avoid the problem where "1" means one place in one context
	and somewhere totally different in another.

The rest of it was just one possibility, allowing all of interfaces, links
and sites, to be numbered with small integers starting from 1.   (That is,
avoid numbers that have bits set up in the high bits, which Jinmei's
B and C seemed to be requiring).

How the numbering is done is pretty much irrelevant to me, provided that
we don't have identifier ambiguity, and ideally, without using identifiers
with magic in the upper bits.   For all I care, you can number the interfaces
1, 2, 3, ... N, then the links N+1, N+2, ... M, then the sites M+1, ... P,
then if a new interface or link (or site) appears, call it P+1.  It doesn't
matter that the numbers for any one type aren't contiguous.

If an implementation wanted, it could even number its interfaces 1 4 7 10 ...
its links 2 5 8 11 ..., and its sites 3 6 9 12 ...  (also no requirement for
all numbers to actually be in use).

The 'Instead "2" in link context would mean a particular link, in site
context it would mean a collection of links, but the link "2" would
certainly be one of them' comment was just meant as one possible way that
small numbers could be assigned in a way that wouldn't be too horrible
(at least the identifier would always mean one general direction).

You might remember that it was also a question - whether that's something
that scheme A would allow (not having followed this debate, I had no idea
whether it was assumed for A that the id's would be 1 2 3 for interfaces,
1 2 3 for links, and 1 2 3 for sites... - that's how it was represented
in the example, and that I don't much like at all).

Certainly I wouldn't want applications to have to go polling (or handling
events) to discover that the id's have all changed because of some interface
reconfiguration - the IDs should certainly be stable from one boot to
another (or at least reasonably stable, if an interface is removed, then
replaced, I don't care if it has the same ID it used to have or not).

I'm not sure how applications should handle the case where an interface
moves from one link to another, or a link moves from one site to another
(which would be done by administrator configuration or some automated
equivalent thereof I assume).   For more applications it probably doesn't
matter, for the others (eg: I want to (many times over an interval) send
to all interfaces in site X) some kind of polling or event mechanism
will probably be needed.

  | I guess one could handle this type of reconfiguration by
  |  - never reusing the IDs at any scope for new stuff, and
  |  - somehow keeping the historic bindings around.

The latter isn't needed, assuming the current bindings are kept around.
But yes, never re-using an ID is one fairly easy way to handle things,
and one which is likely to be safe.

Maybe what I'd like to say would be that no identifier should be used for
any interface, link, or site, that is also used for another of those,
unless the smaller of those (as defined, ie: interface < link < site)
is a subset of the bigger (as configured).   No requirement that there
ever be any duplication, just a restriction on when duplicate ids in
different scopes are permitted.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 16 Aug 2001 01:37:28 +0900

>>>>> On Mon, 13 Aug 2001 16:12:27 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

   
> => it seems we agree to say it is *not* ok.

Of course not.

Aside from this particular issue, it seems that MIB guys also want
zone IDs that can identify particular scope types.  If such usage has
reality, it would mean 4+28 (or something similar) IDs are more
suitable.

I talked with Steve (and some other guys who supported the idea A) on
this issue assuming such usage in MIBs, and we thought we could
compromise on this point, as long as we could avoid "flexibility" that
the idea C would provide.

So, the basic idea is as follows:

- take 4+28 split.
- actual mapping from zone to the 28 bit part does not matter, but it
  should not change while the node is running (as discussed in this
  thread)
- introduce "aliases" for numeric zone IDs to improve readability in
  the textual representation. e.g. "link2" is an alias of a link ID
  whose intra-link id is 2 (i.e. 0x20000002).  "site4" is an alias of
  a site ID whose intra-site id is 4 (i.e. 0x50000004).  We now allow
  fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004)
- when a zone ID is used with an address (typically in the sockaddr_in6
  structure), the scope type of the ID must be equal to the scope type
  of the address.

This should basically be the same idea as B.  So I guess supporters of
B do not oppose to this (I hope not, actually).  As I said above, most
of supporters of A could live with this.

Can we (especially those who support C) make a compromise on this with
this plan?  Then I'll revise the textual representation in the scope
architecture draft, according to the idea.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Aug 2001 19:39:30 +0200

Aside from this particular issue, it seems that MIB guys also want
   zone IDs that can identify particular scope types.
   
=> ah! They want zone IDs which stand by themselves.

   This should basically be the same idea as B.  So I guess supporters of
   B do not oppose to this (I hope not, actually).

=> no opposition! Where I can sign? (:-)
   
   this plan?

=> I believe C is not for the basic API but we can open a new activity
about C in the advanced API (C people will propose things, A people will
reject proposals which are not useful, B people will take holidays :-)?

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 15:40:25 +0200 (CEST)

>   structure), the scope type of the ID must be equal to the scope type

Seems like, to the extent that there are existing applications
which use if_nametoindex() -> sin6_scope_id for link-local addresses,
we need to also support the top 4 being zero as an alias for the 
interface or link scope.

Does anybody know of such applications?
Does anybody know of applications doing the reverse (taking sin6_scope_id
and passing it to if_indextoname())?

If nobody on the list knows of such applications we could take the
optimistic path and ignore the existence any such applications...

  Erik

---

From: Atsushi Onoe <[email-masked]>
Date: Thu, 16 Aug 2001 23:28:03 +0900 (JST)

>   structure), the scope type of the ID must be equal to the scope type

As I said at the meeting, I agree with the idea.

Some isssues:
	- need to define the mapping between scope and top 4 bit?
		my guess is yes.  MIB peaple may want to map a value
		into alias (e.g. "link") from a remote system.

	- should care existing implementations?
		yes.  But I guess most of such applications use a interface
		index for scope_id, so it can be saved either:
	    - assign scope value (4bit) 0 to link-local.
		or
	    - implementation MAY accept the value 0 in implementation-
	      specific manner, but SHOULD NOT return 0 for scope (4bit).

	- need to introduce new functions to map scope-name and the value?
		I hope not to define new functions, so want to _define_
		the textual representation (e.g. "link", "site", ...)
		instead.

Atsushi Onoe

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 16 Aug 2001 23:30:35 +0900

>>>>> On Thu, 16 Aug 2001 15:40:25 +0200 (CEST), 
>>>>> Erik Nordmark <[email-masked]> said:

> and passing it to if_indextoname())?

Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo()
use this mapping, all applications that use those two functions are
affected, including ping, traceroute, ifconfig, netstat, route,
telnet, ssh, ftp,...

So we should probably provide some trick to ensure backward
compatibility for such applications.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 17:31:26 +0200 (CEST)

> affected, including ping, traceroute, ifconfig, netstat, route,

I'm confused.
When you ship a new release that supports a link ids, site ids, etc
won't you also ship a getaddrinfo and getnameinfo which can handle those?

Thus I think the only concern should be for applications which
directly use if_nametoindex or if_indextoname for sin6_scope_id.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Aug 2001 02:18:14 +0900

>>>>> On Thu, 16 Aug 2001 17:31:26 +0200 (CEST), 

> won't you also ship a getaddrinfo and getnameinfo which can handle those?

Of course I will.  However, we should also provide backward
compatibility to applications that are statically linked with older
libraries.  (probably my text in the previous message was unclear,
sorry).

> directly use if_nametoindex or if_indextoname for sin6_scope_id.

So, unfortunately, this is not true, at least for some vendors
including us.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Aug 2001 18:20:30 +0200

Thus the kernel needs to be able to tell whether the application
   was statically linked against getnameinfo. This is hard as far as I
   know.
   
=> the only easy way is to change something in system calls (AF_INET6
value, system call numbers, ...). But how many real applications
need scoped addresses? All examples I know are for system tools
(ifconfig, ...) which are *not* real applications with only one
(bad) exception: net$cape.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Aug 2001 16:33:48 +0200

=> change the dynamic library and recompile all statically linked
applications?

=> a MAY was proposed... But I am in favor of a *short* period with
the trick enabled by default.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Aug 2001 16:29:40 +0200

Some isssues:
   
=> multicast scope values?

=> the MAY is fine.

=> I prefer real names than xxxNNN. Can we get both (i.e. a config file
plus a default translation rule)?

Regards

PS: scopes are according to draft-ietf-ipngwg-addr-arch-v3-06.txt:
             0  reserved
             1  interface-local scope
             2  link-local scope
             3  subnet-local scope
             4  admin-local scope
             5  site-local scope
             6  (unassigned)
             7  (unassigned)
             8  organization-local scope
             9  (unassigned)
             A  (unassigned)
             B  (unassigned)
             C  (unassigned)
             D  (unassigned)
             E  global scope
             F  reserved
2 and 5 have a meaning for unicast.
--------------------------------------------------------------------
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: Fri, 17 Aug 2001 10:09:32 +0200 (CEST)

> libraries.  (probably my text in the previous message was unclear,

Ah - static linking is such a mess :-(

If you need to solve the static linking issue then there is a hard
problem for passing sin6_scope_id from the kernel to the application.
Somehow the kernel needs to know whether the application wants the backwards 
compatible (top 4 bits being zero so the statically linked 
getnameinfo/if_indextoname will work) scope_id or the new one.
Thus the kernel needs to be able to tell whether the application was statically
linked against getnameinfo. This is hard as far as I know.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 18 Aug 2001 18:10:58 +0900

>>>>> On Fri, 17 Aug 2001 18:20:30 +0200, 

> (bad) exception: net$cape.

I'm not sure about the issue of "net$cape", but we (some KAME users
and I) sometimes use link-local addresses for ssh and telnet, in order
to log into an adjacent node (typically a router);

% ssh fe80::1234%2

However, we should only care about the sending side in such usages,
which would be (much) easier than the receiving side.  So, considering
the sending part only might be a reasonable way to go...

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 18 Aug 2001 17:31:44 +0900

>>>>> On Fri, 17 Aug 2001 16:29:40 +0200, 

> plus a default translation rule)?

I do not object to introducing real names, but I'd like to leave that
part as implementation dependent, and just define the formal aliases
(like "link2") in the scope architecture draft.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 18 Aug 2001 17:28:11 +0900

>>>>> On Thu, 16 Aug 2001 23:28:03 +0900 (JST), 
>>>>> Atsushi Onoe <[email-masked]> said:

> 		into alias (e.g. "link") from a remote system.

Yes.  As for the mapping, using the 4-bit "scop" value in multicast
addresses is the easiest (and most intuitive) way, although we should
consider the backward compatibility issue below.

> 	      specific manner, but SHOULD NOT return 0 for scope (4bit).

If we take the latter way, even older applications will see non-zero
zone IDs for the link-local scope.  Doesn't this annoy the
applications?

> 		the textual representation (e.g. "link", "site", ...)

I agree.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 18 Aug 2001 18:05:29 +0900

>>>>> On Fri, 17 Aug 2001 10:09:32 +0200 (CEST), 

> problem for passing sin6_scope_id from the kernel to the application.

That's right.  This is the difficult part of the problem.

> linked against getnameinfo. This is hard as far as I know.

Yes, so, I guess we have (at least) three options.

1. just forget statically linked applications
2. care about statically linked applications for sending side only
3. care about statically linked applications for both sending and
   receiving side

#2 might be a reasonable point of compromise.  If we can agree with
 this, things will be quite easy.

					JINMEI, Tatuya

---

From: Atsushi Onoe <[email-masked]>
Date: Sun, 19 Aug 2001 13:45:00 +0900 (JST)

>  this, things will be quite easy.

Agreed.  And also note that even for such applications, they should
accept the textual addresses with non-zero scope.  So cut & paste
still works well.
ex.
	new kernel				old applications
	--------------------------------------------------------------
	fe80::1%link1	- old getnameinfo ->	fe80::1%536870913
						(fe80::1%0x20000001)
	fe80::1%link1	<- old getaddrinfo -

Atsushi Onoe

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 23:02:28 -0400 (EDT)

Folks,

In the next few weeks I will be updating the base api to be in accordance
with the IEEE wording.  I assume you all have reviewed that over the last
month.

I see no consensus on sin6_scope_id.  Hence,  I will do nothing to alter
its semantics or syntax.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Aug 2001 11:15:04 +0200

=> I don't understand your problem there: I prefer fe80::xxxx%eth0 to
fe80::xxxx%link12, I believe you too...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Aug 2001 11:20:11 +0200

=> ssh and telnet are standard applications on *BSD (and there are
dynamicallly linked). So they will inherit the getnameinfo update

   % ssh fe80::1234%2
   
=> % ssh fe80::1234%link2 will be better, and % ssh fe80::1234%eth0
even better!

Regards

---

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Fri, 17 Aug 2001 02:02:35 +0900

> won't you also ship a getaddrinfo and getnameinfo which can handle those?

We need some paths to keep backward compatibility on systems
such that kernel / library and applications may be developed / distributed
separately by respective maintainers.
ex.) linux kernel, glibc and other utilities such as ping6, net-snmp etc.

Atsushi Onoe wrote:
> I won't oppose that an implementation accepts the values which don't match
> the scope type, but at least it MUST NOT returns such values to applications,
> IMHO.

So just "MUST NOT" is not acceptable.
To leave meaning of 0-scope unspecified (for kernel<->userland) may be ok.

--yoshfuji

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 29 Aug 2001 22:15:16 +0900

Sorry for the delayed response, I'm just back from a vacation.

>>>>> On Mon, 20 Aug 2001 11:15:04 +0200, 

   
> fe80::xxxx%link12, I believe you too...

Well, as a developer and a user of the KAME IPv6 stack, I prefer
fe80::xxxx%eth0 to fe80::xxxs%link12.  The implementation (at least
currently) assumes one-to-one mapping between interfaces and links,
which is natural in a normal operation, and thus eth0 should be more
intuitive than link12.

However, from a stricter architectural point of view, using interface
names as link IDs can be rather confusing, because two different
interfaces can belong to a single link.  Also, the naming convention
might differ among implementations.

So, as a co-author of the scoping architecture draft, I'd rather stick
to the artificial notation (i.e. "link10", "site5", etc) as the
"official" textual representation, which will be described in the draft.
Of course, each implementation may introduce more readable and more
intuitive "names" (e.g. eth0) as zone IDs, based on its own naming
convention.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Aug 2001 15:20:12 +0200

=> I just want aliases, not only a standard name (i.e. my concern
is about one-to-one mapping between zone IDs and names).

Regards