Subject: RE: IESG comments on draft-ietf-ipngwg-default-addr-select-06.txt

From: "Dave Thaler" <[email-masked]>
Date: Tue, 11 Jun 2002 10:49:17 -0700

> Proposed new wording:
> 
>    Rule 7: Prefer public addresses.
> 
>    If SA is a temporary address and SB is a public address, then
prefer
>    SA. 
[...]

The rest of the line after "Rule 7" doesn't match the rest of the text.
The rest of the new wording looks fine to me.

-Dave

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

---

From: [email-masked]
Date: Wed, 12 Jun 2002 17:06:15 -0400

On Wednesday, 06/12/2002 at 03:20 AST, [email-masked] wrote:
> I don't quite follow the logic here. Having the stack, by default,
> give preference to temporary over public addresses only means that
> they will be used without applications having explicitely asked for
> their use. For existing applications, that might cause
> surprise/problems in some cases.

Yes, but it is even worse than that.  The same application may run
perfectly fine on one host, but fail on another, if only some of
the hosts support temporary addresses.  And when upgrading an OS from
a level which doesn't support temporary addresses to one which does,
applications may suddenly begin to fail.  And there is absolutely
nothing a user can do to fix it, short of changing their OS to
one which does not support temporary addresses.  These are the types
of things which drive users, system programmers, and call centers crazy.
I know on the product on which I work, we wouldn't even begin to
consider making a change like this to our external behavior - our
customers simply wouldn't let us get away with it.

> Future applications, on the other hand, still need to be written, and
> one could argue they will need to make intelligent choices about
> whether the use of temporary addresses will cause problems, and code
> accordingly.

So, how exactly does the application know if temporary addresses will
cause problems?  Do they need to first try connecting using a temporary
address and, if this fails, try to connect using public address?  Do
they need to support configuration on a per-destination basis so some
poor end user can try to configure the application properly when trying
to access sites which require public addresses?  And will the typical
application programmer even know (s)he needs to include such logic when
converting their application from AF_INET sockets to AF_INET6 sockets?

If we know that applications need code to support temporary addresses
in order for them to work properly in certain cases, wouldn't it make
sense to have the application indicate it has the necessary support
before using them?

Roy

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:18:55 -0400

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-masked]]
> Sent: Tuesday, June 11, 2002 12:19 PM
> To: [email-masked]
> 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:
> 
>    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

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 15:23:30 -0400

Maybe...........
/jim

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 9:45 AM
> Cc: Thomas Narten
> Subject: Re: IESG comments on
> draft-ietf-ipngwg-default-addr-select-06.txt
> 
> 
> JINMEI Tatuya / 神明達哉 wrote:
> > 
> > >>>>> On Wed, 12 Jun 2002 10:38:24 -0400,
> > >>>>> Margaret Wasserman <[email-masked]> said:
> > 
> > >> The proposed text is trying to say that temporary 
> addresses are preferable
> > >> but that there might be issues (such as applications 
> having problems)
> > >> which consistitute a good enough reason to not follow 
> the default.
> > >> Thus there is significant freedom for implementors to 
> use their best
> > >> judgement based on their knowledge about the applications.
> > 
> > > Is it optional for a vendor to implement temporary 
> addresses?  Is it optional
> > > for a user to configure site-local addresses on a box (or 
> perhaps even for
> > > a vendor to support them)?
> > 
> > Good point...I thought in this context we assume vendors implement
> > temporary addresses and users configure temporary addresses by
> > default.  Otherwise, the original concern:
> > 
> >   "The IESG is concerned that if temporary addresses are 
> not enabled by
> >   default, they won't see widespread use in practice."
> > 
> > would not make sense.
> 
> But in fact that isn't a correct assumption. It's only a 
> certain class of
> systems (today's pure-client style PCs or their equivalents) 
> for which the
> privacy aspect of temporary addresses makes any sense. For 
> them, a SHOULD rule
> for preferring temporary addresses makes sense. But many 
> other hosts (servers
> and anything that wants to break out of the client/server 
> restriction) won't
> use temporary addresses and will use other privacy 
> mechanisms; so for them
> it's simply irrelevant. I think that is the answer to my 
> colleague Roy Brabson's
> objection to the proposed change - hosts that have the 
> problem he describes
> won't be using temporary addresses anyway. And anyone who 
> attempts to run server
> style apps on a host using temporary addresses will get all 
> kinds of trouble
> anyway.
> 
> But it should be a SHOULD.
> 
>    Brian
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> On assignment at the IBM Zurich Laboratory, Switzerland
> Board Chairman, Internet Society http://www.isoc.org
> INET 2002, Washington, DC, 18-21 June http://www.inet2002.org 
>   <<=== seats still available!
> 
> 
> > If, for example, the premise is implementing and 
> configuring temporary
> > addresses are both optional, I'll be just okay with the proposed
> > change.  Users (or administrators) who dare to configure temporary
> > addresses under such an environments should have a strong desire for
> > privacy.  So, even if the source address selection prefers public
> > address by default, such users will explicitly (try to) reverse the
> > logic for every communication.  This makes the default meaningless,
> > and thus preferring temporary address should make much sense.
> > (though the premise would be meaningless according to the original
> > motivation; widespread use of temporary addresses)
> > 
> >                                 X-Mozilla-Status: 0009
> >                                         Communication Platform Lab.
> >                                         Corporate R&D 
> Center, Toshiba Corp.
> >                                         [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 14 Jun 2002 09:13:02 -0400

Hi Alberto,

I understand but that is not a valid logic argument to cause us to break many things in our boxes that is coming out now.  I also think as Jinmei stated it is not a per application issue but per user issue.  That means it cannot be a default from my view.

/jim

> From: Alberto Escudero-Pascual [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 3:45 PM
> To: Bound, Jim
> Cc: Erik Nordmark; Keith Moore; Thomas Narten; 
> [email-masked]
> Subject: RE: IESG comments on
> Hi Jim!
> If only the users that have concerns about privacy will end 
> up using temp
> addresses (RFC3041) we will end up with a minority group of 
> techno-geeks
> or as you call us 'paranoids' highly observable and easy to 
> identify from
> the crowd.
> 
> I firmly beleive that RFC3041 should be the default option 
> and only the
> nodes that require a fixed address should enable that option. 
> 'Privacy'
> should  be the default option. I don't want to be sorrounded 
> by boxes with
> EUI-64 based addresses and be myself the only one running RFC3041.
> 
> /aep
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:05 -0400

Kieth,

IMO that should be a new API doc.  

/jim

> From: Keith Moore [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 6:34 PM
> To: Tony Hain
> Cc: Keith Moore; Alberto Escudero-Pascual; Bound, Jim; Erik Nordmark;
> Thomas Narten; [email-masked]
> > get off the soap box... IPv6 requires a new API, so there 
> is no valid
> > argument that we are not changing it. If you want to argue that we
> > should minimize the changes, I would agree.
> 
> believe it or not there are already lots of progams using the 
> v6 API...
> many of which were very slight modifications to v4 programs.
> 
> I'm happy that IESG has decided not to insist on temp addresses as
> the default and has backed the idea that there should be an API
> to request them.  Now, who's going to define the API extension? 
> 
> Keith
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:06 -0400

Itojun,

I am glad to here I am not the only one who has been embarassed.

This as I said to Keith should be new API doc if it is in fact needed.

/jim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 6:35 PM
> To: Tony Hain
> Cc: [email-masked]
> >get off the soap box... IPv6 requires a new API, so there is no valid
> 	no more changes, *please*.  we have spent more than 
> reasonable amount
> 	of years to settle down to RFC2553/bis.  and people are 
> now using it.
> 
> 	I would quote words from sendmail people - "first 
> gethostbyname2,
> 	then gethostbyname3, then getipnodebyname, then you want us to
> 	switch to getaddrinfo?  how can we know that it will be 
> the final one?"
> 	I was so embarrassed when i heard this.
> 
> itojun