disabling client use of SLAAC

[Brian E Carpenter]

Ole,

On 2010-03-06 12:18, Ole Troan wrote:
> Brian,
> 
>>> The M and O flags says "get info via DHCP", but it seems they don't mean
>>> "do NOT use SLAAC" if I read http://www.ietf.org/rfc/rfc2462.txt correctly?
>>>
>>> So bottom line, how to make clients not use SLAAC with a Cisco router?
>>>
>> Note that this is known to be a tricky area in mutlti-vendor, multi-o/s
>> situations.
>>
>> Quoting draft-carpenter-renum-needs-work-05:
>>
>>   We should note a currently unresolved ambiguity in the interaction
>>   between DHCPv6 and SLAAC from the host's point of view.  RA messages
>>   include a 'Managed Configuration' flag known as the M bit, which is
>>   supposed to indicate that DHCPv6 is in use.  However, it is
>>   unspecified whether hosts must interpret this flag rigidly (i.e., may
>>   or must only start DHCPv6 if it is set, or if no RAs are received) or
>>   whether hosts are allowed or are recommended to start DHCPv6 by
>>   default.  An added complexity is that DHCPv6 has a 'stateless' mode
>>   [RFC3736] in which SLAAC is used to obtain an address but DHCPv6 is
>>   used to obtain other parameters.  Another flag in RA messages, the
>>   'Other configuration' or O bit, indicates this.
>>
>>   Until this ambiguous behaviour is clearly resolved by the IETF,
>>   operational problems are to be expected, since different host
>>   operating systems have taken different approaches.  This makes it
>>   difficult for a site network manager to configure systems in such a
>>   way that all hosts boot in a consistent way.  Hosts will start SLAAC
>>   if so directed by appropriately configured RA messages.  However, if
>>   one operating system also starts a DHCPv6 client by default, and
>>   another one starts it only when it receives the M bit, systematic
>>   address management is impeded.
> 
> I wouldn't say it is quite that indeterministic.
> a network manager is still in making the choice of what address assignment mechanism to use.

Well, the feedback we got on our renumbering draft definitely
indicated operational uncertainty in real usage.

> I think you can reasonably safely assume that a host will use SLAAC if the A flag is set. it will not do SLAAC if the A flag is off. if it supports DHCPv6 it will most likely do DHCP if the M-flag is set and it may do it without, and especially in the case where the A flag is off. (;-))

Thanks, I think we should think about adding that to our draft (except that
it's already almost passed the IESG.)

> if a host tries DHCP on a link which doesn't support it. no harm done.

Agreed, apart from a little wasted time.

    Brian