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

Re: ND-proxy applicability and loop-prevention

On Mon, 22 Mar 2004, Erik Nordmark wrote:
> elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end
> up with consumer-class "routers" (devices that sit between different types of
> L2) that do v6-to-v6 NAT because that would be more plug and play 
> than the alternatives hence we need an alternative like ndproxy
> (at least I think you made that argument).


> Saying that ndproxy needs to be manually enabled and can't be enabled
> by default doesn't match this concern.

Oh, sorry -- I meant that ND-proxying would not be manually enabled on
*hosts* (naturally not) -- and if a router has some routing
information, ND proxy could be disabled in any case.  As a matter of
fact, as push-button on the side of the box, "proxy/router", might be
> I also don't see how one can prevent consumers from connecting such
> devices in ways that form loops.

They cannot be prevented, yes.  (And I don't think this is a serious
problem, but more of a kind of support FAQ to show to the users.)

> It *might* be sufficient if the solution could detect loops and sound the alarm
> (and stop forwarding frames), but ndproxy can't even detect loops and shut
> itself off. Thus when loops are formed the result is that the consumer will
> see their network die (100% link utilization due to frames looping around
> forever; ndproxy doesn't decrement the hop count).

I don't personally think 100% link utilization is that bad a signal.  
It rather simply conveys that "oops-- I've done something wrong when I
added the box there." and after it's removed all starts to work again
-- intuitive.  What would be worse is that some packets would work but
some others not.  Total connectivity loss is a good indicator of a
problem :).

I think it would be possible to detect loops if we wanted really hard 
to do that.  That might just lead to reinvention of the spanning tree 
protocol, though.

For example, the ND proxy could send in ND solicitation for its own IP
address.  If it hears back that solicitation on some other interface,
it can conclude that someone is looping those packets and it should
e.g. shut down completely.

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