> -----Original Message----- > From: Erik Nordmark [mailto:[EMAIL PROTECTED] > Sent: Friday, February 18, 2005 12:45 PM > To: Dave Thaler > Cc: Margaret Wasserman; [email protected] > Subject: Re: [NDProxy#16] Loop prevention, revisited > > Dave Thaler wrote: > > > I agree this may be interesting, but it would be good to start a new > > thread, > > since it is for a very different scenario than a proxy, which has the > > constraint that it must be completely transparent to the router. > > What I sketched would be completely transparent to the router. > > It is merely a mechanism to prevent a large class of loops by ensuring > that a proxy can not be a child of another proxy. > > Thus this can NOT happen: > > Router > | > ------------------------ > | | > Proxy1 Proxy2 > | | > ---- Proxy3 -------- > > Proxy3 will not enable its proxy capability because it receives RAs with > the P bit set. > > While this CAN happen: > > Router > | > ------------------------ > | | > Proxy1 Proxy2 > | | > ------------------- > | > Host > > But perhaps this can be prevented as well, by having the proxy disable > itself it it receives a RA (P bit or not?) on its downstream interface > (Could still have a temporary loop, unless we require that the proxy > send its P-bit RA on the downstream interface for a while before > enabling the proxying/flooding.
Ok I understand what you mean now. Once you start trying to prevent all the corner cases, I suspect you end up with something closer to STP, in which case either you don't solve the corner cases and hope for the best, or you do the safe thing which is more complex. Of course if a device already has an STP implementation (because it supports L2 bridging, or because it already did it for an ARP Proxy in the 802.11 scenario), I don't think it would need to do anything else. (This is the case for Windows, btw, but would also apply to any hardware bridge that would want to add 802.11 support) That is, for such devices, using STP is actually the simplest thing, and any other approach is more complex. This was the primary reason for choosing STP. I don't mean to discourage fleshing out the P bit idea though, but I don't think it belongs in the existing ND proxy spec at this point. a) When the WG originally agreed that the draft should be Informational not PS it was because it was agreed there were multiple ways to do it and this draft just documents one way, which documents one type of proxy deployed today works, and that was the reason Brian Carpenter suggested the type change. b) If you have an ARP/ND Proxy that is deployed into an environment with no IPv6 router, STP works whereas the P bit proxy does not (although this is another one of those corner cases which is potentially solvable). Remember one of the listed requirements was "Also work in the absence of any routers." -Dave > Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
