> There are essentially two ways to break loops: either by using a
> "routing protocol" of some kind that imposes a correct routing structure
> on the set of proxies; or by using a form of "loop detection" option in
> the ND messages. The spanning tree algorithm is an example of the first
> class of solution; we could also conceivably use RIP or OSPF with host
> entries.

And RBridges argues that one can do this without any changes on
hosts or routers; they see the same behavior as without the
RBridges even though the RBridges use a routing protocol (on L2 and/or
L3 addresses) between eachother.

> I looked at the second class of solutions in a now expired draft. The
> basic idea is to add a "forwarded by" option in the discovery messages
> sent by the proxy, and to use that option to detect loops, either with a
> hop limit (don't forward more that N times) or with a packet inspection
> (don't forward what you have already forwarded once).

If one were do to a loop detection scheme something like that would make sense.
 > The routing or spanning tree solution is the most transparent to the
> hosts, since it does not change any byte in the ND packets. However,
> transparency may not be entirely desired, since SEND requires being
> fairly explicit about relays. The "forwarded by" option is perhaps more
> powerful, as it allows for real-time discovery of alternate paths. 

I guess I don't understand the need for explicit relays.
SEND works over existing L2 bridges - it can't even see that they are there.
(As a result there are L2 derived security issues - you can "redirect"
things at L2 unless L2 is somehow secure.)
I guess I don't understand the tradeoffs between running SEND over
a larger transparently "bridged" LAN vs. using "relays" that are
visible to SEND.

  Erik
 


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

Reply via email to