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

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
>> dhcwg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dhcwg
>>     

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg