Hello Brian,
For the most part, there has been less than optimal public discussion. The minutes from Seoul indicate that Thomas was less than happy with the level of comments. However, the people who did speak up were in favor of it.
Hmm - I'm spoken up in more than one IPv6 WG meeting pointing out the flaws in the protocol. So clearly all people that spoke up were not in favor of it.
I take it from your detailed responses below that you see it in IETF's best interest to publish this document and protocol without any quality improvements to neither the document nor the protocol. Did I understand that correctly?
I think that saying it harms the Internet is a little broad. The use cases for proxynd is more at the edge. Loops will be localized and shouldn't bring the whole Internet down.
I suspect the users that will have their "measly" edge networks melt down would disagree with this; the harm doesn't have to make everything melt at once for it to be a harmful thing AFAIK.
- Another form of potential harm is creating obstacles for deployment
of Secure Neighbor Discovery. The protocol does not work in conjunction with SeND, which is particularely odd since section 3 explicitly lists this as a requirement. (The line of reasons seems to
be that it is a fault of SeND that proxynd doesn't work when SeND is
used, which is a bit odd.)
The security section points out, correctly, that 2461 supports proxying and that SeND doesn't support it. In addition, the scenarios supported by proxynd don't seem to be the same as those where SeND would be used.
Yes, but as I stated above, section 3 explicitly says that working with SeND is a requirement for proxynd. And then the protocol doesn't satisfy that. Given that the protocol doesn't satisfy what the document itself says are the requirements, the document (and perhaps the protocol as well) has a quality problem by being self-inconsistent.
Note that if there is sufficient interest in the WG, it isn't hard to solve the two technical issues listed above. (But the SeND interaction would require the proxies to be able to be promiscious receivers, which might be problematic in the wireless upstream scenario).
Agree that may be an issue. The question is whether SeND would be used in that scenario.
The counterexample is that there are ISPs that have their home users with 802.11 run public hotspots and get some compensation from the ISP. In this case, since it is a public access 802.11, SeND would be a good thing to use. And 802.11 is also a key scenario for proxynd.
There is at least one other listed requirement which the protocol doesn't seem to satisfy: - Allow dynamic removal of a proxy without adversly disrupting the network Since there will be host which have the, now dead, proxy's link layer address in their ARP/ND cache, communication will fail until this stale information is flushed, which might take a minute or so. That seems like an adverse impact on the network too me.
Agree that removal of a proxy, or the loss of a proxy, could adversely affect the network. However, this seems equivalent to a network failure or re-design and not an everyday activity.
Again, the issue is the self-inconsistency in the document/protocol.
Section 3 says that dynamic removal of a proxy should adversely disrupt the network. Yet the protocol doesn't satisfy this requirement as far as I can see.
Regards, Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
