In your previous mail you wrote:
I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when
the unicast and multicast hop limits are different.
=> there was already an old thread about this. If the socket is bound
there is no ambiguity. I believe the conclusion was to return an error
for unbound sockets (default hop limits are too different), this makes
the choice between sticky parameters / parameters per sendmsg() call
more sound (i.e. the source address is considered as a standard parameter).
This can happen
in two cases. First, prior to any setsockopt() for IPV6_HOPLIMIT,
IPV6_UNICAST_HOPS, or IPV6_MULTICAST_HOPS. Second, a setsockopt()
for IPV6_HOPLIMIT followed by a setsockopt() for either
IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS.
=> there is nothing about interaction between IPV6_HOPLIMIT and
IPV6_XXXCAST_HOPS...
I still think all of this is unnecessary, anyway. Applications
can use IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for getsockopt()
and setsockopt() and IPV6_HOPLIMIT for ancillary data and receive
consistent and predictable results.
=> but the ancillary data coding style is considered as very painful
to use in some cases so the options are defined for both the sticky
and the ancillary styles.
Introducing IPV6_HOPLIMIT on
getsockopt() and setsockopt() seems to provide little to no value
=> the 6.3 section of last 2292bis I-D explicitely mentions sticky
IPV6_HOPLIMIT...
Regards
[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]
--------------------------------------------------------------------
