Subject: RE: [NDProxy#16] Loop prevention, revisited

From: "Dave Thaler" <[email-masked]>
Date: Fri, 18 Feb 2005 14:05:46 -0800

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Friday, February 18, 2005 12:45 PM
> To: Dave Thaler
> Cc: Margaret Wasserman; [email-masked]
> Subject: Re: [NDProxy#16] Loop prevention, revisited
> 
> Dave Thaler wrote:
> 
> > I agree this may be interesting, but it would be good to start a new
> > thread,
> > since it is for a very different scenario than a proxy, which has
the
> > constraint that it must be completely transparent to the router.
> 
> What I sketched would be completely transparent to the router.
> 
> It is merely a mechanism to prevent a large class of loops by ensuring
> that a proxy can not be a child of another proxy.
> 
> Thus this can NOT happen:
> 
> 	Router
> 	   |
> 	------------------------
> 	   |                 |
> 	Proxy1             Proxy2
> 	   |                 |
> 	   ---- Proxy3 --------
> 
> Proxy3 will not enable its proxy capability because it receives RAs
with
> the P bit set.
> 
> While this CAN happen:
> 
> 	Router
> 	   |
> 	------------------------
> 	   |                 |
> 	Proxy1             Proxy2
> 	   |                 |
> 	   -------------------
>             |
> 	  Host
>
> But perhaps this can be prevented as well, by having the proxy disable
> itself it it receives a RA (P bit or not?) on its downstream interface
> (Could still have a temporary loop, unless we require that the proxy
> send its P-bit RA on the downstream interface for a while before
> enabling the proxying/flooding.

Ok I understand what you mean now.  Once you start trying to prevent all
the corner cases, I suspect you end up with something closer to STP, in
which case either you don't solve the corner cases and hope for the
best, or you do the safe thing which is more complex.

Of course if a device already has an STP implementation (because it
supports L2 bridging, or because it already did it for an ARP Proxy
in the 802.11 scenario), I don't think it would need to do anything
else.
(This is the case for Windows, btw, but would also apply to any hardware
bridge that would want to add 802.11 support)  That is, for such
devices, using STP is actually the simplest thing, and any other
approach is more complex.  This was the primary reason for choosing STP.

I don't mean to discourage fleshing out the P bit idea though, but I
don't think it belongs in the existing ND proxy spec at this point.
a) When the WG originally agreed that the draft should be Informational
   not PS it was because it was agreed there were multiple ways to do it
   and this draft just documents one way, which documents one type of
   proxy deployed today works, and that was the reason Brian Carpenter
   suggested the type change.
b) If you have an ARP/ND Proxy that is deployed into an environment
   with no IPv6 router, STP works whereas the P bit proxy does not
(although
   this is another one of those corner cases which is potentially
solvable).
   Remember one of the listed requirements was "Also work in the absence
of
   any routers."

-Dave
 
>     Erik

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Feb 2005 14:33:24 -0800

> best, or you do the safe thing which is more complex.

Not so, because STP is trying to work in an arbitrary toplogy, and 
ndproxy can just turn itself off it the topology is something different 
than the one it can handle.

> don't think it belongs in the existing ND proxy spec at this point.

FWIW I disagree.
The WG charter item was to solve something rather specific in the case 
when a /64 prefix is provided by the upstream, and not try to provide a 
"proxy on steroids".
My take is that "proxy on steroids" is not in the IPv6 WG charter.

>    Remember one of the listed requirements was "Also work in the absence

Which of the scenarios in the document doesn't have a router?

    Erik

---

From: Bob Hinden <[email-masked]>
Date: Fri, 18 Feb 2005 16:26:35 -0800

Hi,

I like Erik's suggestion as a simple default mechanism to deal with the 
looping case.  It's not perfect, but would provide a default mechanism that 
would prevent people from hurting themselves.  It does support the scenario 
I am interested in (/64 advertised from upstream, router/proxy, single 
subnet downstream with a few devices).  It's easy to turn off for people 
who know more about their topology or perhaps the case Pekka describes.

I think people are going to build things like this independent of what the 
IETF does and publishing this (with the changes being discussed) seems like 
a reasonable thing thing for the community.  It will help people avoid many 
of the mistakes that have been discussed.

Bob (with no hats on)

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Feb 2005 18:59:08 -0800

Bob Hinden wrote:
> looping case.  It's not perfect, but would provide a default mechanism 
> that would prevent people from hurting themselves.  It does support the 
> scenario I am interested in (/64 advertised from upstream, router/proxy, 
> single subnet downstream with a few devices).  It's easy to turn off for 
> people who know more about their topology or perhaps the case Pekka 
> describes.

FWIW it also support a single proxy having multiple downstream 
interfaces. I don't know if that is an interesting case when multiple L2 
technologies are being used.

> I think people are going to build things like this independent of what 
> the IETF does and publishing this (with the changes being discussed) 
> seems like a reasonable thing thing for the community.  It will help 
> people avoid many of the mistakes that have been discussed.

Yep.

    Erik

---

From: Bob Hinden <[email-masked]>
Date: Sat, 19 Feb 2005 08:52:36 -0800

Erik,

>FWIW it also support a single proxy having multiple downstream interfaces. 
>I don't know if that is an interesting case when multiple L2 technologies 
>are being used.

Good point.  I can think of a device with more than two interfaces (for 
example, GPRS, WLAN, BT, and USB).

>>people avoid many of the mistakes that have been discussed.

Thanks,
Bob