I support nd proxy it should be PS. It should not go to DS without wide implementation from multiple members I do not believe it is under specified either. Would I recommend it on a production network, not at all. What some may be uncomfortable with if they are not implementers is the complexity for net centric implementation capabability. The idea has been implemented in many forms and has nothing to do with ARP or ND, they are simply the vehicle to permit the deployment model of partitioned links. This team did its job and checked with multiple domain experts across the IETF my input is to move on.
/jim > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brian E > Carpenter > Sent: Monday, September 19, 2005 8:47 AM > To: Pekka Savola > Cc: [EMAIL PROTECTED]; ipv6@ietf.org > Subject: Re: [Int-area] concerns about draft-ietf-ipv6-ndproxy-03.txt > > People might want to look in the tracker at the other comments > that have come up. > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie > w_id&dTag=12623&rfc_flag=0 > > Brian > > Pekka Savola wrote: > > (FWIW, I think ND proxies are useful and needed.) Some comments > > inline. Adding ipv6 WG. > > > > On Thu, 15 Sep 2005, Thomas Narten wrote: > > > >> 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 > > > > > > v4 part is said to reflect what one implementation does, > but I guess > > even for Informational, that info might be too much. I > guess it could > > be taken out of fleshed out in a separate spec (if anyone > is interested > > in documenting proxy-arp behaviour..) > > > >> 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. > > > > > > Wording could be enhanced, but I do not think this document > should be > > blocked by the missing SEND details. > > > >> 3) this document may have implications for DHC. In particular, > >> document says: > > > > > > This is moot if v4 parts are removed. > > > >> 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. > > > > ... > > > >> But it's scope is quite a lot broader than what > >> the charter called for. > > > > > > I'm not sure if I understand your comment. Are you saying > the ND proxy > > spec is too complicated? > > > > Well, I myself suggested removing the spanning tree loop > prevention from > > the draft completely (now it has a bit in the RAs) because > it wasn't > > needed in the applicability we had in mind. But folks that > didn't like > > ND proxy argued that infinite loops are not nice, even in illegal > > configurations, so we're stuck with some additional specification. > > > > How would you like to see it simplified? Do you have an > alternative in > > mind? > > > > (To me, ND proxies seems "as simple as it can get" excluding loop > > prevention which I argued for removal but folks thought the failure > > modes were too dangerous..) > > > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
