I believe requirement 3 is incorrectly stated; I think the discussion in the past was to have M=0/O=0 mean that the node SHOULD NOT start DHCPv6. I believe it was just desired that it *NOT* be a MUST NOT.
Just remember what RFC 2119 states regarding these two phrases: 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Several rasons to have SHOULD NOT at the present time are: 1. That several DHCPv6 clients today must be manually configured to run, likely because they don't have access to the M and O bits so can't make use of them. 2. There could be multiple RAs with conflicting M&O bits. 3. Or the M and O bits have changed and at least RFC 2462 states that only FALSE -> TRUE transitions trigger running the "stateful address configuration protocol" (and a TRUE -> FALSE transition does not cause the protocol to stop running). - Bernie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, August 02, 2005 10:38 AM > To: IETF IPv6 Mailing List > Subject: remarks > > My remarks in the session just now: > > IIRC, 24 bits of the address are encoded in the solicited node > address, good luck finding hardware that can handle this many > multicast groups. > > I still would like to know what exactly requirement 3 would be: > > - still DHCPv6 if routers send the default 00 MO bits, or > - "requirement" to do DHCPv6 always regardless what routers say > > (Note that all I care about / anyone here should care about > is out of > the box behavior, if people configure their hosts to play the French > national anthem when the O bit is set, which is clearly not mandated > by any RFC, they can always do that. Vendors just shouldn't make it > happen by default.) > > The question: are there now implementations that do something > different when the MO bits aren't 00 as opposed to when they are? > I.e., what do we break by redifining these bits? > > All the stuff I've seen in the wild just ignores the bits. > > Iljitsch van Beijnum > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
