On 14 Jul 2011, at 23:00 , Joel Jaeggli wrote: > On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote: > >> On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote: >>> There appear to be several different cases, which can be addressed >>> by different reasonable mechanisms (not firewalls, and not lengthening >>> the subnet prefix.) >>> >>> For ISPs, I would assume the primary concern is routers connecting >>> to subnets used to provide services. A non-dynamic approach to ND >>> can address that. >>> >>> For ISPs providing bridged residential services, the ISP normally >>> operates on the basis that it gets registration information >>> from all the devices in the home. Thus, it does not need >>> to generate ND solicitations. >> >> Agreed. >> >> I do think it would be useful to have an informational document >> that describes the issue, describes the several cases, and outlines >> some reasonable mechanisms (possibly separate mechanisms for each case), >> both for the benefit of network operations folks and also for >> the benefit of equipment suppliers. > > we discussed some possible (but certainly incomplete) mitigations in: > > http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 > > but we also proposed changes to v6nd so that's why we brought it to 6man > >> Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG >> item than an IPv6 WG item. So I'm wondering whether this thread belongs >> over there rather than here. > > possibly, probably it straddles both groups.
(First, a broad apology for cross-posting this note, which is in a thread that originated on the IPv6 WG mailing list. I encourage authors of follow-up notes to consider whether their follow-up might belong only on 1 of these 2 lists. WG Chair guidance about proper place for follow-up discussion would also be welcome. :-) I apologise for being unclear. The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG. To some extent, I would prefer an approach where IPv6 Ops would work on that informational document (threats/concerns, operational use cases, existing mitigations that could be deployed) first. Then, if there were use cases not adequately covered by the material in that (proposed) IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document to examine potential protocol specification changes on a much more informed basis. I am concerned that the current document is inadvertently "putting the cart in front of the horse" by going straight to the IPv6 WG, without starting with an informational "issues and existing-mitigations" type document over in the IPv6 Ops WG. Operator input on this topic would be strongly beneficial since this is fundamentally an operations issue. I'm also concerned that most of the operational folks are active in the IPv6 Ops WG , while only some of those folks are active in IPv6 WG. So it would seem better to start working these concerns over there and later, after the IPv6 Ops WG has reached some conclusions about the issues/existing mitigations, possibly bring that output to the IPv6 WG to drive discussion of potential protocol specification changes in a more informed way than we seem to be achieving just now. Perhaps I am more nearly an outlier in my concern that we not start with protocol modification discussions and instead start with a separate document covering the concerns/issues, use cases, and existing/known mitigations (possibly organised by use case). Yours, Ran Atkinson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
