People might want to look in the tracker at the other comments
that have come up.
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12623&rfc_flag=0
Brian
Pekka Savola wrote:
(FWIW, I think ND proxies are useful and needed.) Some comments
inline. Adding ipv6 WG.
On Thu, 15 Sep 2005, Thomas Narten wrote:
1) I do not believe the material on IPv4 ARP proxy should be
included. It is not in-scope for the IPv6 WG to be developing it, and
any document on proxy ARP in IPv4 really requires review from the
broader community. AFAIK, that review has not taken place.
Recommendation: remove the IPv4 material and place in a separate
document
v4 part is said to reflect what one implementation does, but I guess
even for Informational, that info might be too much. I guess it could
be taken out of fleshed out in a separate spec (if anyone is interested
in documenting proxy-arp behaviour..)
2) This document breaks SEND (but does not say this clearly). I have
doubts that we should be publishing documents that break our standards
track protocols (especially ones that we believe are important). Or at
the very least, if it is published, very strong wording is needed to
point out that it is incompatable with SEND, e.g., an IESG note.
Wording could be enhanced, but I do not think this document should be
blocked by the missing SEND details.
3) this document may have implications for DHC. In particular,
document says:
This is moot if v4 parts are removed.
4) The history of this document is troubling, and I believe it does
not have strong support from the WG. Rather, I'd characterize this as
an effort that has gotten this far mostly because the vast majority of
the WG has tuned out and no longer is following the work.
The history of this effort (though I may be biased) is that the IPv6
WG desired a simple proxy mechanism for the following case. Suppose
one has an access router connecting to an upstream ISP, and that link
is assigned a prefix (say X). It would be nice if the access router
could readvertise that prefix (say for a home network), acting as a
simple bridge.
...
But it's scope is quite a lot broader than what
the charter called for.
I'm not sure if I understand your comment. Are you saying the ND proxy
spec is too complicated?
Well, I myself suggested removing the spanning tree loop prevention from
the draft completely (now it has a bit in the RAs) because it wasn't
needed in the applicability we had in mind. But folks that didn't like
ND proxy argued that infinite loops are not nice, even in illegal
configurations, so we're stuck with some additional specification.
How would you like to see it simplified? Do you have an alternative in
mind?
(To me, ND proxies seems "as simple as it can get" excluding loop
prevention which I argued for removal but folks thought the failure
modes were too dangerous..)
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
