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 for a
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
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 be
]
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, there's no way an end
user or IT
department can buy a bunch of machines based on the text currently
contained
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 privacy
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.
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
-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, there's no way an end user
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 prefer B, but
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 privacy
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:
There MUST be a
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 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 RFC3041
,
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 addresses
From the corporate World: option
At Mon, 2 Apr 2012 23:43:57 +,
Dave Thaler dtha...@microsoft.com 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
, 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 addresses are a menace to fault
finding, audit, logging
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 coordinates.
And
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 IPv6.
really need to start rolling out IPv6 and find out what works.
Tom Petch
- Original Message -
From: Ray Hunter ray.hun...@globis.net
To: Brian Haberman br...@innovationslab.net
Cc: ipv6@ietf.org
Sent: Tuesday, March 27, 2012 7:00 PM
Subject: Re: 3484bis and privacy addresses
From
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,
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 hundred
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 we
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
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
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
already a global stable address.
Regards,
Jordi
-Mensaje original-
De: Brian Haberman br...@innovationslab.net
Responder a: br...@innovationslab.net
Fecha: Tue, 27 Mar 2012 03:33:48 -0400
Para: ipv6@ietf.org
Asunto: 3484bis and privacy addresses
All,
The chairs would like to get
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
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
stable address.
Regards,
Jordi
-Mensaje original-
De: Brian Habermanbr...@innovationslab.net
Responder a:br...@innovationslab.net
Fecha: Tue, 27 Mar 2012 03:33:48 -0400
Para:ipv6@ietf.org
Asunto: 3484bis and privacy addresses
All,
The chairs would like to get a sense
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
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 fixed
: Tue, 27 Mar 2012 10:09:16 +0200
Para: ipv6@ietf.org
CC: Jordi Palet Martinez jordi.pa...@consulintel.es
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
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
) 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
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
-trail (so Fernando's proposal is
useful here)
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
Brian Haberman
Sent: mardi 27 mars 2012 09:34
To: ipv6@ietf.org
Subject: 3484bis and privacy addresses
All,
The chairs would like to get
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 boot
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,
B for me.
Sent from my iPad
On Mar 27, 2012, at 10:44 AM, Simon Perreault simon.perrea...@viagenie.ca
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
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 the privacy
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 Personal
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 Personal
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 public
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...
Regards
Folks,
I think that one error in which we have incurred at least in the couple
of years (myself included) is that we focus our discussion on
mac-derived addresses vs privacy addresses when the question should
really be about stable addresses vs. temporary addresses.
Clearly, we don't want any
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
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 fg...@si6networks.comwrote:
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
On 03/27/2012 04:44 PM, Dominik Elsbroek wrote:
since I got confused on the discussion in the plenary this morning: I
think we have to consider that having a temporary address like defined
in RFC 4941 does not prevent from or even mitigates the scanning
problem mentioned this morning in
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.
Dear all
I'm working on ETSI and ISO standardization for ITS (vehicular
communication) where location privacy at the IPv6 layer is one of big
concerns. From the viewpoint of IPv6 ITS communication, we definitely need
to preserve location privacy. Accordingly, I strongly support the method
Fernando,
On 3/27/12 8:57 AM, Fernando Gont wrote:
Folks,
I think that one error in which we have incurred at least in the couple
of years (myself included) is that we focus our discussion on
mac-derived addresses vs privacy addresses when the question should
really be about stable 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,
--
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
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 manager is
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,
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.
While I
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
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
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
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
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
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
62 matches
Mail list logo
