Erik,
On Jan 21, 2005, at 0:34, Erik Nordmark wrote:
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 misspoke. Most people who spoke up were in favor. The last comments I see from you in the meeting minutes are from IETF 57.
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 never said that. I was commenting on the very broad brush you were
painting with. If there are things that can be changed to improve a spec,
they should be considered. In this particular case, it appears that the
supporters of the spec are limiting the deployment scenarios. With
those limitations, I am not sure that SeND would be used in concert with
proxy ND.
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.
First, lets keep in mind that this is an Informational document. I don't
see it as the eventual solution for the problem space. Secondly,
I see proxy ND being used in very small, cost-constrained networks.
Something where a router is over-kill.
- 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.
I will admit to missing the stated requirement in to support SeND. The Security Considerations section spells out how SeND does not work with the existing proxy text in 2461. That, to me, made interoperating with SeND a non-requirement.
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.
This is the first I have ever heard of that particular 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.
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.
At this point, I think it would be useful if the supporters of this document
chimed in on these issues.
Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
