Subject: summary of discussions about the semantics of sin6_scope_id

From: JINMEI Tatuya / 神明達哉<[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: Vladislav Yasevich <[email-masked]>
Date: Tue, 26 Jun 2001 14:48:06 -0400

I guess I would prefere a combination between B and C.

The thing that I like from (C) is the ability to specify
a scope (top 4 bits) with the unspecified address.  This offers
some rather interesting flexibility that would be used in
more advanced applications.  I haven't considered the implications
of allowing a full ID (both the '4' and the '28').  At first glance
the specifying the '28' in this case may be a bit too much.

The thing I disklike about (C) is that
scope(sin6_scope_id) <= scope(sin6_addr).  This would
make it much harder to compare scoped addresses.  Also
looking at numerical representation like this:
	fec0::1%20000001
... it just looks wrong to me.  It's essentially saying
that we have this site-local address in link scope.

I think we could add the first flexibility of (C) to 
option B and not increase complexity alot.

-vlad 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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, 27 Jun 2001 00:32:05 -0400 (EDT)

that was very useful

thank you.

/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Jun 2001 17:03:33 +0200 (MEST)

> (C) the flexible 4+28 split

(A) makes the most sense to me since it seems simpler.

  Erik