> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:int-area- > [EMAIL PROTECTED] On Behalf Of James Kempf > Sent: Thursday, September 15, 2005 3:47 PM > To: [EMAIL PROTECTED]; Thomas Narten > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt > > Thomas, > > I share your concerns about this draft. At a minimum, pulling the IPv4 > specification out of the draft seems appropriate.
This was Issue #10 on the old NDProxy Issues list: http://www.icir.org/dthaler/NDProxyOldIssues.htm#Issue%2010 The resolution of that issue was previously: > [IETF 59 minutes]: > Options include: > 1) leave IPv4 in with caveat; > 2) remove all mention of IPv4; and > 3) put IPv4 support in an appendix. > After some discussion, the chairs polled the room. Approximately 8 people > felt we should remove IPv4 support, and approximately 4 people felt we > should keep it in. Thomas Narten observed that it was disappointing that > there were so few opinions in the room. The chairs noted that since the > working group didn't have a strong opinion, we should defer to the author. > > [DT comment]: > So far the authors have chosen the path of least author work (i.e., > no change). Since there seems to still be vocal support for removing IPv4, and no vocal support for keeping it, and the poll at IETF59 also had more in favor of removing, I have removed the IPv4 portions from draft-04 as suggested. > My particular concern, though, is with the lack of support for security. > When SEND was finalized, we had some very vague ideas about how to do > proxy > ND security which didn't seem ready for standardization. Now, after about > a > year and a half of discussion in IRTF/MOBOPTS, I think we are beginning to > have some firmer ideas about how SEND could be extended to proxy ND. If > the > WG decides that it would like to continue working on this and decides that > security is important, we could bring some of the IRTF/MOBOPTS work into > IETF. Jari Arkko submitted proposed replacement text for the security considerations section which summarizes the above, and the text has been incorporated. > jak > > ----- Original Message ----- > From: "Thomas Narten" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, September 15, 2005 8:44 AM > Subject: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt > > > I'm sending this to the int-area because the concerns I have are > > broader than the just the ipv6 WG. This document is really about > > bridging/proxy arp in general, and it does not restrict itself to > > IPv6; it also covers IPv4. > > > > I've read this document a couple of times (it is on the IESG's plate > > to review), but have general concerns. I wonder if others in the > > community share my concern. > > > > The bottom line is that I think the IPv6 portion of document/protocol > > is both under-specified and too broad in scope and I worry that there > > are a lot of potential gotchas lurking. I also worry that it will > > break some of our standards track protocols. And if it gets widely > > implemented, we'll have to deal with the resultant mess. We have > > plenty of experience in IPv4 with proxy arp, and some of it has been > > unpleasant. > > > > I have the following meta concerns: > > > > 1) I do not believe the material on IPv4 ARP proxy should be > > included. It is not in-scope for the IPv6 WG to be developing it, and > > any document on proxy ARP in IPv4 really requires review from the > > broader community. AFAIK, that review has not taken place. > > > > Recommendation: remove the IPv4 material and place in a separate > > document Removed as recommended. > > 2) This document breaks SEND (but does not say this clearly). I have > > doubts that we should be publishing documents that break our standards > > track protocols (especially ones that we believe are important). Or at > > the very least, if it is published, very strong wording is needed to > > point out that it is incompatable with SEND, e.g., an IESG note. Updated security considerations section with text from Jari Arkko. > > 3) this document may have implications for DHC. In particular, > > document says: > > > > One limitation of this rule is that if the authentication > > protocol for DHCPv4 described in [DHCPAUTH] is used, only > > clients that set the BROADCAST flag themselves will be able to > > use DHCPv4 through the proxy. > > > > If this document breaks some forms of DHC, that needs to be noted up > > front and more visibly. I also think more discussion would be > > appropriat here, to be sure we fully understand the issue here. > > Again, I'm also not sure we should be promoting documents that cause > > problems for existing standards track protocols. Removed IPv4 material, so this point goes away. > > 4) The history of this document is troubling, and I believe it does > > not have strong support from the WG. Rather, I'd characterize this as > > an effort that has gotten this far mostly because the vast majority of > > the WG has tuned out and no longer is following the work. > > > > The history of this effort (though I may be biased) is that the IPv6 > > WG desired a simple proxy mechanism for the following case. Suppose > > one has an access router connecting to an upstream ISP, and that link > > is assigned a prefix (say X). It would be nice if the access router > > could readvertise that prefix (say for a home network), acting as a > > simple bridge. That way the end site wouldn't need a separate prefix > > (say if the ISP as stingy and didn't want to give it out). I had > > always assumed this configuration was a simple star topology with the > > access router at the center. Indeed, the current IPv6 charter says: > > > >> - Develop Proxy Neighbor Discovery solution for prefix delegation > >> and publish. This enables a simple site border router to > >> re-advertise downstream a prefix it hears on its upstream link. > > > > The WG had such an item in its charter for a long time (years), but > > from what I can tell, there was limited interest in terms of actually > > doing the work, so it languished. What "the WG" finally produced was > > the above document. But it's scope is quite a lot broader than what > > the charter called for. And, I think its fair to say that the work > > reflects a small number of contributers (with good intentions) but > > apathy and almost no help from the rest of the WG (e.g., the last WG > > LC received no comments). So, this document is going through the > > process by default, rather than being a strongly reviewed piece of > > work. > > > > Margaret (as AD) raised a similar point about the scope of this work > > in the WG a few months back. For details, review the discussion > > during the WG last call in May: (sorry, I can't find a a good URL to > > point to -- sigh). There was hardly strong support for the document, > > and in fact, the reviews were negative and the document was taken off > > standards track and put on experimental in response to that thread. > > > > In summary, I believe there are good reasons why the document in its > > current form should not be published with an IETF blessing. > > > > Some possible options: > > > > 1) Drop the work completely. This may not be as silly as it seems. A > > basic premise of this work is that its somehow not possible (or too > > hard) to get a proper prefix delegated from an ISP. However, there > > is little evidence that this will be a real issue in IPv6. Current > > RIR address allocation polcies and existing ISP practices is to > > give out chunks of address space (rather than /64s), or a single > > address. > > > > 2) Move all the IPv4 material to a separate document (this should be > > done in any case if work on this continues). Also, the IPv4 > > material would need serious review from the IPv4 community. Removed IPv4 material from this document. > > 3) Pull out all the more general bridging stuff for the IPv6 case and > > just solve the narrow problem described earlier, namely a single > > router acting as a star/hub for proxying. > > > > 4) Add an IESG note with a warning that this has potential issues and > > the IETF doesn't recommend widespread adoption/use. (Indeed, the > > current applicability statement is really weak and gives > > insufficient guidance in terms of where this technology can safely > > be used) > > > > And what I'd _really_ like to see, more than anything else, is strong > > support from the community both for scope of this document and the > > details of what are contained in the document. In the absence of that, > > if the document is published, I'd like to see a strong note adequately > > characterizing the issues above. > > > > Thomas Proposed updated draft is at http://www.icir.org/dthaler/draft-ietf-ipv6-ndproxy-04.txt Thanks, -Dave _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
