Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Apr 2004 13:05:16 -0400

Christian - where have you seen phrases like "do DHCP, and only if it fails
do auto-config."  They are clearly wrong.  SLAAC and DHCPv6 are clearly
independent - a host can use neither, one or the other or both - and are
controlled independently.  If that independence is not clear in the specs,
than we should fix the text in the specs.

- Ralph

At 09:29 AM 4/28/2004 -0700, Christian Huitema wrote:
>I think a whole lot of the issue has to do with the supposedly mandatory 
>nature of the M flag, which leads to phrases like "do DHCP, and only if it 
>fails do auto-config." It would be much simpler to simply define the flags 
>as "announcing an available service", as in:
>
>1) The "M" flag is set to indicate that a DHCPv6 address configuration 
>service is available on this link, as specified in RFC3315.
>
>2) The "O" flag is set to indicate that a DHCPv6 information service is 
>available on this link, as specified in RFC3736.
>
>We should then leave it at that, and leave it to nodes to decide whether 
>they want to use these services or not. For example, a server with a 
>configured address will never use DHCPv6 address configuration; an 
>appliance that never has to resolve DNS names will never use the 
>information service. By setting the flags to indicate service 
>availability, we will reduce the amount of useless chatter on the link 
>when the services are not in fact available.
>
>We should note that, from a protocol point of view, there is no need to 
>use the M bit to control stateless address configuration. This function is 
>already achieved by the "Autonomous flag" in the prefix information 
>option. If the flag is not set, the hosts will not configure information 
>from the prefix.
>
>-- Christian Huitema
>
>--------------------------------------------------------------------
>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: Fred Templin <[email-masked]>
Date: Wed, 28 Apr 2004 10:42:21 -0700

Ralph,

While the functions may be independent, wouldn't it be better
if we had a unified set of messages for accessing the functions?
(I'm thinking some sort of hybrid fusion of the RFC2461 ND
and RFC3315 DHCPv6 messages.) Perhaps it is too late in the
game to even consider this...

Fred
[email-masked]

Ralph Droms wrote:

>> I think a whole lot of the issue has to do with the supposedly 
>> mandatory nature of the M flag, which leads to phrases like "do DHCP, 
>> and only if it fails do auto-config." It would be much simpler to 
>> simply define the flags as "announcing an available service", as in:
>>
>> 1) The "M" flag is set to indicate that a DHCPv6 address 
>> configuration service is available on this link, as specified in 
>> RFC3315.
>>
>> 2) The "O" flag is set to indicate that a DHCPv6 information service 
>> is available on this link, as specified in RFC3736.
>>
>> We should then leave it at that, and leave it to nodes to decide 
>> whether they want to use these services or not. For example, a server 
>> with a configured address will never use DHCPv6 address 
>> configuration; an appliance that never has to resolve DNS names will 
>> never use the information service. By setting the flags to indicate 
>> service availability, we will reduce the amount of useless chatter on 
>> the link when the services are not in fact available.
>>
>> We should note that, from a protocol point of view, there is no need 
>> to use the M bit to control stateless address configuration. This 
>> function is already achieved by the "Autonomous flag" in the prefix 
>> information option. If the flag is not set, the hosts will not 
>> configure information from the prefix.
>>
>> -- Christian Huitema
>>