that was very useful
thank you.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Wed, 27 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
