[Corrected error in subject line]
Margaret & Thomas,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title : Bridge-like Neighbor Discovery Proxies (ND Proxy) Author(s) : D. Thaler, et al. Filename : draft-ietf-ipv6-ndproxy-00.txt Pages : 17 Date : 2004-12-13
as a Informational RFC. This document represents the consensus of the IPv6 working group. The Last Call completed on December 28, 2004.
I for one missed the last call, because I was on vacation during much of those two weeks. Given that there isn't likely to be an IETF-wide last call, I'd wish the WG and/or ADs take these comments into account.
I think there are several serious reasons why the document should not be published (which I've expressed in the past in the IPv6 WG):
- There has not been much review of the document in the WG; very few if
any messages have been sent on the WG mailing list and there were no
last call comments.
- There doesn't seem to be much interest in the protocol in the WG.
If there was one would expect there to be clarifying questions
(because I find the document less than clear to implement from).
If there isn't much interest, maybe this item should be removed from
the WG charter instead of publishing a poorly reviewed document.
- The protocol, if deployed, can cause harm to the Internet. The primary source of harm is the optional loop prevention. This will cause networks to melt when proxies are configured in a loop, since proxies are constrained to not decrement the IP ttl. Note that these loops would be particularely severe for IP multicast, since such packets are duplicated and sent out each proxy interface. - 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.)
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).
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.
Regards, Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
