PM Lashley wrote:
> But service discovery will often have a non-.local domain; so I
think we
> need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything
> outside in-addr.arpa. Given the existence of the .local domain, I don't
> see any utility in advertising a service in an in-ad
Brooks Davis wrote:
On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote:
Brooks Davis wrote:
It just occured to me that the daemon could handle this without any
interaction with dhclient or the static interface configuration. In the
mode where you only want an LLA if there isn't a
>> The nsswitch.conf should IHMO be :files dns mdns,
>
>> and the mdns nss module should ship with a default to only allow
>> queries to
>>.local
>>.168.254.in-addr.arpa
>
> I think you meant .254.168.in-addr.arpa here.
Actually .254.169.in-addr.arpa :)
Err, yes. I knew that... :-)
>>
> 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
> On Thu, 24 Aug 2006 13:42:29 -0500,
> Brooks Davis <[EMAIL PROTECTED]> said:
>> Um...I'm not sure if this is even possible. Let's forget mDNS and
>> go back to basic IP.
>> Say a multi-homed host has two interfaces both configured with an
>> address in the rage 169.254/16, say 169.254.1
Re the ZeroConf/Bonjour/IPv4LL chat: this just in ...
Original Message
Subject:New Bonjour Internet Drafts posted
Date: Thu, 24 Aug 2006 17:20:23 -0700
From: Marc Krochmal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hello,
Today we submitted the latest version
On Thu, Aug 24, 2006 at 03:21:41PM -0700, Chuck Swiger wrote:
> On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote:
> >>Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3,
> >>to choose a non-BIND specific term).
> >
> >We're talking about mDNS here, not DNS. I would argue that bec
On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote:
> Brooks Davis wrote:
> >
> >It just occured to me that the daemon could handle this without any
> >interaction with dhclient or the static interface configuration. In the
> >mode where you only want an LLA if there isn't another ad
On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote:
Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3,
to choose a non-BIND specific term).
We're talking about mDNS here, not DNS. I would argue that because
mDNS is link-local it makes perfect sense to be able to resolve
254.169
Chuck Swiger wrote:
On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote:
The nsswitch.conf should IHMO be :files dns mdns,
and the mdns nss module should ship with a default to only allow
queries to
.local
.168.254.in-addr.arpa
I think you meant .254.168.in-addr.arpa here.
Actually .2
Brooks Davis wrote:
It just occured to me that the daemon could handle this without any
interaction with dhclient or the static interface configuration. In the
mode where you only want an LLA if there isn't another address it's a
simple matter of watching the routing socket for messages and a)
On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote:
The nsswitch.conf should IHMO be :files dns mdns,
and the mdns nss module should ship with a default to only allow
queries to
.local
.168.254.in-addr.arpa
I think you meant .254.168.in-addr.arpa here.
Actually .254.169.in-addr.arpa
On Thu, Aug 24, 2006 at 11:51:55PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >
> >The problem with that is that we want to support the use of both on the
> >same link. So we'd either need to allow more than one keyword, or have
> >'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is ve
On Aug 24, 2006, at 9:20 AM, Pat Lashley wrote:
Unless we modify the IPv4 routing code to actually know that
different
interfaces with LLAs are on different subnets, we will need to insure
that there is only one interface with an LLA on it at once. The
modification probably makes sense, but I
Pat Lashley wrote:
The problem with that is that we want to support the use of both on the
same link. So we'd either need to allow more than one keyword, or have
'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I
think it would be cleaner to have something like:
The magi
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
> >explicitl
On Thu, Aug 24, 2006 at 10:00:08PM +0200, Fredrik Lindberg wrote:
> Brooks Davis wrote:
> >
> >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
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
Brooks Davis wrote:
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 t
Pat Lashley wrote:
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.)
Yes this is correct (if I've implied ot
> 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
David,
On Thu, Aug 24, 2006 at 10:29:32AM -0700, David Christensen wrote:
D> In general the problem isn't that the status block isn't being updated,
D> but that
D> the status update occurs AFTER the ISR has stopped looking at the status
D> block, but before the ISR has re-enabled interrupts, thu
On Thu, Aug 24, 2006 at 12:20:39PM -0400, Pat Lashley wrote:
> >> > 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 sh
> > 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
Doug Barton wrote:
Fredrik Lindberg wrote:
I've been thinking about that too, but I'm still not sure. The RFC
says . . .
Which RFC(s)? :) My read is that there are several that are relevant,
generally, to LLA and mDNS, so it would be useful to know precisely what
we're discussing.
Sorry, we
Brooks Davis wrote:
> On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote:
>> The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss
>> module should ship with a default to only allow queries to
>> .local
>> .168.254.in-addr.arpa
>> .168.192.in-addr.arpa
>> .16.172
Fredrik Lindberg wrote:
> I've been thinking about that too, but I'm still not sure. The RFC
> says . . .
Which RFC(s)? :) My read is that there are several that are relevant,
generally, to LLA and mDNS, so it would be useful to know precisely what
we're discussing.
Which reminds me, that's some
On Thu, Aug 24, 2006 at 08:40:09PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >
> >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
On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >>> Things get a bit more complex for multi-homed hosts; especially if they
> >>> are connected to more than one local link using IPv4 Link Local
> >>> Addressing...
> >>
> >>Well, I already have a proof-of-con
Pat Lashley wrote:
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 thi
Pat Lashley wrote:
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
On Thu, Aug 24, 2006 at 10:46:50AM -0400, Pat Lashley wrote:
> >> As I mentioned in an earlier posting, I would really like to see it
> >> support multiple TLDs for a single host. In particular, if I'm using
> >> example.com, then mumble.local and mumble.example.com should both
> >> resolve via mDN
On Thu, Aug 24, 2006 at 10:55:15AM -0400, Pat Lashley wrote:
> >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
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
> On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> D> This "lost interrupt" type of problem is addressed by the
> use of the
> D> status_tag
> D> field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> D> structure).
> D> Everytime the status block is up
> D> This "lost interrupt" type of problem is addressed by the
> use of the
> D> status_tag
> D> field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> D> structure).
> D> Everytime the status block is updated a new tag value is
> written to the
> D> status block.
> D>
Pat Lashley wrote:
But the whole 'direct communication between LLA and non-LLA on the same
link' discussion is really a side issue. It should only come up for us
in a scenario where we want to have a completely zeroconf FreeBSD
machine (using LLA) in an environment with non-LLA machines. If t
>> 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
Pat Lashley wrote:
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 should claim a unique host and also
advertise a HINFO record, but this in my opinion a policy decision
and
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
On Thu, Aug 24, 2006 at 04:55:12PM +0200, Fredrik Lindberg wrote:
> Pat Lashley wrote:
> >>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 fo
Pat Lashley wrote:
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
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
Pat Lashley wrote:
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 ad
Here I have prepared a patch, that utilizes the
tag in status block on the chips that can do this.
It also moves some chip quirks startup code to a
separate function.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: if_bge.c
=
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.
Hi all,
I have a weird problem. It seems that tcp over pptp can not handle
high speeds and connections terminate with no obvious reasons(at
least to me). The tcpdump is from 6-STABLE, but I also have a
7-CURRENT machine I can test/try things. I have tried with fetch,
konqueror and opera. The resul
Pat Lashley wrote:
As for mDNS/SD I think a generic responderd.conf/mdns.conf file should
be available where you can configure "static" dns records.
I would really rather see the service advertisement done in each
service's rc.d script. That has the advantage of not requiring the
mdns.conf fi
Colleagues,
pondering on the Linux driver more I have found that the only
thing that fixed this problem on 5700 (no status tag support) is
the hack in the local timer.
So, I have prepared a hack that fixes my problem. Certainly,
the performance of request-response test is awful, since chip
On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
D> This "lost interrupt" type of problem is addressed by the use of the
D> status_tag
D> field in the status block. (Listed as bge_rsvd0 in the bge_status_block
D> structure).
D> Everytime the status block is updated a new tag va
55 matches
Mail list logo
