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

From: Margaret Wasserman <[email-masked]>
Date: Thu, 17 Feb 2005 20:45:55 -0500

Hi Dave,

>Point taken. How about:
>A proxy MUST ensure that loops are prevented, either by running
>the Spanning Tree Algorithm and Protocol defined in [BRIDGE] on all
>proxy interfaces as described below, or by being deployable only in
>an environment where physical loops cannot occur.  For example, in a
>cell phone which proxies between a PPP dialup link and a local Ethernet
>interface, it is typically safe to assume that physical loops are not
>possible and hence there is no need to support the Spanning Tree
>Protocol (STP).

This suggestion appears to be operational advice (about what features 
be enabled in given situations, not what should be supported by 
implementations), and implementations can't really know that that 
they will always be deployed in situations where loops are 
impossible...  So, you would do better to say something like "all 
implementations MUST support loop prevention.  A configuration option 
to disable loop prevention MAY be supported, but all implementations 
MUST have loop prevention enabled by default".

You could certainly avoid loops in ND Proxy by using STP, although I 
think you would have to say a lot more about how it would be 
applied...  A reference to the rbridges work might be premature.

Ultimately, though, I am not sure why we would want to add this 
complexity to ND Proxy as I don't view it as a sound, scalable 
mechanism for link aggregation.  It is quite similar to the Proxy ARP 
mechanisms supported in some IPv4 implementations, and it seems 
likely to have the same problems.

My understanding of the current ND Proxy work (and why I grudgingly 
agreed to leave it on the most recent IPv6 charter despite the fact 
that we had not managed to reach consensus on this proposal for 
several years) was that we were planning to trim down the original ND 
Proxy proposal to a one-hop prefix delegation mechanism (perhaps with 
a flag to indicate whether the prefix has already been delegated, in 
which case it mustn't be delegated again) to provide a non-DHCP 
alternative for one-hop prefix delegation.  I've never been quite 
sure why a non-DHCP mechanism is needed, but I'm also not religiously 
against the idea of standardizing an alternative.

 From my perspective, though, the ND Proxy spec doesn't seem to have 
been trimmed down into a simple prefix delegation mechanism at all. 
And, now we are talking about complicating it even further with a 
complex loop prevention scheme (or two).

Is there any reason to believe that we can reach consensus on this 
more complex version of ND Proxy given that we haven't managed to 
achieve consensus on the basic concept in the past ~5 years?

Margaret

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Feb 2005 18:25:57 -0800

Margaret Wasserman wrote:

> agreed to leave it on the most recent IPv6 charter despite the fact that 
> we had not managed to reach consensus on this proposal for several 
> years) was that we were planning to trim down the original ND Proxy 
> proposal to a one-hop prefix delegation mechanism (perhaps with a flag 
> to indicate whether the prefix has already been delegated, in which case 
> it mustn't be delegated again) to provide a non-DHCP alternative for 
> one-hop prefix delegation.  I've never been quite sure why a non-DHCP 
> mechanism is needed, but I'm also not religiously against the idea of 
> standardizing an alternative.

I think this should be explored further.

It might not be that hard to come up with something which is is limited 
to a single hop.
Here is a straw-man:
  - add something to the RA which indicates that the sender is a proxy. 
Could be just a single 'P' bit I think.
  - a proxy can take an RA which arrives without the P bit, and send it 
out as a RA with the P-bit.
  - a proxy must not redistribute an RA with the P-bit set; if it 
receives any (or only?) RAs with the P-bit set, that interface can not 
be an upstream interface from a proxy perspective.

I haven't worked through the cases to see if this will avoid all loops; 
perhaps there can be (at least multicast) packet duplication if two such 
proxies are connected in parallel.

   Erik