Some details:
..., CGA (cryptographically
generated addresses) and non-CGA addresses etc..
=> you should note that CGAs are covered by some IPRs.
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).
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_ ?
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.
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.
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.
- Is there a need for REQUIRE flags in addition to or instead of the
PREFER flags?
=> yes, in some cases it is very important.
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.
- 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.
Thanks
[EMAIL PROTECTED]
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 7]
INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
8. References
Normative references:
[1] Richard Draves, "Default Address Selection for IPv6",
draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002.
[2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens,
"Basic Socket Interface Extensions for IPv6",
draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002.
Informative references:
[3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-20.txt, January, 2003.
[4] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, Dec. 1998.
[5] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced
Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt
April 19, 2002.
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses.",
NDSS 2002, February 2002.
[8] Castelluccia, C. and G. Montenegro, "Securing Group Management
in IPv6 with Cryptographically Generated Addresses",
draft-irtf-gsec-sgmv6-01 (work in progress), July 2002.
9. Acknowledgements
The authors like to thank members of mobile-ip and ipv6 working
groups for useful discussion on this topic. Richard Draves and
Dave Thaler suggested that getaddrinfo also needs to be considered
along with the new socket option. Gabriel Montenegro suggested that
CGAs may also be considered in this document. Thanks to Alain Durand,
Renee Danson, Alper Yegin and Francis Dupont for useful discussions.
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 8]
INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003
10. Authors' Addresses
Erik Nordmark
Sun Microsystems Laboratories, Europe
180 Avenue de l'Europe
38334 Saint Ismier, France
Email: [EMAIL PROTECTED]
Samita Chakrabarti
Sun Microsystems, Inc.
4150 Network Circle
Santa Clara, CA 95054, USA
Email: [EMAIL PROTECTED]
Julien Laganier
Sun Microsystems Laboratories, Europe
180 Avenue de l'Europe
38334 Saint Ismier, France
Email: [EMAIL PROTECTED]
draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 9]
--Clutter_of_Cats_249_000--
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
