At 08:08 PM 2/15/2005 -0800, Dave Thaler wrote:
Three editorial suggestions from Ralph Droms (no further discussion as yet): #1 > 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.
Scenario 2 has different link-layer header formats, but Scenario 1 does not (the inability to bridge is due to the inability to be promiscuous, rather than any link-layer header difference), so it needs to be worded more generically. Proposed change:
OLD: When any other IP broadcast or multicast packet (other than to the IPv6 Link-scoped STP Multicast Group) is received on a proxy interface, in addition to any normal IP behavior such as being delivered locally, it is forwarded unchanged out all other proxy interfaces on the same link.
NEW: When any other IP broadcast or multicast packet (other than to the IPv6 Link-scoped STP Multicast Group) is received on a proxy interface, in addition to any normal IP behavior such as being delivered locally, it is forwarded unchanged (other than using a new link-layer header) out all other proxy interfaces on the same link.
OK with me.
and
OLD: When any other IP unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged to the proxy interface for which the next hop address appears in the neighbor cache.
NEW: When any other IP unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which the next hop address appears in the neighbor cache.
OK with me.
#2 > 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.
Proposed text to add to Abstract:
The behavior of one common type of IPv4 ARP Proxy deployed today is documented herein for informational purposes, but this document concentrates on describing similar behavior for IPv6.
I'll have to reread the draft, but it seems to me the description of IPv4 ARP Proxy and DHCPv4 is more than simply informational.
#3 > Sections 4.1 and 4.2 might be more accurately titled "Forwarding Packets" > and "Originating packets".
Propose accepting as suggested.
OK...
-Dave
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
