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.

> 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.

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.

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to