> ==> perhaps validation functions would be nice, but generally speaking, it
> is not possible to, for certainty, to ensure what an address is or isn't?
In some cases yes, but there are some issues related e.g. to the late binding
of source addresses for e.g. UDP.
For instance, if you specify PREFER_SRC_TMP with the semantics of it being
a requirement (i.e. REQUIRE_SRC_TMP) then getaddrinfo() might succeed,
the setsockopt might succeed, yet when you go to send a UDP packet
then sendto() would have to fail because there is no more a temporary source
address available for the destination to which you are trying to send.
When using TCP then the failure would appear at the time of connect which
is better, but it might still be hard to react reasonably to such failures.
The validation allows doing a getsockname() after connect() to see what
address the socket ended up with, which allows for "softer" error handling.
Thus I don't think we can do only hard requirements but that we also need
to be able to express preferences. And preferences + validation seems to be
able to solve what you can do with preferences + requirements.
> ==> Please clarify whether you meant a macro like "IN6_IS_ADDR_LOOPBACK" or
> something "verify whether this address assigned on the node was of type
> X"?
Given that there is an extensible set of flags it might make more sense to
define the validation as a function which take the flags as arguments
e.g.
inet6_is_addr(struct in6_addr *, uint32_t flags)
where the flags contain the SRC_PREFER flag set.
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]
--------------------------------------------------------------------
