[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ND-proxy applicability and loop-prevention


We've discussed ND-proxy applicability in home networks for "informal 
prefix sharing" (see draft-ietf-v6ops-unmaneval-01.txt).  I thought it 
might be good idea to try to move some of the discussion on IPv6 WG 
list where ND-proxy is being specified.


On Tue, 16 Mar 2004, Erik Nordmark wrote:
[Erik quoting me:]
> > Another angle here is how are you going to deal with the case where 
> > you have to have stacked gateways.  E.g., the home gateway is doing 
> > prefix delegation, and advertising /64's on its links.  One of the 
> > nodes at home is also a router, and behind it is a host.  How do you 
> > get v6 to that host behind the node?  That's a very common scenario 
> > today.  I think it in most cases you could probably move that node to 
> > the same link, but in some cases (e.g., mismatching media) it might 
> > not be possible.
> The solution you want in this space is something which allows plug&play of
> the devices that glue together the stacking. And since you don't know how
> the customer will plug things together, I think you must deal with loops.

I have a fundamental disagreement with this.  Any scenario where you 
would plug these in any other mode than in series should be strictly 
out of scope.  IMHO, we don't want to deal with that.

If the user plugs three ND-proxies in a triangle or two (or 
more) ND-proxies in a loop, the everything breaks -- and the customer 
fixes the set-up or calls someone to fix it.  Immediate failure, 
immediate fix.  I see no problem with this.  As it is, ND-proxy should 
never be enabled by default in any case.

> It is true that ndproxy as written can handle this, but it handles
> it by running IEEE 802.1D spanning tree protocol over all media - including
> non-IEEE 802 media - without specifying the details of how to carry IEEE 802 
> bridge PDUs over Avian Carriers, bluetooth, etc.
> That doesn't seem like the best approach.
> An approach like draft-perlman-zerouter-rbridge-00.txt, which builds
> a (very thin) overlay above the link layer between the rbridges look
> a lot more interesting to me; no need to carry bridge PDUs around etc.

No comment about this because I strongly believe we should get rid of 
the whole IEEE 802.1D spanning tree protocol hack from the protocol in 
the first place.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6