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

[Greg Daley <[e-mail]>]

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