IETF Logo Mail Archive

RE: 3484bis and privacy addresses

"STARK, BARBARA H" <bs7652@att.com> Tue, 27 March 2012 23:12 UTC

Return-Path: <bs7652@att.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C921E8024 for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 16:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.363
X-Spam-Level:
X-Spam-Status: No, score=-104.363 tagged_above=-999 required=5 tests=[AWL=-1.764, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoUWEnfi+r4c for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 16:12:37 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1021E800C for <ipv6@ietf.org>; Tue, 27 Mar 2012 16:12:36 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 269427f4.0.921387.00-266.2575014.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Tue, 27 Mar 2012 23:12:37 +0000 (UTC)
X-MXL-Hash: 4f7249650391d845-2a68fbd045dd68bdb330d3723e7b46deb4d61efa
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2RNCYvu007926 for <ipv6@ietf.org>; Tue, 27 Mar 2012 19:12:34 -0400
Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2RNCTeZ007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipv6@ietf.org>; Tue, 27 Mar 2012 19:12:29 -0400
Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor) for <ipv6@ietf.org>; Tue, 27 Mar 2012 19:12:06 -0400
Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.156]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 19:12:05 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: 3484bis and privacy addresses
Thread-Topic: 3484bis and privacy addresses
Thread-Index: AQHNC+v+2U4M41ZD9E+yTBxtVxQMXJZ+oVWAgAAL1ICAABc6gIAALB6A///Pe+A=
Date: Tue, 27 Mar 2012 23:12:04 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com>
References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl>
In-Reply-To: <1332884609.2633.22.camel@karl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.181.125]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=1.0 c=1 a=-zmdt4OLJFcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo]
X-AnalysisOut: [wA:10 a=IkcTkHD0fZMA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=vF]
X-AnalysisOut: [e4QFSVHcmGuUoLv0EA:9 a=sUXQSeghq9yqauk1UVgA:7 a=QEXdDO2ut3]
X-AnalysisOut: [YA:10 a=PWP-GHiY0KrSVWbz:21 a=b8Ss305SxOfTd1gq:21]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 23:12:38 -0000

I think the rules for which (temporary vs not temporary) to use should be application-specific. And the people who are best-positioned to determine what's right for the app are the app developers or designers. Not IETF.

I vote for 3484bis to remain silent as to a preference, but to provide guidance as to what might cause an app to select one address over the other.

Apps that aren't designed for Internet access (e.g., UPnP, enterprise applications to run on corporate devices inside the corporate network) have no need for temporary addresses, and may find that they cause a bad user experience. Apps that register their presence with a server (like a SIP registration server) are ill-served by temporary addresses. Apps that need to be able to receive unsolicited traffic shouldn't use temporary addresses. On the other hand, I think I'd prefer if my web browser did use a temporary address, if that feature were enabled on my device.
Barbara

v2.46.0 | Report a Bug | By Email | System Status