Hi Erik,
On Jan 18, 2005, at 14:14, Erik Nordmark wrote:
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.
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.
- 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.
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.
- 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.
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.
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.
Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
