Subject: [Tsvwg] IPv6 scope & SCTP (FW from IPNGWG: summary of discussions about t he semantics of sin6_scope_id)

From: [email-masked]
Date: Wed, 27 Jun 2001 10:32:07 +0300

Hi all,

This mail comes from the IPNGWG.  I think that this is quite relevant to
the IPv6 discussions with respect to SCTP.  It is possible that IPv6
addresses escape their scope in INIT & INIT-ACK messages.  Therefore,
I imagine that most implementations will need to examine the sin6_scope_id
in order to make sure that any recieved addresses are correct in scope.

I favor option B listed below. It would be good to get some comments on
this.

best regards,
John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> 
> Sent: June 26, 2001 21:08
> To: [email-masked]
> Subject: summary of discussions about the semantics of sin6_scope_id
> 
> 
> 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]
> --------------------------------------------------------------------
> 

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Wed, 27 Jun 2001 08:29:32 -0500

John:

Steve Deering and I will be releasing a scoping draft
sometime later this week. Steve is currently doing
some minor tweaks he wants incorporated and we should
have it out by Friday... Hopefully this will address
these issues..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)