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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------