Selon Pars MUTAF <[EMAIL PROTECTED]>:
> Firstly, the multicast name resolution idea that started
> with ZEROCONF (if I'm correct), has the potential to find
> many new and popular applications.
Dear AD, chairs, folks;
I would like to bring a new problem statement draft to your
attention (1 page
Mark Andrews wrote:
>>A real difference between unicast and multicast/broadcast of CSMA/CA
>>wireless link such as 802.11 is that the latter can not be ACKed and
>>is unreliable.
>
>
> Multicast is unreliable, period. This is independent of the
> media being used.
If you assume L4
> PS
>
> A real difference between unicast and multicast/broadcast of CSMA/CA
> wireless link such as 802.11 is that the latter can not be ACKed and
> is unreliable.
Multicast is unreliable, period. This is independent of the
media being used.
Mark
--
Mark Andrews, IS
> I'm not sure why LLMNR uses only one multicast address.
> I see serious problems with that. A LLMNR query would
> wake up every dormant host, in this case. Why this may
> be a serious problem?
There was actually a reasonably thorough discussion of this issue during
the design of LLMNR. You can f
Selon Jari Arkko <[EMAIL PROTECTED]>:
> Pars,
>
> Various possible DNS designs are possible. However,
> I want to go back to your suggestion that multicasting
> will cause significant inefficiencies when running over
> WiMax and 802.16.
>
Thank you very much for this mail. Please see below:
> I
> As a result, it seems fairly effective in ensuring
> that multicast does not wake up unnecessary
> neighbors. It does not solve all problems -- if
> you were to run LLMNR over it you would still
> be sending to every node, because only one
> multicast address is used. But then again,
> I'm not su
Pars,
Various possible DNS designs are possible. However,
I want to go back to your suggestion that multicasting
will cause significant inefficiencies when running over
WiMax and 802.16.
It might, indeed -- Christian's note about the high
speed wireless designs was right on. But the question
is w
[EMAIL PROTECTED] wrote:
>>There are also some nasty interactions between multicast and power
>>saving. To save power, the stations sleep most of the time, wake up
>>occasionally, and poll the server for any queued data. For multicast,
>>you have to either guarantee that all stations wake up at th
On Sat, Jan 13, 2007 at 11:32:53AM -0800, Christian Huitema wrote:
> > > I really do not understand you. Try in French :-) Because,
> obviously,
> > > if it is unicast, it is not multicast :-)
> >
> > unicast is a degenerative case of multicast.
>
> Bill, this is emphatically not true for hig
> > I really do not understand you. Try in French :-) Because,
obviously,
> > if it is unicast, it is not multicast :-)
>
> unicast is a degenerative case of multicast.
Bill, this is emphatically not true for high speed wireless links, such
as the upcoming IEEE 802.11n standard.
In high s
Hallam-Baker, Phillip wrote:
> I still don't understand what the plan is.
>
> There is a lot of Internet broadband content distribution
> going on today. I do not see where this proposal fits in.
"Content Distribution" in the form of Akamai and other such solutions
are GREAT for Big Companies(tm)
Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola
>> Sent: Friday, January 12, 2007 4:37 AM
>> To: Paul Vixie
>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>> namedroppers@ops.ietf.org; ipv6@ietf.org
>> Subject:
Sent: Friday, January 12, 2007 4:37 AM
> To: Paul Vixie
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> namedroppers@ops.ietf.org; ipv6@ietf.org
> Subject: DNS opcode DISCOVER [Re: multicast DNS without
> multicast (in IPv6 only)]
>
> [DNS opcode DISCOVER]
>
> On Thu,
rg; ipv6@ietf.org
> Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without
> multicast (in IPv6 only)]
>
> At 10:43 AM -0800 1/12/07, Hallam-Baker, Phillip wrote:
> >I am really confused here.
> >
> >First, I know that multicast has a base in the IETF. Is
On Thu, Jan 11, 2007 at 11:03:44PM +, Paul Vixie wrote:
> > do you want the code (8.1.2 based and haq'ed into 9.3.1 ) or do you
> > want to start fresh?
>
> put both up for ftp and share the url's here, and isc among others will take
> a look at them.
i think i will defer for
On Fri, Jan 12, 2007 at 09:28:21AM +0100, Stephane Bortzmeyer wrote:
> On Thu, Jan 11, 2007 at 05:41:26PM +0100,
> Pars Mutaf <[EMAIL PROTECTED]> wrote
> a message of 31 lines which said:
>
> > > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is
> > > clearly possible (section
On Thu, 2007-01-11 at 17:53 +, Paul Vixie wrote:
> > My question to Paul Vixie:
> >
> > > you'll also have to cope with networks that aren't using EUI64 or for that
> > > matter aren't using a 64-bit netmask.
> >
> > Is this an important limitation? (I'm asking the question)
>
> i think so,
On Wed, 2007-01-10 at 17:56 +0200, Rémi Denis-Courmont wrote:
> Le mercredi 10 janvier 2007 17:14, Pars Mutaf a écrit :
> > > So, the proposal is that if the hash collides for different names,
> > > then "johnsmith.local" must rename himself, right?
> >
> > Right. Please let me know if you see a pr
On Fri, Jan 12, 2007 at 11:36:31AM +0200, Pekka Savola wrote:
> [DNS opcode DISCOVER]
>
> On Thu, 11 Jan 2007, Paul Vixie wrote:
> >yes, it has.
> >
> >>why, under $DIETIES green earth would you want to push a dead
> >>technology? The IESG is dead-set against this.
> >
> >because the IESG
> do you want the code (8.1.2 based and haq'ed into 9.3.1 ) or do you
> want to start fresh?
put both up for ftp and share the url's here, and isc among others will take
a look at them.
> the text will be pumped out shortly.
thanksly.
--
> My question to Paul Vixie:
>
> > you'll also have to cope with networks that aren't using EUI64 or for that
> > matter aren't using a 64-bit netmask.
>
> Is this an important limitation? (I'm asking the question)
i think so, but it's a subjective matter. we're funded to do some early
DHCPv6 w
On Thu, Jan 11, 2007 at 05:41:26PM +0100,
Pars Mutaf <[EMAIL PROTECTED]> wrote
a message of 31 lines which said:
> > Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is
> > clearly possible (section 2.4).
>
> But it is still multicast DNS?
I really do not understand you. Try in
On Thu, Jan 11, 2007 at 03:30:26PM +0100,
Pars Mutaf <[EMAIL PROTECTED]> wrote
a message of 81 lines which said:
> I used the term .local with no particular reason. If recent advances
> showed that it is unnecessary.
Not unecessary: bad. If I'm correct, it is bad because everyone would
have a
> > > > ... if your L2 supports broadcast but at significant power cost then i
> > > > suggest we revive bmanning's old DNS DISCOVER proposal.
> > >
> > > I have no problem with that.
> >
> > yo, bill!
>
> yes?
yes, you.
> you mean the DISCOVER ID that is -still- in the RFCED que
[DNS opcode DISCOVER]
On Thu, 11 Jan 2007, Paul Vixie wrote:
yes, it has.
why, under $DIETIES green earth would you want to push a dead
technology? The IESG is dead-set against this.
because the IESG has turned over N times during those 8 years, and the idea
is still solid a
> > why, under $DIETIES green earth would you want to push a dead
> > technology? The IESG is dead-set against this.
>
> because the IESG has turned over N times during those 8 years, and the idea
> is still solid and useful and interesting, and the current proposed RFC is
> experimental,
> > > L2 broadcast will have to work in order to support ARP. if your L2 does
> > > not support broadcast at all then i don't know what to suggest beyond some
> > > kind of distinguished destination address that operates a location
> > > brokerage for other services. if your L2 supports broadcast
Pars Mutaf writes:
> On Thu, 2007-01-11 at 09:40 -0500, Thomas Narten wrote:
> > Pars Mutaf <[EMAIL PROTECTED]> writes:
> >
> > > I believe that dot-local DNS (also called multicast DNS) will be
> > > even more useful in the future. However, I suspect that there is
> > > a problem. For example, in
On Thu, 2007-01-11 at 15:55 +0100, Stephane Bortzmeyer wrote:
> On Thu, Jan 11, 2007 at 03:30:26PM +0100,
> Pars Mutaf <[EMAIL PROTECTED]> wrote
> a message of 81 lines which said:
>
> > I used the term .local with no particular reason. If recent advances
> > showed that it is unnecessary.
>
>
On Thu, 2007-01-11 at 09:40 -0500, Thomas Narten wrote:
> Pars Mutaf <[EMAIL PROTECTED]> writes:
>
> > I believe that dot-local DNS (also called multicast DNS) will be
> > even more useful in the future. However, I suspect that there is
> > a problem. For example, in WiMax, a cellular standard, no
Pars Mutaf <[EMAIL PROTECTED]> writes:
> I believe that dot-local DNS (also called multicast DNS) will be
> even more useful in the future. However, I suspect that there is
> a problem. For example, in WiMax, a cellular standard, nodes cannot
> L2 multicast.
Who cares what happens at L2? That is
Hi all,
Thank you all for your comments!
Alex and Julien: thanks for clarifications on 16ng.
Stephane and Brian Carpenter: I used the term .local with
no particular reason. If recent advances showed that it is
unnecessary. That's OK for me. I'm not even sure if my
proposal needs to be "local".
Pars Mutaf wrote:
> This threat is probably another good reason for not allowing
> multicast.
Wrong.
As I already stated reasons, there is no point not allowing
broadcast.
Masataka Ohta
--
Multicast DNS does not imply the Bad (tm) ".local"! Read
draft-ietf-dnsext-mdns-47.txt (approved by the IESG on 31 Oct 2006 and
stucked in RFC editor queue since, for unknown reasons).
It isn't stuck as far as I can see, it's just a member of the queue.
And indeed, as far as I know, there is no
Hi Pars,
On Wednesday 10 January 2007 11:06, Pars Mutaf wrote:
> (IPv6 WG CCed sorry all for cross-posting)
>
> Dear namedroppers,
>
> I believe that dot-local DNS (also called multicast
> DNS) will be even more useful in the future.
> However, I suspect that there is a problem. For
> example, in
Pars Mutaf writes:
> My answer is that installing DNS in a router is going to far.
Once you step off the cliff of altering the protocols to suit the
limitations, it's probably hard to know where to stop. :->
> > So, the proposal is that if the hash collides for different names,
> > then "johnsm
On Wed, Jan 10, 2007 at 11:06:38AM +0100,
Pars Mutaf <[EMAIL PROTECTED]> wrote
a message of 52 lines which said:
> I believe that dot-local DNS (also called multicast DNS)
Multicast DNS does not imply the Bad (tm) ".local"! Read
draft-ietf-dnsext-mdns-47.txt (approved by the IESG on 31 Oct 20
Pars Mutaf wrote:
> I believe that dot-local DNS (also called multicast DNS) will be
> even more useful in the future. However, I suspect that there is
> a problem. For example, in WiMax, a cellular standard, nodes cannot
> L2 multicast.
As was learned with the abandoned attempt of NBMA, link pr
> ...
> These problems make me think that dot-local usage is not as general
> as it should be in IPv6. What about this approach?
>
> It works exactly as multicast DNS, except that there is no multicast.
>
> 1. Let the responder's DNS name be "johnsmith.local". The responder
> configures a name-b
Pars Mutaf wrote:
On Wed, 2007-01-10 at 08:15 -0500, James Carlson wrote:
Pars Mutaf writes:
Dot-local DNS is also very useful in MANETs. However, you have to
flood the network to resolve a name. This consumes bandwidth and
energy in the whole network.
It isn't just multicast DNS that depend
Le mercredi 10 janvier 2007 17:14, Pars Mutaf a écrit :
> > So, the proposal is that if the hash collides for different names,
> > then "johnsmith.local" must rename himself, right?
>
> Right. Please let me know if you see a problem with this.
My understanding of James remarks is that your proposa
On Wed, 2007-01-10 at 08:15 -0500, James Carlson wrote:
> Pars Mutaf writes:
> > Dot-local DNS is also very useful in MANETs. However, you have
> > to flood the network to resolve a name. This consumes bandwidth
> > and energy in the whole network.
>
> It isn't just multicast DNS that depends on t
Pars Mutaf writes:
> Dot-local DNS is also very useful in MANETs. However, you have
> to flood the network to resolve a name. This consumes bandwidth
> and energy in the whole network.
It isn't just multicast DNS that depends on the use of multicast --
there are many protocols (including neighbor
43 matches
Mail list logo
