> correlation but their admins won't let them use temporary addresses,
> then random-per-network (row 3) provides some benefits over random (row 2).
So is the goal of the draft to give a new way for network administrators to
decrease privacy of users? If yes, then if this goal was removed, would
In such an attack, is the attacker on the path between the victim and the
server? If yes, there are more efficient ways how they can DoS the victim. If
no, how does the attacker know which of the billions hosts on the Internet will
be talking to this DNS server in the next second (in order to se
arif...@nttv6.net]
Sent: Thursday, November 17, 2011 9:14 PM
To: Dmitry Anipko
Cc: ipv6@ietf.org
Subject: Re: multiple policy tables handling in
draft-ietf-6man-addr-select-opt-01
Hi,
thank you for your comment.
On 2011/11/14, at 14:21, Dmitry Anipko wrote:
Hello,
I have a question about this text
Hello,
I have a question about this text the -01 revision:
>>A node MAY use OPTION_DASP in any of the following two cases:
1: The address selection option is delivered across a secure,
trusted
channel.
The OPTION_DASP is configured by a network administrator
Hello Fred,
Rule 7 does help to distinguish native IPv6 versus ISATAP.
However, rule 7 doesn't help to distinguish ISATAP from native IPv4: the rule 7
is only considered after rule 6, and per rule 6 ISATAP is already prioritized
higher than IPv4 due to the default prefix policy table precedenc
Hi Fred,
>> Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'?
Yes, that's correct.
Thank you,
Dmitry
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Templin, Fred L
Sent: Friday, March 12, 2010 1:13
Hello,
I wanted to follow up on Fred's comment earlier in this thread:
>> OK. That will greatly simplify the checks needed for new
automatic tunneling protocols that have a format other
than ip-proto-41.
For the designers of new tunneling protocols, shall perhaps a recommendation on
best practi
Thanks Hesham, Hemant and Suresh for your responses.
It seems from them that the implied intent was that unicast-destined RSes
should be allowed to be both sent and received and should be handled equally
with multicast-destined ones. If that is the case, shall the RFC text be
amended to reflect
Hello,
I have a question on whether router solicitations with unicast destination
addresses are valid under RFC 4861, and if they are, whether they shall be
handled by routers equally to the solicitations with multicast destination
address.
The RFC says:
>>6.3.7. Sending Router Solicitations
