On Aug 18, 2011, at 3:43 PM, George, Wesley wrote: > > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Joel > Jaeggli > Sent: Sunday, August 07, 2011 1:58 PM > To: ipv6@ietf.org > 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.
Wow. I hadn't though of that, but seeing as a bunch of things already snoop / relay DHCP, this seems clever... W > > 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-00 > 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. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
