Some comments on draft-ietf-ipv6-ndproxy-00.txt...
Substantive comments:
I think this document would be more appropriately published as an Experimental RFC rather than Informational. The inconsistencies between the requirements for securing IPv6 neighbor discovery and allowing dynamic addition/removal of a proxy and the text itself should be fixed.
In section 1.1, there is a description of a scenario in which ND bridging would provide in-site networking when a service provider provides just a single address to a customer. The current IAB recommendation is to provide a /48 prefix to each customer. Do we have supporting evidence that some service providers will, in fact, provide just a single address? All of the service providers I've talked to expect to provide a /48 to each customer, through the use of prefix delegation that requires no configuration of the CPE on the part of the customer.
As another example of deployment where a loop might be possible but unexpected, there is a specification under development for cable-broadband deployments in which the in-home coax cable may be used as a link, using different frequencies than the frequencies used between the cable modem and the CMTS. The in-home coax link is logically separate from the CM-CMTS link. It is possible that a device that can communicate on both links would employ NDproxy between the two links. If there is more than one such device, a loop is possible.
There are two small issues with the mechanism for accommodating DHCPv4. First, the mechanism is incompatible with the authentication protocol for DHCPv4 described in RFC 3118. In fact, the mechanism will be incompatible with any authentication that verifies the integrity of the data in the DHCPv4 message header, as changing the broadcast bit from 0 to 1 should be detected as a change in the contents of the message. Second, there should be a warning that a DHCPv4 client might detect, with subsequently undefined behavior, that the broadcast bit has been changed from the setting in the message originally set by the client.
Editorial suggestion:
My understanding is that NDproxy is intended for use between media that cannot be bridged at the link-layer, and which, presumably, have different link-layer header formats. While it would, I guess be obvious to an implementor, It would clarify the text to add a sentence or two in the last paragraph of section 4.1 explaining that the entire layer two header in the outgoing packet must be modified to the format of the layer 2 media over which the packet will be forwarded.
Unimportant editorial nits:
Although the title is "Bridge-like Neighbor Discovery Proxies (ND Proxy)", the Abstract does not restrict the protocols in the specification to IPv6. In fact, there is support for IPv4 bridging, including ARP and DHCPv4. I think it would clarify the intent of the draft to change the title (or, at least, the abstract) to reflect that bridging of some IPv4 protocols is included in this specification.
Sections 4.1 and 4.2 might be more accurately titled "Forwarding Packets" and "Originating packets".
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
