I would like to see B; which would reflect common practice in the -bis RFC, but allow the default to be changed.
Nothing precludes a host using privacy addresses also having a static/DNS registered address it's reachable by, but as Tassos says that's not the topic for the vote. Tim On 27 Mar 2012, at 09:09, Tassos Chatzithomaoglou wrote: > Maybe i have misunderstood something, but how does DNS interfere with source > address selection? > > I would go with option A. > I would even prefer to limit even more the usage of temporary addresses, but > that's another talk. > > -- > Tassos > > > On 27/3/2012 9:41 πμ, JORDI PALET MARTINEZ wrote: >> Hi Brian, >> >> I think by default privacy addresses (option B) should be selected. >> >> It is up to applications that require "stable" addresses to force the >> other way around, and a quick guess is that this kind of applications >> already do it by means of selecting a DNS name that should typically have >> already a global stable address. >> >> Regards, >> Jordi >> >> >> >> >> >> >> -----Mensaje original----- >> De: Brian Haberman<[email protected]> >> Responder a:<[email protected]> >> Fecha: Tue, 27 Mar 2012 03:33:48 -0400 >> Para:<[email protected]> >> Asunto: 3484bis and privacy addresses >> >>> All, >>> The chairs would like to get a sense of the working group on >>> changing the current (defined 3484) model of preferring public addresses >>> over privacy addresses during the address selection process. RFC 3484 >>> prefers public addresses with the ability (MAY) of an implementation to >>> reverse the preference. The suggestion has been made to reverse that >>> preference in 3484bis (prefer privacy addresses over public ones). >>> Regardless, the document will allow implementers/users to reverse the >>> default preference. >>> >>> Please state your preference for one of the following default >>> options : >>> >>> A. Prefer public addresses over privacy addresses >>> >>> B. Prefer privacy addresses over public addresses >>> >>> Regards, >>> Brian, Bob,& Ole >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
