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

> Brian E Carpenter <brian.e.carpen...@gmail.com> 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        

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to