>>>>> On Mon, 31 Oct 2005 10:29:04 -0800,
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> I'm afraid you misunderstood my point. (Perhaps the additional
>> question obscured the main point...) My main question is:
>>
>> In my understanding, if either of the flags of a particular rule is
>> off, it means the system default should be used for that rule. For
>> example, if 'flags = IPV6_PREFER_SRC_TMP', then the system default
>> will apply for HOME vs COA, CGA vs NONCGA, etc. Is that correct?
>> If so, when an application wants to make the rules revert to system
>> default, it should be able to call setsockopt without setting any
>> flag, shouldn't it? Or in other wise, it does not have to remember
>> the old rule values by calling getsockopt beforehand for this
>> purpose.
> No, it isn't "apply system default", it is "leave unchanged".
> Given that a socket starts with the system default, then subsequent
> setsockopts of IPV6_PREFERENCES can be used to tweak different
> preferences; one setsockopt can specify public vs. tmp preferences, and
> a different setsockopt can specify home vs. coa.
Ah, OK, then it makes sense. Unless I was missing something,
however, this point was not very clear. I've not read the 04 version
yet, but I hope this point is clarified there.
>> Yes, and this leads me to think we should rather define other variants
>> of IN6_IS_ADDR_xxx(). That is,
>>
>> in6_is_addr_home()
>> in6_is_addr_careof()
>> in6_is_addr_temporary()
>> in6_is_addr_cga()
> You mean that each of those would just take an struct sockaddr * as an
> argument?
> And return true/false?
Yes or no, depending on how we should return an error.
> What if the address in question isn't even assigned to the host i.e. the
> host can't determine whether it is of a particular category?
Actually, I wasn't thinking about that level of details, but it will
probably return some error.
But I think these questions equally apply to the inet6_is_srcaddr().
>> etc. Or, it's probably better not to adhere to recycling the
>> IPV6_PREFER_xxx "flags" for multiple purposes, and consider something
>> like this:
>>
>> int in6_getaddrattr(struct sockaddr_in6 *addr, uint32_t *attrp);
>>
>> On success, this function returns 0 and sets the "attributes" of the
>> address as bit-wise flags in '*attrp'. The flags are, for example,
>>
>> IN6_ADDRATTR_HOME
>> IN6_ADDRATTR_COA (not sure if we need this in addition to HOME
>> though)
>> IN6_ADDRATTR_TMP
>> IN6_ADDRATTR_CGA
> This seems like more work than definining a handful of specific
> in6_is_addr_*() functions.
> I'm not sure this generality is worth-while.
Frankly, I'm not sure either. This may be a matter of preference, and
so if no one else has a particular opinion, I don't insist on this
point as a blocking issue.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
