Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]

[Ralph Droms <[e-mail]>]

On Jun 1, 2011, at 4:42 PM 6/1/11, Thomas Narten wrote:

> Brian E Carpenter <[e-mail]> writes:
> 
>> Ray,
> 
>> Without going into details: how about turning this into
>> draft-hunter-v6ops-something and having the debate over in v6ops?
> 
>> I think that would be useful, personally.
> 
> Actually, let me suggest something else.
> 
> Before spending a whole lot of time on this topic, is there anyone
> else who thinks there is a problem here that needs solving? The last
> thing we (as a group) need to do is spend time on a non-problem.
> 
> Personally, I don't see the issue here. I think the problem as stated
> is a non-problem. And to be honest, this is the first time I have
> heard anyone suggest what you describe is a real problem. So I wonder
> whether anyone else thinks there is a problem here that needs fixing.

I don't think there is a problem worth fixing.

> 
> To the point:
> 
>>> Ray Hunter wrote:
>>>> It's definitely going to become an operational FAQ, unless it is very
>>>> clear whether/how a network operator can force equivalent use of
>>>> DHCPv4 static address assignment for both source and destination
>>>> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of
>>>> GUA on an interface via a flag, or via RFC3484 bis), and how to
>>>> achieve this effect for all nodes on a link, without resorting to
>>>> local configuration. So I may as well be the first to ask.
> 
> A fine way to deal with this problem is not advertise any prefixes in
> RAs for stateless address autoconfiguration. The network operator is
> in control here. They decide how/whether DHCP and/or SLAAC is used.

I recently wrote: Use of SLAAC is controlled by the A bit in the Prefix Information option.  If the A bit is zero, the host will not configure an address on the receiving interface using SLAAC.  

The M bit in an RA gives a hint that DHCPv6 service is available.  The host behavior is not entirely controlled by the M bit; a host can choose to run DHCPv6 independent of the setting of the M bit.  A reasonable host might not bother with DHCPv6 if the M bit is 0; at the same time, a reasonable host might go ahead with DHCPv6 if it doesn't receive any Prefix Information options with the A bit set to one.

> 
> Why is this not sufficient?

Sounds sufficient to me...

- Ralph

> 
> Thomas