[rbridge] Draft problem statement
aidan at nicta.com.au
Thu May 27 16:22:02 PDT 2004
Erik Nordmark wrote:
> > The "multilink" proposal at the time had scope to become more than an
> > ARP/ND proxy. It was heading toward "IP bridging". Work had been done
> > looking at IS-IS as the underlying routing mechanism ("host routes") and
> > on getting DHCP to work.
> Was this the ND-proxy-based multilink subnet work, or was there
> some other body of work that you are thinking of?
It was the thinking that was going on around (perhaps prior) to the
ND-proxy-based multilink subnet work.
I think (expired) drafts
are worth a read because they list some design goals and three
approaches to a solution.
What ended up being pushed forward in the ipv6 wg was the ND-proxy approach.
> > On the other hand, an "IP-bridging" solution would better handle
> > incompatible L2 links (ie links with different MAC address formats and
> > MTUs).
> I suspect that there can be many potential requirements here.
> While I haven't thought much about it, it might be that one can
> come up with robust solutions that provide 2 out of 3 (but not all 3 of):
> - handle different MAC address formats
> - invisible to the hosts e.g. not decrementing the IP ttl
> - not restricted to sending data packets along a spanning tree
> I certainly haven't seem something which claims to handle all 3, which is
> why I think we should be careful about not overconstraining the problem.
I agree that there are many potential requirements.
I'm still thinking about the "not decrementing IP ttl" requirement.
> Personally I think that working across L2 links with different MAC address
> formats is lower priority than the other two above, but I'm interested in what
> others think about this.
I think supporting differing MAC address formats is a worthwhile design
goal. If we had IP bridging we could bridge IP datagrams directly to
Bluetooth devices, Firewire, IRDA, [insert new L2] and avoid the
redundant ppp or ethernet encapsulation cruft that gets added. Having
worked in the home networking space in my previous job, I think it would
be a boon.
Because the home is an environment where people will plug stuff together
in wierd ways, robust loop prevention is very important. Having some
things that do ND-proxy/ARP-proxy without loop detection/prevention
feels like a disaster waiting to happen.
More information about the rbridge