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] --------------------------------------------------------------------
