Subject: [v6ops] DAD issues in IPv6 backbone environments

From: Eli Dart <[email-masked]>
Date: Mon, 15 Aug 2011 19:45:47 -0700

Hi all,

We have run across an operational issue with IPv6 in backbone 
environments.  The issue concerns Duplicate Address Detection (DAD).

It is common in backbone environments to troubleshoot some transport 
system issues by installing soft loops in the middle of the problem 
circuit facing the ends, and walking the loops out toward the routers at 
the ends while checking for connectivity.  This is a common 
fault-isolation technique.  In an IPv4 network, connectivity on the 
circuit is restored when the loops are removed and the circuit is 
normalized.  In an IPv6 network, this is not always the case.

In an IPv6 network, when the loops are installed the routers at the ends 
see themselves and therefore believe that another host in the same 
broadcast domain has the same address.  RFC 4862 section 5.4.5 states 
that when DAD detects a duplicate address that appears to be derived 
from a hardware address (e.g. duplicate link-local address), IPv6 
operation on the interface SHOULD be disabled.  Since the circuit is 
looped back on itself, the router sees itself and shuts down IPv6 
processing on that interface.

The result of this behavior is that transport-layer troubleshooting can 
break IPv6, and IPv6 can stay broken even after the circuit is 
normalized (soft loops can be installed and removed without causing the 
interface to bounce, so DAD is never reset).  IPv4 does not have DAD, so 
IPv4 is self-healing under these circumstances.  Therefore, you can get 
into a situation where IPv4 has self-healed, and IPv6 stays broken until 
somebody notices.

ESnet has asked one of our router vendors for an interface config knob 
(off-by-default so as to avoid direct confrontation with standards) that 
would cause a router with an interface disabled due to DAD to re-run the 
DAD test on the interface periodically, subject to a timer.  This would 
cause IPv6 to be self-healing in the same way that IPv4 is self-healing 
under troubleshooting conditions common in backbone environments.  Note 
that the semantics here are very similar to the err-disable state 
timeout on Cisco routers.

Please understand that this behavior is almost certainly not unique to 
one vendor - this is behavior that is specified by and conforms to 
current IPv6 standards.  The standard behavior appears reasonable in a 
LAN environment.  However, it appears suboptimal in a backbone/provider 
networking context.

Many thanks,

		--eli

-- 
Eli Dart                                            NOC: (510) 486-7600
ESnet Network Engineering Group (AS293)                  (800) 333-7638
Lawrence Berkeley National Laboratory
PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3

---

From: Greg Daley <[email-masked]>
Date: Tue, 16 Aug 2011 16:20:30 +1000

Hi Eli, 

I am concerned that the DAD timer isn't specifically the issue.

An interface timer doesn't fix things because next time DAD NS is sent 
the address is still "Duplicate" because the NS will be received 

again by the interface. If another (4941 privacy, CGA) address is picked it would also be seen as "Duplicate" whenever they are selected.

This is because the duplicate DAD NS will be seen while the address is tentative.

S5.4.3 of 4862 defines appropriate behaviour for the case where multicast messages may be looped back.  This is effectively

a case as defined there.  

It also specifies the circumstances where a device is to believe the simultaneous DAD NS indicates a duplicate attempt.  An 
in depth treatment of this is provided in Appendix A, which deals with the difficulty of identifying duplicate Link-layer addresses.

The loopback semantics being defined within the network are not that there is a duplicate device or that there is a duplicate MAC
address but that the number of multicast NS messages received by an interface exceed that expected by the MAC.

This is really only an issue with DAD NS while you are tentative of course, since if you receive a  DAD defense NA (to all-nodes), you
know you did not send it.   Once you have completed DAD, any new DAD NS messages (with unspecified source) are defended
against with multicast NA.

So really on some media or environments, it may be necessary to ignore DAD NS packets with the same source Link-Layer address
while the interface comes up and is tentative.  this could be specified with a (Default=off) interface level flag.

This leads to a slight weakening of DAD in these circumstances, but as discussed in Appendix A, duplicate MAC addresses are a hard
issue anyway.

Greg Daley

> Date: Mon, 15 Aug 2011 19:45:47 -0700
> From: [email-masked]
> To: [email-masked]
> Subject: [v6ops] DAD issues in IPv6 backbone environments
> 
> Hi all,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Aug 2011 10:09:57 +0200 (CEST)

> LAN environment. However, it appears suboptimal in a backbone/provider 

I've seen this happening on POS interfaces (which by definition isn't even 
a LAN interface, it's a point-to-point interface). Haven't seen it in a 
while, so it might be that the vendor actually disabled DAD on this type 
of interface in newer versions.

But yes, I agree, this is a problem.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2011 10:50:48 +0200

Hi,

> But yes, I agree, this is a problem.

Same here (on POS, because we don't usually loop ethernet interfaces,
but I can see the problem there as well).

Gert Doering
        -- Operator
-- 
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: Thomas Narten <[email-masked]>
Date: Tue, 16 Aug 2011 09:24:16 -0400

Having a configuration knob to turn of DAD to deal with these sorts of
issues seems perfectly reasonable to me. Fine for a router, seems
unnecessary for a host. Disabled by default.

I don't think any spec needs to be changed. This is an example of the
kind of thing an implementation should just be able to do if
necessary.

Thomas

---

From: [email-masked]
Date: Tue, 16 Aug 2011 15:48:27 +0200 (CEST)

> kind of thing an implementation should just be able to do if

The desire is not necessarily to turn off DAD, but to ensure that DAD
is retried once in a while.

I have at least two different use cases here:

1. An Ethernet circuit is looped (for instance, via Ethernet over SDH
and a loop in the SDH network). The router sees itself via DAD, and
disables the interface. When the loop is removed, the interface is
*not* automatically enabled again. I would like DAD to be rerun after
automatically after a while - this removes the need for manually
bouncing the (sub)interface.

2. The customer on a point to point Ethernet circuit configures the
same IPv6 address as the provider, and DAD disables the interface at
the provider end. When the config error is corrected at the customer
end, the interface is *not* automatically enabled again. As above, I
I would like DAD to be rerun after automatically after a while - this
removes the need for manually bouncing the (sub)interface.

Particularly in the second case I absolutely *don't* want to turn off
DAD permanently. In the first case turning off DAD might be a solution,
but rerunning at intervals seems to me to be a *better* solution.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Aug 2011 09:55:38 -0400

> bouncing the (sub)interface.

So, it's OK for the  interface to go down for an extended period of
time (i.e., until DAD is rerun some time later)?

Isn't this a case where you'd want to "kick" the interface to try
again (once the loopback is disabled)

> removes the need for manually bouncing the (sub)interface.

What kind of time frame are you talking about? I'd be worried if the
"rerun DAD" timer was short, because it would increase the odds that
DAD would succeed when it shouldn't. But if the time out is long, it
seems to me you wouldn't really solve the customer problem. I.e, you
can't tell them to "fix your address, and wait 3 hours". Right?

> but rerunning at intervals seems to me to be a *better* solution.

Again, what time frames are you talking about?

Thomas

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2011 15:55:46 +0200

Hi,

> but rerunning at intervals seems to me to be a *better* solution.

+1

(possibly combined with the "if it's coming from my own MAC address, 
assume it's me talking to myself and don't take it as DAD failure at 
all" approach)

Gert Doering
        -- Operator

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Aug 2011 10:05:03 -0400

> assume it's me talking to myself and don't take it as DAD failure at 

If you see a packet with your own MAC address  as the source, there
are two possibilities:

1) You are seeing your own packet (e.g., a loopback)

2) There are interfaces with duplicate MAC addresses on your network.

Fundamentally, DAD detects the second case (since stateless address
autoconf generated address contains the embedded MAC address).

If you assume that any received packet with a src MAC address that is
the same as your own is in fact your own, you might as well not bother
running DAD at all. But doing so opens up your network to even bigger
problems, because things won't work right (when duplicate MAC addrs
exist), but diagnosing the situtuation is difficult. IPv6 defined DAD
the way it did to prefer disabling interfaces in such cases rather
than trying to automatically do something different because
fundamentally, when you have to machines using the same MAC addr you
have problems that can't be fixed without operator intervention.

Thomas

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2011 16:17:48 +0200

Hi,

> 2) There are interfaces with duplicate MAC addresses on your network.

Indeed.

> autoconf generated address contains the embedded MAC address).

In ISP networks, the first case happens more often than the second
case, and DAD-without-retries forces operator action, which is something
to avoid.

(One of the examples we saw was a transient failure on a STM-1, which 
led to a "link down", "link up with loop", "link stays up but loop goes 
away" situation - IPv4 recovered just fine, IPv6 died, because DAD
disabled IPv6 and kept it down.  Image this link flap being at 3 am
in the morning, and someone having to get out of bed to fix something
for IPv6 that wasn't needed for IPv4...)

> running DAD at all. 

Having such a knob available for the ISP side of things would not
something I'd object to...  (or a DAD variant that will warn you, but 
not disable the protocol - like what Cisco does for IPv4, warn that
there is a duplicate address, but use it anyway)

> But doing so opens up your network to even bigger

In my network history, I have seen one case of duplicate MAC (which was
indeed quite painful to diagnose), and numerous cases of links being
looped for diagnosis.  So for our application case, something that fixes
a very rare problem by making a "nearly day-to-day" operation *break*
is not the right answer.

Of course DAD catches more than "duplicate MAC", but also "mis-typed
static IPv6 configuration" - and that, indeed, happens every so often,
so DAD should learn to discern the difference - 

 "same IPv6 address, different MAC -> not me, shutdown protocol" 

 "same IPv6 address, same MAC -> might be me, flag warning, don't 
  disable port, retry in regular intervals" (so if it's indeed a 
  duplicate MAC address, the logs will at least hint at the problem)

Gert Doering
        -- Operator

---

From: Philip Homburg <[email-masked]>
Date: Tue, 16 Aug 2011 16:25:26 +0200

>the same as your own is in fact your own, you might as well not bother

It's a little bit more subtle. That packet you would discard is identical to
the one you just sent. If you just sent an NS, and you got an NA, then 
obviously there is something wrong. 

If you just sent an NS and got an extra NS, then it could be either a loop or
a duplicate MAC.

If, when adding systems to a link, you do it slowly enough that one node will
have completed DAD before the next one starts, then you don't need to do
anything special in case of duplicate MACs.

For router networks, this is typically the case.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Aug 2011 10:39:56 -0400

As I recall, the classic solution for this in the PPP case was to 
include a random nonce in the message.  If you got your own nonce, you 
could assume it was a reflected message.

It is not clear to me that is worth doing in this case.

Yours,
Joel

---

From: Doug Barton <[email-masked]>
Date: Tue, 16 Aug 2011 07:59:48 -0700

> 2) There are interfaces with duplicate MAC addresses on your network.

3) Your network is under a DOS attack.

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Aug 2011 11:42:59 -0400

> It is not clear to me that is worth doing in this case.

Agreed.

That said, it would not be very hard to define/add a Nonce option,
that could (optionally) be included in NS (or other ND
messages). Implementations would be required to ignore them (per
existing specs).

We'd then find out to what degree current implementations actually do
ignore options that say "ignore if you don't understand". :-)

Indeed, if you really wanted to properly "solve" the problem of
detecting when loopback has been enabled/disabled, you could detect
the condition (easily) and at fairly high frequency probe the link to
see when the condition has been fixed.

Thomas

---

From: [email-masked]
Date: Tue, 16 Aug 2011 18:06:03 +0200 (CEST)

> time (i.e., until DAD is rerun some time later)?

I was thinking of rerunning DAD, say, every 5 to 10 minutes. If it
takes 5 to 10 minutes for a problem to "fix itself" (i.e. we don't
have to do something on our router) that's okay.

> again (once the loopback is disabled)

If the delay is 5 to 10 minutes, I would much rather avoid "kicking"
the interface, because that requires manual intervention on router.
Also, note that the people removing the loop and the people who could
"kick" an interface might very well be very different.

> can't tell them to "fix your address, and wait 3 hours". Right?

5 to 10 minutes is the timeframe I'm thinking of.

---

From: Eli Dart <[email-masked]>
Date: Tue, 16 Aug 2011 09:08:53 -0700

> bouncing the (sub)interface.

Yes.  This is especially problematic when the subinterface (or 
interface...the issue is the same) is carrying both IPv4 and IPv6 
traffic.  This means you take a hit in one address family to correct for 
an issue in another address family.

> but rerunning at intervals seems to me to be a *better* solution.

Yes.

		--eli

---

From: [email-masked]
Date: Tue, 16 Aug 2011 18:09:20 +0200 (CEST)

>  "same IPv6 address, different MAC -> not me, shutdown protocol" 

But I'd like DAD retry to be performed even here.

---

From: Eli Dart <[email-masked]>
Date: Tue, 16 Aug 2011 09:12:23 -0700

> Again, what time frames are you talking about?

Something with reasonable utility on troubleshooting and maintenance 
window time scales.  I know that's mushy, but really that's the need.  I 
think tens of seconds to low single-digit minutes, configurable by 
operator (e.g. a timer specified in seconds, with acceptable values in 
the range 30 - 3600) is about right.

It would also be desirable to have a CLI operational-mode command to 
kick DAD for real-time troubleshooting, but that's not a standards issue.

		--eli

---

From: [email-masked]
Date: Tue, 16 Aug 2011 18:17:29 +0200 (CEST)

> a very rare problem by making a "nearly day-to-day" operation *break*

Agreed. Also, as you pointed out, it is important that IPv6 isn't seen
as significantly more problematic than IPv4 operationally...

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Aug 2011 09:25:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Thomas Narten
> Sent: Tuesday, August 16, 2011 8:43 AM
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: [v6ops] DAD issues in IPv6 backbone environments
> 

Can the nonce option defined in RFC3971 be used for
this purpose?

Fred
[email-masked]

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Aug 2011 18:31:03 +0200

Hi,

> But I'd like DAD retry to be performed even here.

No objections.  A configurable knob would certainly be useful.

Gert Doering
        -- NetMaster

---

From: Greg Daley <[email-masked]>
Date: Wed, 17 Aug 2011 05:27:21 +1000

Hi Fred, 

Yes.  The nonce from 3971 can be used for identification of the NS.

I was thinking about using it in NA responses when working out potential solutions for/before the DNA working group.

In the end we went for a mechanism that didn't require message content changes.

The essence here is that the nonce would have to (MUST) be decoupled from the IID and MAC address generation.

Greg Daley

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Tue, 16 Aug 2011 09:25:31 -0700
> CC: [email-masked]

---

From: Greg Daley <[email-masked]>
Date: Wed, 17 Aug 2011 05:49:03 +1000

Hi Thomas, 

> have problems that can't be fixed without operator intervention.

I think that the issue here is the period where duplicate MACs exist and IIDs are both tentative, 
since an existing address will not be tentative (will defend), and will not be shutdown.

Where both are tentative and see the DAD-NS, the consequences of ignoring it are that neither detects
simultaneous DAD.

If one of the devices completes DAD and state transitions from tentative, it could then send  all-nodes NA.

We remain with a race condition where either could become non-tentative without having seen the other's NA.
(which is a small chance given initial NS backoff timers).

I think that comparison of Nonces as indicated by Fred is possibly better, but the randomness of the Nonces
need to be assured, so we don't pick another colliding identifier.

Greg Daley

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 16 Aug 2011 16:44:24 -0500

Eli,

> interface to bounce, so DAD is never reset).   

If the IPv6 enabled interface was up/functional before the soft loop was
placed, then why should DAD/NS be firing up after the soft loop is
placed (given that the interface didn't bounce)?

> DAD test on the interface periodically, subject to a timer.  This
would

Well, the better solution would be for the node to check the src MAC
addr, declare the packets getting looped back if matched, and log this
event. 

If not, then just disable DAD (e.g. rfc4862 section4) on a p2p
interface. 

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eli
> Dart
> Sent: Monday, August 15, 2011 10:46 PM
> To: IETF v6ops list

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 16 Aug 2011 17:17:53 -0500

Gert,

+1

>   duplicate MAC address, the logs will at least hint at the problem)

+1 (almost). 

Well, there isn't any benefit in retrying for the sake of it, unless we
want to shut down the protocol after few (5,10,..?) retrials. But the
number would have to depend on the time-gap taken by the layer1-looping
event. And that is very non-deterministic, making a headache to choose
the right no (variable in every network).

So, the logging part by itself is beneficial, of course, while
recognizing it as a loopback. 

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gert
> Doering
> Sent: Tuesday, August 16, 2011 10:18 AM
> To: Thomas Narten
> Cc: [email-masked]

---

From: Eli Dart <[email-masked]>
Date: Tue, 16 Aug 2011 15:24:46 -0700

> want to shut down the protocol after few (5,10,..?) retrials.

We should not do that - if we do that, we're back where we started, i.e. 
IPv6 goes down hard and stays down until a person touches it.  In a 
circumstance where one part of the organization (the people who run the 
DWDM/Optical infrastructure) are doing work, this means that people from 
a potentially completely different part of the organization (the people 
who run the routing infrastructure) need to go restore service after the 
maintenance, or at least check to make sure IPv6 didn't wedge itself.

> But the

What is wrong with retrying periodically?  The point is to do this every 
few tens of seconds, or every minute or two, so as to avoid spending a 
lot of CPU on DAD.  However, the desire is that layer 3 be self healing 
once layer 2 has been fixed.  IPv4 is self-healing in this way.  IPv6 is 
currently not.

		--eli

>>> Gert Doering<[email-masked]>  writes:
>>>

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Aug 2011 17:14:36 +0900

+1

---

From: Scott Beuker <[email-masked]>
Date: Wed, 17 Aug 2011 21:12:00 +0000

+1

I'd use this timer, with a very high value of ~30 minutes or so. We've been dealing with this issue for a while now, when I approached our vendor about either a retry timer or even just a command to force another DAD attempt, it went nowhere.

Right now we use an anomaly report that compares the state of IPv4 and IPv6 on an interface, and alerts are operations staff if they're not equal (and addresses are configured for both). Our non-IPv4 impacting solution to get IPv6 unstuck is to manually assign an IPv6 link-local address, and then remove it, which triggers DAD for the link-local to take place again.

- Scott

---

From: Thomas Narten <[email-masked]>
Date: Tue, 23 Aug 2011 11:30:27 -0400

> > What is wrong with retrying periodically?  The point is to do this
> > every few tens of seconds, or every minute or two, so as to avoid
> > spending a lot of CPU on DAD.  However, the desire is that layer 3
> > be self healing once layer 2 has been fixed.  IPv4 is self-healing
> > in this way.  IPv6 is currently not.

I agree. The other thing to keep in mind is that if an interface is in
loopback mode, the interface is effectively not working (i.e,. not
forwarding traffic), and any "load" caused by such probes is
pretty much irrelevant.

What I'd suggest as a next step is that someone write a short ID that
describes the problem, and sketches out a recommended algorithm for
handling this situation.

E.g., use NS/ND probes to detect the condition, switch to periodic
probing mode when the interface is in loopback, and then describe
how/when to switch back to normal mode.

This appears to be doable using existing packet/option formats, so no
new protocol extensions are needed.

We can then publish it as a short BCP or informational document (we
can figure out later which once the actual content has been worked
out).

Do we have a taker?

Thomas

---

From: Eli Dart <[email-masked]>
Date: Tue, 23 Aug 2011 10:02:11 -0700

> can figure out later which once the actual content has been worked

Yes - I'll take it.

I have never written an ID before, so I'll need the help that a newbie 
would be expected to need.  However, I'm happy to contribute.

Many thanks,

		--eli

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 23 Aug 2011 13:19:51 -0500

Thomas,

I started the ID already. Would appreciate the
participation/contribution.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Thomas Narten
> Sent: Tuesday, August 23, 2011 11:30 AM
> To: Scott Beuker
> Cc: [email-masked]

---

From: Eli Dart <[email-masked]>
Date: Tue, 23 Aug 2011 14:16:40 -0700

Hi Rajiv,

> participation/contribution.

OK - sounds fine.

Thanks,

		--eli

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 24 Aug 2011 14:56:54 -0500

Thomas,

Please see inline,

> forwarding traffic), and any "load" caused by such probes is

Well, the ND messages are likely handled by the CPU, which may not get
involved for forwarding packets. So, whether or not the interface is
being used (for forwarding packets) is irrelevant for ND messages
handling.

> new protocol extensions are needed.

Agreed. I have drafted the ID and would submit in a week or so.

Cheers,
Rajiv

Of

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 26 Aug 2011 09:56:43 -0400

Rajiv -

I've reviewed your draft, and I have some comments on your solution algorithm. I agree that this is a potential problem, and I support this work.
I think that there are some situations where this will still result in the original brokenness - If the loop is placed, but the problem is intermittent, the following might occur:

Loop up
Step 1
Step 2
Loop drops (fault on the line) causing step 3 to fail
step 4/5, leading to disabled IPv6.
The above is a corner case example, but does happen. It may be necessary to add some explicit recommendation that if the interface changes state, everything resets and the duplicate is ignored, rather than simply relying on timers.

An alternate way to do this is to recommend that the implementation uses any built-in loop detection mechanism of the underlying interface to signal ND to temporarily disable DAD.
For example, when a Cisco router sees a certain set of conditions on an interface using HDLC, the interface shows up/up (looped). It should be possible to simply use that state change as a trigger to disable DAD temporarily, and when the state changes back to down or up (but not looped) DAD is re-enabled.
Your proposed solution would still be a good recommended enhancement for implementations that do not have some lower-layer method to detect the presence of a loop.

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Wednesday, August 24, 2011 3:57 PM
To: Thomas Narten; Scott Beuker
Cc: [email-masked]
Subject: Re: [v6ops] DAD issues in IPv6 backbone environments

Thomas,

Please see inline,

Cheers,
Rajiv

Of

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: Fri, 26 Aug 2011 10:07:45 -0500

Hi George,

Appreciate the feedback.

> I agree that this is a potential problem, and I support this work.

Thanks.

> step 4/5, leading to disabled IPv6.

If the loop dropped, then 
 - If the interface stayed UP, then step 5 result in keeping IPv6
enabled on that interface, since the same NS message as the one
transmitted should no longer be removed.
 - If the interface went DOWN, then IPv6 would stay enabled (since step
2 hadn't disabled it) and follow the normal course (this needs to be
phrased better in the draft, as you suggest below).

> The above is a corner case example, but does happen. It may be
necessary to
> add some explicit recommendation that if the interface changes state,
> everything resets and the duplicate is ignored, rather than simply
relying on
> timers.

Good suggestion. I agree to adding this text.

> An alternate way to do this is to recommend that the implementation
uses any
> built-in loop detection mechanism of the underlying interface to
signal ND to
> temporarily disable DAD.

Good suggestion. That's worth adding as the 3rd solution as well. 

> Your proposed solution would still be a good recommended enhancement
for
> implementations that do not have some lower-layer method to detect the
> presence of a loop.

I agree.
 
Cheers,
Rajiv

> From: George, Wesley [mailto:[email-masked]]
> Sent: Friday, August 26, 2011 9:57 AM
> To: Rajiv Asati (rajiva); Thomas Narten; Scott Beuker
> Cc: [email-masked]
> Subject: RE: [v6ops] DAD issues in IPv6 backbone environments
> 
> Rajiv -
> 
> I've reviewed your draft, and I have some comments on your solution
algorithm.
> I agree that this is a potential problem, and I support this work.
> I think that there are some situations where this will still result in
the
> original brokenness - If the loop is placed, but the problem is
intermittent,
> the following might occur:
> 
> Loop up
> Step 1
> Step 2
> The above is a corner case example, but does happen. It may be
necessary to
> add some explicit recommendation that if the interface changes state,
> everything resets and the duplicate is ignored, rather than simply
relying on
> timers.
> 
> An alternate way to do this is to recommend that the implementation
uses any
> built-in loop detection mechanism of the underlying interface to
signal ND to
> temporarily disable DAD.
> For example, when a Cisco router sees a certain set of conditions on
an
> interface using HDLC, the interface shows up/up (looped). It should be
> possible to simply use that state change as a trigger to disable DAD
> temporarily, and when the state changes back to down or up (but not
looped)
> DAD is re-enabled.
> Your proposed solution would still be a good recommended enhancement
for
> implementations that do not have some lower-layer method to detect the
> presence of a loop.
> 
> Thanks,
> 
> Wes George
> 
> 
Of
> Rajiv Asati (rajiva)
> 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: "Frank Bulk" <[email-masked]>
Date: Fri, 26 Aug 2011 11:09:49 -0500

Except the person(s) testing the link may not be the same people that can
disable/renable DAD for the test.  If v4 normals without intervening on L3,
v6 should, too.  

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Narten
Sent: Tuesday, August 16, 2011 8:24 AM
To: [email-masked]
Cc: IETF v6ops list
Subject: Re: [v6ops] DAD issues in IPv6 backbone environments

Thomas

---

From: "Frank Bulk" <[email-masked]>
Date: Fri, 26 Aug 2011 11:09:52 -0500

Let's not design a solution that is susceptible to race conditions.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Homburg
Sent: Tuesday, August 16, 2011 9:25 AM
To: Thomas Narten
Cc: [email-masked]
Subject: Re: [v6ops] DAD issues in IPv6 backbone environments

<snip>

If, when adding systems to a link, you do it slowly enough that one node
will
have completed DAD before the next one starts, then you don't need to do
anything special in case of duplicate MACs.

---

From: Fred Baker <[email-masked]>
Date: Fri, 26 Aug 2011 10:25:03 -0700

> again (once the loopback is disabled)

Seems like a case where it might kick itself, in a network with any degree of size or complexity.