I have been lurking on this discussion for a while and have one observation. Regardless of the values of the M&O bits or the prefixes (and their lengths) that are advertised, I suggest that the client not send any messages until it receives a "General Query (RFC 3810)." If the client does not hear a GQ within a suitable time (either TBD or SOL_TIMEOUT, etc per RFC 3315), I suggest that the client "assumes" that no DHCPv6 server is available. This goes a short way to preventing the simplest RA (here meaning router advertisement, NOT relay agent) spoofing.
Thoughts? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TJ Sent: Friday, October 17, 2008 9:07 AM To: 'IPV6 List Mailing' Cc: 'DHC WG' Subject: RE: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits Not trying to oversimplify things here, but to me it makes the most sense to start with what we have working now and *not* make any broad, sweeping changes. To do otherwise is not only a tremendous disservice to all of those who have implemented/adopted IPv6 (or are considering doing so) but also fails IMHO to be a good, technical approach to the problem at hand. I am in no way saying we can't continue adding capabilities (e.g. - XML config via RA-provided URL) ... but to make drastic changes to functions that real people are using in real networks to provide real services seems, well, sub-optimal. What we have: SLAAC Stateless DHCPv6 Stateful DHCPv6 (Manual Configuration, out of scope for / irrelevant to this conversation) SLAAC is well defined, and works quite well - even w/o DNS-option support being widespread. Once RFC5006 support is in place, this will be sufficient for most uses, with a valid concern about the host identification / (dynamic) name resolution areas. We can address those, rather than toss the baby with the bath water. DHCPv6 is also well defined, with some questions rising around the acillary pieces - e.g. when does a host run it, and choose which mechanism. IMHO, simply making a clearer definition of the M & O bits would be sufficient. In my world view, the following would be the least painful and most functional approach: Host sends RS If RA recevied - look for A/prefix, M, O bits and act accordingly. ... if one RA specifies one approach, and one RA specifies the another, do both ... In almost all properly functioning scenarios this is all the we need, yes? Additionally ... If no RA received, I am OK with the host making a one-shot attempt at both stateless and stateful DHCP, just in case ... the question here - what is the assumed prefix length / "on link" approach? ... if we stick with the "right" answer of /128, well then DHCPv6 didn't accomplish much ... unless something else comes in to play ... LLMNR, etc. providing a hint on onlinkedness, or somesuch. ... if we assume /64 we raise other problems / questions I think this case is somewhat degenerate and should be rare; but should nonetheless have a consistent, well defined behavior. Am I missing anything fundamental here? /TJ PS - I totally agree with Iljitsch's "the amount of people that complain that IPv6 changes too much seems to be about the same as those that complain that IPv6 doesn't change enough so my guess is that they got this more or less right" ... I believe another relevant quote would be "rough consensus and running code". -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
