Hi Dave,
Point taken. How about: A proxy MUST ensure that loops are prevented, either by running the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all proxy interfaces as described below, or by being deployable only in an environment where physical loops cannot occur. For example, in a cell phone which proxies between a PPP dialup link and a local Ethernet interface, it is typically safe to assume that physical loops are not possible and hence there is no need to support the Spanning Tree Protocol (STP).
This suggestion appears to be operational advice (about what features be enabled in given situations, not what should be supported by implementations), and implementations can't really know that that they will always be deployed in situations where loops are impossible... So, you would do better to say something like "all implementations MUST support loop prevention. A configuration option to disable loop prevention MAY be supported, but all implementations MUST have loop prevention enabled by default".
You could certainly avoid loops in ND Proxy by using STP, although I think you would have to say a lot more about how it would be applied... A reference to the rbridges work might be premature.
Ultimately, though, I am not sure why we would want to add this complexity to ND Proxy as I don't view it as a sound, scalable mechanism for link aggregation. It is quite similar to the Proxy ARP mechanisms supported in some IPv4 implementations, and it seems likely to have the same problems.
My understanding of the current ND Proxy work (and why I grudgingly agreed to leave it on the most recent IPv6 charter despite the fact that we had not managed to reach consensus on this proposal for several years) was that we were planning to trim down the original ND Proxy proposal to a one-hop prefix delegation mechanism (perhaps with a flag to indicate whether the prefix has already been delegated, in which case it mustn't be delegated again) to provide a non-DHCP alternative for one-hop prefix delegation. I've never been quite sure why a non-DHCP mechanism is needed, but I'm also not religiously against the idea of standardizing an alternative.
From my perspective, though, the ND Proxy spec doesn't seem to have been trimmed down into a simple prefix delegation mechanism at all. And, now we are talking about complicating it even further with a complex loop prevention scheme (or two).
Is there any reason to believe that we can reach consensus on this more complex version of ND Proxy given that we haven't managed to achieve consensus on the basic concept in the past ~5 years?
Margaret
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
