Subject: multicast DNS without multicast (in IPv6 only)

From: Pars Mutaf <[email-masked]>
Date: Wed, 10 Jan 2007 11:06:38 +0100

(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 WiMax, a cellular standard, nodes cannot
L2 multicast. Even if they could, L2 multicast would wake up every
dormant host. Dormant mode for energy efficiency is very important
in this context. There is also a serious L2-specific signaling cost
associated with dormant mode. (I'm not entering into details.)

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.

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-based link-local IPv6 address:
  
            link-local subnet prefix | 64bithash("johnsmith.local")

where hash is SHA1, and '|' means concatenation. It can be noted 
that 64bithash("johnsmith.local") is the IPv6 interface ID.
The link-local subnet prefix is constant and well-known.

2. When the initiator user (or application) enters the name
johnsmith.local, the DNS request is sent to the above address, 
instead of being multicast.

Am I missing something?

Thanks.

pars mutaf

ps: An earlier version of this work proposed the "blind" usage 
of name-based addresses (also called HUMID addresses). It can 
be found here:

http://www.freewebs.com/pmutaf/humid.html

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jan 2007 08:15:58 -0500

> 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 discovery) that will
either fail to work properly if multicast is outlawed or will need
modifications or limitations.

This sounds like a syntax error to me.  The system in question
apparently wants to use what are effectively point-to-point links but
is instead modeling as a crippled broadcast-type network.

I say "apparently," because the proposal below wouldn't work unless
there's some central node involved.  As part of resolving that IPv6
link-local address to an L2 address, nodes will send multicast
neighbor solicitations.  The apparent fact that this doesn't wake
everyone up means that the network is already partitioned.

Given that use of multicast typically isn't a privileged operation,
how does that central node stop someone from draining everyone else's
batteries anyway, even if this one protocol is fixed?

> The link-local subnet prefix is constant and well-known.
[...]
> http://www.freewebs.com/pmutaf/humid.html

So, the proposal is that if the hash collides for different names,
then "johnsmith.local" must rename himself, right?

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 10 Jan 2007 16:14:26 +0100

> batteries anyway, even if this one protocol is fixed?

This threat is probably another good reason for not allowing 
multicast.

>From an abstract point of view (hoping to answer all your concerns
above): if we already know the destination's unicast address, then 
we should not send a multicast query. We should send a unicast query.
This is my proposal. This is the conservative approach IMHO.

As an example, we can take WiMax (IPv6 over WiMax is being standardized
by the 16ng WG). In 16ng, the access router has a list of all nodes.
This corresponds to what you call a central node. DAD 
(duplicate address detection) is achieved 
using unicast. This is work in progress. As for neighbor discovery, 
I agree that it is more reliable over L2 multicast. I hope that the
access router can use it to recover from loss of state, but not 
during normal operation (because it is costly). 16ng WG will decide. 

Now one can say: if the WiMax AR knows knows everything, why not 
register the localname->address bindings also to the AR? 

My answer is that installing DNS in a router is going to far. 
I'm proposing a solution for not doing this. The AR speaks IPv6, 
so lets encode the names into IPv6 addresses.

But again, IMHO, from an abstract point of view, unicast will always
be the conservative approach. I.e. not only for WiMax.

> then "johnsmith.local" must rename himself, right?

Right. Please let me know if you see a problem with this.

Thanks!
pars

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 10 Jan 2007 17:56:00 +0200

> Right. Please let me know if you see a problem with this.

My understanding of James remarks is that your proposal merely moves the 
problem away from DNS to Neighbor Discovery, but does not solve the 
core issue at all, which is that some kind of multicast/broadcast is 
needed for non-point-to-point IPv6 links.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jan 2007 18:31:31 +0100

Pars Mutaf wrote:
>>> 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.
>> apparently wants to use what are effectively point-to-point links 
>> but is instead modeling as a crippled broadcast-type network.
>> 
>>  there's some central node involved.  As part of resolving that 
>> IPv6 link-local address to an L2 address, nodes will send multicast
>>  how does that central node stop someone from draining everyone 
>> else's batteries anyway, even if this one protocol is fixed?
> 
> above): if we already know the destination's unicast address, then we
>  should not send a multicast query. We should send a unicast query. 

I agree.  I'm not sure whether that draft allows this behaviour or not
(send direct DNS message instead of multicast).  It can be suggested though.

> As an example, we can take WiMax (IPv6 over WiMax is being 
> standardized by the 16ng WG).

They look mostly at 802.16 less at WiMax which is somehow normal to me
since WiMax are moving more than 802.16.

> In 16ng, the access router has a list of all nodes.

Not sure which entity you mention?  Not necessarily WiMax.  I think any
router has a list of its neighbours in NC.

> This corresponds to what you call a central node. DAD (duplicate 
> address detection) is achieved using unicast.

Not sure which document you refer to.  The first DADing NS is sent to
solicited-node multicast address (by rfc2462), and not to unicast address.

Some documents in 16ng talk 'Relay DAD' which would maintain a list and
then unicast a NS; but other signals in WiMax forum seem to indicate
deprecating the use of 'Relay ND' for rfc4541 instead.

> This is work in progress. As for neighbor discovery, I agree that it
>  is more reliable over L2 multicast.

Yes, more reliable and mandatory.  Actually IPv6 ND doesn't work at all
over a link-layer that isn't doing multicast link-layer addresses.

> I hope that the access router can use it to recover from loss of 
> state, but not during normal operation (because it is costly). 16ng 
> WG will decide.
> 

Because not scalable?  Ie memory can overflow if too many nodes?

> My answer is that installing DNS in a router is going to far. I'm 
> proposing a solution for not doing this. The AR speaks IPv6, so lets
>  encode the names into IPv6 addresses.

Err...?  If I want to encode my private key and my name into my IPv6
64bits would this work?

Alex

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jan 2007 17:58:52 +0000

> ...

you'll also have to cope with networks that aren't using EUI64 or for that
matter aren't using a 64-bit netmask.  and you'll have to cope with hash
collisions, however improbable they may be.

> instead of being multicast.

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 but at significant power cost
then i suggest we revive bmanning's old DNS DISCOVER proposal.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jan 2007 17:58:52 +0000

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Jan 2007 21:23:30 +0900

Pars Mutaf wrote:
 
> L2 multicast.

As was learned with the abandoned attempt of NBMA, link protocols
not being capable of broadcast is useless.

> Even if they could, L2 multicast would wake up every
> dormant host.

That's fine as long as L2 broadcast is infrequent.

Note that L2 broadcast is as costly as L2 multicast.

So, don't bother to say "multicast", when broadcast is harmful which
is the case of CATENET, which is partly why IPv6 failed. IP over 1394
failed, too, because of purposeless attempt to avoid broadcast.

>             link-local subnet prefix | 64bithash("johnsmith.local")

And the address is a multicast address joined by all the hosts with
64bithash("johnsmith.local")=64bithash(DNS name).

						Masataka Ohta

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 10 Jan 2007 11:36:02 +0100

On Wed, Jan 10, 2007 at 11:06:38AM +0100,
 Pars Mutaf <[email-masked]> 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 2006 and
stucked in RFC editor queue since, for unknown reasons).

>             link-local subnet prefix | 64bithash("johnsmith.local")

It really looks like PNRP :

http://www.microsoft.com/technet/itsolutions/network/p2p/pnrp.mspx
http://en.wikipedia.org/wiki/PNRP

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jan 2007 13:58:04 -0500

> 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.  :->

> Right. Please let me know if you see a problem with this.

I don't necessarily; I was just trying to clarify the proposal.
Fortunately, he can call himself "jacksmith.local" with no loss of
information.

The general multicast issue, though, seems like a hazardous one.  If
it's a walled garden (where users just "can't" send multicast), then
you're obviously free to do anything you like.  You don't even need to
use IP.  If it's not such a deployment, then it seems to me that
outlawing multicast is a near impossible task and trying to modify
protocols to avoid it is a losing proposition.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 11 Jan 2007 09:24:34 +0100

Hi Pars,

On Wednesday 10 January 2007 11:06, 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. Even if they could, L2 multicast would
> wake up every dormant host. 

WiMAX is one system architecture built upon IEEE 802.16 
standard. 

AFAIK 802.16 MAC is point-to-point between a mobile 
station and the base station, and perfectly capable of 
multicast, it's just that at most two nodes can 
receive a multicast packet: the two end of the 
point-to-point link.

--julien

> Dormant mode for energy 
> efficiency is very important in this context. There
> is also a serious L2-specific signaling cost
> 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.
>
> These problems make me think that dot-local usage is
> not as general as it should be in IPv6. What about
> this approach?
>
> 1. Let the responder's DNS name be
> "johnsmith.local". The responder configures a
> name-based link-local IPv6 address:
>
> where hash is SHA1, and '|' means concatenation. It
> can be noted that 64bithash("johnsmith.local") is
> the IPv6 interface ID. The link-local subnet prefix
> is constant and well-known.
>
> 2. When the initiator user (or application) enters
> the name johnsmith.local, the DNS request is sent to
> the above address, instead of being multicast.
>
> Am I missing something?
>
> Thanks.
>
> pars mutaf
>
> ps: An earlier version of this work proposed the
> "blind" usage of name-based addresses (also called
> HUMID addresses). It can be found here:
>
> ----------------------------------------------------
>---------------- IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jan 2007 10:52:28 +0100

> 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 TLD called "local".

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Jan 2007 07:37:44 +0900

> This threat is probably another good reason for not allowing 

Wrong.

As I already stated reasons, there is no point not allowing
broadcast.

						Masataka Ohta

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 11 Jan 2007 15:30:26 +0100

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". I can also reach other subnets
in theory (if my host has learned the list of neighboring 
subnets).

I also take note of RFC4541. Thanks.

But I still don't see why I would send a multicast query
if I know the destination's unicast address. Sending the DNS
query directly to the destination may be useful. For example, 
the host may have already resolved the destination's
MAC address (through multicast). But the user is trying many 
different names... (for example). 

My question to Paul Vixie:

On Wed, 2007-01-10 at 17:58 +0000, Paul Vixie wrote:
> matter aren't using a 64-bit netmask. 

Is this an important limitation? (I'm asking the question)

>  and you'll have to cope with hash

Fortunately, there is no problem with that. If a given name-based
address was accidentally configured the query will be silently 
dropped.

> then i suggest we revive bmanning's old DNS DISCOVER proposal.

I have no problem with that.  

Thanks

pars

---

From: Thomas Narten <[email-masked]>
Date: Thu, 11 Jan 2007 09:40:11 -0500

> a problem. For example, in WiMax, a cellular standard, nodes cannot

Who cares what happens at L2? That is not a concern to IP.

If you are really saying that over a WiMax network, IP multicast is
not supported, well, I would expect that this will be a problem for
any application that relies on multicast. Presumably the market will
sort out whether this is a problem or not.

Thomas

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 11 Jan 2007 16:55:37 +0100

> Who cares what happens at L2? That is not a concern to IP.

But we can build new applications comfortably if we know that the
signaling and energy costs were minimized ?
(I mean regardless of L2 specific details)  

pars

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 11 Jan 2007 17:41:26 +0100

On Thu, 2007-01-11 at 15:55 +0100, Stephane Bortzmeyer wrote:
> On Thu, Jan 11, 2007 at 03:30:26PM +0100,
>  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 ".local" and merging of two organizations would become a
> nightmare. It is quite easy and cheap to get a real domain name so
> every organization, even non connected, should use one.

Thanks for the clarification. 

> > I'm not even sure if my proposal needs to be "local". I can also
> > reach other subnets in theory
> 
> The domain name in use has nothing to do with the fact that the
> protocol is routable or single-link. Different layers.
> 
> > But I still don't see why I would send a multicast query if I know
> > the destination's unicast address. Sending the DNS query directly to
> > the destination may be useful.
> 
> Again, *read* draft-ietf-dnsext-mdns-47.txt, the use of unicast is
> clearly possible (section 2.4).

But it is still multicast DNS?
pars

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Jan 2007 12:19:18 -0500

> (I mean regardless of L2 specific details)  

I suspect that doing so implies the use of point-to-point links
(rather than what appears to be broadcast emulation), and reducing
energy costs would seem to require having cached data available on the
single peer node to avoid querying "everybody."

---

From: [email-masked]
Date: Thu, 11 Jan 2007 18:32:41 +0000

> > > 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 but at
> > > significant power cost then i suggest we revive bmanning's old DNS
> > > DISCOVER proposal.
> > 
> yo, bill!

	yes?
	you mean the DISCOVER ID that is -still- in the RFCED queue?	
	(and has been in one form or another for the past eight years?)
	why, under $DIETIES green earth would you want to push a dead
	technology?  The IESG is dead-set against this.

--bill

---

From: [email-masked]
Date: Thu, 11 Jan 2007 21:23:01 +0000

> 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, and most importantly, because the need for it will continue to
> resurface until we push it over the top of the hill and roll it down to the
> town.

	sigh... let me ramp up here.
	do you want the code  (8.1.2 based and haq'ed into 9.3.1 ) or do you want to 
	start fresh?

	the text will be pumped out shortly.

--bill

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Jan 2007 11:36:31 +0200 (EET)

[DNS opcode DISCOVER]

On Thu, 11 Jan 2007, Paul Vixie wrote:
> yes, it has.

The problem was, AFAIR, that allocating opcodes requires a Standards
Action.  No experimental spec can do that.  If DISCOVER is to be 
revived it will need to use one of other publication processes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Jan 2007 11:15:13 +0900

> (I mean regardless of L2 specific details)  

With the obvious example of you,

supporting a L3 multicast address over broadcast L1 is just as
costly as supporting a L3 unicast address over broadcast L1,
regardless of L2 specific details.

Wireless L2 protocols not supporting L3 multicast is just poor.

In addition, wireless L2 protocols can also naturally support
L2 broadcast. If power consumption of terminals but not central
stations is the issue, broadcast can be issued only from (or
relayed by) central stations and can be rate limited.

Thus, all the properly designed L3 or upper protocols can enjoy
properly designed L2 multicast at any rate and L2 broadcast maybe
with rate limitation. It has nothing specific to mDNS.

However, there is an IPv6 design flaw that all the nodess join
all-nodes multicast, which is just a common multicast address
for L2. The flaw was derived from a misconception that multicast
were less costly than broadcast, though broadcast is less costly
than multicast.

All-nodes multicast can cost a lot if someone use it frequently.

For example, ND is specified with:

   o  MinRtrAdvInterval 0.03 seconds

That is, as IPv6 is not propderly designed, L2 under it MAY
suppress multicast entirely and SHOULD supress the all-nodes
multicast address.

A dirty workaround is to supress rate of L2 address of all-nodes
multicast and never use the same L2 address for other rate-unlimited
multicast addresses.

						Masataka Ohta

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
-----------From [email-masked] Fri Jan 12 07:33:24 2007
Date: Fri, 12 Jan 2007 11:15:13 +0900
From: Masataka Ohta <[email-masked]>
To: [email-masked]
Cc: Thomas Narten <[email-masked]>, [email-masked], [email-masked]
Subject: IPv6 design flaw to force all-nodes multicast

> (I mean regardless of L2 specific details)  

With the obvious example of you,

supporting a L3 multicast address over broadcast L1 is just as
costly as supporting a L3 unicast address over broadcast L1,
regardless of L2 specific details.

Wireless L2 protocols not supporting L3 multicast is just poor.

In addition, wireless L2 protocols can also naturally support
L2 broadcast. If power consumption of terminals but not central
stations is the issue, broadcast can be issued only from (or
relayed by) central stations and can be rate limited.

Thus, all the properly designed L3 or upper protocols can enjoy
properly designed L2 multicast at any rate and L2 broadcast maybe
with rate limitation. It has nothing specific to mDNS.

However, there is an IPv6 design flaw that all the nodess join
all-nodes multicast, which is just a common multicast address
for L2. The flaw was derived from a misconception that multicast
were less costly than broadcast, though broadcast is less costly
than multicast.

All-nodes multicast can cost a lot if someone use it frequently.

For example, ND is specified with:

   o  MinRtrAdvInterval 0.03 seconds

That is, as IPv6 is not propderly designed, L2 under it MAY
suppress multicast entirely and SHOULD supress the all-nodes
multicast address.

A dirty workaround is to supress rate of L2 address of all-nodes
multicast and never use the same L2 address for other rate-unlimited
multicast addresses.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 18:50:46 +0000

> > > > ... if your L2 supports broadcast but at significant power cost then i
> > > > suggest we revive bmanning's old DNS DISCOVER proposal.
> > > 

yes, you.

> 	you mean the DISCOVER ID that is -still- in the RFCED queue?	

yes, that one.

yes, it has.

---------------------------------------------------------

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 18:50:46 +0000

yes, you.

yes, that one.

yes, it has.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 17:53:02 +0000

> 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 work at the moment, showing that at least one large company in the
world doesn't think stateless autoconfig is the right way to go.  i think
there's also reason to believe that the "/64 per LAN" ideology might be
tied to the stateless autoconfig ideology.  (DHCPv6 and /112's work fine.)

> > you'll have to cope with hash collisions, however improbable they may be.
> 
> Fortunately, there is no problem with that. If a given name-based address
> was accidentally configured the query will be silently dropped.

that sounds like a problem, to me.  why isn't it a problem?

yo, bill!

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 17:53:02 +0000

yo, bill!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Jan 2007 09:28:21 +0100

On Thu, Jan 11, 2007 at 05:41:26PM +0100,
 Pars Mutaf <[email-masked]> wrote 

> But it is still multicast DNS?

I really do not understand you. Try in French :-) Because, obviously,
if it is unicast, it is not multicast :-)

Also, it is not really DNS, it is LLMNR (same packet format, many
similar concepts but a different protocol).

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 23:03:44 +0000

yo, bill!

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 17:53:02 +0000

yo, bill!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Jan 2007 09:28:21 +0100

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 23:03:44 +0000

> 	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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Jan 2007 15:55:44 +0100

> reach other stfix) with ESMTP
	id 7C0A626C224; Fri, 12 Jan 2007 09:28:22 +0100 (CET)
Date: Fri, 12 Jan 2007 09:28:21 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Pars Mutaf <[email-masked]>
Organization: NIC France
Cc: [email-masked], Stephane Bortzmeyer <[email-masked]>,
	[email-masked]
Subject: Re: multicast DNS without multicast (in IPv6 only)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 23:03:44 +0000

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Jan 2007 23:03:44 +0000

thanksly.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Jan 2007 15:55:44 +0100

i, 12 Jan 2007 07:30:10 -0500
Cc: [email-masked], [email-masked]
Subject: Re: multicast DNS without multicast (in IPv6 only) 
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

thanksly.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Jan 2007 15:55:44 +0100

> reach other i, 12 Jan 2007 07:30:10 -0500

thanksly.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Jan 2007 15:55:44 +0100

subnets in theory

subnets in theory

---

From: [email-masked]
Date: Fri, 12 Jan 2007 14:25:57 +0000

> revived it will need to use one of other publication processes.

	of course, the justification for requiring a Standards Track action
	for the allocation of an opcode was never questioned.  the impediment
	that such a requirement places on development is so onerous that many
	folks just ignore the IETF's strictures and don't bring their work 
	to that forum.  Who was it that promoted an RFC on getting allocations
	for experimental use?  Can't remember who that was, but it was a little
	to late.   DISCOVER is in no shape to be a full-fledged Standards track
	item.  It IS an idea that is worthy of further use/experimentation to 
	see if it can be integrated into a data-driven networking architecture.
	And for that reason, it is worthy of an opcode assignment.  But, thats
	my opinion and we know what that is worth.

--bill

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 12 Jan 2007 18:17:46 +0100

> needed for non-point-to-point IPv6 links.

Hi Remi, 

(Sorry for the delay, I'm trying to respond to each mail but
I rate limited myself)

The main idea of my proposal was:

"If it works using unicast, then we *really* don't care what 
happens at L2."

Is it multicast capable or not? It is poor design or not? Is it 
costly or not ? (in terms of energy and signaling)... All these 
questions would disappear. That was my point.

But folks say: multicast is a MUST. I can't really argue 
against that.

pars

(I CCed again namedroppers without your permission, supposing 
that is not a problem for you)

---

From: Pars Mutaf <[email-masked]>
Date: Fri, 12 Jan 2007 19:18:38 +0100

> tied to the stateless autoconfig ideology.  (DHCPv6 and /112's work fine.)

Yes I'm from mobile/stateless school :-)

> that sounds like a problem, to me.  why isn't it a problem?

Quick reminder:

The responder configured IPv6 address from hash(name).
The query is sent to that unicast address.

For example John wants to reach Carol. But Carol isn't here. 
Instead there is David. And accidentally hash(Carol)=hash(David).

The DNS query(Carol) will be received by David. 
David can silently drop it. Or he can respond: I'm not Carol. 

I missed something?

Thanks
pars

---

From: [email-masked]
Date: Sat, 13 Jan 2007 13:05:41 +0000

> if it is unicast, it is not multicast :-)

	unicast is a degenerative case of multicast.

> similar concepts but a different protocol).

	LLMNR is not DNS mostly 'cause the IESG mandated it.
	one could easly see this as DNS on a different port#.

--bill

---

From: [email-masked]
Date: Sat, 13 Jan 2007 13:14:23 +0000

> put both up for ftp and share the url's here, and isc among others will take

	i think i will defer for the moment.  the code uses OPCODE 5,
	which, if seen in the wild would further antagonise the IESG.

> > 	the text will be pumped out shortly.

	the last iteration, castrated and pacified for IESG/IETF consumption.
	---------------------------------------------------------------------

Network Working Group                                       Bill Manning
draft-manning-opcode-discover-02.txt                              ep.net
Expires: May 2006                                             Paul Vixie
                                                                     ISC
                                                        16 November 2005

                 DISCOVER: Supporting Multicast DNS Queries

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on XXXXXX.

   Distribution of this memo is unlimited.

Abstract

   This document describes the DISCOVER opcode, an experimental
   extension to the Domain Name System (DNS) to use multicast queries
   for resource discovery.  A client multicasts a DNS query using the
   DISCOVER opcode and processes the multiple responses that may
   result.

1. Introduction

   In the standard Domain Name System (DNS) [3] [4], queries are always
   unicast using the QUERY opcode.  The TBDS research project, funded
   under DARPA grant F30602-99-1-0523, explored the use of multicast
   DNS [3][4] queries for resource discovery.  Multicast queries may
   return multiple replies, while the standard DNS QUERY operation [5]
   expects a single reply.  Instead of extending the QUERY
   opcode, the project developed and tested a new query operation,
   DISCOVER, that is designed to accommodate multiple responses from a
   multicast query.  This memo documents the processing rules for
   DISCOVER, for possible incorporation in a future revision of the DNS
   specification.

2. DISCOVER Processing Rules

   A requester will send a DISCOVER query message to a multicast
   destination address, with some particular multicast scope.  The
   requester must be prepared to receive multiple replies from multiple
   responders, although we expect that there will be a single reply
   per responder.

   DISCOVER responses (i.e., response messages from DISCOVER queries)
   have standard Answer, Authority, and Additional sections.  For
   example, the DISCOVER response is the same as the response to a
   QUERY operation.  Zero-content answers should not be sent, to avoid
   badly formed or unfulfilled requests.  Responses should be sent to
   th unicast address of the requester, and the source address should
   reflect the unicast address of the responder.  DISCOVER responses
   may echo the request's Question section or leave it blank, just as
   for QUERY.

   DISCOVER works like QUERY, except:

	1. The Question section of a DISCOVER operation contains
	   <QNAME=zonename,QTYPE=SOA> tuples, if the section is
           present.

 	   Within TBDS, this structure was augmented with:
	   <QNAME=service,QTYPE=SRV>.  While this worked, it would be
	   cleaner to ask the SRV question in a separate pass, and any
	   future work should take this into consideration.

        2. If QDCOUNT equals 0, then only servers willing to do recursion
	   should answer; other servers must silently discard a DISCOVER 
           request with QDCOUNT equals 0. 

        3. if QDCOUNT is not equal to 0, then only servers that are 
	   authoritative for the zones named by some QNAME should answer.

     Hence, replies to DISCOVER queries will always be authoritative or
     else have RA (Recursion Available) set.

3. Using DISCOVER Queries

3.1  Performing Host Lookups

   To perform a hostname lookup using DISCOVER, a node could:

     o  Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
        ip6.arpa domain.

     o  DISCOVER whether any in-scope server(s) are authoritative for
        this zone.

                If so, query these authoritative servers for local
                in-addr/ip6 names.

     o  If not, DISCOVER whether there are recursive servers available.

                If so, query these recursive servers for local
                in-addr/ip6 names.

        The requester can determine from the replies whether there are
	any DNS servers that are authoritative (or support recursion)
	for the zone.

     o  Once the host's FQDN is known, repeat the process to
        discover the closest enclosing authoritative server for
        this local name.

     o  Cache all NS and A data learned in this process, respecting TTL's.

3.2 Performing Service Lookups

   To lookup a service name using DISCOVER, the following steps may be
   used:

     o  Use DISCOVER as outlines in Section 3.1 to perform
	gethostbyaddr() and then gethostbyname() on one's own
	link-local address.  This gives a list of local authoritative
        servers.

     o  Assume that the closest enclosing zone for which an
        authoritative server responds to an in-scope DISCOVER message is
        this host's "parent domain", and compute the SRV name as

	       _service._transport.*.parentdomain.

	This is a change to the definition as defined in RFC 1034 [3].
	A wildcard label ("*") in the QNAME used in a DNS message with
	op-code DISCOVER should be evaluated with special rules: the
	wildcardshould match any label for which the DNS server data is
	authoritative.  For example 'x.*.example.com.' would match
	'x.y.example.com.' and 'x.yy.example.com.', provided that the
	server was authoritative for 'example.com.'

     o  Finally, send a SRV query for this SRV name to the discovered
        local authoritative servers, to complete the getservbyname() call.
        
	This call returns a structure that can be populated by response
	values, as follows:

        s_name    The name of the service, "_service" without the
                  preceding underscore.

        s_aliases The names returned in the SRV RRs in replies
                  to the query.

        s_port    The port number in the SRV RRs replies to the
                  query.  If these port numbers disagree - one
                  of the port numbers is chosen, and only those
                  names which correspond are returned.

        s_proto   The transport protocol from named by the
                  "_transport" label, without the preceding
                  underscore.

3.3  Using DISCOVER for Disconnected Names

   DISCOVER allows discovery of a host (for example, a printer offering
   LPD services) whose DNS server answers authoritatively for a domain
   name that hasn't been delegated to it, but is defined within some
   local scope.  Since DISCOVER is explicitly defined to discover
   undelegated zones for tightly-scoped queries, this behavior isn't a
   violation of DNS's coherency principles.   Note that a responder to
   DISCOVER might not be traditional DNS software, it could be
   special-purpose software.

   DISCOVER usage for disconnected networks with no authoritative
   servers can be achieved using the following conditions.

          o Hosts run a "stub server" that acts as though its FQDN
            were a zone name.

          o The computed SOA gives the host's FQDN as the MNAME, "." as
	    the ANAME, seconds-since-1Jan2000 as the SERIAL, and low
	    constants for EXPIRE and the other SOA timers.

          o  NS is used as the host's FQDN.

          o  The glue is computed as the host's link-local address, or
 	     hosts may run a  "DNS stub server" that acts as though its
	     FQDN were a zone name.
        
   The rules governing the behavior of this stub server are given 
   elsewhere [1] [2].

   Such stub servers should answer DISCOVER packets for its zone, and
   will be found by the iterative "discover closest enclosing authority
   server" by DISCOVER clients, in either the gethostbyname() or SRV
   cases described above.  Note that stub servers answer only with
   zone names which exactly match QNAME's, not with zone names which
   are owned by QNAME's.

4. IANA Considerations

   The IANA will need to assign a numeric value for the DISCOVER opcode.

5. Security Considerations

   No new security considerations are known to be introduced with a new
   DNS query operation.  However, using multicast for service discovery
   has the potential for denial of service from flooding attacks.  It
   may also be possible to enable deliberate misconfiguration of
   clients simply by running a malicious DNS server that falsely claims
   to be authoritative for delegations.  One possible way to mitigate
   this threat is to use credentials, such as CERT resource records
   within an RR set.  The TBDS project took this approach.  TBDS did
   not directly utilize DNSSEC and so possible interactions with
   DNSSEC aware/capable servers are unknown.

6. Acknowledgments

   This material was generated in discussions on the mdns maili
   list hosted by Zocalo in March 2000 and updated by discussions in 	
   September/October 2003 on a closed mailing list.  David Lawrence, 
   Scott Rose, Stuart Cheshire, Bill Woodcock, Erik Guttman were 
   active contributors. Suzanne Woolf was part of the original
   implementation team and an invaluable sanity checker.

7. References

[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
        Work in Progress, November 2000.

[2]  Woodcock, B., Manning, B., "Multicast Domain Name Service",
        Work in Progress, August 2000.

[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
        RFC 1034, November 1987.

[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
        RFC 1035, November 1987.

[5]  QUERY opcode -- defined in section 3.7, 4.3, and section 5 of RFC
	1034 and in section 4.1.1 of RFC 1035.

Authors' Addresses

   Bill Manning
   PO 12317
   Marina del Rey, CA. 90295

   Paul Vixie
   950 Charter Street
   Redwood City, CA 94063

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 13 Jan 2007 11:32:53 -0800

> 	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 speed wireless networks, the physical layer gets tuned between
sender and receiver, resulting in huge gains in transmission quality.
You can only apply a fraction of these tunings to multicast traffic. 

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 the same time,
which is hard, or accept to effectively replicate the multicast packet
for each station.

Transmission tuning and power saving are both very desirable. The
natural consequence is to try avoid multicast operation whenever
possible.

-- Christian Huitema

---

From: [email-masked]
Date: Sat, 13 Jan 2007 19:49:24 +0000

> You can only apply a fraction of these tunings to multicast traffic. 

	re wireless... unless you have tightly coupled directional
	antennas, high speed wireless (one presumes that "high speed"
	in this context is the 802.11n draft standard) there is 
	a "footprint" of signal propogation that -any- receiver
	within that "footprint" may receive.

> which is hard, or accept to effectively replicate the multicast packet

	for multicast, you can assume that all intended receivers are
	"awake" for your application design, but that is not (to my understanding)
	an intrinsic component of multicast.
 
> natural consequence is to try avoid multicast operation whenever

	The first i agree with, the second depends on design goals.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 14 Jan 2007 16:06:57 +0900

> 	an intrinsic component of multicast.

It is merely that each station is required to wake up when
packets to the station are transmitted, regardless of whether
the packets are unicast, multicast or broadcast.

Thus, the amount of power consumption of a station increases
proportional to the number of multicast addresses the station
joins.

It's not a problem if the station is running streaming applications,
which, anyway, consume considerable amount of power.

However, frequently multicast RAs to all-nodes multicast address
are really annoying.

							Masataka Ohta

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.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 14 Jan 2007 13:01:49 +0200

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 whether it will actually be the case for WiMax as
it is being defined and used. As you may know, there has
been active work in the 16ng working group during the
summer and autumn, and that has resulted in a
number of changes to the way that people originally
planned to run this. In particular, the WG has
considered issues relating to waking up dormant
hosts. My understanding is that their current
designs do NOT have that problem. For instance,
they plan to recommend a point to point like link
model where the host's ND or other link local
multicast traffic does not impact other hosts.
And there is a plan on employing RFC 4541 (MLD
snooping) where 802.16 is run as an Ethernet.
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 sure how big practical problem this
is. I hope the providers are not setting up
their 802.16 networks so that people can
find printer.local in the Tokyo subnet...

Anyway, if we think of the hash approach independently
of your 802.16 use case, I think there are still several
significant problems. As others have mentioned, you
still need something that allows ND to work, and it,
in turn is based on multicast at IP level. Perhaps
more fundamentally, I think a local unmanaged naming
system should be able to live with collisions. As your
scheme combines the name space to the IP space
this becomes very difficult. For starters, to allow
multiple similar names, you would have to disable
DAD and change ND, and I suspect it would not work
with current TCP and applications. Also, there
are operational issues such as inability to search
except for exact match.

Jari

---

From: [email-masked]
Date: Sun, 14 Jan 2007 13:16:31 +0000

> find printer.local in the Tokyo subnet...

	and this would be bad in what way?  :)

> are operational issues such as inability to search

	DISCOVER works with namespace collisions.
	fuzzy matching -after- the collision is detected
	requires more than just the FQDN and address.  When
	we did the original work on this (a decade ago) in 
	the TBDS project, we used a local crypto key as a third
	discriminator.  

	Neither DISCOVER or TBDS is v6-specific.

---

From: Pars MUTAF <[email-masked]>
Date: Sun, 14 Jan 2007 19:51:41 +0100

Thank you very much for this mail. Please see below:

> neighbors.

Great news. This means that ND and DAD will work
without waking up all dormant hosts. If I understand
correctly.

> It does not solve all problems -- if

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?

Firstly, the multicast name resolution idea that started
with ZEROCONF (if I'm correct), has the potential to find
many new and popular applications. This means that many
users may use it in the future, especially in wireless
broadband networks. However, this also means that it may
create a lot of multicast queries that wake up every host
and consume a lot of energy.

>From this point of view, I suspect that LLMNR's potentials
are underestimated by its own design.
(I mean: if a LLMNR query must be forwarded to every node)

Secondly, nothing prevents a user from trying different
names again and again. Each query would wake up many
dormant hosts. Can we call this a DoS attack? I'm not
even sure. He/she is doing that for fun perhaps. But the
consequences would be bad if a LLMNR query must be
forwarded to all (probably dormant) devices.

> are operational issues such as inability to search

Pushing my own scheme is not my intent in this discussion.
(I wanted feedback, and I had a lot and I thank you all)
However, the good news that you have announced in your mail
are also good news for my proposal.

My proposal *needs* ND for address resolution, and DAD
for address (i.e. name) collision detection. If these protocols
will run without waking up every dormant host, then this is
also great for me.

I will think more about your other comments (I'm not
sure to understand). Thanks!

pars

ps: I'm not sure if folks realize the costs of waking up
every dormant host at the same time. It is not only an
energy consumption problem. It is also a signaling
problem. The most efficient dormant is achieved using a
mechanism called "paging". This is a generic protocol. To
wake up a dormant host, you have to search it in many cells.
This is for one host. You can probably imagine what would
happen if you try to page every dormant host.

> Jari

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Jan 2007 12:32:07 -0800

> wake up every dormant host, in this case. Why this may

There was actually a reasonably thorough discussion of this issue during
the design of LLMNR. You can find it in the list archive. At one time,
there was a design proposal to use multiple multicast groups. The
group-id would be derived from the queried name. The proposal was
eventually discarded.

Part of the reason was implementation complexity. A hash based solution
requires to write the name in canonical form before hashing. Canonical
functions are hard to get right, especially with international names,
and could cause significant interoperability issues. 

Another reason was the general overhead of multiple multicast groups.
Many station interfaces can only handle a limited number of groups, and
fall back to promiscuous mode and software filtering after that number.
In switched environments, switches have to maintain routing state for
the multiple groups. The multiple groups may reduce the overhead of
individual queries, but there is a significant management overhead.

Given that, it was decided to just keep it simple, and use exactly one
group.

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Mon, 15 Jan 2007 10:57:41 +1100

> wireless link such as 802.11 is that the latter can not be ACKed and

	Multicast is unreliable, period.  This is independent of the
	media being used.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Jan 2007 09:18:03 +0900

> 	Multicast is unreliable, period.  This is independent of the

If you assume L4 ack and retransmission, you are right.

However, even at L4, unidirectional UDP unicast is just as reliable
as unidirectional UDP multicast.

At L2, Ethernet multicast is as reliable as Ethernet unicast and
802.11 unicast, because there are CD or ACK and retransmissions.

OTOH, 802.11 multicast with no CD, ACK nor retransmission is a
lot less reliable.

							Masataka Ohta

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 30 Jan 2007 23:22:37 +0100

Selon Pars MUTAF <[email-masked]>:

> many new and popular applications.

Dear AD, chairs, folks;

I would like to bring a new problem statement draft to your
attention (1 page). Until it appears in the I-D rep, please
find it here:

http://www.freewebs.com/pmutaf/draft-mutaf-piqproblem-00.txt

I believe that not having this application
would be very unfortunate. (I think this is an INT area topic.)
And currently available name resolution techniques do not
address this problem as they should.

Do you have any comments on this problem statement?

Thanks.
pars mutaf

ps: sorry I kept the IPv6 WG CCed, but it looked like a good
idea because I was forwarded to namedroppers by IPv6 folks.
I wanted to keep them informed.