> during RFC2292 to 2292bis transition, it seems that the following text > has been added to multiple places: > > (how to reset values set by IPV6_HOPLIMIT setsockopt) > > In order to clear a sticky IPV6_HOPLIMIT option the application can > > specify -1 as the value. Alternatively, the application can specify <-- > > an IPV6_HOPLIMIT socket option with a zero length. <-- > > i don't think it is a usual practice for setsockopt. they normally > take a parameter with fixed length. > i'm wondering where did this behavior come from, and how popular is it > for UNIX setsockopt to behave like this. any hints?
I guess I stuck that text in there based on some goal of consistency with the other IPV6_ options in the spec. Clearly(?) for IPv6_DSTOPTHDR it makes sense to be able to clear the sticky option by setting it to zero length. (I think this is consistent with setting IP_OPTIONS to zero length.) So what about IPV6_HOPLIMIT that is a fixed length quantity? Is it more important to be consistent with the other IPv6 options (and allow zero length as a way to clear it) or is it more important to make the option value always have a fixed length (meaning that -1 is the only way to set if to "default"). I don't have a strong opinion either way. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
