--------------------------------------------------
From: "Mark Smith" <i...@69706e6720323030352d30312d31340a.nosense.org>
Sent: Wednesday, March 09, 2011 5:18 PM
To: "huabing yu" <yhb810...@gmail.com>
Cc: <ipv6@ietf.org>
Subject: Re: draft-yhb-6man-ra-privacy-flag-02
On Wed, 9 Mar 2011 09:29:54 +0800
huabing yu <yhb810...@gmail.com> wrote:
2011/3/9 Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org>
> On Tue, 8 Mar 2011 23:09:46 +0800
> "Yu Hua bing" <yhb810...@gmail.com> wrote:
>
> > Hi, I have submit draft-yhb-6man-ra-privacy-flag-02. The problem
> > to
> > be solved is as follows:
> >
> > In some sites, the network administrators want to deploy stateless
> > address autoconfiguration, and just permit the hardware-derived
> > addresses to communicate with the Internet.They will do as
> > follows:
> >
> <snip>
> >
> > Now we can provide two solutions to the network administrators:
> > (1) SLAAC + bind the MAC address and the hardware-derived address
> > on
> the access switch + disable the temporary addresses
> > (2) DHCPv6 + DHCPv6 snooping
> > The first solution is cheaper, and is easier to deploy.
>
<snip>
> Regards,
> Mark.
>
In some sites, the network administrators want to prevent the host from
using any IPv6 address,
like DHCPv6 plus DHCPv6 snooping. Your method can't.
So, looking at the text at the top of the draft (although this is from
the -01 version, as I can't seem to find the -02 one), where you
present your use case -
"when the network is in trouble,it is difficult to find out
which host is attacking the other hosts."
it seems your real and fundamental goal is to be able to track the
mappings between MAC addresses and corresponding IPv6 addresses. Since
privacy addresses naturally makes that harder, and the decision to use
that is in the control of the end-host, you think the way to achieve
that auditability is to provide a mechanism to suppress privacy them.
I think you should sit back and think about the problem some more. The
people who are likely to execute these attacks will have also have
a motive to (a) choose an operating system where the tools to execute
these attacks are more commonly available and (b) as that operating
system is likely to be an open source one, modify the kernel, or
install somebody else's kernel patch that ignores any "disable privacy"
addresses mechanisms you manage to get deployed. You can't completely
trust the end-host to follow mechanisms that aren't in its owner's
interests.
I think you'll be more successful at achieving your fundamental goal by
observing and recording their IPv6 address use rather than trying to
control it with mechanisms they have the ability to disable.
Regards,
Mark.
I have submit draft-yhb-6man-ra-privacy-flag-02 by email to
internet-dra...@ietf.org.
IETF didn't publish it. Please wait.
I described the problem to be solved in the email
"draft-yhb-6man-ra-privacy-flag-02".
I just want to cite an example to let you realize the value of the flag.Some
people may
not like it, but the other people may like it.
Yu Hua bing
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
