Overall comment:
1. The draft talks about setting flag X and flag not-X, but the only
place I see where this can happen is trying to set these together:
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
AI_PREFER_SRC_CGA | AI_PREFER_SRC_NONCGA
Am I missing something? Can I somehow turn-off the use of Care-of
Addresses as source addresses? Maybe it's implied that if I don't set
the flag in the setsockopt()/getaddrinfo() call that it turns-off using
that type of source address?
------------------------------------------------------------------------
The combination of flag X and not-X is not allowed - only one should be
set at one time, becuase one packet has one source address.
After talking to Vlad I now understand this, you're saying these are
invalid flags to set together:
HOME | COA
TMP | PUBLIC
CGA | NONCGA
LARGE | SMALL
From a C-code perspective, flag X and not-X would mean:
HOME & ~HOME
So I don't like the X/not-X text, I like the wording of "conflicting
flags" much better as used in a few other places. Maybe if the end of
Section 4 could say this:
Setting conflicting flags at the same time results in the error
EINVAL. For example, invalid combinations of flags are:
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
IPV6_PREFER_SRC_LARGESCOPE | IPV6_PREFER_SRC_SMALLSCOPE
If flags are set as a combination of 'X' and 'Y', and if 'Y'
is not applicable or available in the system, then the selected
address has attribute 'X' and system default for the attribute 'Y'.
For example, a possible valid combination of flags can be:
IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE
There are other places that would need updating too.
The default flags are described in section 7. For example, by default
*_SRC_HOME is the choice of flag, ( it means COA address is not used
by default as source address), but one can change that by using setsockopt()
with *_SRC_COA.
The default is to follow RFC 3484, right? :)
IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that
can be used on an AF_INET6 socket, are supported in this API. In
some cases the IPv4-mapped addresses may not make much sense because
the attributes are IPv6 specific. For example, IPv6 temporary
addresses are not the same as private IPv4 addresses. However, the
IPv4 mapped-address support may be useful for mobile home address and
care-of-address. At this point it is not understood whether this API
has any value to IPv4 addresses or AF_INET family of sockets.
The second to last sentence here is confusing (regarding mobile), can
you explain what you meant?
It was discussed in the ipv6 list sometimes ago that IPV4-mapped IPv6
addresses may be useful for home-address and COA for IPv4
and IPV6 interoperability. It is not well understood, but I think it
is possible that a MIPv4 compliant dual-stack node may want to comunicate with a
IPv6 address.
Ok, then can this sentence be changed to give that information:
"However, the IPv4 mapped-address support may be useful for mobile home
address and care-of-address."
Thanks,
-Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
