Thomas, I can't support this at my end. It should be left to configuration. All we can do is tell users the danger (which I believe is mostly perceived) forcing people to not use public addresses is very bad as a default. That was not what many of us bought into when the paranoid forced us to create 3041. Temp is there if you perceive a problem.
I don't support the current wording below. /jim > -----Original Message----- > From: Thomas Narten [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 11, 2002 12:19 PM > To: [EMAIL PROTECTED] > Subject: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt > > > The IESG has a number of comments on this document. Most of them are > of an editorial nature, and I'll let Rich summarize those in a > separate note. > > One issue was substantive and requires WG feedback. The -06 document > specifies that public addresses are to be preferred over temporary by > default. My recollection is that the WG originally had temporary > addresses being preferred, but more recently switched this under > concerns that there were cases where the use of temporary addresses > might harm an application. Thus, the conservative thing to do would be > to prefer public addresses but allow the application (via an API) to > reverse this preference. > > The IESG is concerned that if temporary addresses are not enabled by > default, they won't see widespread use in practice. This would > significantly decrease the overall impact that RFC 3041 will have on > reducing the threat it attempts to address. What the IESG would > prefer seeing is that temporary addresses be given preference by > default, but also include more guidance text in the document to make > it clear that there are cases where the use of temporary addresses by > default may not be appropriate. > > The following text has been proposed to address this issue: > > Proposed new wording: > > Rule 7: Prefer public addresses. > > If SA is a temporary address and SB is a public address, > then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > An implementation MUST support a per-connection configuration > mechanism (for example, an API extension) to reverse the sense of > this preference and prefer public addresses over public > addresses. > > In order for temporary addresses to have their desired effect, they > must become widely used in practice. The above rule is designed to > ensure widespread usage and enablement of temporary addresses. It > is believed that in many cases, temporary addresses can be used in > place of public addresses without problems. However, there are some > classes of applications that may fail due to the relatively short > lifetime of temporary addresses (compared with public addresses) or > due to the possibility of the reverse lookup of a temporary address > either failing or returning a randomized name. Implementations in > which it is believed that such applications exist MAY reverse the > sense of this rule and by default prefer public addresses over > temporary addresses. > > It should also be noted that a simple "prefer" or "don't prefer" > configuration switch with regards to the default selection of > temporary addresses is not sufficiently flexible in many cases. In > practice, it is expected that both client and server applications > will run on the same devices simultaneously. Client applications > will generally be able to use temporary addresses, while servers > will generally need to use public addresses. One possible heuristic > for distinguishing these cases is to assume that an application > that invokes a passive open (as its first network usage) is a > server, while an application that first invokes an active open be > assumed to be a client. > > (Note also, that the above text changes a "may" to MUST with regards > the need to provide a way for individual applications to change the > default via, e.g, a socket option) > > Is the above a reasonable way forward? (Individual responses, even if > they are along the lines of "fine with me" would be appreciated, as > this document is needed soon to meet a 3GPP deadline). > > Thomas > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
