Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: "Weil, Jason" <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; Liubing (Leo) <[e-mail]>; Wuyts Carl <[e-mail]>; "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Wednesday, 30 October 2013 6:59 AM
> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> I wasn't claiming it was a problem that a host has two addresses. I was
> just saying it might be beneficial in certain scenarios for all hosts on a
> network segment (SLAAC-only, SLAAC+DHC, DHC-only) to have a single address
> created using the same algorithm.
> 

Once you have a host using two different address configuration methods at the same time (SLAAC+DHC), then I don't think it is possible to avoid having a host have two addresses. 

Regarding the using the same algorithm, that is the reason why I asked for the text in the opaque stable IID draft to not specifically limit the address generation algorithm specified in it to be limited to SLAAC. There is no reason why a stateful DHCPv6 server couldn't use the algorithm to generate IPv6 addresses/IIDs before handing them to clients.

Regards,
Mark.


> Jason
> 
> 
> On 10/29/13 3:28 PM, "Mark ZZZ Smith" 
> <[e-mail]> wrote:
> 
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>>>  From: "Weil, Jason" <[e-mail]>
>>>  To: Liubing (Leo) <[e-mail]>; Wuyts Carl
>>> <[e-mail]>; "[e-mail]" 
> <[e-mail]>
>>>  Cc: "[e-mail]" <[e-mail]>; 
> "[e-mail]"
>>> <[e-mail]>;
>>> "[e-mail]"
>>> <[e-mail]>
>>>  Sent: Wednesday, 30 October 2013 1:44 AM
>>>  Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:
>>> draft-liu-bonica-v6ops-dhcpv6-slaac-problem
>>> 
>>>  Leo,
>>> 
>>>  First I wanted to say this is useful work and I support it.
>>> 
>>>  This topic in this email reminds me of an issue that we have run across
>>>  that might be relevant to your draft:
>>> 
>>>  The use case involves a home network whose gateway router sets M=1 and
>>> A=1
>>>  in order to provide DHC and and SLAAC for hosts that do not implement a
>>>  DHC client. If the DHCPv6 Server is implementing IP assignment using
>>>  interface-identifier and using the same prefix as advertised in the PIO
>>>  (assuming the server resides on the router advertising the PIO) with
>>> the A
>>>  bit set, hosts that support SLAAC and a DHCPv6 client could construct
>>> the
>>>  same address using DHC as the one they construct using SLAAC. What is
>>> not
>>>  clear is what hosts should do in this situation. IMO, there is a 
> benefit
>>>  if hosts that support both SLAAC and DHCPv6 construct the address and
>>>  prefer the DHC address over the SLAAC address. The benefit is that you
>>>  reduce the number of active addresses and all hosts end up with a 
> single
>>>  address per prefix administered in this fashion.
>>> 
>>>  Of course if your DHC Server implements another assignment algorithm
>>> (e.g.
>>>  Random) then your hosts that support both may end up with 2 addresses
>>> out
>>>  of the same prefix.
>>> 
>> 
>> Another way to describe your scenario is that it is a transition scenario
>> between SLAAC and stateful DHCPv6, since some of your hosts don't 
> support
>> stateful DHCPv6.
>> 
>> In your scenario, I don't think it is a big problem that some of your
>> hosts will have two addresses within the same prefix - IPv6 hosts are
>> designed to cope with many addresses, and a /64 has plenty of addresses
>> to go around.
>> 
>> If you do want to be specifically selective about which hosts use SLAAC
>> and which hosts use stateful DHCPv6 for addressing, use host specific RAs
>> which set the M and the PIO A bits on a selected host basis.
>> 
>> Regards,
>> Mark.
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary 
> information, which is privileged, confidential, or subject to copyright 
> belonging to Time Warner Cable. This E-mail is intended solely for the use of 
> the individual or entity to which it is addressed. If you are not the intended 
> recipient of this E-mail, you are hereby notified that any dissemination, 
> distribution, copying, or action taken in relation to the contents of and 
> attachments to this E-mail is strictly prohibited and may be unlawful. If you 
> have received this E-mail in error, please notify the sender immediately and 
> permanently delete the original and any copy of this E-mail and any printout.
>