Re: 3484bis and privacy addresses

Dave and Ray, thanks for putting together regarding these points. I'll compile these into the revision of DHCP option draft soon. Thanks ! On 2012/05/05, at 15:40, Ray Hunter wrote: > ACK. Thanks. > > Dave Thaler wrote: >> I wrote in response to Ray Hunter: >>> I take your comment as asking fo

Re: RE: 3484bis and privacy addresses

ACK. Thanks. Dave Thaler wrote: I wrote in response to Ray Hunter: I take your comment as asking for a summary table in rfc 3484bis of system-wide config options. That could be done as a purely editorial change, although if there's only 1 thing in the table it's less interesting. But if other

RE: 3484bis and privacy addresses

I wrote in response to Ray Hunter: > I take your comment as asking for a summary table in rfc 3484bis of > system-wide config options. That could be done as a purely editorial > change, although if there's only 1 thing in the table it's less interesting. > But if others in the WG think this would

RE: 3484bis and privacy addresses

> Forgive me if I read your reply wrongly, but you seem to point the blame for > there being an incomplete solution for remote management squarely at > draft-ietf-6man-addr-select-opt-03. No, I'm saying the issues you're raising are issues with draft-ietf-6man-addr-select-opt not rfc3484bis. > S

Re: 3484bis and privacy addresses

RFC 3484. -Dave Ray Hunter <mailto:v6...@globis.net> 13 April 2012 09:25 inline IMVHO [long answer] Dave Thaler <mailto:dtha...@microsoft.com> 11 April 2012 21:17 -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Wednesday, April 11, 2012 6:51 AM To: Dave Tha

RE: 3484bis and privacy addresses

Hi Ray, I appreciate the detailed response. Thanks. > 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. > > Sessions originated from a server on today's implementations e.g. >

Re: 3484bis and privacy addresses

inline IMVHO [long answer] Dave Thaler <mailto:dtha...@microsoft.com> 11 April 2012 21:17 -Original Message- From: Ray Hunter [mailto:v6...@globis.net] Sent: Wednesday, April 11, 2012 6:51 AM To: Dave Thaler Cc: Brian E Carpenter; ipv6@ietf.org Subject: Re: RE: 3484bis and p

RE: RE: 3484bis and privacy addresses

> -Original Message- > From: Ray Hunter [mailto:v6...@globis.net] > Sent: Wednesday, April 11, 2012 6:51 AM > To: Dave Thaler > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: RE: 3484bis and privacy addresses > > With all due respect to everyone concerned, th

Re: RE: 3484bis and privacy addresses

With all due respect to everyone concerned, there's no way an end user or IT department can buy a bunch of machines based on the text currently contained in this proposed Standard Track document and 1) be able to predict how each machine will behave by defaultin advance of actually plugging it

RE: 3484bis and privacy addresses

Brian Carpenter writes: > > The wording I propose to add is: > > > > "There SHOULD be an administrative option to change this preference, if > > the > > implementation supports privacy addresses. If there is no such option, > > there > > MUST be an administrative option to disable

Re: 3484bis and privacy addresses

below... On 2012-04-10 01:08, Dave Thaler wrote: > Brian Carpenter writes: >> On 2012-03-27 20:33, Brian Haberman wrote: >> ... >>> A. Prefer public addresses over privacy addresses >>> >>> B. Prefer privacy addresses over public addresses >> In terms of a general default in shipped IPv6 stacks, I

RE: 3484bis and privacy addresses

Brian Carpenter writes: > On 2012-03-27 20:33, Brian Haberman wrote: > ... > > > > A. Prefer public addresses over privacy addresses > > > > B. Prefer privacy addresses over public addresses > > In terms of a general default in shipped IPv6 stacks, I prefer B, but it has > to be qualified: > > T

Re: 3484bis and privacy addresses

Behalf Of *Ray Hunter *Sent:* Tuesday, March 27, 2012 10:30 PM *To:* Brian Haberman *Cc:* ipv6@ietf.org *Subject:* Re: 3484bis and privacy addresses From the corporate World: option A as default, with local user controlled option to override. RFC3484 (which references RFC3041) "Temporary

RE: 3484bis and privacy addresses

[mailto:ipv6-boun...@ietf.org] On Behalf Of Ray Hunter Sent: Tuesday, March 27, 2012 10:30 PM To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses >From the corporate World: option A as default, with local user controlled option to override. RFC3484 (which references RFC3

Re: 3484bis and privacy addresses

On Apr 3, 2012, at 10:44 , JINMEI Tatuya / 神明達哉 wrote: > At Mon, 2 Apr 2012 23:43:57 +, Dave Thaler wrote: >> >> I prefer B, and this is what most existing implementations of RFC 3484 seem >> to already do (i.e., they follow the MAY not the SHOULD) whenever privacy >> addresses are enabled

Re: 3484bis and privacy addresses

At Mon, 2 Apr 2012 23:43:57 +, Dave Thaler wrote: > I prefer B, and this is what most existing implementations of RFC 3484 seem > to already do (i.e., they follow the MAY not the SHOULD) whenever privacy > addresses are enabled. I have yet to hear of an implementation of RFC 3484 > that a

Re: 3484bis and privacy addresses

08, etc.) have them disabled by default, but can be enabled by an administrator. -Dave *From:* ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] *On Behalf Of *Ray Hunter *Sent:* Tuesday, March 27, 2012 10:00 AM *To:* Brian Haberman *Cc:* ipv6@ietf.org *Subject:* Re: 3484bis and privacy add

RE: 3484bis and privacy addresses

Behalf Of Ray Hunter Sent: Tuesday, March 27, 2012 10:00 AM To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses >From the corporate World: option A as default, with local user controlled >option to override. RFC3484 (which references RFC3041) "Temporary ad

Re: 3484bis and privacy addresses

On 03/30/2012 02:24 AM, Mark Andrews wrote: > In message <4f74f78f.1020...@dougbarton.us>, Doug Barton writes: >> >> Also, if you're on a home network, it doesn't matter what the bottom 64 >> bits are, your network prefix is enough information for the bad guys to >> use as ICBM targeting coordinate

Re: 3484bis and privacy addresses

In message <4f74f78f.1020...@dougbarton.us>, Doug Barton writes: > > Also, if you're on a home network, it doesn't matter what the bottom 64 > bits are, your network prefix is enough information for the bad guys to > use as ICBM targeting coordinates. And if we want to address home networks then

Re: 3484bis and privacy addresses

On 3/29/2012 6:13 AM, Alex Abrahams wrote: > I'm sorry, but while I agree we have to think outside > the corporate environment, I think we have to think way outside and we > need to remember the kind of reasons why privacy exists, before saying > the privacy extensions are only to keep a few hundre

Re: 3484bis and privacy addresses

I'm sorry, but while I agree we have to think outside the corporate environment, I think we have to think way outside and we need to remember the kind of reasons why privacy exists, before saying the privacy extensions are only to keep a few hundred people happy. To give just one example, homosexu

Re: 3484bis and privacy addresses

; Yup, we really need to start rolling out IPv6 and find out what works. Tom Petch - Original Message - From: "Ray Hunter" To: "Brian Haberman" Cc: Sent: Tuesday, March 27, 2012 7:00 PM Subject: Re: 3484bis and privacy addresses > From the corporate World: opt

Re: 3484bis and privacy addresses

On 3/27/2012 2:43 PM, Karl Auer wrote: > On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: >> IMHO the proper *default* behavior is still "off" = option A. In other >> words, default = IPv4-like behavior, at least until we really figure >> out how to operate all of these fancy new features of IP

Re: Re: 3484bis and privacy addresses

Draft RFC3484bis-01 currently references RFC4941 as a normative reference in Section 11.1: Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [RFC4941 ]. So I think we have to assume that a node will have suc

Re: 3484bis and privacy addresses

Hello, I vote for B. I think it makes sense for applications get privacy by default and applications that need the more persistent addresses will explicitly ask for one. Cheers, Jonne. -- Jonne Soininen Renesas Mobile Tel: +358 40 527 4634 E-mail: jonne.soini...@renesasmobile.com On 3/27

Re: 3484bis and privacy addresses

In your previous mail you wrote: > Also not sure if any DHCPv6 server implementations actually provide > DHCPv6 assigned temporary addresses in practice. => I coded this for the ISC DHCP some years ago so I am sure there is at least one. Regards francis.dup...@fdupont.fr ---

Re: 3484bis and privacy addresses

On Tue, Mar 27, 2012 at 9:33 AM, Brian Haberman wrote: > 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 > addr

Re: 3484bis and privacy addresses

On 2012-03-27 20:33, Brian Haberman wrote: ... > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses In terms of a general default in shipped IPv6 stacks, I prefer B, but it has to be qualified: There MUST be a user option to change this pre

RE: 3484bis and privacy addresses

On Tue, 2012-03-27 at 23:12 +, STARK, BARBARA H wrote: > 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. The applica

RE: 3484bis and privacy addresses

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 guida

Re: 3484bis and privacy addresses

On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: > IMHO the proper *default* behavior is still "off" = option A. In other > words, default = IPv4-like behavior, at least until we really figure > out how to operate all of these fancy new features of IPv6. The question is not whether the use of

Re: 3484bis and privacy addresses

> B. If an application wants to use the public address it will bind to it. > Applications that don't explicitly choose don't seem to care, and then > privacy addresses as default seems the best solution. > +1 IETF IPv6 working

Re: 3484bis and privacy addresses

Hi Brian, > 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 B. If an application wants to use the public address it will bind to it. Applications that don't expl

RE: 3484bis and privacy addresses

> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Karl Auer > > 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 > > B. >

Re: 3484bis and privacy addresses

I happen to like your draft. But even in the presence of a mechanism to distribute an advisory address-generation policy (which may or may not not be supported by all end-node implementations for another 10 years) IMHO the proper *default* behavior is still "off" = option A. In other words, def

Re: 3484bis and privacy addresses

On 03/27/2012 07:00 PM, Ray Hunter wrote: > My take on this is that a set of a few hundred individual persons who > are worried about privacy are more likely to be able to control their > own particular machines to correctly override the "default off" setting > than a single corporate network manag

Re: 3484bis and privacy addresses

From the corporate World: option A as default, with local user controlled option to override. RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fault finding, audit, logging, firewall rules, filtering, QoS matching, conformance: anywhere where an ACL or stable address is

Re: 3484bis and privacy addresses

On 03/27/2012 09:33 AM, Brian Haberman wrote: > 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 Having to choose between these two, I'd go with B. Thanks, -

Re: 3484bis and privacy addresses

On 3/27/12 8:43 AM, Fernando Gont wrote: On 03/27/2012 09:33 AM, Brian Haberman wrote: 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. B

Re: 3484bis and privacy addresses

Hi, all To me, the option "A. Prefer public addresses over privacy addresses". Cheers. On Tue, Mar 27, 2012 at 3:27 PM, Fernando Gont wrote: > On 03/27/2012 12:40 PM, Karl Auer wrote: > > While I realise that the Argument From Personal Ignorance is not very > > convincing, I am having a very ha

Re: 3484bis and privacy addresses

On 03/27/2012 12:40 PM, Karl Auer wrote: > While I realise that the Argument From Personal Ignorance is not very > convincing, I am having a very hard time imagining why anyone would turn > on privacy addresses, then prefer non-privacy addresses... They don't. Some operating systems enable them by

Re: 3484bis and privacy addresses

In your previous mail you wrote: > Brian: Terminology issue here: Are "public addresses" a short hand for > "IPv6 addresses with Modified EUI-64 format identifiers"? -- I ask > because all of these addresses are public. => IMHO public is not RFC 4941 "private". The draft is clearer... Regard

Re: 3484bis and privacy addresses

On 03/27/2012 09:33 AM, Brian Haberman wrote: > 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. Brian: Terminology issue here: Are "pub

Re: 3484bis and privacy addresses

On Tue, 2012-03-27 at 03:33 -0400, Brian Haberman wrote: > 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 B. While I realise that the Argument From Perso

Re: 3484bis and privacy addresses

On Tue, 2012-03-27 at 03:33 -0400, Brian Haberman wrote: > 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 B. While I realise that the Argument From Perso

RE: 3484bis and privacy addresses

2012 10:15 To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses In your previous mail you wrote: > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses => I voted A but I have no strong opinion (I think

Re: 3484bis and privacy addresses

B for me. Sent from my iPad On Mar 27, 2012, at 10:44 AM, "Simon Perreault" wrote: > Brian Haberman wrote, on 03/27/2012 09:33 AM: >> A. Prefer public addresses over privacy addresses >> >> B. Prefer privacy addresses over public addresses > > I prefer B. > > I don't buy the "HTTP cookies a

Re: 3484bis and privacy addresses

I also prefer B. I haven't decided if I'll use privacy addresses myself, but I think: a) I don't want to assume the working life of cookies and even http is the same as ipv6, don't want it to drive this decision (I'm not advocating a return to gopher ;) ) b) I'd like IP logs to be just that, somet

Re: 3484bis and privacy addresses

Brian Haberman wrote, on 03/27/2012 09:33 AM: > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses I prefer B. I don't buy the "HTTP cookies already give us away" argument. Privacy at all levels of the stack is good. (I randomize my L2 MAC at

RE: 3484bis and privacy addresses

I prefer A. (public address is to be preferred) Whatever the final choice will be, I would like 3484bis to allow the policy setting to be reversed. BTW, my choice is based on: - privacy is anyway given away with cookies, HTTP headers such as User-Agent string - stable address is key for audit-tra

RE: 3484bis and privacy addresses

Option A (with ability to configure privacy as preferred). -Samita -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, March 27, 2012 12:34 AM To: ipv6@ietf.org Subject: 3484bis and privacy addresses All, The c

Re: 3484bis and privacy addresses

Hi, On 27.03.2012 09:33, Brian Haberman wrote: 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 I prefer option B. Regards, Roland

Re: 3484bis and privacy addresses

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

Re: 3484bis and privacy addresses

Dear All, option B prefered with RFC 4941 section 3.6 properly implemented as: " Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. Additionally, sites might wish to selectively enable or disa

Re: 3484bis and privacy addresses

: Jordi Palet Martinez Asunto: Re: 3484bis and privacy addresses >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 t

Re: 3484bis and privacy addresses

In your previous mail you wrote: > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses => I voted A but I have no strong opinion (I think the privacy addresses is a silly response to a silly concern. BTW as using the Free ISP 6rd I get a fi

Re: 3484bis and privacy addresses

Hi, I prefer B for reasons of avoiding privacy issues arising from using HW-based identifiers. Best regards, Teemu 27. maaliskuuta 2012 9.33 Brian Haberman kirjoitti: > All, > The chairs would like to get a sense of the working group on changing > the current (defined 3484) model of prefer

Re: 3484bis and privacy addresses

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,

Re: 3484bis and privacy addresses

Support option B. -Raj On 3/27/12 9:33 AM, "ext Brian Haberman" wrote: >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 >pr

Re: 3484bis and privacy addresses

Hi, if an co-author has a right to vote :) I like B. If privacy address is attached, then it should mean it should be preferred. On 2012/03/27, at 16:33, Brian Haberman wrote: > All, > The chairs would like to get a sense of the working group on changing the > current (defined 3484) model

Re: 3484bis and privacy addresses

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 alrea