Sorry, missed an important part. Replying in full. Le 2014-04-15 11:15, Ted Lemon a écrit : > On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen <[email protected]> wrote: >> Right, to a certain extent that is true, of course; but not in the same >> drive-by fashion where a single packet can put everyone offline (if the >> option is not in the regular announcements). > > This is a good point. Given that this draft depends on IPv6 configuration > that comes with lifetimes, it would make sense to specify that the no-ipv4 > configuration information is only valid for the lifetime of the configuration > message that delivered it—e.g., the prefix lifetime for RA, or the lease > lifetime for DHCP, or for DHCP information-requests, the information refresh > timer interval. Since we're doing the IPv6 configuration protocol anyway, > there's no damage done by continuing to rely on it to suppress IPv4 > configuration.
Makes total sense. Will be added in the next revision. >> Would it not be reasonable to add in a requirement that if a client has >> already received a DHCPv4 lease (or more generally, has been configured >> for IPv4 in some way), it will ignore requests to turn off the stack? > > No, because this just leaves the client open to a different DoS attack. If > you have rogue configuration protocols running on your network, you need to > fix it. This just moves the problem around—it doesn't solve it. > > One thing that I think would make this less likely to happen would be to > state that no-ipv4 must be present on all valid configuration states received > on a particular interface in order for no-ipv4 to be valid for that > interface. IOW, if you are getting rogue RAs that say "no IPv4" and also a > non-rogue RA that doesn't say "no IPv4," the host assumes that IPv4 is > permitted. This prevents a rogue RA from killing IPv4 connectivity even for > the lifetime of that RA. So that means if you're running DHCPv6, and assuming you use RAs for provisioning at least the default gateway, you need to put the No-IPv4 option in both RA and DHCPv6. If we specify that then we could just kill the DHCPv6 option since it would then be useless. > Of course the downside to this is that if you have multiple advertisers on > your link and they don't all agree, you lose, but again that's a > configuration error that the admin can fix, and hence not something that > needs to be addressed at a protocol level. Agreed. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
