Subject: RE: remarks (RE M/O Bits & Requirement 3)

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 2 Aug 2005 12:20:53 -0400

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-masked] [mailto:[email-masked]] 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
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Aug 2005 11:47:22 +0200

[Unfortunately I don't have connectivity in my hotel, so belatedly...]

> I believe it was just desired that it *NOT* be a MUST NOT.

I don't think the question we need to answer is "SHOULD NOT" or "MUST  
NOT" do DHCPv6 when the bits are 00. I believe it's a given that some  
people are going to run DHCPv6 without bothering to change the RA bits.

The real question is what happens out of the box. Consider the  
situation where a popular OS does DHCPv6 when MO==00 by default.  
Since hunting down each and every one of these hosts and  
reconfiguring them to NOT do DHCPv6 isn't feasible, this means we  
then live in a universe where there will always be DHCPv6 packet on  
all links everywhere. (Even if most other OSes don't do DHCPv6 with  
MO==00 by default.) I don't think this is compatible with any  
interpretation of the use of the bits.