Zeroconfig and Multicast DNS

[Brooks Davis]

On Thu, Aug 24, 2006 at 02:36:58PM -0400, Pat Lashley wrote:
> >> We also need to be able to handle the case where they are on physically
> >> different links; but the host is acting as a bridge between them to make
> >> one logical link sharing a single LLA subnet.  (We don't need to 
> >explicitly
> >> handle the case where the bridging is being handled externally because 
> >that
> >> should be virtually indistinguishable from a single physical link.)
> >
> >If there's a bridge (only considering if_bridge here) then the bridge
> >interface should have the LLA.  Configuring LLAs on the physical
> >interfaces would be wrong and isn't worth supporting.
> 
> It's been a long time since I've set up a bridge; so I'm a bit rusty on all 
> of the details. But from the if_bridge man page, it doesn't look like the 
> bridge interface has an IP address of its own. (And I can't see why it 
> would want one.)

With if_bridge there is a single virtual interface which is the single
correct place to hang IP addresses should you wish to both bridge
L2 traffic and exchange IP packets.  This is similar to the way managed
switches work.

> Also, I was using 'bridge' as a short-hand which would include any sort of 
> proxying or routing that would make two physical segments operate as one 
> local link for address negotiation.
> 
> Overall, I don't really expect that to be a big issue; just one of those 
> less common setups that we need to ensure does something reasonable by 
> default.

To be honest, I'm not sure that's even worth much effort to make the
default reasonable.  Documenting that behavior is undefined in such
situations and spending effort on the bigger fish seems much more
productive, but if someone wants to do it, they certainly shouldn't let
my opinion stop them.  I just don't think it's the sort of edge case
that should block initial integration into the tree.  It's possible to
do some amazingly bizarre things with your IP configuration, but I don't
think we need to make all of them work. :)

> >The right way to deal with this is almost certainly to adopt the KAME
> >%interface decoration for link local addresses.  LLAs are meaningless
> >outside the context of an interface.  Unless you only have one interface
> >with an LLA, you must know which interface you are addressing to know
> >where to send the packet.  While you can hack around this in some cases
> >by trying all of them and hoping there aren't any collisions, I think
> >that's the wrong way to go.
> 
> Except in the case where multiple interfaces are on the same segment for 
> redundancy.  But in general, I suspect that you are right that using a 
> %interface notation is the way to go.

If you actually want redundancy then you don't want multiple IP
addresses since you'll lose all your connections on the interface that
goes down.  What you actually want is etherchannel in which case you end
up with one IP address and one one MAC address.

> Now, how do we handle the problem in DNS-SD ? The service records just have 
> a domain name.

The resolver needs to be smart enough to resolve the domain name to the
annotated link local address.  For the most part this probably isn't
worth worrying about.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20060824/ad3a34a3/attachment.pgp