I have list of intended edits based on the bulk of your comments. Here
are some comments on the non-trivial parts.
JINMEI Tatuya / 神明達哉 wrote:
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.
Maybe we can simply say the sending host cannot *always* detect
whether the destination is reached via tunnel. Additional explanation
you mentioned above may also help, but I don't have a particular
opinion on how much of the details we should provide here.
ok
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?
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?
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.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
