I'm sending this to the int-area because the concerns I have are
broader than the just the ipv6 WG. This document is really about
bridging/proxy arp in general, and it does not restrict itself to
IPv6; it also covers IPv4.
I've read this document a couple of times (it is on the IESG's plate
to review), but have general concerns. I wonder if others in the
community share my concern.
The bottom line is that I think the IPv6 portion of document/protocol
is both under-specified and too broad in scope and I worry that there
are a lot of potential gotchas lurking. I also worry that it will
break some of our standards track protocols. And if it gets widely
implemented, we'll have to deal with the resultant mess. We have
plenty of experience in IPv4 with proxy arp, and some of it has been
unpleasant.
I have the following meta concerns:
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
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.
3) this document may have implications for DHC. In particular,
document says:
One limitation of this rule is that if the authentication
protocol for DHCPv4 described in [DHCPAUTH] is used, only
clients that set the BROADCAST flag themselves will be able to
use DHCPv4 through the proxy.
If this document breaks some forms of DHC, that needs to be noted up
front and more visibly. I also think more discussion would be
appropriat here, to be sure we fully understand the issue here.
Again, I'm also not sure we should be promoting documents that cause
problems for existing standards track protocols.
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. That way the end site wouldn't need a separate prefix
(say if the ISP as stingy and didn't want to give it out). I had
always assumed this configuration was a simple star topology with the
access router at the center. Indeed, the current IPv6 charter says:
> - Develop Proxy Neighbor Discovery solution for prefix delegation
> and publish. This enables a simple site border router to
> re-advertise downstream a prefix it hears on its upstream link.
The WG had such an item in its charter for a long time (years), but
from what I can tell, there was limited interest in terms of actually
doing the work, so it languished. What "the WG" finally produced was
the above document. But it's scope is quite a lot broader than what
the charter called for. And, I think its fair to say that the work
reflects a small number of contributers (with good intentions) but
apathy and almost no help from the rest of the WG (e.g., the last WG
LC received no comments). So, this document is going through the
process by default, rather than being a strongly reviewed piece of
work.
Margaret (as AD) raised a similar point about the scope of this work
in the WG a few months back. For details, review the discussion
during the WG last call in May: (sorry, I can't find a a good URL to
point to -- sigh). There was hardly strong support for the document,
and in fact, the reviews were negative and the document was taken off
standards track and put on experimental in response to that thread.
In summary, I believe there are good reasons why the document in its
current form should not be published with an IETF blessing.
Some possible options:
1) Drop the work completely. This may not be as silly as it seems. A
basic premise of this work is that its somehow not possible (or too
hard) to get a proper prefix delegated from an ISP. However, there
is little evidence that this will be a real issue in IPv6. Current
RIR address allocation polcies and existing ISP practices is to
give out chunks of address space (rather than /64s), or a single
address.
2) Move all the IPv4 material to a separate document (this should be
done in any case if work on this continues). Also, the IPv4
material would need serious review from the IPv4 community.
3) Pull out all the more general bridging stuff for the IPv6 case and
just solve the narrow problem described earlier, namely a single
router acting as a star/hub for proxying.
4) Add an IESG note with a warning that this has potential issues and
the IETF doesn't recommend widespread adoption/use. (Indeed, the
current applicability statement is really weak and gives
insufficient guidance in terms of where this technology can safely
be used)
And what I'd _really_ like to see, more than anything else, is strong
support from the community both for scope of this document and the
details of what are contained in the document. In the absence of that,
if the document is published, I'd like to see a strong note adequately
characterizing the issues above.
Thomas
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
