At 10:05 AM +0200 6/27/00, Francis Dupont wrote:
>For this reason (selection of a sub-zone), an implementation might
>find it useful to assign a distinct value for each zone index, so that
>they are unique across all zones, regardless of scope.
Yes, I think that makes the most sense. 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).
>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?
> - should we extend this model to global addresses (this is a proposal
> for the sin6_scope_id meaning)?
Our draft does mention the use of smaller-scope zone indices when sending
to a global destination address (section 7, last paragraph, penultimate
sentence).
> - 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?
> 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. For example, Figure 1 in the draft shows a node with zone indices
for each of the following zones:
intf1, intf2, intf3, intf4, intf5, link1, link2, link3, link4,
site1, site2, site3
The zone indices for interfaces arise from the definition of the (multicast)
node-local scope as spanning only a single interface. Then, by allowing
any transmission to be constrained to a lesser-scope zone, we can use
those node-local zone indices to specify a particular outgoing interface,
even for sending unicasts.
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.
> - identifying only the outgoing zone (for non-global destinations),
> and leaving it to the IP layer to choose an outgoing interface
> within that zone, or
>
>=> I don't know if the non-global restriction is really needed.
It's not. In the above-quoted text, I was trying to avoid the diversionary
issue of using of lesser-scope zones.
> 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.
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.
- 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.
- 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.
- to determine the specific arrival interface of a packet, you would
use the in6_pktinfo structure of the advanced API.
- when joining a multicast group, you would use IPV6_JOIN_GROUP with
either an interface index, a zone index, or zero (unspecified).
(If the above is just a restatement of what some of you have been
saying all along, please forgive me for spending more time talking
than listening.)
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
