Subject: 3484bis and privacy addresses

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Mar 2012 03:33:48 -0400

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 addresses with the ability (MAY) of an implementation to 
reverse the preference.  The suggestion has been made to reverse that 
preference in 3484bis (prefer privacy addresses over public ones). 
Regardless, the document will allow implementers/users to reverse the 
default preference.

      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

Regards,
Brian, Bob, & Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Mar 2012 09:41:37 +0200

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
already a global stable address.

Regards,
Jordi

-----Mensaje original-----
De: Brian Haberman <[email-masked]>
Responder a: <[email-masked]>
Fecha: Tue, 27 Mar 2012 03:33:48 -0400
Para: <[email-masked]>
Asunto: 3484bis and privacy addresses

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 27 Mar 2012 16:46:11 +0900

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 of preferring public addresses over privacy addresses during the address selection process.  RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference.  The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference.
> 
>     Please state your preference for one of the following default options :
>

---

From: <[email-masked]>
Date: Tue, 27 Mar 2012 08:02:57 +0000

Support option B.

-Raj

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 27 Mar 2012 10:09:16 +0200

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:
> De: Brian Haberman<[email-masked]>
> Responder a:<[email-masked]>
> Para:<[email-masked]>
>> Brian, Bob,&  Ole

---

From: Teemu Savolainen <[email-masked]>
Date: Tue, 27 Mar 2012 10:13:16 +0200

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 <[email-masked]>kirjoitti:

> 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 addresses with the ability (MAY) of an implementation to reverse the
> preference.  The suggestion has been made to reverse that preference in
> 3484bis (prefer privacy addresses over public ones). Regardless, the
> document will allow implementers/users to reverse the default preference.
>
> ------------------------------**------------------------------**--------
> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> ------------------------------**------------------------------**--------
>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 10:15:01 +0200

>  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 fixed /64 prefix with my fixed IPv4
address embedded in it, so privacy addresses can only bring trouble
to me :-).

My question is different and more for you as an IAB member: is this
a chance to get the address selection document (currently RFC 3484)
downgraded as a BCP (from its current standard track) so it will
take less years to be updated the next time?

Note it was known from beginning the RFC 3484 should have never been
in the standard track, and it was obsolete as soon as being published...

Thanks

[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Mar 2012 10:15:14 +0200

That was my point, just to make sure that it is not misunderstood, I added
the DNS comment as my expectation for apps requiring stable public
addresses.

Regards,
Jordi

-----Mensaje original-----
De: Tassos Chatzithomaoglou <[email-masked]>
Responder a: <[email-masked]>
Fecha: Tue, 27 Mar 2012 10:09:16 +0200
Para: <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>
Asunto: Re: 3484bis and privacy addresses

>> This electronic message contains information which may be privileged or
>>confidential. The information is intended to be for the use of the
>>individual(s) named above. If you are not the intended recipient be
>>aware that any disclosure, copying, distribution or use of the contents
>>of this information, including attached files, is prohibited.
>>
>>
>>

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 27 Mar 2012 10:17:24 +0200 (CEST)

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 disable the
    use of temporary addresses for some prefixes.
....
    implementations SHOULD provide a way to enable and disable generation
    of temporary addresses for specific prefix subranges.  This per-
    prefix setting SHOULD override the global settings on the node with
    respect to the specified prefix subranges.  Note that the pre-prefix
    setting can be applied at any granularity, and not necessarily on a
    per-subnet basis.
"

Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Tue, 27 Mar 2012, Brian Haberman wrote:

> the current (defined 3484) model of preferring public addresses over privacy 
> addresses during the address selection process.  RFC 3484 prefers public 
> addresses with the ability (MAY) of an implementation to reverse the 
> 3484bis (prefer privacy addresses over public ones). Regardless, the document 
> will allow implementers/users to reverse the default preference.
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 Mar 2012 09:17:32 +0100

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 2012, at 09:09, Tassos Chatzithomaoglou wrote:

> Maybe i have misunderstood something, but how does DNS interfere with source address selection?
> 
> I would even prefer to limit even more the usage of temporary addresses, but that's another talk.
> 
> --
> Tassos
> 
>

---

From: Roland Bless <[email-masked]>
Date: Tue, 27 Mar 2012 10:29:03 +0200

Hi,

> B. Prefer privacy addresses over public addresses

I prefer option B.

Regards,
  Roland

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 27 Mar 2012 04:34:42 -0400

Option A (with ability to configure privacy as preferred).

-Samita 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, March 27, 2012 12:34 AM
To: [email-masked]
Subject: 3484bis and privacy addresses

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 addresses with the ability (MAY) of an implementation to reverse the preference.  The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). 
Regardless, the document will allow implementers/users to reverse the default preference.

Regards,
Brian, Bob, & Ole

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 27 Mar 2012 10:37:45 +0200

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-trail (so Fernando's proposal is
useful here)

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brian Haberman
> Sent: mardi 27 mars 2012 09:34
> To: [email-masked]
changing
> the current (defined 3484) model of preferring public addresses over
privacy
> 3484bis (prefer privacy addresses over public ones).
options
> :

---

From: Simon Perreault <[email-masked]>
Date: Tue, 27 Mar 2012 10:44:03 +0200

> 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 boot time, lots of fun!)
If we have good privacy at L3, then we "only" have L7 left to fix.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alex Abrahams <[email-masked]>
Date: Tue, 27 Mar 2012 05:28:58 -0400

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, something to be looked after, but not
something I have law after law to think about, changing country to country,
because .gov think I am tracking people. (e.g. You can't log IPs centrally
because that is personal data, which can't leave the country) I'm not
saying tracking people is good or bad (not going there), just that I want
to be free of that kind of oversight as much as possible.

Alex

---

From: Tina TSOU <[email-masked]>
Date: Tue, 27 Mar 2012 09:27:35 +0000

B for me.

Sent from my iPad

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 27 Mar 2012 10:48:25 +0200

+1 for option A

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: dinsdag 27 maart 2012 10:15
To: Brian Haberman
Cc: [email-masked]
Subject: Re: 3484bis and 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 fixed /64 prefix with my fixed IPv4 address embedded in it, so privacy addresses can only bring trouble to me :-).

My question is different and more for you as an IAB member: is this a chance to get the address selection document (currently RFC 3484) downgraded as a BCP (from its current standard track) so it will take less years to be updated the next time?

Note it was known from beginning the RFC 3484 should have never been in the standard track, and it was obsolete as soon as being published...

Thanks

---

From: Karl Auer <[email-masked]>
Date: Tue, 27 Mar 2012 21:23:10 +1100

> B. Prefer privacy addresses over public addresses

B.

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

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: Karl Auer <[email-masked]>
Date: Tue, 27 Mar 2012 21:23:10 +1100

B.

Regards, K.

---

From: Karl Auer <[email-masked]>
Date: Tue, 27 Mar 2012 21:40:49 +1100

B.

Regards, K.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 14:43:14 +0200

On 03/27/2012 09:33 AM, Brian Haberman wrote:
> over privacy addresses during the address selection process.

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.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 14:48:13 +0200

>  because all of these addresses are public.

=> IMHO public is not RFC 4941 "private". The draft is clearer...

Regards

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 15:27:44 +0200

> on privacy addresses, then prefer non-privacy addresses...

They don't. Some operating systems enable them by default.

Thanks,

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 27 Mar 2012 16:16:45 +0200

Hi, all

To me, the option "A. Prefer public addresses over privacy addresses".

Cheers.

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Mar 2012 11:20:11 -0400

> because all of these addresses are public.

Based on the terminology in 3484 and 3484bis, I am asking for the WG's 
view of preferring public over temporary (rather than private) addresses 
as defined in RFC 4941.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 18:30:24 +0200

> B. Prefer privacy addresses over public addresses

Having to choose between these two, I'd go with B.

Thanks,

---

From: Ray Hunter <[email-masked]>
Date: Tue, 27 Mar 2012 19:00:07 +0200

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 used today. Sure 
we shouldn't use fixed/stable IP literals, but we do. And in many cases 
there aren't any practical alternatives in today's products, so the IP 
address is the lowest common denominator used to identify a machine (and 
dare I say even "a user" in some circumstances).

Also not sure if any DHCPv6 server implementations actually provide 
DHCPv6 assigned temporary addresses in practice.

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 manager is to be able to guarantee 
overriding a "default on" setting on 100% of 10000 machines attached to 
their network.

regards,
RayH

Brian Haberman wrote:
> <div class="moz-text-flowed">All,
> changing the current (defined 3484) model of preferring public 
> addresses over privacy addresses during the address selection 
> process.  RFC 3484 prefers public addresses with the ability (MAY) of 
> an implementation to reverse the preference.  The suggestion has been 
> made to reverse that preference in 3484bis (prefer privacy addresses 
> over public ones). Regardless, the document will allow 
> implementers/users to reverse the default preference.
>
> </div> 

-- 
Ray Hunter
[email-masked]
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 19:42:27 +0200

> overriding a "default on" setting on 100% of 10000 machines attached to

Well, that's because we should probably do something like this:
<http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>

While I understand the "procedural constraints" (i.e., document in
WGLC), I think that much of the discussion that we're having is because
we have limited choices in a number of areas. Namely:

1) Inability to convey address-generation policy in RA messages.
2) Stable privacy-enhanced addresses

So we worry about selecting the right default because:

1) We have no mechanism to change that default dynamically
2) If we were to use stable addresses, in msot cases that implies
"privacy-harmful" addresses.

Thanks,

---

From: Ray Hunter <[email-masked]>
Date: Tue, 27 Mar 2012 21:05:35 +0200

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, default = IPv4-like behavior, at least until we really figure out 
how to operate all of these fancy new features of IPv6.

regards,
RayH

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 27 Mar 2012 14:07:51 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Karl Auer

> on privacy addresses, then prefer non-privacy addresses...

+1.

I am generally in favor of using public addresses always, but I have to agree with Karl's point. Maybe this logic should be stated explicitly in a 3484bis.

Bert

---

From: Sander Steffann <[email-masked]>
Date: Wed, 28 Mar 2012 00:02:09 +0400

Hi Brian,

> 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 explicitly choose don't seem to care, and then privacy addresses as default seems the best solution.

- Sander

---

From: Dominik Elsbroek <[email-masked]>
Date: Tue, 27 Mar 2012 22:22:21 +0200

> 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

---

From: Karl Auer <[email-masked]>
Date: Wed, 28 Mar 2012 08:43:29 +1100

On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote:
> 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 privacy addresses (temporary
addresses) should be enabled by default. Though some OSes do that, I
believe.

The question is, where a host *does* have both a temporary and a
non-temporary addresses, which one it should prefer by default. "Prefer
by default" in this case means "select as the source address for new
outbound connections in the absence of specific instructions to do
otherwise".

Regards, K.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 27 Mar 2012 23:12:04 +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

---

From: Karl Auer <[email-masked]>
Date: Wed, 28 Mar 2012 10:26:32 +1100

On Tue, 2012-03-27 at 23:12 +0000, 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 application always has that control anyway. The very first source
address selection rule is "use the source address the application
specifies". The other source address selection rules apply only if the
application does not specify a source address.

> I vote for 3484bis to remain silent as to a preference,

Leaving the source address preference unspecified won't change anything
for applications, but will lead to some implementations preferring
privacy addresses and some implementations preferring non-privacy
addresses. In general, standards should be deterministic - given the
same circumstances, all implementations should behave the same way.
Hence the need for a default position.

Regards, K.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2012 14:42:54 +1300

On 2012-03-27 20:33, Brian Haberman wrote:
...
> 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 preference.

There SHOULD be a network manager option to change this preference.

The rationale for this is that we need privacy by default in shipped
products, with the ability for the person deploying the product to
override this.

    Brian C

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 28 Mar 2012 08:43:41 +0200

> B. Prefer privacy addresses over public addresses

If it also is stated that there _should_ be an options to override it
either by policy (Enterprise/Corp) or by manual (typical end-user),
then I would say options B over A.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 28 Mar 2012 09:04:08 +0200

>  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

---

From: <[email-masked]>
Date: Wed, 28 Mar 2012 08:52:45 +0000

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: [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Wed, 28 Mar 2012 11:14:30 +0200

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  <http://77.72.230.30/html/rfc4941>].
So I think we have to assume that a node will have such addresses 
present by default when considering RFC3484bis.

I could completely agree with your logic if RFC3484bis did not have 
RFC4941 as a normative reference, or if 3484bis was coupled with 
draft-gont-6man-managing-slaac-policy-00, or 
draft-ietf-6man-addr-select-opt-03 was already deployed in the field,  
or the M&O bits of RA were defined to force use of DHCPv6, or there was 
a common proprietary cross-OS mechanism available or indeed anything 
else that would allow a network manager to reliably control use of 
temporary addresses. But there isn't AFAIK. Unless you also 
intentionally break SLAAC.

So IMHO, in the absence of any other reliable OFF switch, RFC3484-bis 
itself currently really is the only place where a reliable default "OFF" 
can be specified at this time. I don't mind how this is achieved: either 
in the preference rules themselves, or in other clarification text that 
describes safe default backwards-compatible end-node behavior that will 
not break other systems that currently rely on IPv4-like behavior.

regards,
RayH

---

From: Doug Barton <[email-masked]>
Date: Wed, 28 Mar 2012 23:42:50 -0700

> outbound connections in the absence of specific instructions to do

Thanks for clarifying this Karl, I thought I was confused about the
question when I saw the answers that people were giving. :)

FWIW, my personal preference is for 4941 addresses *both* on by default,
*and* chosen first by default. But I definitely think that if 4941
addresses are enabled, they should be used by default. (So, my answer to
Brian H's question is B.)

Longer, but hopefully useful answer from an implementor ... Some time
ago I looked at changing the default for both on FreeBSD to "On" with
the thinking that if it's good enough for Uncle Bill, it's good enough
for us. (Well, really with the thinking that it would be the right thing
to do, help protect FreeBSD users' privacy, etc.) I even floated a
trial-balloon about making the change, and got generally positive
responses. Eventually I lost interest because of a non-zero number of
replies to the effect that "The RFC says use should be off by default,
so we shouldn't enable it by default." Given that I only have so much
time to push so many rocks up so many hills, I took a different approach.

Rather than enabling it by default, I made it much easier to enable at
all by adding a knob to the default rc.conf file:

ipv6_privacy="NO" # Use privacy address on RA-receiving IFs (RFC 4941)

When implementing the guts to make that knob effective I turned on both
the sysctls to create the addresses, and to prefer them, without giving
users a knob to turn off the latter. That was 2 years ago in HEAD (our
bleeding edge development branch) and no one has ever complained. That
knob shipped in our 9.0-RELEASE (January 2012).

Regarding the topic of privacy generally, I agree with the sentiments
that just because we're losing the war doesn't mean that we shouldn't
fight the battles that we can. However, if you want to get really
depressed about browser privacy, take a look at these 2 sites. The first
one is sort of scary, the second one should really terrify you:

http://www.b2knet.com/
https://panopticlick.eff.org/

Regarding the second one, I am ULTRA paranoid about my browser privacy
... I have numerous firefox plugins to enhance it, including cookies off
by default and selectively enabled with CookieMonster, super-tight
whitelist settings for RequestPolicy, BetterPrivacy, wipe out everything
when the browser exits, etc. And I still get the result that my
fingerprint is unique (out of over 2 million users).

and so it goes,

Doug

---

From: "t.petch" <[email-masked]>
Date: Thu, 29 Mar 2012 12:03:21 +0200

A categorically.

I think that Ray summarises the arguments well below.  I only disagree with him
in that I see the arguments applying outside the corporate world as well.

I think too that Ray is spot on with a later post about
"how to operate all of these fancy new features of IPv6."

Yup, we really need to start rolling out IPv6 and find out what works.

Tom Petch

----- Original Message -----
From: "Ray Hunter" <[email-masked]>
To: "Brian Haberman" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 27, 2012 7:00 PM
Subject: Re: 3484bis and privacy addresses

> > B. Prefer privacy addresses over public addresses

--------------------------------------------------------------------------------

---

From: Alex Abrahams <[email-masked]>
Date: Thu, 29 Mar 2012 14:13:03 +0100

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, homosexuality still carries the death penalty in
9 countries. While I know there are other ways of tracking people online,
I'd really prefer it if we didn't make it too easy for someone enforcing
those laws to see who had used their pay-as-you-go smart phone to visit
websites where guys would like to meet other guys, then a day later renewed
their state car tax/insurance with the same phone.

So while I agree from a technical stand point a network will be much easier
to run if addresses are static, I think that not everyone that requires
privacy have technically knowledge to understand the difference or make the
change.

My take is, if available, default to using the privacy address extensions,
with corporations using group policy, or other tools to change as needed. I
also think OS implementations SHOULD inform the user when a change from the
privacy extensions has been enforced on the network.

Alex

---

From: Doug Barton <[email-masked]>
Date: Thu, 29 Mar 2012 17:00:15 -0700

On 3/29/2012 6:13 AM, Alex Abrahams wrote:
> 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.

I agree that the "few hundred people" thing was grating, and
unfortunate. But I think there is still a bit of a misunderstanding
about what problem 4941 (and its predecessor) was designed to address.

If you're in a corporate environment (at least in most of the western
world) you have ZERO expectation of privacy, and should act accordingly.
I anticipate that corporate IT departments who are concerned about the
problems presented by 4941 addresses are going to disable them as a
matter of policy. Period, end of discussion.

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.

All that said, the real problem that 4941 was designed to fix was that
if you take the same system (think laptop, and now mobile phones,
iThing, etc.) and connect it to multiple different networks (as in, the
top 64 bits of your address are different) without 4941 or a similar
mechanism it is still possible to uniquely identify that host. For that
particular part of the problem, 4941 does very nicely, and end-user
devices don't (or shouldn't) care what address is being used for their
*outbound* connections, as long as their device and its applications
handle the situation correctly.

hth,

Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Mar 2012 11:24:34 +1100

> use as ICBM targeting coordinates.

And if we want to address home networks then we need a way to signal
that we want both stable and temporary prefixes with PD and a way
to differentiate them when advertising them via RA.  DHCPv6 already
has IA_NA and IA_TA.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Mar 2012 18:47:08 +0200

On 03/30/2012 02:24 AM, Mark Andrews wrote:
> to differentiate them when advertising them via RA. 

Please see:

Thanks,