> I'd sure be interested in hearing what others in the WG think
> on this issue.
I agree with Erik.
I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to
downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary topologies. Must
handle loops.
publishing a specification for ND proxy with support for a restricted
topology (multiple routers) without handling loops is just
irresponsible.
/ot
>> > 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.
>
> Pekka,
>
> 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.
>
> I also don't see how one can prevent consumers from connecting such
> devices in ways that form loops.
> 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).
>
> This doesn't satisfy what I think you say you want to solution to do.
>
> Erik
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
