Subject: AD Evaluation: draft-ietf-6man-enhanced-dad

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Dec 2014 12:40:24 -0500

All,
     I have completed my AD evaluation of the Enhanced DAD draft.
Apologies for it taking this long.  I have a few comments/questions that
I would like to resolve before moving this to IETF Last Call...

1. Overall, I find the draft a little wordy and I think that makes the
document harder to parse.  I will point out exact situations that I
think can be made more concise, but I want the WG to consider what
points it thinks need to be made in this document.

2. Section 1.1 could really be condensed to a single paragraph that says
there are problems with DAD when an interface is looped back.  The "not
common configuration" commentary in 1.1 really detracts from that message.

3. Section 2 - As a part of any edits to address #2 above, I would
suggest moving the Terminology section before the current 1.1 since it
uses some of the terminology defined in Section 2.

4. Section 3 really detracts from the protocol aspects of this proposal.
 It could either be stricken or moved to an informative appendix.
Operational guidance provided in a protocol specification is probably
not going to reach the appropriate audience.

5. The 2nd paragraph of Section 4 is not very clear for a protocol
specification.  Is it saying "a sender MUST generate a six byte NONCE
value" or something else?  Why is the guidance in 3971 sufficient for
the actual nonce size (i.e., length chosen to ensure 8-byte alignment of
the entire option)?  Additionally, 3971 does not provide a
recommendation for PRFs, but guidelines do exist.  Was any thought given
to provide a reference to RFC 4086?

6. I really don't understand the need to update RFC 3971 described in
Sections 4.3 and 4.6.  This approach is just reusing the option and
doesn't change the actual SEND behavior as best I can tell.

7. I don't think Sections 4.4 and 4.5 add anything to this document.
The Updates tag will point implementers of 4861 and 4862 to this RFC and
I think that is sufficient.

8. If this document updates 4861 and 4862 AND works with Optimistic DAD,
why doesn't it also update 4429?

9. I don't see any Enhanced DAD protocol points in Section 5.  That text
could be provided in an appendix, but falls into the same "operational
guidance" bucket as #4 above.

10. A process point to address... The document lists 6 authors, but the
RFC Editor has guidance that suggests limiting the number of authors to
5 (https://www.rfc-editor.org/policy.html#policy.authlist).  If the six
people listed shared an equal editorial load, I need an explicit request
to ask for such an exception.

11. A 2nd process point... ID Nits complains about the lack of "a
disclaimer for pre-RFC5378 work".  Has the WG/chairs/shepherd confirmed
with all authors of 4861, 4862, and other RFCs to be updated have
granted BCP 78 rights to re-use text?

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 15 Dec 2014 20:43:54 +0000

Brian,

No problem with the delay and thanks for the review.   We will discuss the comments within the authors and get back to you shortly. 

Regards,

Hemant

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Monday, December 15, 2014 12:40 PM
To: 6man WG; [email-masked]; 6man Chairs
Subject: AD Evaluation: draft-ietf-6man-enhanced-dad

All,
     I have completed my AD evaluation of the Enhanced DAD draft.
Apologies for it taking this long.  I have a few comments/questions that I would like to resolve before moving this to IETF Last Call...

1. Overall, I find the draft a little wordy and I think that makes the document harder to parse.  I will point out exact situations that I think can be made more concise, but I want the WG to consider what points it thinks need to be made in this document.

2. Section 1.1 could really be condensed to a single paragraph that says there are problems with DAD when an interface is looped back.  The "not common configuration" commentary in 1.1 really detracts from that message.

3. Section 2 - As a part of any edits to address #2 above, I would suggest moving the Terminology section before the current 1.1 since it uses some of the terminology defined in Section 2.

4. Section 3 really detracts from the protocol aspects of this proposal.
 It could either be stricken or moved to an informative appendix.
Operational guidance provided in a protocol specification is probably not going to reach the appropriate audience.

5. The 2nd paragraph of Section 4 is not very clear for a protocol specification.  Is it saying "a sender MUST generate a six byte NONCE value" or something else?  Why is the guidance in 3971 sufficient for the actual nonce size (i.e., length chosen to ensure 8-byte alignment of the entire option)?  Additionally, 3971 does not provide a recommendation for PRFs, but guidelines do exist.  Was any thought given to provide a reference to RFC 4086?

6. I really don't understand the need to update RFC 3971 described in Sections 4.3 and 4.6.  This approach is just reusing the option and doesn't change the actual SEND behavior as best I can tell.

7. I don't think Sections 4.4 and 4.5 add anything to this document.
The Updates tag will point implementers of 4861 and 4862 to this RFC and I think that is sufficient.

8. If this document updates 4861 and 4862 AND works with Optimistic DAD, why doesn't it also update 4429?

9. I don't see any Enhanced DAD protocol points in Section 5.  That text could be provided in an appendix, but falls into the same "operational guidance" bucket as #4 above.

10. A process point to address... The document lists 6 authors, but the RFC Editor has guidance that suggests limiting the number of authors to
5 (https://www.rfc-editor.org/policy.html#policy.authlist).  If the six people listed shared an equal editorial load, I need an explicit request to ask for such an exception.

11. A 2nd process point... ID Nits complains about the lack of "a disclaimer for pre-RFC5378 work".  Has the WG/chairs/shepherd confirmed with all authors of 4861, 4862, and other RFCs to be updated have granted BCP 78 rights to re-use text?

Regards,
Brian

---

From: "George, Wes" <[email-masked]>
Date: Tue, 16 Dec 2014 09:20:28 -0500

On 12/15/14, 12:40 PM, "Brian Haberman" <[email-masked]> wrote:

Brian - responding to two specific points...

>not going to reach the appropriate audience.

WG] I respectfully disagree. The idea here is to discuss the alternatives,
as well as why they aren't full solutions to the problem, so as to build
the case for the recommended change to the protocol. IPv6 is far enough
along in deployment now that protocol changes to something so fundamental
as DAD behavior should not be made lightly, and thus have a burden of
proof so that they don't look arbitrary, and help to justify the work
necessary for implementers to actually implement the change. The
alternative is to write a problem statement draft, and then write a
separate solution draft, but IMO that's publishing additional drafts for
the sake of publishing them. While I concede that it probably needs an
editing pass for wordiness, this isn't exactly a long draft, thus
splitting this out seems an over-optimization. Further, as the
contributing author responsible for section 3.2, I believe that this is a
legitimate part of the protocol spec, because we are identifying another
way to address this problem that MUST be implemented, SHOULD be enabled if
the underlying Layer 2 protocol supports it, but acknowledging that this
is not a complete solution since not all Layer 2 protocols support this
behavior.
>to ask for such an exception.
WG] well, this is a self-correcting problem if the WG decides that section
3.2 should be stricken, but assuming that doesn't happen, the authors will
discuss how we think best to proceed.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

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: Brian Haberman <[email-masked]>
Date: Tue, 16 Dec 2014 10:00:28 -0500

Hi Wes,

> is not a complete solution since not all Layer 2 protocols support this

If there is a need for such justification, you will definitely not hear
from me a message to write a problem statement RFC. :)

Given the above, let me suggest the following text...

NEW:

3.1. Disable DAD on an Interface

   One can disable DAD on an interface so that there are no NS(DAD)
   messages issued.  While this mitigation may be the simplest, the
   mitigation has three drawbacks: 1) care is needed when making such
   configuration changes on such point-to-point interfaces, 2) this is
   a one-time manual configuration on each of such interfaces, and 3)
   genuine duplicates on the link will not be detected.

   A Service Provider router, such as an access concentrator, or network
   core router, SHOULD support this mitigation strategy.

3.2. Dynamic Disable/Enable of DAD Using Layer-2 Protocol

   Some layer-2 protocols include provisions to detect the
   existence of a loopback on an interface circuit, usually by comparing
   protocol data sent and received.  For example, the Point-to-Point
   Protocol (PPP) uses a magic number (section 6.4 of [RFC1661]) to
   detect a loopback on an interface.

   When a layer-2 protocol detects that a loopback is present on an
   interface circuit, the device MUST temporarily disable DAD on the
   interface.  When the protocol detects that a loopback is no longer
   present (or the interface state has changed), the device MUST
   (re-)enable DAD on that interface.

   This mitigation has several benefits.  It leverages layer-2
   protocol's built-in loopback detection capability, if available.  It
   scales better since it relies on an event-driven model which
   requires no additional state or timer.  This may be significant on
   devices with hundreds or thousands of interfaces that may be in
   loopback for long periods of time (e.g., awaiting turn-up).

   This solution SHOULD be enabled by default, and MUST be a
   configurable option if the layer-2 technology provides means for
   detecting loopback messages on an interface circuit.

I will leave the editorial pass on 3.3 to the WG/authors.

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 16 Dec 2014 21:25:20 +0000

Brian,

Thanks much for contributing the new text.  A little background for this document - Rajiv, WesG, Eli, and Carlos had a Problem Statement draft submitted to v6ops.  WesB and I wrote a solution/protocol for the problem and submitted the draft to the 6man WG.  Seeing both drafts, Thomas Narten and others suggested to just merge the two documents and have one document move through 6man.  That is why we took the WG guidance and went this route.   

Also, each of the six authors have contributed to portions of the document and thus if an exception can be made to include all six authors, all of authors would appreciate it.

Regards,

Hemant

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2014 10:00 AM
To: George, Wes; 6man WG; [email-masked]; 6man Chairs
Subject: Re: AD Evaluation: draft-ietf-6man-enhanced-dad

If there is a need for such justification, you will definitely not hear from me a message to write a problem statement RFC. :)

NEW:

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 16 Dec 2014 21:59:51 +0000

Brian,

Please see in line below.

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Monday, December 15, 2014 12:40 PM
To: 6man WG; [email-masked]; 6man Chairs
Subject: AD Evaluation: draft-ietf-6man-enhanced-dad

>5. The 2nd paragraph of Section 4 is not very clear for a protocol specification.  Is it saying "a sender MUST generate a six byte NONCE value" or something else?  Why is the >guidance in 3971 sufficient for the actual nonce size (i.e., length chosen to ensure 8-byte alignment of the entire option)?  Additionally, 3971 does not provide a >recommendation for PRFs, but guidelines do exist.  Was any thought given to provide a reference to RFC 4086?

<hs>The intent is to just use the nonce defined in RFC 3971.  Thus we can clean up text.  Sure, it makes sense to reference RFC 4086 - thanks for the reference. 

>6. I really don't understand the need to update RFC 3971 described in Sections 4.3 and 4.6.  This approach is just reusing the option and doesn't change the actual SEND >behavior as best I can tell.

<hs>Ok, we can remove this section and also remove the update to 3971.

>The Updates tag will point implementers of 4861 and 4862 to this RFC and I think that is sufficient.
A reviewer (JouniK) in 6man asked for sections 4.4 and 4.5.   If Jouni agrees with the AD comment above, we can elide sections 4.4 and 4.5 from the document. 

>8. If this document updates 4861 and 4862 AND works with Optimistic DAD, why doesn't it also update 4429?
<hs> Oops.  Missed the update to 4429.  I will add 4429 to the "Updates" list of RFCs.

>9. I don't see any Enhanced DAD protocol points in Section 5.  That text could be provided in an appendix, but falls into the same "operational guidance" bucket as #4 above.

<hs> Let me discuss with other authors to see where they'd move the text of section 5 to - a new appendix or to the operational guidance section. 

Thanks for the review.

Regards,

Hemant