In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote: >http://resources.infosecinstitute.com/slaac-attack/ > >When you have unfiltered L2 access, there are LOTS of evil things you >can do.
The world is not black and white. Rogue RAs are easy for hit and run attacks. Maybe I should already create 'ipv4begone'. Would be a nice way to reserve the wireless for yourself in busy wifi networks. In contract MITM attacks are much harder to pull off. Any don't really gain much compared to just sniffing the wifi. >No, you can just re-send the No-IPv4 option with value 0. We added it >specifically to re-enable IPv4 when it has been previously disabled by >mistake. So now, any RA daemon also has to know to start dhclient. So it is more than just your oneliner. >And this is one advantage of using IPv6 for signalling the absence of >IPv4 service. If you use IPv4 instead, and you make a mistake, there's >no going back. Not if you just suspend DHCP operation for a while... >> Which means that >> any serious vendor will spend a lot of code making sure that the DHCP >> is only suspended for a couple of RA intervals, which leads to a way >> more complex interaction. > >As discussed with Ted Lemon, the next revision will specify that the >No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA. Similar to what you describe here. There is of course an easy way out. Let this run its course and then write an informational RFC that allocates the required option for DHCPv4. More choices are always better... Let the OS vendors decide. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
