Subject: [NDProxy#21] Editorial nits in ipv6-00

From: "Dave Thaler" <[email-masked]>
Date: Tue, 15 Feb 2005 20:08:01 -0800

123456789012345678901234567890123456789012345678901234567890123456789012
34567890
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. 

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.

#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.

#3
> Sections 4.1 and 4.2 might be more accurately titled "Forwarding
Packets"
> and "Originating packets".

Propose accepting as suggested.

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Fri, 18 Feb 2005 11:05:14 -0500

>header) out all other proxy interfaces on the same link.

OK with me.

>hop address appears in the neighbor cache.

OK with me.

>   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.

>Propose accepting as suggested.

OK...