> Then what's all this controversy with
> draft-gont-6man-managing-privacy-extensions? :-) -- That aside, there have
> been quite a few publications asessing the real "privacy" provided with the
> so-called privacy-extensions
Using randomized host identifiers is way more private than sticki
Hi, Brian,
On 15/03/2011 07:16 p.m., Brian E Carpenter wrote:
>>> I agree. I sort of accept that an ISP can know my addresses in use, in
>>> part because they gave them to me. However, for an ISP to not let me
>>> choose if I want to use privacy addresses on the Internet would
>>> be completely un
In your letter dated Tue, 15 Mar 2011 20:27:32 +0100 you wrote:
>
>On 2011-03-15, at 19:27 , Philip Homburg wrote:
>
>> If you just need stable addresses, then you can also put your own =
>random
>> numbers in DHCP.=20
>
>I just thought it would be nice if DHCP, manual configuration and =
>stateles
On 2011-03-16 09:35, james woodyatt wrote:
...
> No certainty is possible. Duplicate Address Detection (DAD) is your last
> best hope for civilization.
If you'll excuse an anecdote, while I was living in Geneva I was regularly
amused when the shiny new information screens in the shiny new buses
Fernando,
On 2011-03-16 00:55, Fernando Gont wrote:
> On 09/03/2011 05:49 p.m., Mark Smith wrote:
>> I agree. I sort of accept that an ISP can know my addresses in use, in
>> part because they gave them to me. However, for an ISP to not let me
>> choose if I want to use privacy addresses on the In
On Mar 15, 2011, at 12:11 , Markus Hanauska wrote:
>
> [...] but making a tiny change to existing RFCs to make it impossible will
> always be better IMHO
Let me try again... there is no "tiny change" to existing RFCs that can make it
*impossible* for address conflicts to arise. The best we can
Hi John,
On 11-03-15 04:15 PM, John Leslie wrote:
Suresh Krishnan wrote:
On 11-03-15 09:25 AM, John Leslie wrote:
But I don't see the equivalent of Section 4.2 of RFC 2460, specifying
the TLV format.
The T is the "Next Header", the L is the "Hdr Ext Len" and V is the
"Header Specific Data" a
Suresh Krishnan wrote:
> On 11-03-15 09:25 AM, John Leslie wrote:
But I don't see the equivalent of Section 4.2 of RFC 2460, specifying
the TLV format.
>>>
>>> The T is the "Next Header", the L is the "Hdr Ext Len" and V is the
>>> "Header Specific Data" as specified in the figure
Hi Kam,
On 11-03-15 10:37 AM, Hing-Kam (Kam) Lam wrote:
I am forgetting what the resolution was on the Hdr Options that were
defined in the -01 version. I find those missing here, so i assume
that they have been intentionally dropped out. I was personally in
favor of those and didnt see too much
On 2011-03-15, at 19:27 , Philip Homburg wrote:
> If you just need stable addresses, then you can also put your own random
> numbers in DHCP.
Of course everything will be fine if you exclusively use DHCPv6. You can have a
pool with addresses for well known devices, so the same device always ge
On 2011-03-15, at 18:28 , james woodyatt wrote:
> Were RFC 4429 and I-D.ietf-6man-dad-proxy among the documents you read over
> the weekend?
I only read the introduction and problem statement of RFC 4429 and neither
seemed to address my concerns, thus I skipped the rest. I just browsed through
In your letter dated Tue, 15 Mar 2011 19:04:48 +0100 you wrote:
>On 2011-03-15, at 16:58 , Philip Homburg wrote:
>
>> I think the answer is that is statistically very unlikely that on a =
>single
>> subnet, a 64-bit random number will ever be equal to any address =
>manually
>> configured in DHCP.
On 2011-03-15, at 16:58 , Philip Homburg wrote:
> I think the answer is that is statistically very unlikely that on a single
> subnet, a 64-bit random number will ever be equal to any address manually
> configured in DHCP.
I'd say this entirely depends on how the (usually pseudo-) random number
On Mar 14, 2011, at 05:00 , Markus Hanauska wrote:
>
> [...] And here is my reply: How is DAD preventing this problem if the device
> with the conflicting address in question is not connected to the network the
> moment DAD is performed? [...]
Were RFC 4429 and I-D.ietf-6man-dad-proxy among the
In your letter dated Mon, 14 Mar 2011 13:00:11 +0100 you wrote:
>And bear in mind, that other RFCs even mention cases where a device might
>create its 64 bit host ID entirely "random"; which is even worse than using a
>hash function.
I think the answer is that is statistically very unlikely that
I am forgetting what the resolution was on the Hdr Options that were
defined in the -01 version. I find those missing here, so i assume
that they have been intentionally dropped out. I was personally in
favor of those and didnt see too much harm in keeping them.
Other than the small nit above, the
Since IPv6 plays an increasingly prominent role in planing network
environments, I spent most of the weekend to think about IPv6 distribution
strategies for our company and my home Internet connection, re-reading most of
the important RFCs and I came across a serious address deployment issue tha
Hi John,
On 11-03-15 09:25 AM, John Leslie wrote:
Suresh Krishnan wrote:
On 11-03-14 06:55 PM, John Leslie wrote:
I notice that Section 4 calls for TLV:
]
] 4. Proposed IPv6 Extension Header format
]
] This document proposes that all IPv6 extension headers be encoded in
] a consistent
Suresh Krishnan wrote:
> On 11-03-14 06:55 PM, John Leslie wrote:
>>
>> I notice that Section 4 calls for TLV:
>>]
>>] 4. Proposed IPv6 Extension Header format
>>]
>>] This document proposes that all IPv6 extension headers be encoded in
>>] a consistent TLV format so that it is possible for
On 09/03/2011 05:49 p.m., Mark Smith wrote:
> I agree. I sort of accept that an ISP can know my addresses in use, in
> part because they gave them to me. However, for an ISP to not let me
> choose if I want to use privacy addresses on the Internet would
> be completely unacceptable.
Why would you
20 matches
Mail list logo
