In your previous mail you wrote:
I actually went back and read the existing RFC2292 - probably
something I should have done originally - and I think I have
a handle on this. Based on the current RFC and the -02 draft
my interpretation is that:
- IPV6_HOPLIMIT should not be allowed on a getsockopt() or
setsockopt() call, but instead IPV6_RECVHOPLIMIT should be
used. IPV6_HOPLIMIT can still be sent/received as ancillary data.
- IPV6_RECVHOPLIMIT should be used on setsockopt() to request
that the IPV6_HOPLIMIT be returned as ancillary data.
Does this sound correct, or am I missing something?
=> no, IPV6_HOPLIMIT is the hop limit to use and IPV6_RECVHOPLIMIT
is a flag saying that the received hop limit must be provided to the user.
IPV6_HOPLIMIT can be sticky or ancillary, IPV6_RECVHOPLIMIT must be
sticky.
Also, I see that the current 2292bis draft has expired. Are there
any plans to produce an updated version? From previous postings
back in November regarding the -02 draft there appear to be some
incompatible changes which are being proposed
=> RFC2292 has many bugs (for instance IPV6_RECVPKTINFO is missing
and IPV6_PKTINFO is badly overloaded).
I'd like to have our implementation track to the ID as
it progresses, but if there aren't any new drafts coming then
we should be implementing to the RFC.
=> you should not because of the bugs...
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]
--------------------------------------------------------------------
