Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

Ralph, Thomas, John,

The attributes that come to mind are those that are DNS related via
RFC6106.  In theory I suppose what John mentioned could be an issue,
however, in a broadband DOCSIS environment we only support stateful DHCPv6
for provisioning today as such I do not anticipate seeing these sort of
issues in this scenario.  I could sooner see the issue John raises
occurring in an enterprise or within a home network, especially the
latter.  Regarding the latter, we have seen home router implementations
that issue link local addresses and global unicast addresses
simultaneously via RFC6106 for DNS server addresses.  This has since been
corrected.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 5/13/11 12:26 PM, "Ralph Droms" <rdroms.ietf@gmail.com> wrote:

>John...
>On May 13, 2011, at 12:19 PM 5/13/11, <john.loughney@nokia.com> wrote:
>
>> Hi all,
>> 
>> In general, I support Thomas' text, but I still think some
>>clarification is needed:
>> 
>>> New:
>>> 
>>>     	<t> DHCPv6 <xref target='RFC3315' /> can be used to obtain and
>>> 	configure addresses. In general, a network may provide for the
>>> 	configuration of addresses through Router Advertisements,
>>> 	DHCPv6 or both.  Some operators have indicated that they do
>>> 	not intend to support stateless address autoconfiguration on
>>> 	their networks and will require all address assignments be
>>> 	made through DHCPv6. On such networks, devices that support
>>> 	only stateless address autoconfiguration will be unable to
>>> 	automatically configure addresses. Consequently all hosts
>>> 	SHOULD implement address configuration via DHCP.</t>
>> 
>> Should we give some guidance on what to do if both mechanisms are
>>available
>> on a network, the methods give contradictory information? I don't think
>>it is
>> enough to say that both SHOULD be supported, without giving additional
>> clarification on what it means when both are supported.
>
>I think the IETF has been pretty good about keeping the information from
>the two sources independent.  Regarding address assignment specifically,
>what contradictory information might be provided?  I can imagine a node
>might get one address from SLAAC and another from DHCPv6, but that's an
>acceptable configuration.  DHCPv6 doesn't provide prefix information, so
>no conflicts there.  I don't think there's an issue if DHCPv6 assigns an
>address that's not in a prefix advertised in an RA.
>
>- Ralph
>
>> 
>> John
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------