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

[Andrea G Forte <[e-mail]>]

Greg,

please read answers inline.

> Sorry about the delay in replying.
No problem at all. I was at the IETF meeting in Dallas. Where you there 
as well? I would have liked to have your feedback at the meeting after 
the presentation.

> 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.
I will be sure to add it in the next version of the draft.

> 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.
We never intended pDAD to be a replacement for Optimistic DAD.
pDAD is meant to address the DAD problem in IPv4 networks. We just 
wanted to mention that perhaps it could be useful in IPv6 networks as 
well (with all the limitations we discussed).

One thing I wanted to ask you about your last point is that apparently a 
link-local address would be created mainly according to the client 
unique ID. Another alternative would be to use something else like a 
token of some sort. My impression though, would be that the former 
scenario is more realistic since you want something as unique as possible.

-Andrea

>
> 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