On 02/04/2013 07:12 PM, Randy Bush wrote:
In scenarios where privacy matters a lot, if our default policy is
"no privacy", those users "opting in" for privacy would be flagged
as "suspicious" just for the act of "opting in".
and 82.3% would not realize they needed to opt out.
i would think tha
> In scenarios where privacy matters a lot, if our default policy is
> "no privacy", those users "opting in" for privacy would be flagged
> as "suspicious" just for the act of "opting in".
and 82.3% would not realize they needed to opt out.
i would think that, in general, across the ietf protocol
On Feb 4, 2013, at 7:48 PM, Fernando Gont wrote:
> On 02/04/2013 12:45 PM, Jouni Korhonen wrote:
>>
>>> On 02/04/2013 06:42 AM, Rémi Després wrote:
In this respect, changing now the IPv6 specification for hosts that
configure IIDs having u=1, although no serious need has been
i
Folks,
I was wondering what's the status of draft-ietf-6man-oversized-header-chain.
Was it ready to ship to the IESG? Or does it still need to be WGLC'ed?
FWIW, this I-D has been stable for a few months now, and quite a few
folks agreed that it was ready to progress.
Thanks!
Best regards,
--
Remi,
I believe that the original question really was "whether it makes
sense to reserve an unused IID range for 4rd".
>>>
>>> A 4rd reserved range, for 4rd activation to never require IPv6
>>> renumbering, has been for long in the specification studied in
>>> Softwire.
>>
>> But my un
On 02/04/2013 12:45 PM, Jouni Korhonen wrote:
>
>> On 02/04/2013 06:42 AM, Rémi Després wrote:
>>> In this respect, changing now the IPv6 specification for hosts that
>>> configure IIDs having u=1, although no serious need has been
>>> identified, and this specification has ben used, would be in m
On 02/04/2013 12:38 AM, Rémi Després wrote:
It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough
exceptions. This is somewhat similar to the expectation that ULA collisions
shouldn't be seen).
This theoretical unicity has been extensively used to assign stable IIDs,
without
Le 2013-02-04 à 11:32, Fernando Gont a écrit :
> On 02/04/2013 06:42 AM, Rémi Després wrote:
>> In this respect, changing now the IPv6 specification for hosts that
>> configure IIDs having u=1, although no serious need has been
>> identified, and this specification has ben used, would be in my
>
2013-02-04 11:37, Fernando Gont :
> On 02/04/2013 06:56 AM, Rémi Després wrote:
>>
>>> I believe that the original question really was "whether it makes
>>> sense to reserve an unused IID range for 4rd".
>>
>> A 4rd reserved range, for 4rd activation to never require IPv6
>> renumbering, has
On Feb 4, 2013, at 12:32 PM, Fernando Gont wrote:
> On 02/04/2013 06:42 AM, Rémi Després wrote:
>> In this respect, changing now the IPv6 specification for hosts that
>> configure IIDs having u=1, although no serious need has been
>> identified, and this specification has ben used, would be in m
On 02/04/2013 06:42 AM, Rémi Després wrote:
> In this respect, changing now the IPv6 specification for hosts that
> configure IIDs having u=1, although no serious need has been
> identified, and this specification has ben used, would be in my
> understanding very counterproductive: stability of alr
On 02/04/2013 07:06 AM, Rémi Després wrote:
>
> Le 2013-02-04 à 10:54, Fernando Gont a écrit :
>
>> On 02/04/2013 05:38 AM, Rémi Després wrote:
>>>
>>> (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare
>>> enough exceptions. This is somewhat similar to the expectation that
>>>
On 02/04/2013 06:56 AM, Rémi Després wrote:
>
>> I believe that the original question really was "whether it makes
>> sense to reserve an unused IID range for 4rd".
>
> A 4rd reserved range, for 4rd activation to never require IPv6
> renumbering, has been for long in the specification studied in
>
>It can't be a consideration, because in order for CGAs to serve their
purpose, nodes must be able to compute the IID. An IID that aims at
protecting user privacy works the other way around: a third->party should
not be able to compute the IID.
Please refer you to CGA RFC.
About SSAS: the purpose
Rémi,
On 04/02/2013 09:11, Rémi Després wrote:
> Hi, Roger,
>
> Please see inline.
>
> 2013-02-03 22:40, Roger Jørgensen :
>
>> On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli wrote:
>>> On 2/3/13 11:39 AM, Joel M. Halpern wrote:
On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
> On 03/02/
Le 2013-02-04 à 10:54, Fernando Gont a écrit :
> On 02/04/2013 05:38 AM, Rémi Després wrote:
>>
>> (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare
>> enough exceptions. This is somewhat similar to the expectation that
>> ULA collisions shouldn't be seen).
>>
>> This theore
2013-02-04 10:41, Fernando Gont :
> On 02/04/2013 06:11 AM, Rémi Després wrote:
>>
>> It depends on what is done with the new design, especially if it is backward
>> compatible and optional.
>>
>> The question that started this discussion is whether reserving a currently
>> unused IID range
On 02/04/2013 05:38 AM, Rémi Després wrote:
>
> (*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare
> enough exceptions. This is somewhat similar to the expectation that
> ULA collisions shouldn't be seen).
>
> This theoretical unicity has been extensively used to assign stable
>
On 02/03/2013 10:55 AM, Ray Hunter wrote:
> What "uniqueness" is strictly required for correct operation of IPv6?
> If the competing technologies can never share an L2 link, what's the
> problem?
>
> IMVHO We should be careful what semantics we import from other standards
> bodies, and only do thi
Hosnieh,
On 02/02/2013 06:41 PM, Hosnieh Rafiee wrote:
>
>> CGA were not designed to address privacy related attacks, they are a means
> of securing NDP exchanges. The fact that they appear random is coincidental
> to their function.
>
> It is true that the main purpose was security, but it is n
On 02/04/2013 06:11 AM, Rémi Després wrote:
>
> It depends on what is done with the new design, especially if it is backward
> compatible and optional.
>
> The question that started this discussion is whether reserving a currently
> unused IID range having u=1 is compatible with the IPv6 addre
Randy,
We have in common, as you know, the objective of IPv6 promotion, and that of
NATs elimination as much as possible.
In this respect, changing now the IPv6 specification for hosts that configure
IIDs having u=1, although no serious need has been identified, and this
specification has ben
Hi, Roger,
Please see inline.
2013-02-03 22:40, Roger Jørgensen :
> On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli wrote:
>> On 2/3/13 11:39 AM, Joel M. Halpern wrote:
>>> On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
On 03/02/2013 17:26, Joel M. Halpern wrote:
>
> To a significant
2013-02-03 à 20:39, Joel M. Halpern :
>
>
> On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
>> On 03/02/2013 17:26, Joel M. Halpern wrote:
>>> To a significant degree Randy, I agree with you in your comment about
>>> magic bits. If I were designing IPv6 from scratch (counter-factual in
>>> so
Brian, Bob,
2013-02-03 12:43, Brian E Carpenter :
> On 03/02/2013 10:57, Rémi Després wrote:
>> Le 2013-02-02 à 18:17, Joel M. Halpern a écrit :
>>
>>> I a not clear what aspect of the semantics of u==1 and the relationship to
>>> EUI-64 is a dead duck. Currently, if you see something wit
On 04/02/2013 07:52, sth...@nethelp.no wrote:
>> I can find many reasons to remove the magic from the U and G bits. I
>> personally ran into the U/G bit issues in RFC 4380 (Teredo) and RFC 6052
>> (IPv4-embedded IPv6 addresses). In both cases, the design would have been
>> simpler if we had not
That is not what I said. Christian, thank you, that is the kibd of information
I was looking for, and expect in the draft or from the authors.
Yours,
Joel
Sent from my Samsung smartphone on AT&T
Original message
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
27 matches
Mail list logo
