Re: To DAD or not to DAD?

Hemant, Erik, 

I will confess that I just don’t understand the cable modem scenario the
way you and the author understand it and that could be a flaw in my
understanding or due to different deployment models. I’ll leave the link
up indication aside, I’m not aware of cable modem deployments that act as
bridges where the upstream router (default router for every host on the
home network assuming a single link deployment), will share a prefix
across two homes for example. That is the only case where that modem’s
failure to connect to the ISP’s upstream router can cause issues when the
connection is established later.

In this simple case:

H1 <——————---->
             |   Modem <————>   ISP’s router
H2 <—————----->   

If the modem is an L2 device and it shows a link up to H1 and H2 when its
link with the ISP’s router is down, I fail to see how this will have a
negative impact on DAD if that ISP’s router is dedicating a separate
prefix for each “home”/“office” or whatever concrete container is built
around H1 and H2. 

I think I’ll just wait to see solutions or further discussion to
understand why this scenario is : 1) causing problems and 2) will be
solved by having reliable DAD.

I’m not talking about fragmented networks that are joined as a generic
case (I think that’s a clear problem in the general case), I am talking
about the above scenario because it came up several times in the
discussion. To me that link is not up and when it’s up H1 and H2 will
configure new addresses which they only need to check against each other.
Of course if that modem is a router, then it’s still the same situation
until it gets configured with a prefix.

Hesham

-----Original Message-----
From: "Hemant Singh (shemant)" <shemant@cisco.com>
Date: Saturday, 28 February 2015 10:59 pm
To: Erik Nordmark <nordmark@acm.org>, Hesham Soliman
<hesham@elevatemobile.com>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: To DAD or not to DAD?

>Specifically for a cable modem, I had contacted Andrew privately.   My
>comment to him for draft-yourtchenko-6man-dad-issues-00 and cable modem
>is included below between squared braces.
>
>[There is this text in your document
>
>"Similarly, a DSL or cable modem whose line status is invisible to IP
>   stack either within the modem or to a host connected on the Ethernet
>   side, also renders the DAD ineffective - the delay before the
>   connectivity is established can be much longer than any DAD wait."
>
>Remove cable modem from the above paragraph.  Cable standards mandate
>each time the RF interface of the modem bounces, the modem initiates DAD;
>so does RFC 4862.  Also, any cable modem resets its LAN interface if the
>modem's RF interface bounces.  This is also mandated in cable standards.]
>
>Hemant
>
>-----Original Message-----
>From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Erik Nordmark
>Sent: Saturday, February 28, 2015 3:35 AM
>To: Hesham Soliman; Erik Nordmark; 6man@ietf.org
>Subject: Re: To DAD or not to DAD?
>
>
>Protocols are supposed to be robust against packet loss. The fact that a
>modem or the spanning tree protocol can cause outages for an tens of
>seconds should just be a particular loss pattern meaning that things
>should recover after the connectivity is back.
>
>RS didn't do that, but now we have resilient-rs.
>
>But I don't think it is useful to have some more fine-grained view of
>different flavors of "link up" means. Do do that one would need to add
>something to the IEEE 802 set of protocols, get the Ethernet device
>drivers to implement that new thing, and then make the DAD code use it.
>Still, after that effort, it would only handle the STP case and not the
>modem case (AFAICT). In the modem case the local link in the house is up.
>But that Ethernet doesn't know that it is being bridged over a modem to
>some other devices; that bridging logic is layered on top of the Ethernet
>port behavior.
>
>    Erik
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------