Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 11 Oct 2011 10:39:16 -0500

Lorenzo,

I realized that the looping back of ND messages, especially during DAD
is an issue that needs to be solved at a fundamental level in ND DAD.
Thus I and Wes Beebee came up with a new document  for 6man that has no
need to sending probes and then also raising questions such as the ones
you raised as in what is the state of the address while the timer is
ticking.   You were on the right track with some of your statement
below.   There was some fun integrating with SEND and also some other
subtle issues.  I think our document can be referenced as an automated
means in the  draft-asati-v6ops-dad-loopback.  See

http://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt

Hemant 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Monday, August 29, 2011 6:15 AM
To: Erik Kline
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback

On Mon, Aug 29, 2011 at 18:54, Erik Kline <[email-masked]> wrote:

+1 to section 3.2, generally.

This is definitely a useful problem to solve. I have personally had to
work around this situation more than once, sometimes by disabling DAD
completely on routers.

A couple of points that the draft doesn't explain:

- Why can't the node simply retry DAD without the nonce option?

- How does the nonce option guarantee that the address is unique? Just
probabilistically, because the nonce would have to collide?

- Why only send the nonce on the second (and subsequent?) messages? Why
not simply send out all NSes with nonces all the time?

- What state is the address in while the timer is ticking?

Also: in some cases this happens when buggy drivers (typically wifi
drivers) loop back the node's own multicast packets. This is a violation
of 802.11, but nobody notices since it doesn't affect IPv4. With your
proposed scheme, DAD would succeed, but the node would be continuously
receiving its own multicast packets. What happens in such situations?

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Oct 2011 11:47:38 -0400

Just so everyone's on the same page, although this draft originally targets v6ops, it is going to be looked at in 6man (per the 6man chairs). That's a discussion you may want to have in 6man.

On Oct 11, 2011, at 11:39 AM, Hemant Singh (shemant) wrote:

> Lorenzo,
>  
> I realized that the looping back of ND messages, especially during DAD is an issue that needs to be solved at a fundamental level in ND DAD.   Thus I and Wes Beebee came up with a new document  for 6man that has no need to sending probes and then also raising questions such as the ones you raised as in what is the state of the address while the timer is ticking.   You were on the right track with some of your statement below.   There was some fun integrating with SEND and also some other subtle issues.  I think our document can be referenced as an automated means in the  draft-asati-v6ops-dad-loopback.  See
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
> This is definitely a useful problem to solve. I have personally had to work around this situation more than once, sometimes by disabling DAD completely on routers.
>  
> - How does the nonce option guarantee that the address is unique? Just probabilistically, because the nonce would have to collide?
> - Why only send the nonce on the second (and subsequent?) messages? Why not simply send out all NSes with nonces all the time?
> Also: in some cases this happens when buggy drivers (typically wifi drivers) loop back the node's own multicast packets. This is a violation of 802.11, but nobody notices since it doesn't affect IPv4. With your proposed scheme, DAD would succeed, but the node would be continuously receiving its own multicast packets. What happens in such situations?
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Washam Fan <[email-masked]>
Date: Thu, 20 Oct 2011 21:47:28 +0800

Hi,

Sorry for late response.

Since NS(DAD) traverse the same link, couldn't we just use src MAC of
the received NS(DAD) to identify if the NS is the one sent by the
interface earlier?

Am I missing something?

THanks,
washam

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Oct 2011 16:07:01 +0200

Hi,

> the received NS(DAD) to identify if the NS is the one sent by the

Yes.  Not all the world is Ethernet.

We've seen this problem mostly on SDH/Sonet links, which are either
HDLC or PPP encapsulated, and don't have MAC addresses in their frames.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 09:08:19 -0500

Washam,

-----Original Message-----
From: Washam Fan [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 9:47 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Erik Kline; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback

No.  Two nodes could almost simultaneously issue a NS(DAD) and both the
nodes have the same mac-address and thus the situation is a DAD failure
and not a looped back NS(DAD).  I use the term of NS(DAD) to denote a NS
issue for the purpose of DAD where the NS has a unspecified source
address.  That is why a nonce is needed and specified in a completed
algorithm to detect looped back NS(DAD) messages in 

http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01

Hemant

---

From: "George, Wes" <[email-masked]>
Date: Thu, 20 Oct 2011 10:19:29 -0400

> a completed
[WEG]] It is also worth noting that the authors of draft-asati are working to incorporate some elements of that draft into the one that Hemant mentions above, and a single draft will proceed within 6man - draft-asati will most likely expire in silence :-)

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 09:32:22 -0500

WesG,

Thanks for the update.  Chairs of 6man, please expect us to present a
merged document at the Taipei IETF.  The asati and hsingh doc teams are
working together to complete a single doc.  We will try and publish the
new merged copy in about a week.

Regards,

Hemant

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 10:19 AM
To: Hemant Singh (shemant); Washam Fan
Cc: [email-masked]; [email-masked]
Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback

> http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01
[WEG]] It is also worth noting that the authors of draft-asati are
working to incorporate some elements of that draft into the one that
Hemant mentions above, and a single draft will proceed within 6man -
draft-asati will most likely expire in silence :-)

Wes George

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 20 Oct 2011 13:53:27 -0500

Hi Lorenzo,

Sorry about the delayed response (and thanks to Hemant for pointing this
out). Pls see inline,

> - Why can't the node simply retry DAD without the nonce option?

The node could simply do so, however, it wouldn't be able to
differentiate between the looped message and spoofed message.

Nonce usage significantly eliminates the possibility of a remote node
sending the spoofed message, and causing the node to think that circuit
being looped when it is not really.

> probabilistically, because the nonce would have to collide?

Nonce doesn't guarantee anything by itself, IMO.

> - Why only send the nonce on the second (and subsequent?) messages?
Why not
> simply send out all NSes with nonces all the time?

This is a good Q. The reason is that the Nonce usage requires the node
to create and maintain the state for some time (t). It is useful when
there is a loop, so the rationale was to first detect the _possibility_
of loop after the 1st receipt and confirm it with Nonce so as to keep
IPv6 enabled.  

Of course, the possibility of the remote node reflecting the same Nonce
value in the spoofed message certainly exists, though it is remote.  

The full-proof way to solve this is SeND, needless to say.

> - What state is the address in while the timer is ticking?

UP (or UP/Looped).

> Also: in some cases this happens when buggy drivers (typically wifi
drivers)
> loop back the node's own multicast packets. This is a violation of
802.11, but
> nobody notices since it doesn't affect IPv4. With your proposed
scheme, DAD
> would succeed, but the node would be continuously receiving its own
multicast
> packets. What happens in such situations?

None of the proposals (including this one) stop the multicast packets
from coming back. Simplest thing is to drop them, based on the Nonce
value. 
	
Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lorenzo Colitti
work
> around this situation more than once, sometimes by disabling DAD
completely on
> routers.
> - Why only send the nonce on the second (and subsequent?) messages?
Why not
> simply send out all NSes with nonces all the time?
> 
drivers)
> loop back the node's own multicast packets. This is a violation of
802.11, but
> nobody notices since it doesn't affect IPv4. With your proposed
scheme, DAD
> would succeed, but the node would be continuously receiving its own
multicast
> packets. What happens in such situations?

---

From: Washam Fan <[email-masked]>
Date: Fri, 21 Oct 2011 11:07:12 +0800

Hi,

> HDLC or PPP encapsulated, and don't have MAC addresses in their frames.
Thanks Gert. Got your points.

washam

---

From: Washam Fan <[email-masked]>
Date: Fri, 21 Oct 2011 11:11:13 +0800

Hi Hemant,

2011/10/20 Hemant Singh (shemant) <[email-masked]>:
> and not a looped back NS(DAD).

Good catch. Thanks.
washam

> I use the term of NS(DAD) to denote a NS