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