Subject: Adoption call of draft-halpern-6man-nd-pre-resolve-addr for 6MAN

From: Ole Troan <[email-masked]>
Date: Wed, 24 Sep 2014 09:24:30 +0200

All,

The authors have requested an adoption call for this document as an informational document.

Please provide a view with reasons as to whether the WG should adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

	Title           : Triggering ND Address Resolution on Receiving DAD-NS
	Author(s)    : I. Chen, J. Halpern
	Filename    : draft-halpern-6man-nd-pre-resolve-addr-00
	Pages        : 7
	Date          : 2014-01-10

http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00

The call ends on October 1st, 2014.

Regards,

Bob Hinden & Ole Trøan

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 24 Sep 2014 02:30:32 -0700

Hi,

I think it is fine to document as (at least) Informational techniques that help further mitigate the ND cache DoS.

One thing the draft needs to mention/consider are hosts' anycast addresses, as DAD isn't performed for them. 

Regards,
Mark.

>________________________________
> From: Ole Troan <[email-masked]>
>To: 6man WG <[email-masked]> 
>Sent: Wednesday, 24 September 2014, 17:24
>Subject: Adoption call of draft-halpern-6man-nd-pre-resolve-addr for 6MAN
> 
>
>All,
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>
>
>

---

From: Karsten Thomann <[email-masked]>
Date: Wed, 24 Sep 2014 12:11:48 +0200

Hi,

I think it is good to document such mechanisms to mitigate DoS attacks.
One note is that the authors should replace the 2001::xx addresses with 2001:db8::xx.

Regards
Karsten

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Sep 2014 23:17:22 +0900

> Please provide a view with reasons as to whether the WG should adopt this

I'm not a fan of this technique because in my experience it encourages
implementation errors.

Lots of home routers already do something like this. If they do not first
see a DAD packet from a particular IP address they will not send any
traffic to that IP address. The result is that traffic to that address is
blackholed if DAD probes are missed, if the router reboots, etc.

This is obviously incorrect behaviour, and to be fair, the draft does not
suggest or allow it.

However, in real life what seems to happen is that because DAD snooping
works most of the time, the real IPv6 ND codepath where the router sends
multicast NS for new addresses that are not in its neighbour cache can
become buggy or unreliable. Perhaps the implementers don't test it, or
perhaps they don't think it needs to be implemented because DAD snooping
will always work. I don't know.

Obviously, a buggy implementation can break any standard, no matter how
robustly designed that standard is. But I think I have seen this problem on
at most of the home routers I've used, so it definitely seems that this
technique is error-prone.

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Sep 2014 08:20:21 +0200

for some additional information, here is the initial discussion of the draft back in January:
https://mailarchive.ietf.org/arch/search/?q=draft-halpern-6man-nd-pre-resolve-addr&gbt=1

and here is the IPR disclosure:
https://datatracker.ietf.org/ipr/2300/

Ole

> On 24 Sep 2014, at 9:24 , Ole Troan <[email-masked]> wrote:
> 
> All,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Sep 2014 08:17:46 +0000

Hi Ole and Authors:

I support this work. The operation is very close to what we already do to populate SAVI tables and is worth documenting. 

Suggestions/comments:

- When possible, the NS-DAD triggered resolution SHOULD be unicast to the Source MAC of the DAD as opposed to mcast. This is effectively more reliable if DEV5 is wireless, and a less impacting for the network in any case.

- DAD time out and retries may vary. All in all, it cannot be sure that the DEV5 address is not there before the next ~10 seconds. DEV1 could either trigger the resolution after a short timer (~1.5 seconds) and eventually perform retries when no answer is received, or wait ~10 seconds to probe. 

- If DEV1 is a SAVI switch doing that same probing operation upon NS DAD, it may not have a Link local address to source the probe with. It may source with unspecified IPv6, effectively probing with a NS DAD that may be perceived as a dup is the address is still tentative in DEV2. In that case, the switch should wait at least these same ~10 seconds.

- The strict application of the rules in the draft may cause silent nodes to be starved when the cache of the router is full of STALE entries for addresses that have been deprecated and replaced by the node, e.g. by some smartphones after a sleep cycle.  Probes could be resent periodically on STALE entries when the cache grows up, to make room, regardless of the origin of these entries. This applies in preference to addresses that appear to be based on RFC 4941.

What do you think?

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: jeudi 25 septembre 2014 08:20
> To: 6man WG
> Subject: Re: Adoption call of draft-halpern-6man-nd-pre-resolve-addr for
> 6MAN
>

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 25 Sep 2014 09:45:56 +0000

I had some offlist discussion with one of the author and now the mechanism is clear (there was misunderstanding on how it works). I found it really interesting and strongly support the adoption of this work.

Thanks,
Best,
Hosnieh

> Sent: Thursday, September 25, 2014 8:20 AM
> To: 6man WG
> Subject: Re: Adoption call of draft-halpern-6man-nd-pre-resolve-addr
> for 6MAN
>

---

From: JF Tremblay <[email-masked]>
Date: Thu, 25 Sep 2014 15:35:21 -0400

I’ve read draft-halpern-6man-nd-pre-resolve-addr-00 and support its adoption. 

It seems a useful mechanism to document. Actually, I’m even surprised by the IPR, as I thought this had been done earlier in several implementations, especially in some CMTS on the Docsis side (ND-DAD is required before anything IPv6 happens in MULPIv3.0). But Hemant would be in a better position than me to comment on this. 

I also second Karsten’s comment, please use 2001:db8::.

JF