On 15.4.2014, at 17.07, Juliusz Chroboczek <[email protected]> wrote:
>> We are soliciting reviews for this SUNSET4 draft: >> >> http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00 >> >> In a nutshell, it defines DHCPv6 and RA options indicating to the host >> that IPv4 is not available. > > It seems to me that options relating to IPv4 don't belong in RA/DHCPv6 > -- they belong in DHCPv4. Having a degenerate DHCPv4 server that just > NAKs every request would appear to solve all of the problems in Section 3. > The main point is that having a dedicated DHCPv4-NAK-ing server avoids > the need to configure all IPv6 routers with IPv4-related information > -- a serious operational concern if you have many IPv6 routers on a single > link. > > (To be fair, you might need a new DHCPv4 option that says "do not try > to contact any other DHCPv4 servers" to solve your problems 3.1/3.2. > But then, I'd like to see some operational experience that shows that it > is a problem in practice.) Disclaimer: I haven’t read the draft. I like the idea on high level, though. Certain not-quite-RFC-compliant DHCP clients send DISCOVER once every 3 seconds until end of the world. I’m not sure this would fix those, though. NAK isn’t probably what you want (due to it’s semantics). However, OFFER that doesn’t really offer anything + magic option that says IPv4 is dead is what I’d want. I would rather see this than RA options as well; that way, the DHCP state machine (if any) can decide how long it honors this request not to do stuff. It also keeps v4 and v6 decoupled which actually makes life much easier in some implementations. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
