RE: Questions from the Authors of draft-gashinsky-v6nd-enhance

["George, Wesley" <[e-mail]>]

From: [e-mail] [mailto:[e-mail]] On Behalf Of Joel Jaeggli
Sent: Sunday, August 07, 2011 1:58 PM
To: [e-mail]
Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance


1.      Is this document (draft-gashinsky-v6nd-enhance) worthwhile?

WEG] Yes

2. Is there critique of the two proposed 4861 changes?


            B. 7.4 ND cache priming and refresh
WEG] might be worth thinking about situations where DHCPv6 is in use and whether that can be leveraged to achieve something similar to this, i.e. watch the DHCPv6 messages go past and pre-populate the ND cache accordingly.


2.      Should we separate the potential mitigations (section 6) and implementation advice (section 7.1 and 7.2) into a separate document.

WEG] yes. I think that there's value in getting the explanation and short-term mitigation techniques out there sooner rather than later, and then if there is consensus that there is protocol work to be done to further mitigate the issue because the workarounds and tweaks discussed aren't enough on their own, the workarounds and discussion of the security issue aren't being delayed by that protocol work.

            A. Assumption (validated in v6ops at ietf81) is that v6ops would be happy
             to take the mitigation and implementation advice as an informational document

            B. Assumption 2 a draft updating 4861 would be a standards track document.

            C. Assumption 3, should harmonize with  draft-nordmark-6man-impatient-nud-0<http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-0>0
WEG] Agree with all 3 assumptions.
Also, a comment on 7.1 - I think that this is roughly the right priority for certain applications, but not necessarily for all cases. In networks where it is more common for devices to be coming and going frequently, it may not be as appropriate to deprioritize traffic to unknown addresses. It may be that in a lot of those applications, DHCPv6 will be preferable to SLAAC, so this may not be a huge issue, but worth considering in this section's recommendations, especially if 7.4 is now in a separate document.

Thanks
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.