Subject: [Efficientnd-dt] Update to dad-issues draft

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Feb 2015 22:52:34 -0800

Andrew and I have made some updates to the dad-issues draft, mainly to 
order the list to make it more clear which issues remain, which are 
already (being) solved and which are more observations about DAD.

Comments welcome,
     Erik

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 27 Feb 2015 07:59:32 +0000

Erik and Andrew,

Some quick comments:
- in intro: add xref to RFC 2460, worth to copy the description of DAD
mechanism in your document if not too long? Also introduce the DAD acronym
early in the intro
- 2.3 should explicitly mention wireless? Should mention the I-D regarding
the use/abuse of mcast traffic by NDP?
- I like the classification by groups of issues rather than the long list
- 3.2 in case of duplicate address, not only TCP is impacted. If the new
host (with colliding address) does not listen on UDP port X while the old
one does, then ICMP port unreachable will be sent which could have
undesirable consequences
- 4.3 readability/clarity could be improved, esp paragraph 4
- 4.5 s/anywhere/anyway/ ?

Hope it helps

-éric

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Feb 2015 14:34:33 -0800

> mechanism in your document if not too long? Also introduce the DAD acronym

Eric,
Thanks for your comments.

DAD is described in 2462. What do we need to cite from 2460?
I'll add a short description of DAD and expand the acronym.
> the use/abuse of mcast traffic by NDP?
2.3 is about Partition-join tolerance. I don't know if there are 
specific partition issues for wireless that are worth mentioning.

Section 2.2 is about the packet loss. We should add a reference in 2.2  
- mcast-not-efficient makes sense. Did you have some additional draft in 
mind?

Should we add a reference to 
draft-desmouceaux-ipv6-mcast-wifi-power-usage? That was more about power 
consumption AFAIR. I'll add a reference to that draft in the efficiency 
section.
> one does, then ICMP port unreachable will be sent which could have
Agreed.

While other protocols can be affected, the description of this is more 
subtle. If the new host sends a packet to some peer the response will go 
back to the old host, which as you say might generate an error. Some 
protocols like a DNS lookup doesn't care about those unreachables. But 
an application layer protocol using UDP which creates or modifies some 
state when it receives the packet from the next host might cause 
failures for the old host's communication. The optimistic DAD draft 
doesn't go into those details, and it is a bit of a tangent for this draft.

Thus I don't want to go into all those details in this draft. I could be 
convinced to add some vague language like
     "Other protocols which manage state like TCP create could also be 
affected."

> - 4.3 readability/clarity could be improved, esp paragraph 4

That is the paragraph about NBMA. I think Andrew added that. I don't 
know if we'd view a multi-link subnet as an NBMA link since each link is 
still broadcast, while the subnet would not have a notion of a 
link-layer broadcast.

A WiFi link and subnet with blocked host-to-host communication is 
different again; there is a subnet prefix assigned to the link, and 
link-local broadcast/multicast can be used for some communication paths 
(e.g., a router can send to all-nodes multicast and it will get through, 
but a host's multicasts will be filtered.)

Perhaps we should preface this with some more explanatory text, and also 
rename the section to be about "odd links" which includes
  - multi-link subnets
  - NBMA links
  - filtering host-to-host communication on a link
With such a prelude, would things be more clear? Or are there specific 
clarifications in para 4 that would fix it?

> - 4.5 s/anywhere/anyway/ ?
Will fix.

Thanks again
    Erik

> _______________________________________________
> Efficientnd-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/efficientnd-dt
>

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 28 Feb 2015 14:04:03 -0800

I've done some updates based on the below comments plus the ones on the 
list.

I think the draft is good enough to be submitted but other comments are 
welcome.

    Erik