Brian, Steve,
>
> I agree completely. As I see it, having to select an interface when sending
> a multicast packet in IPv4 is just a hack to get around the lack of the zone
> concept in IPv4. This the architecturally clean and simple way to do it.
> We shouldn't propagate bad hacks forward from v4 into v6.
>
> > Then, I think we could probably get rid of
> > IPV6_MULTICAST_IF altogether (i.e., deprecate it).
>
> Yes.
>
> > The scope/zone spec is not "still missing", though it
> > certainly still needs work.
>
> Well, the draft itself might need a little bit of cleanup, but the concepts
> contained therein are well understood, exist in multiple implementations,
> etc.
>
I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_-
scope_id for what it was originally intended, to identify the zone from
which a datagram was received and to identify the zone to which a datagram
should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF
does that is unfortunate but it certainly isn't the only or even the worst
example of duplicated functionality in the API specifications.
Application writers are familiar and confortable with the notion of
specifying the outgoing interface to be used for multicast and I just don't
see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make
application writers' lives easier. Gratuitous changes to APIs piss
people off even if they are improvements.
I have been as guilty as anyone of beating the snot out of the dead horse
that is rfc2553 but I don't see any upside to making this change at this
late date.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
