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
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
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
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
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
Christian,
Well, I think it is quite a simple trade-off. Increasing Sec increases
computational effort on both sides by equal amount. Increasing the length of
the hash increases computational effort only on the attacker side. As a result,
the hash bits are relatively valuable.
Jari, the effec
> Well, I think it is quite a simple trade-off. Increasing Sec increases
> computational effort on both sides by equal amount. Increasing the length of
> the hash increases computational effort only on the attacker side. As a
> result, the hash bits are relatively valuable.
Jari, the effect of
> 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
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
> 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.
>
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
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
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
In response to coments on draft draft-zhou-6man-mhash-cga-00
It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
a factor of 2^(16*Sec). It also increases the cost of brute-force
attacks by the same factor. That is, the cost of creatin
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,
-
+1
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
> Fernando Gont
> Sent: mardi 27 mars 2012 15:26
> To: Tassos Chatzithomaoglou
> Cc: ipv6@ietf.org
> Subject: Re: question about draft-gont-6man-oversized-header-chain-00
>
> On 03/27/2012 11
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
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
describe
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
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 dis
Regards~~~
-Sujing Zhou
Jari Arkko 写于 2012-03-27 16:21:52:
> Well, I think it is quite a simple trade-off. Increasing Sec
> increases computational effort on both sides by equal amount.
> Increasing the length of the hash increases computational effort
> only on the attacker side. As a resul
Hi Fernando,
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 discussion. Scanning MAC-address
derived addr
Well, I think it is quite a simple trade-off. Increasing Sec increases
computational effort on both sides by equal amount. Increasing the length of
the hash increases computational effort only on the attacker side. As a result,
the hash bits are relatively valuable.
The trade-off that we have
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
In response to coments on draft draft-zhou-6man-mhash-cga-00
1. It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
a factor of 2^(16*Sec). It also increases the cost of brute-force
attacks by the same factor. That is, the cost of crea
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
On 03/27/2012 11:30 AM, Tassos Chatzithomaoglou wrote:
> i was wondering, is there any actual (from a production network, not
> created on purpose in a lab) sample ipv6 traffic showing an ipv6 header
> comprising of two or more packets?
No. That's exactly the point: such traffic does not occur in
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
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
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
Some questions/comments about this draft:
1) I think it should be better to provide an alternative terminology in
order to better describe the topology, like hub and spokes or root and
leaf(s).
2) IPv6 over PPP is not affected and should probably be mentioned.
3) Under 4.2.2, i believe there
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
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
+1 for option A
Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
carl.wu...@technicolor.com
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
Ed
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
i was wondering, is there any actual (from a production network, not
created on purpose in a lab) sample ipv6 traffic showing an ipv6 header
comprising of two or more packets?
--
Tassos
IETF IPv6 working group mailing lis
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
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
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
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
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
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
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
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
Responder a:
Fecha: Tue, 27 Mar 2012 10:09:16 +0200
Para:
CC: Jord
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
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
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,
Just some comments on the MS/TP draft, of which I support advancement.
Does MS/TP have any distinction between classes of devices?
Something like Host vs Router? Something like multiply-interfaced
machine vs. singly-interfaced? More powerful machine vs less powerful?
Maybe this distinction co
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
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
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
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
52 matches
Mail list logo
