> Some details:
>
> ..., CGA (cryptographically
> generated addresses) and non-CGA addresses etc..
>
> => you should note that CGAs are covered by some IPRs.
While I'm concerned about IPR and the IPR on CGA, I don't see
the benefit of cluttering every document and slide which contains
the string "CGA" with text about the IPR.
We seem to have been able to talk about RSA for a decade or more
without sprinkling text about IPR everywhere the string "RSA" appeared.
Is it a hard requirement from the WG that we do this?
> It is recommended that the application does a getsockopt() prior
>
> => this comes only from the uncommon style (one flag from Home,
> another one from Care-of, etc).
Point taken. Others have commented on this as well.
> The following flags are added for the ai_flags in addrinfo data
> structure defined in Basic IPv6 Socket API Extension [2].
>
> AI_PREFER_SRC_HOME
> AI_PREFER_SRC_COA
> AI_PREFER_SRC_TMP
> AI_PREFER_SRC_PUBLIC
> AI_PREFER_SRC_CGA
> AI_PREFER_SRC_NONCGA
>
> => why _SRC_ ?
To try to make it clearer that the application can't express this type
of preferences for the destination addresses.
> 5. IPv4-Mapped IPv6 Addresses
>
> IPv4-Mapped IPv6 addresses are not supported for setting preference
> on home, care-of-address, CGA, non-CGA, public or privacy auto-
> configured addresses as source addresses. Because they are all pure
> IPv6 addresses.
>
> => this is not true for home/care-of and this section is not useful.
Agreed.
> 6. Security Considerations
>
> It is also recommended that
> the applications set IPV6_V6ONLY IP level socket option to permit
> the nodes to not process IPv4 packets as IPv4 Mapped addresses.
>
> => I disagree about the implicit argument that IPv4 Mapped IPv6
> addresses are unsafe. And BTW this has nothing to do in this document.
Agreed.
> 7. Open Issues
>
> - Are there more flags we should define at this point in time?
> For instance, PREFER_LARGEST_SCOPE?
>
> => all "matter of taste" rules of address selection which cannot be
> controlled through the policy table should be covered here.
Do you have a list handy?
> - Is there a need for REQUIRE flags in addition to or instead of the
> PREFER flags?
>
> => yes, in some cases it is very important.
Any concerns about where and when the failures due to lack of
an address satisfying the REQUIREs?
> Note that in general it isn't possible to verify
> that a requirement can be satisfied until sendto() or connect()
> (when the destination address is known) thus this would result
> in late errors being reported to the application.
>
> => this is not really true because an application can use a connect()
> to verify the selected source but as I am against any changes in
> application I agree with the conclusion.
I don't understand what you are suggesting to change in the document
with respect to this.
Care to elaborate?
> - Is there a need for "validation" functions to go with these
> preferences such as functions that check whether an address is
> a temporary address?
>
> => it should be useful for some applications to have access to
> status of addresses.
Ack.
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]
--------------------------------------------------------------------
