In your previous mail you wrote:
=> I apologize because I've forgotten the draft-ietf-ipngwg-scoping-arch-00.txt
document (I was disturbed by the fact that the -01 was never/not yet
available in the I-D directories). The zone inclusion property is in
the I-D and there are some rules about emission using it as:
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.
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?
- should we extend this model to global addresses (this is a proposal
for the sin6_scope_id meaning)?
- should we extend this model to the reception side, ie. one matches
only when the incoming interface belongs to the right zone?
This seems not hard to implement (other opinions?), we just need
a scoped routing table (already needed today) and a good zone naming
scheme (users should understand it :-).
Last point, where to put this? In the rfc2553bis or the scoping arch?
(we can introduce a hard dependence between the two I-Ds)
I'm sure I'm not following all the intricacies of the arguments, but
maybe this is helpful (or maybe not, or maybe not even relevant):
=> this is relevant!
When sending a multicast packet in IPv4, one has the choice of either
identifying a specific outgoing interface or leaving it to the IP layer
to choose an outgoing interface (the "default" multicast interface).
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?
- 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.
There are some situations where it is very nice to have a per-interface
(sorry, a per-link) default route(r).
- leaving it to the IP layer to choose both the outgoing zone (of
the scope of the destination address) and the outgoing interface
within that zone.
All this could be done with the single sin6_scope_id field in the sending
API,
=> we can do a similar thing in the receiving API. I'd like to have the
same kind of usage between the sending and the receiving sides (in fact,
this point is the reason I've jumped into this discussion :-).
if the local indexes for the interfaces plus all zones (i.e., links,
sites, and any additional multicast zones configured on the node) are
given distinct values out of the same scope_id space, and if one index
value (say, 0) is reserved to mean "unspecified". Then, I think we could
probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it).
=> the only reason we should have to keep IPV6_MULTICAST_IF is an
interface specification can be finer than a link one...
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).
from which it can also determine the arrival zones of each possible
scope, since each interface can belong to only one zone of each scope.
=> there are two points: API (what the user will get) and PCB matching
then I don't fully understand you...
That -01 version never made it into the Internet Drafts
directories (it was posted during the time just before Adelaide while
ID submissions were being refused), but we will rectify that ASAP.
=> thanks!
[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]
--------------------------------------------------------------------
