>> I would expect anyone using a real domain (as in using a real TLD,
>> and a name registered at a domain registrar) to have a unicast DNS
>> server.
>
> But those servers are typically outside the firewall (or in a DMZ).
> Their purpose is to advertise the publicly visible hosts. The LAN(s)
> be
> What makes you think that there even IS a unicast DNS server for the
> (sub)domain in question?
I would expect anyone using a real domain (as in using a real TLD,
and a name registered at a domain registrar) to have a unicast DNS
server.
But those servers are typically outside the firewall (o
> Apple's primary consumer base for Zeroconf systems doesn't normally
> have to deal with multi-homed systems; so it probably isn't much of
> a priority for them.
Um, Pat...?
All of the laptops Apple sells have ethernet & 802.11 wireless built in and
thus are multihomed from day one; all of the
I believe Apple creates /32 host-specific routes for Zeroconf traffic on the
other interfaces, if seen. That may actually just be the normal ARP-handling
code in operation rather than Zeroconf, per se, although Apple's
implementation of ARP is Zeroconf-compliant in terms of timing, setting
"s
> No, I don't think that there's any good reason to restrict mDNS service
> discovery to .local; when you're using some other domain on the LAN, you
> still want to easily do the dynamic service advertisement, even if the A
> records are being handled by a traditional unicast DNS server and static
> I think this all means that for a multi-homed host, we should not
> automatically add a route for the 169.254/16 network. Instead, we
> should just add specific /32s as discovered; and use ARP when we
> need to find a new 169.254.x.y -> MAC translation.
MacOS X has the notion of interface prio
> 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 connecti
First, I'd like to correct something that slipped by earlier. Service Discovery
via DNS does -NOT depend on mDNS; it may be implemented using traditional
unicast DNS. (And to a pure client, there should be no detectable difference.)
> In general, I agree with, and have been known to strongly
> I think that I'd reverse the default on that. There should normally be
> no harm in having an LLA address, as long as we've got the non-LLA
> preference stuff working correctly. It is quite likely that the LLA
> address would never actually be used; but so what?
>
I've been thinking about that
Me too. :) The chief objection to mDNS (and other p2p types of dns
services) is the possibility of making it easier to hijack "real" websites.
I do not object (off hand) to a mechanism to define additional hostnames to
announce other than your own, but I think that we should do something like
unc
> Actually, it is quite possible for multiple interfaces to be on the same
> LLA link/subnet; so we can't make any assumptions either way. We -do- need
> to be able to handle the case where they are on different links. That
> really isn't an 'unless', it's a 'when'.
I can't see how it's worth w
> > There is also an option to force it to assign
> >(as an alias) a LLA address even if the interface is already is
> >configured with another address.
>
> I think that I'd reverse the default on that. There should normally be no
> harm in having an LLA address, as long as we've got t
If you want to communicate with an LLA host, fine, obtain an LLA
address otherwise take a hike.
I'd make that '..., obtain an LLA address, or figure out how to do it via ARP,
otherwise...'
My LLA implementation already does this..it never removes an address
from a interface it didn't set its
I guess it's just my nature, I really don't want to restrict end users
ability to do stuff when there is no TECHNICAL limitation of doing so.
It's the classical policy versus mechanism scenario, imho policy should
be left to the user, of course provided with sane default values that
can be used ou
>> Howevery, your statement above brings up a question, do you assume
>> that a system configured with lla should be able to communicate
>> with a system configured via dhcp?
>
> Yes, of course. The question is basically the same as whether hosts on
> the same link but different IP (sub)net ranges
I should probably explain better what I mean with this mdns.conf file,
as I think there might be a misunderstanding about it.
Let us for a second pretend that SD doesn't exist but mDNS does, mDNS
without SD is still a very valuable protocol.
No argument there.
The specs. says that each host s
I treat LLA and mDNS as separate things. They can be used individually
or together. I see LLA as a way of configuring an IP-address while
mDNS is a way of resolving DNS-like hostnames.
Don't forget service discovery. That's an important part of zeroconf,
implemented via mDNS.
Howevery, your
I've been watching this thread with great interest, having recently been
introduced to the possibilities of OLSR (net/olsrd) for local (and
beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in.
Some refs: My discovery point, a great (online) book found from a review
by Geoff Huston
Um..wouldn't the routing code handle this?
If you set a lla address and some other address on a interface like
192.168.0.2
or something and then a default route of 192.168.0.1, I
would assume that an application without specific knowledge that tries
to contact an external address would get 192.
DHCP+static is rather weird, but common enough that we do support it. I
suspect LLA with other address types is also of use at least some
of the time so we should ideally support it. Actually if we don't mind
always configuring a LLA I think we might support be OK right now as
long as the LLA da
> I would agree that LLA is part of the minimal set; and as I mentioned
> before, it is the only part for which there is currently no FreeBSD
> solution. It should be possible to enable LLA on a per-NIC basis in
> rc.conf; and it should be possible to have both LLA and non-LLA addresses
> on the s
> 2. What are the linux flavors doing?
It appears that the Avahi (http://avahi.org/) responder is the
current leader, it's API compatible (client wise) with mDNSResponder.
It is my impression that the mDNSResponder API compatibility lib/shim is a
build-time option and not actually used by the
If no one else steps forward, I will be glad to lead the charge to get an
implementation of this committed. Before I do though, we'll need to get some
basic questions answered (some of which have already been discussed here).
1. What are the other *BSDs doing in this area?
2. What are the linux f
My responder does one thing (ok it's many things but anyway), it
responds to queries and it makes queries. A mDNS record is always
a mDNS record (shared or unique), at this point SD records are
treated as any other record.
Long-term records can be configured with responderd.conf, it
supports dyna
> Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that,
> Multicast DNS, Service Discovery and anything else that removes the need
> for manual configuration.
Yeah, I actually know that. It's just that I've developed a bad habit of
calling it zeroconfig in the absence of a short
In short, zeroconfig allows a host to automatically negotiate
a collision free ip-address with other hosts on the network in the
absence of a DHCP-server. It's suitable for small ad-hoc networks,
or in embedded solutions.
Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that,
M
I'm trying to set up a Zeroconf/Bonjour based network. The net/avahi port
should handle the service publication and discovery; but so far I haven't
figured out how to do the RFC 3330 IPv4 Link Local addressing negotiation. Is
there an implementation for FreeBSD (6.1) ?
Thanks,
-Pat
___
--On Thursday, December 23, 2004 13:25:16 +0900 Sangwoo Shim <[EMAIL
PROTECTED]> wrote:
On Wed, Dec 22, 2004 at 07:15:16PM -0800, Pat Lashley wrote:
[snip]
Now that that's out of the way, Sangwoo, could you post the details
of your dubp + ng_eiface solution? I might want to switch to
--On Wednesday, December 15, 2004 18:12:57 +0900 Sangwoo Shim <[EMAIL
PROTECTED]> wrote:
I would like to establish a TCP/IP connection over USB between my
FreeBSD box and my PDA (Sharp Zaurus SL-6000L) that has a USB host port.
I've read that udbp can be used for this purpose, but I have not found
--On Tuesday, September 14, 2004 20:59:43 -0400 "Eric W. Bates" <[EMAIL PROTECTED]>
wrote:
It's a small store. Folks with broken computers bring the
machines in because "It doesn't work". They usually don't
know what is wrong with any given machine; and they try to
be careful (remove the hard dri
30 matches
Mail list logo
