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

From: Andrea G Forte <[email-masked]>
Date: Tue, 14 Mar 2006 11:36:28 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Greg Daley <[email-masked]>
Date: Thu, 16 Mar 2006 16:42:49 -0500

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Mar 2006 15:12:41 -0700

Greg, I'm a little surprised by this discussion - I would think it unlikely 
and possibly even Really Bad to do stateless and stateful on the same wire at 
the same time.   Obviously you don't see it the same way.   Can you say 
anything about what sort of scenario would require this?   If you needed to 
support both, why not only advertise half the address range for stateless, 
and hold back the other half for stateful?

---

From: Greg Daley <[email-masked]>
Date: Thu, 16 Mar 2006 17:40:43 -0500

Hi Ted,

It's not a really bad idea to have SAA and DHCP on the
same link, it's how IPv6 was designed.  There is an
Autonomous (A) configuration flag, per prefix,
and a Managed Addressing (M) flag which governs the
use of DHCP assigned addressing.

No document indicates that they are mutually exclusive.
In fact, the document specifically describing M/O flag
issues nowhere mentions autonomous configuration flags.
(draft-ietf-ipv6-ra-mo-flags-01.txt)

This is because the system is generally useful, when
hosts using SAA and DHCP share the same link.

Say I have a server.  Should I get it an allocated address,
as we don't want the address tied to a particular NIC (which
may die) ?  We could easily use DHCP to retrieve this address
(rather than rely on Manual configuration).

Other devices on the same link may not need to have a DHCP
address, as they don't have a DNS entry.

You can't advertise half a /64. And the designators for
different classes of address multiplexed on the u/g bits
in the IID have all been taken.  DHCP necessarily resides
in the same address range as SAA.

This is going to happen.  Designing solutions which assume
addresses won't conflict is a Bad Idea.

Greg

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 17 Mar 2006 10:06:22 +0900

Hi Andrea - Let me clarify one point before jumping into
this thread. Are you targeting for an mobile environment
in conjunction with DHCP ? Obviously, DAD latency is
a problematic scheme at least in case user moves to a 
new wireless link. If yes, I think DHCP server extension
seems a bit simple and useful to maintain its DAD-free
address pool without user's DAD operation while 
configuring its own address. In case MN configures its
CoA address, I think aDAD would be fine...
(draft-han-mobileip-adad-01.txt)

Is there any other use cases ?

Thanks,

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Andrea G. Forte" <[email-masked]>
Date: Sat, 18 Mar 2006 21:53:57 -0500

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

---

From: Greg Daley <[email-masked]>
Date: Fri, 31 Mar 2006 09:58:04 -0500

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

---

From: Andrea G Forte <[email-masked]>
Date: Fri, 31 Mar 2006 17:50:28 -0500

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.

> unset to force global address configuration using DHCP,
I will be sure to add it in the next version of the draft.

> 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

>> your points as in the draft I clearly say "pDAD in its present form 
>> is not intended
>> 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.