> I think we did discuss this is the past and concluded that the
> v4-mapped v6 addresses were only meaningful when carrying IPv4
> non-loopback, unicast addresses. Thus, the IPv6 node should not
> have to do multiple, different prefix checks to determine if an
> address is a multicast address or a loopback address.
Well, then I would like to beg and plead for a reconsideration.
As someone writing a multicast app, I look at the unicast API with
envy... Three simple function calls and I'm ready to move data
with either v4 or v6 hosts.
gethostinfo()
socket()
[bind()]
connect()
But with multicast I have to have duplicate code. In fact the same
duplicate code that every other multicast app has to have.
gethostinfo()
socket()
if (sa_family==AF_INET6){
setsockopt()'s for v6
[bind()]
[connect()]
} else if (sa_family==AF_INET){
setsockopt()'s for v4
[bind()]
[connect()]
}
And every time I have to handle an group address (group address,
local address, or a remote address) I have to write two sections
of code, one for v6 and one for v4.
And this same duplication of effort goes into every v6 multicast
application (because every one of them will want to be v4 compatible).
And all this duplication could be avoided if applications could
simply use v4mapped multicast addresses with the basic v6 api.
At the very least you should change section 2 paragraph 6 which
currently reads:
Because of the importance of providing IPv4 compatibility
in the API, these extensions are explicitly designed to
operate on machines that provide complete support for both
IPv4 and IPv6....
If the setsockopt() options IPV6_MULTICAST_IF IPV6_MULTICAST_HOPS
IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP cant be used on v4 multicast
sockets (whether AF_INET or mapped AF_INET6), then the above
paragraph is not being honest and language should be added to
indicate that v4 multicast is not in any way supported by this API.
If these socket options are to be supported for v4 multicast sockets,
then language should be added to make it clear what the basic API
should support.
brad
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
