In your previous mail you wrote:
Our current draft suggests,
but does not require, that different scopes use different zone indices,
but I'd be in favor of changing that in the next revision (just have
to convince my co-authors).
=> I'd like to have a require for the numerical values.
>If we have distinct values then we can implement any kind of outgoing
>zone selection, ie. we can specify in the sin6_scope_id field the zone
>of the outgoing interface, the only restriction is its scope must be
>smaller or equal to the address scope. Then I have three questions
>about this:
> - a link zone can have more than one interface, is there practical
> example where this can be a problem?
I'm not sure what you are asking. Are you asking if there is a practical
reason to support multiple interfaces to the same link? Or are you asking
if we have all the machinery necessary to properly support multiple
interfaces to the same link?
=> second but if we can convert node-local to interface-local the whole
issue will be magically solved!
> - should we extend this model to the reception side, ie. one matches
> only when the incoming interface belongs to the right zone?
Are you talking about using bind() to limit the zone of acceptance?
=> yes, I like symmetry.
> For IPv6, with its scoped addresses, the analogous capabilities would
> be a choice among:
>
> - identifying a particular outgoing interface, or
>
>=> do you mean a particular outgoing link (someone has already corrected
>me about the difference :-) or do you rely on IPV6_MULTICAST_IF?
In the above-quoted text, I was referring to an outgoing interface, not
an outgoing link. If you read the scoping architecture draft carefully,
you'll see that we specify separate zone indices for interfaces and for
links.
=> I've missed the usage of node-local (*) zone IDs for denoting
interfaces. (*) we *must* change the name to interface-local ASAP!
Now, that's a pretty sneaky way of unifying interface indices and zone
indices, and it is pretty counterintuitive too: a packet whose transmission
is constrained to a node-local zone ought not to be allowed to leave the
node. And I think that if I were starting from scratch, I would eliminate
the node-local multicast scope altogether (and use link-local multicast
scope on the phantom loopback link to achieve the purposes for which
node-local was intended). So I'm now more inclined towards explicitly
distinguishing between interface indices and zone indices, but giving
them distinct values so they can both be carried unambiguously within a
single field, such as the interface field in the in6_pktinfo structure.
=> I agree but can we do these necessary changes?
> On reception, the upper-layer should be told the arrival interface,
>
>=> how? The sin6_scope_id should contains the index of the zone of the
>address scope (this rule implies global addresses in any cases will get
>the zero sin6_scope_id in recvfrom() because there is only one global zone).
Yes, my thinking was muddled. I think we need to distinguish between
two different uses of zone/interface indices:
(1) to identify the zone of an address, in a node that is attached to
more than one zone of that address's scope. This is the purpose
of the sin6_scope_id field in the sockaddr_in6 structure, and of
the "%" qualifier in the textual representation of IPv6 addresses.
(2) to constrain the set of interfaces over which a packet may be
transmitted -- or on which a multicast group is to be joined --
to a set *less than* that implied by the zone of the relevant
address. This is the purpose of the interface index in the
in6_pktinfo structure, and in the IPV6_MULTICAST_IF and
IPV6_JOIN_GROUP setsockopts, and of a "-i <interface>" or
"-z <zone>" command line option in, for example, a ping command.
=> don't forget that IPV6_JOIN_GROUP has a global effect then one can
easily misunderstand what is really "a multicast group join"...
I am not convinced that we need to distinguish between the two cases,
in fact I'd like to not go backward to -i/-z extra parameters to all
the applications...
This leads to the following suggestions:
- a non-zero sin6_scope_id value used when bind()ing a socket or
sending a packet is used only to identify the relevant zone of the
source or destination address, and *not* to identify a particular
interface for sending or receiving, even if the sin6_scope_id happens
to be an interface index. I.e., the use of an interface index would
not be interpreted as (over) specifying the choice of outgoing
interface. Of course, it would be cleaner to just use zone indices,
not interface indices, for sin6_scope_id, but backwards compatibility
with existing implementations might argue for allowing either.
=> I agree but what happens if we convert node-local to interface-local
(I think that the whole restriction will vanish).
- the sin6_scope_id value returned in a sockaddr_in6 when receiving
a packet is interpreted only as identifying the zone of the source
address, not as the specific interface on which the packet arrived.
Again, it would be cleanest if only zone indices were used, but
interface indices could be "tolerated" for backwards-compatibility
reasons.
=> I agree and in this case there is no issue because all the addresses
have a scope strictly greater than node-local with the exception of ::1
which is already very special.
- to constrain an outgoing packet to a specific interface or a set of
interfaces smaller than the set belonging to the destination
address's zone, you would specify an interface index or a zone index
in the in6_pktinfo structure of the advanced API. For multicast
packets, you could alternatively use IPV6_MULTICAST_IF.
=> why is it not enough for zones to use sin6_scope_id as suggested
in the scope arch I-D? I'd like to have both (extended) in6_pktinfo
and sin6_scope_id, functions are not exactly the same (in6_pktinfo
can specify the source address too) and there are a lot of old codes
using in6_pktinfo, for instance all the RIPng implementations I know...
- to determine the specific arrival interface of a packet, you would
use the in6_pktinfo structure of the advanced API.
=> I agree. We have to extend in6_pktinfo to IPv4 too in order to
have more regular codes.
- when joining a multicast group, you would use IPV6_JOIN_GROUP with
either an interface index, a zone index, or zero (unspecified).
=> fine.
Thanks
[EMAIL PROTECTED]
PS: the two remaining questions are:
- do we agree about this model?
- do we convert node-local to interface-local or put interface indexes
into another space than zone IDs (this will force by side effect all
the interface index restrictions)?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
