Comments on draft-ietf-ipngwg-rfc2553bis-00.txt
(and on the POSIX spec by extension...):
1) It would be very useful to be able to obtain (via getaddrinfo) the
list of local addresses to which you can bind. There's at least two
ways I can think of to potentially support this:
a) AI_PASSIVE could return a list of sockaddrs, with the unspecified
address always being first.
b) Use a new flag to enable behavior of obtaining the whole list
2) In porting IPv4 apps to IPv6, it's inconvenient that nodename and
servname cannot both be NULL. There are applications that actually
want to bind to INADDR_ANY/in6addr_any with an unspecified port.
The intuitive behavior of allowing both to be NULL would be to get
back local addresses without port numbers.
3) When multicast addresses are stored in a sockaddr_in6, how is the scope
id field interpreted? My interpretation of the current wording (which
I agree with) is that it's interpreted the same way as for unicast
addresses. That is, a link-local multicast address uses the same
sin6_scope_id as a link-local unicast address on that link.
A site-local multicast address uses the same scope id as a site-local
unicast address in that site. For other multicast scope levels, the scope id
field can contain an id identifying the interfaces in that scope. Again, I
believe this is the correct interpretation, and is consistent with the current
RFC and draft.
Reasoning (in case you disagree...)
For *link-local* multicast, it's very convenient to store the scope id
for the link-local scope on the interface (i.e., the ifindex or whatever
the implementation uses). This is especially useful in that one doesn't
need to do IPV6_MULTICAST_IF before sending to a link-local multicast
address, since the sockaddr in the sendto() is unambiguous.
For scopes between link-local and global, the issues are:
1) is the scope_id for a site-local group the site id or an ifindex
(or equivalent link id)?
2) If you say the scope_id for multicast is always the ifindex, then
you cannot tell that two sockaddrs actually refer to the same group,
like you could for unicast, when both interfaces are inside the same
scope.
3) If the scope_id is not an ifindex, then what is the meaning for
scopes other than global and site-local?
Basically, there's a disconnect between some purposes wanting the ifindex
to know how to send/join, and using a site id (or equivalent) to uniquely
identify the address. It's more consistent with unicast to use a site id
(and the current draft appears to say this is the case), not an ifindex,
but this would require an id for every scope level between link and global
scope.
An "unspecified" value (e.g. 0) might be legal in a given implementation
for non-global multicast addresses, if it allows unspecified scope ids
in non-global unicast addresses. (I'd tend to disallow this all
together, but others disagree.)
-Dave
