Subject: Request to Advance: <draft-ietf-ipv6-ndproxy-00.txt> [RESEND]

From: Bob Hinden <[email-masked]>
Date: Mon, 17 Jan 2005 14:36:19 -0800

[Corrected error in subject line]

Margaret & Thomas,

On behalf of the IPv6 WG, the chairs request the advancement of:

	Title		: Bridge-like Neighbor Discovery Proxies (ND Proxy)
	Author(s)	: D. Thaler, et al.
	Filename	: draft-ietf-ipv6-ndproxy-00.txt
	Pages		: 17
	Date		: 2004-12-13

as a Informational RFC.  This document represents the consensus of the IPv6
working group.  The Last Call completed on December 28, 2004.

Regards,
Bob Hinden & Brian Haberman
IPv6 WG chairs

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Jan 2005 11:14:10 -0800

> working group.  The Last Call completed on December 28, 2004.

I for one missed the last call, because I was on vacation during much of 
those two weeks. Given that there isn't likely to be an IETF-wide last 
call, I'd wish the WG and/or ADs take these comments into account.

I think there are several serious reasons why the document should not be 
published (which I've expressed in the past in the IPv6 WG):
  - There has not been much review of the document in the WG; very few if
    any messages have been sent on the WG mailing list and there were no
    last call comments.
  - There doesn't seem to be much interest in the protocol in the WG.
    If there was one would expect there to be clarifying questions
    (because I find the document less than clear to implement from).
    If there isn't much interest, maybe this item should be removed from
    the WG charter instead of publishing a poorly reviewed document.

  - The protocol, if deployed, can cause harm to the Internet. The
    primary source of harm is the optional loop prevention. This will
    cause networks to melt when proxies are configured in a loop, since
    proxies are constrained to not decrement the IP ttl. Note that these
    loops would be particularely severe for IP multicast, since such
    packets are duplicated and sent out each proxy interface.
  - Another form of potential harm is creating obstacles for deployment
    of Secure Neighbor Discovery.  The protocol does not work in
    conjunction with SeND, which is particularely odd since section 3
    explicitly lists this as a requirement. (The line of reasons seems to
    be that it is a fault of SeND that proxynd doesn't work when SeND is
    used, which is a bit odd.)

Note that if there is sufficient interest in the WG, it isn't hard to 
solve the two technical issues listed above. (But the SeND interaction 
would require the proxies to be able to be promiscious receivers, which 
might be problematic in the wireless upstream scenario).

There is at least one other listed requirement which the protocol 
doesn't seem to satisfy:
  - Allow dynamic removal of a proxy without adversly disrupting the
    network
Since there will be host which have the, now dead, proxy's link layer 
address in their ARP/ND cache, communication will fail until this stale 
information is flushed, which might take a minute or so.
That seems like an adverse impact on the network too me.

Regards,
    Erik

---

From: Brian Haberman <[email-masked]>
Date: Thu, 20 Jan 2005 15:44:09 -0500

Hi Erik,

On Jan 18, 2005, at 14:14, Erik Nordmark wrote:

>
> I for one missed the last call, because I was on vacation during much 
> of those two weeks. Given that there isn't likely to be an IETF-wide 
> last call, I'd wish the WG and/or ADs take these comments into 
> account.
>
> I think there are several serious reasons why the document should not 
> be published (which I've expressed in the past in the IPv6 WG):

For the most part, there has been less than optimal public discussion.
The minutes from Seoul indicate that Thomas was less than happy
with the level of comments.  However, the people who did speak up
were in favor of it.

>    packets are duplicated and sent out each proxy interface.

I think that saying it harms the Internet is a little broad.  The use 
cases
for proxynd is more at the edge.  Loops will be localized and shouldn't
bring the whole Internet down.

>    used, which is a bit odd.)

The security section points out, correctly, that 2461 supports proxying
and that SeND doesn't support it.  In addition, the scenarios supported 
by
proxynd don't seem to be the same as those where SeND would be used.

> would require the proxies to be able to be promiscious receivers, 
> which might be problematic in the wireless upstream scenario).

Agree that may be an issue.  The question is whether SeND would be
used in that scenario.

> address in their ARP/ND cache, communication will fail until this 
> stale information is flushed, which might take a minute or so.

Agree that removal of a proxy, or the loss of a proxy, could adversely
affect the network.  However, this seems equivalent to a network
failure or re-design and not an everyday activity.

Regards,
Brian