Re: [dhcwg] draft-forte-dhc-passive-dad-01

[Greg Daley <[e-mail]>]

Hi Andrea,

Sorry about the delay in replying.

I appreciate that the system will work if the
network is designed to not support autoconfiguration
of global addresses.

As it stands though, the default configurations of
IPv6 address configuration allow SAA addresses to
co-exist with DHCPv6 addresses.  In this case the
guarantees you need don't work.

If you write an applicability statement for the IPv6
portion indicating the issue (v. brief), and indicating
that the Autonomous configuration (A) flag needs to be
unset to force global address configuration using DHCP,
this will help a lot.


Please be aware that the delays for link-local address
configuration will not be curtailed for this system,
as a link-local address is required to form a DHCP message.
For those addresses Optimistic DAD is still needed.

Greg

Andrea G. Forte wrote:
> Dear Greg,
> 
> first of all I want to thank you for the interesting comments.
> I agree with what you say, however I am a little surprised by some of 
> your points as in the draft I clearly say "pDAD in its present form is 
> not intended
> for supporting the stateless configuration mechanism of DHCPv6". This 
> means that I do not see pDAD as being applicable where Stateless Address 
> Allocation is used (mixed or not with Stateful Allocation).
> Optimistic DAD most probably is the way to go for IPv6, however I do not 
> see any harm in suggesting that pDAD could also be used in IPv6 when 
> only Stateful Address Allocation is used. Furthermore, I think that the 
> information provided by the AUC could be useful for other things than 
> just DAD such as intrusion detection ... but this is another story, with 
> its own set of problems.
> I want to look more in detail at Optimistic DAD and see if there are 
> some performance evaluations of real life deployments. Please let me 
> know if you or anyone else might have some pointers to it.
> 
> -Andrea
> 
> 
> Greg Daley wrote:
>> Dear Andrea,
>>
>> At the last IETF session, I mentioned that there is
>> previous work in this area for IPv6, which limits
>> the applicability of this solution to that protocol.
>>
>> There are significant issues in IPv6 which cause
>> problems with immediate address allocation to a configuring
>> host.  Particularly, IPv6 addresses can be allocated without
>> reference to DHCP servers, and hosts may sit passively
>> (without sending Neighbour Discovery packets) after it has
>> completed configuration for this address, unless
>> someone has a packet destined to them (in that case the
>> relay may not see the NA response).
>>
>> Given that IPv6 addresses configured through Stateless Address
>> Allocation (or manual configuration) do not have an explicit
>> expiry time, and may be constructed without reference to DHCP
>> addressing pools, any reboot of the passive AUC, DHCP server,
>> or even just unavailability at the time of Stateless Address
>> Autoconfiguration can cause the passive DAD service to assume
>> that an address is valid even though it is legitimately held
>> by an IPv6 host.
>>
>> Alternatives have been proposed in the past, which either
>> actively DAD check allocatable addresses in advance
>> (draft-han-mobileip-adad-01.txt) or force responses from
>> each address holder on the link (draft-daley-ipv6-mcast-dad-02.txt).
>> These allow an agent to either say a particular reserved address
>> is available, or that a particular requested address is definitely
>> not on a link.
>>
>> Saying that the pDAD will work for IPv6 now is incorrect,
>> as it cannot definitively say that the address is available,
>> and there's no way to "Retract" the allocation after a duplicate
>> address has been found, if it was inaccurate.
>>
>> Additionally, the cost of DAD in IPv6 is significantly reduced
>> due to Optimistic Duplicate Address Detection
>> (draft-ietf-ipv6-optimistic-dad-07.txt), which is in AUTH48 in
>> the RFC editor's queue.
>>
>> People will use Optimistic Duplicate Address Detection because it
>> is safe and it works with no modifications to peers or network
>> infrastructure, without the time expense you're trying to
>> counter.
>>
>> So please leave out IPv6 from your description.
>>
>> Greg
>>
>>
>> Andrea G Forte wrote:
>>  
>>> Dear all,
>>>
>>> we have submitted the new version of the pDAD draft.
>>> You can find it here:
>>> https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13702 
>>>
>>>
>>> We have also taken some measurements to show the traffic load between
>>> AUC and DHCP server.
>>> Please note that the measurements were taken using the old architecture
>>> (from draft 00) without client ID support.
>>> A short technical report regarding this can be found here:
>>> http://mice.cs.columbia.edu/getTechreport.php?techreportID=392&format=pdf& 
>>>
>>>
>>> I am looking forward to discuss it more in detail at the next IETF 
>>> meeting.
>>> Thank you for all your feedback.
>>>
>>> -Andrea
>>>
>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>>     
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg