Erik, On CGA. It is different now. We face mass deployment of required security worldwide and I hear it all the time now. CGA being a base for our addresses is far different scope of use than RSA mumbo-jumbo et al. The IPR is a real problem and I think a show stopper. There can be no vendor advantage over others with CGA if it is to become pervasive, and questionable for the IETF to pursue this to far without getting some type of resolution. The IETF could be setting a precedent and opening pandora's box and end up sitting in anti-trust problem. Go talk to your IETF ISOC council is my advise if you have not already. It is also not the same type of legal problem as using RSA as an entity.
I think labeling it often as IPR issue is prudent in our community. Including not using it because of the IPR. /jim >-----Original Message----- >From: Erik Nordmark [mailto:[EMAIL PROTECTED] >Sent: Friday, March 21, 2003 11:52 AM >To: Francis Dupont >Cc: Samita Chakrabarti; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: [mobile-ip] Draft on IPv6 source address >selection socket API > > >> 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] >-------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
