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

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Jan 2005 21:34:56 -0800

Hello Brian,

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

Hmm - I'm spoken up in more than one IPv6 WG meeting pointing out the
flaws in the protocol. So clearly all people that spoke up were not in
favor of it.

I take it from your detailed responses below that you see it in IETF's
best interest to publish this document and protocol without any quality
improvements to neither the document nor the protocol. Did I understand
that correctly?

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

I suspect the users that will have their "measly" edge networks melt
down would disagree with this; the harm doesn't have to make everything
melt at once for it to be a harmful thing AFAIK.

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

Yes, but as I stated above, section 3 explicitly says that working with
SeND is a requirement for proxynd. And then the protocol doesn't satisfy
that. Given that the protocol doesn't satisfy what the document itself
says are the requirements, the document (and perhaps the protocol as
well) has a quality problem by being self-inconsistent.

> 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).
> 
> 
> Agree that may be an issue.  The question is whether SeND would be 
> used in that scenario.

The counterexample is that there are ISPs that have their home users 
with 802.11 run public hotspots and get some compensation from the ISP. 
In this case, since it is a public access 802.11, SeND would be a good 
thing to use. And 802.11 is also a key scenario for proxynd.

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

Again, the issue is the self-inconsistency in the document/protocol.
Section 3 says that dynamic removal of a proxy should adversely disrupt 
the network. Yet the protocol doesn't satisfy this requirement as far as 
I can see.

Regards,
    Erik

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 21 Jan 2005 09:43:42 -0500

Erik,

> flaws in the protocol. So clearly all people that spoke up were not in

I misspoke.  Most people who spoke up were in favor.  The last comments
I see from you in the meeting minutes are from IETF 57.

> improvements to neither the document nor the protocol. Did I understand

I never said that.  I was commenting on the very broad brush you were
painting with.  If there are things that can be changed to improve a 
spec,
they should be considered.  In this particular case, it appears that the
supporters of the spec are limiting the deployment scenarios.  With
those limitations, I am not sure that SeND would be used in concert with
proxy ND.

> melt at once for it to be a harmful thing AFAIK.

First, lets keep in mind that this is an Informational document.  I 
don't
see it as the eventual solution for the problem space.  Secondly,
I see proxy ND being used in very small, cost-constrained networks.
Something where a router is over-kill.

> well) has a quality problem by being self-inconsistent.

I will admit to missing the stated requirement in to support SeND.  The
Security Considerations section spells out how SeND does not work
with the existing proxy text in 2461.  That, to me, made interoperating
with SeND a non-requirement.

> with 802.11 run public hotspots and get some compensation from the 
> ISP. In this case, since it is a public access 802.11, SeND would be a 
> good thing to use. And 802.11 is also a key scenario for proxynd.

This is the first I have ever heard of that particular scenario.

> Section 3 says that dynamic removal of a proxy should adversely 
> disrupt the network. Yet the protocol doesn't satisfy this requirement 
> as far as I can see.
>

At this point, I think it would be useful if the supporters of this 
document
chimed in on these issues.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Jan 2005 11:24:30 +0100

> First, lets keep in mind that this is an Informational document.

I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.

I can see how this could be very useful in certain types of
network environment, and publishing as Experimental will allow
people to share experience and try to fix the open questions.

Since the deployment future of SEND is unknown, I don't think
it's appropriate to block this work because of SEND.

    Brian

Brian Haberman wrote:
> painting with.  If there are things that can be changed to improve a spec,
> First, lets keep in mind that this is an Informational document.  I don't
> ------------------------------------------------------------------------
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Jan 2005 09:26:11 -0800

> that there is some doubt about the viability of the solution.

That would be better than informational.

But I still think the document should say "MUST prevent loops; SHOULD 
run IEEE 802.1D to prevent loops" and then talk about cases when the 
protocol is not needed. The one example we have is the case of PPP (e.g. 
to a GGSN) where the probability of a loop would be very small, so in 
that particular case there is no need for 802.1D (and there might be 
other examples, but the 802.11 scenario in the document isn't one of them).

> people to share experience and try to fix the open questions.

ok

> it's appropriate to block this work because of SEND.

Yes, but at least the document should be internally inconsistent and not 
claim in section 3 that working with SeND is a requirement, even though 
it doesn't work with SeND.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Jan 2005 09:38:46 -0800

> those limitations, I am not sure that SeND would be used in concert with

You say that, yet you fail to respond to my comment that the 802.11 
scenario in the document is a case where this might be used and there is 
also a desire to use SeND.

> see it as the eventual solution for the problem space.  Secondly,

I think INFO documents produced by IETF WGs should have "truth in 
advertising", so I don't buy the claim that the document can be silent 
on the dangers of loops, and misleading (internally inconsistent) on 
whether it works in the presence of SeND.

 > Something where a router is over-kill.

Unfortunately, there are many times when the IETF has created a protocol 
intending it to be used in a limited environment, where the generality 
of IP has resulted in it being more widely deployed. The IETF tries to 
avoid this (for example, see the security requirements for IP Storage, 
where the original argument was that it would be used in a limited local 
environment, hence no need for things like IPsec), by requiring that 
protocols not cause harm should they be deployed much more widely than 
the designers anticipated.

> with SeND a non-requirement.

So now you understand the issue.

I suspect that the requirement should effect how a protocol is designed, 
as opposed to creating requirements which are the things that the 
artifact is capable of supporting. But as I said to Brian, in this case 
the issue is to make the document clear what it supports and doesn't 
support, with some explicit warnings that it can't be deployed in 
conjunction with SeND.

> This is the first I have ever heard of that particular scenario.

And Jim Kempf said, it's being deployed that way.

    Erik

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jan 2005 13:27:49 -0800

> And Jim Kempf said, it's being deployed that way.

specifically, speakeasy has a program listed on their web site where you get
credits for routing your neighbor's traffic through your .11 ap. perhaps
other isps too?

                jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Jan 2005 01:14:09 +0200

> That would be better than informational.

I agree. But I also think that if the document has
inconsistencies those should be corrected even before
publishing it as experimental.

--Jari

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Jan 2005 18:37:31 -0500

I apologize if I've missed this particular point earlier in the discussion -
Experimental seems appropriate to me unless there is widespread deployment
of some version of the protocol that this document is specifying.  And I
agree about correcting any inconsistencies prior to publication...

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jan 2005 16:27:41 -0800

> credits for routing your neighbor's traffic through your .11 ap. perhaps

sonic.net is another case.

   Erik

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Jan 2005 20:51:20 -0800

James,

>credits for routing your neighbor's traffic through your .11 ap. perhaps

Thanks.  Could supply a link to additional information on this?

Bob

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 26 Jan 2005 00:51:28 -0500

> Thanks.  Could supply a link to additional information on this?

http://www.speakeasy.net/netshare/

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Jan 2005 08:34:46 -0800

jak

----- Original Message ----- 
From: "Bob Hinden" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; "Brian Haberman"
<[email-masked]>; "Thomas Narten" <[email-masked]>; "Margaret
Wasserman" <[email-masked]>; "IPv6" <[email-masked]>
Sent: Tuesday, January 25, 2005 8:51 PM
Subject: Re: Request to Advance: <draft-ietf-ipv6-ndproxy-00.txt> [RESEND]

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jan 2005 02:20:15 -0800

> publishing it as experimental.

Fixing inconsistencies is a strict minimum that can be expected.
This is a wg duty.

That said, I have a problem with publishing a document related to ND 
that specify
something that will not work with the IETF standardized approach to 
secure ND.

Either, the deployment of ndproxy will be marginal and there will
be no problems, but in that case, why even bother publishing it?
Or NDproxy picks up and it may become an obstacle to get SEND deployed.

The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.

Erik seems to hint that there are ways to get NDproxy to work with SEND,
IMHO, those should be explored and the current document should be put 
on hold
until this is resolved.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jan 2005 15:02:22 +0100

Alain Durand wrote:
...
> defining standards for special cases but for the whole Internet. 

I disagree as a matter of principle. It is perfectly OK to have
specs that are incompatible with each other as long as they are
never implemented on the same network. It isn't OK to do that without
documenting the incompatibility.

It's clear that this argument doesn't apply to end to end
protocols, but strictly to things that have topologically limited
scope.

Actually we have plenty of examples of this; they are called routing
protocols.

That doesn't settle the issue of whether SEND and NDproxy are or
are not incompatible, but I have no problem with the concept that
a given (bridged) LAN can only run one of them.

    Brian

---

From: Alain Durand <[email-masked]>
Date: Thu, 27 Jan 2005 09:56:50 -0800

> Actually we have plenty of examples of this; they are called routing

I'm not sure the parallel is relevant. Routing protocols are 
self-contained elements
that do not need each other...
Here, at least in the example Jim Kempf & Erik gave, the two elements 
could very
well be used together...

As a matter of principle, I think it is better to standardize things so 
they work
together all the time rather than balkanizing the domain of application
by defining mutually exclusive standards.

	- Alain.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 28 Jan 2005 14:59:50 -0800

I know NDproxy is a WG item, but I think this problem space deserves a
discussion on its own. Although it has implications on IPv6 ND, I think
stretching subnets beyond links mean further than that. And there is
already another proposal contending for a similar problem space,
Rbridging. Before we drive NDproxy to finish line, shouldn't we be
having a thorough discussion on this problem space and proposals?

Alper

---

From: Ralph Droms <[email-masked]>
Date: Sun, 30 Jan 2005 05:19:53 -0500

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