Re: multicast DNS without multicast (in IPv6 only)
Masataka Ohta
> 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 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.
> 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")
And the address is a multicast address joined by all the hosts with
64bithash("johnsmith.local")=64bithash(DNS name).
Masataka Ohta
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Masataka Ohta
> This threat is probably another good reason for not allowing
> multicast.
Wrong.
As I already stated reasons, there is no point not allowing
broadcast.
Thomas Narten
> 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 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
bman...@karoshi.com
> > > 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.
> >
> > I have no problem with that.
>
> 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
bman...@karoshi.com
> > technology? The IESG is dead-set against this.
>
> 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.
Masataka Ohta
>>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)
With the obvious example of you,
link-local subnet prefix | 64bithash("johnsmith.local")
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
Pekka Savola
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 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.
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
bman...@karoshi.com
> [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 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.
>
> 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
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
Hallam-Baker, Phillip
First, I know that multicast has a base in the IETF. Is there at this =
point any real prospect of widespread use? Multicast violates the =
principle of keeping the core of the Internet as simple and unchanging =
as possible. Multicast is also the amplification mechanism to beat all =
amplification mechanisms.=20
A distributed caching model achieves the same effect with considerably =
less impact on the core Internet infrastructure. Instead of doing =
branching in the network core we do it at the next level up in the =
stack. This allows us to build in security in a coherent way. It also =
eliminate the probably bogus assumption that all participants are =
interacting synchronously. This is not the case in video-on-demand due =
to pause features.
What is it that is being proposed? Is it a feature that is to assist =
deployment of multicast or a feature that has some other advantage that =
happens to use multicast?
=20
I would like to see a concise statement of objectives and requirements =
that does not reference a previous post in the thread.
> -----Original Message-----
> From: owner-nam...@ops.ietf.org=20
> [mailto:owner-nam...@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Friday, January 12, 2007 4:37 AM
> To: Paul Vixie
> Cc: bman...@karoshi.com; pars....@int-evry.fr;=20
> namedr...@ops.ietf.org; ip...@ietf.org
> Subject: DNS opcode DISCOVER [Re: multicast DNS without=20
> multicast (in IPv6 only)]
>=20
> [DNS opcode DISCOVER]
>=20
> 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=20
> years, and the=20
> > idea is still solid and useful and interesting, and the current=20
> > proposed RFC is experimental, and most importantly, because=20
> the need=20
> > for it will continue to resurface until we push it over the=20
> top of the=20
> > hill and roll it down to the town.
>=20
> The problem was, AFAIR, that allocating opcodes requires a=20
> Standards Action. No experimental spec can do that. If=20
> DISCOVER is to be revived it will need to use one of other=20
> publication processes.
>=20
> --=20
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20
> --
> to unsubscribe send a message to=20
> namedroppe...@ops.ietf.org with the word 'unsubscribe'=20
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>=20
Ted Hardie
>I am really confused here.
>
There is ongoing (okay, possibly petering out) discussion on the NANOG list at
the moment on this topic, related to "internet video" (the NANOG archives
are at http://www.merit.edu/mail.archives/nanog/ . The threads are
"Network end users to pull down 2 gig" and
"Internet Video: The Next Wave of Massive Disruption to the US Peering Ecosystem".)
One of the points made early on by Sean Donelan is that there isn't a
bright line here where multicast is useful above and isn't useful below.
To quote one of his points:
Multicast doesn't have to be real-time. If you collect interested subscribers over a longer time period, e.g. scheduled downloads over the next hour, day, week, month, you can aggregate more multicast receivers through the same stream. TiVo collects its content using a broadcast schedule.
I believe you will find the rest of the thread gives an interesting set of perspectives
on how multicast fits in among other technologies; particularly, it gives you a
sense of how one operational community might use to smooth spikes in usage.
Ted
>A distributed caching model achieves the same effect with considerably less impact on the core Internet infrastructure. Instead of doing branching in the network core we do it at the next level up in the stack. This allows us to build in security in a coherent way. It also eliminate the probably bogus assumption that all participants are interacting synchronously. This is not the case in video-on-demand due to pause features.
>
>What is it that is being proposed? Is it a feature that is to assist deployment of multicast or a feature that has some other advantage that happens to use multicast?
>
>
>I would like to see a concise statement of objectives and requirements that does not reference a previous post in the thread.
>
>
>> -----Original Message-----
>> From: owner-nam...@ops.ietf.org
>> [mailto:owner-nam...@ops.ietf.org] On Behalf Of Pekka Savola
>> Sent: Friday, January 12, 2007 4:37 AM
>> To: Paul Vixie
>> Cc: bman...@karoshi.com; pars....@int-evry.fr;
>> namedr...@ops.ietf.org; ip...@ietf.org
>> Subject: DNS opcode DISCOVER [Re: multicast DNS without
>> multicast (in IPv6 only)]
>>
>> [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 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.
>>
>> 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
>>
Hallam-Baker, Phillip
There is a lot of Internet broadband content distribution going on =
today. I do not see where this proposal fits in.
Is this the choice of the right tool or 'have hammer, will use it' or =
'have always wanted this particular hammer and looking for excuse to get =
one' ?
> -----Original Message-----
> From: Ted Hardie [mailto:har...@qualcomm.com]=20
> Sent: Friday, January 12, 2007 2:23 PM
> To: Hallam-Baker, Phillip; Pekka Savola; Paul Vixie
> Cc: bman...@karoshi.com; pars....@int-evry.fr;=20
> namedr...@ops.ietf.org; ip...@ietf.org
> Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without=20
> multicast (in IPv6 only)]
>=20
> 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=20
> there at this point any real prospect of widespread use?=20
> Multicast violates the principle of keeping the core of the=20
> Internet as simple and unchanging as possible. Multicast is=20
> also the amplification mechanism to beat all amplification mechanisms.
>=20
> There is ongoing (okay, possibly petering out) discussion on=20
> the NANOG list at the moment on this topic, related to=20
> "internet video" (the NANOG archives are at=20
> http://www.merit.edu/mail.archives/nanog/ . The threads are=20
> "Network end users to pull down 2 gig" and "Internet Video:=20
> The Next Wave of Massive Disruption to the US Peering Ecosystem".)
>=20
> One of the points made early on by Sean Donelan is that there=20
> isn't a bright line here where multicast is useful above and=20
> isn't useful below.
> To quote one of his points:
>=20
> Multicast doesn't have to be real-time. If you collect=20
> interested subscribers over a longer time period, e.g.=20
> scheduled downloads over the next hour, day, week, month, you=20
> can aggregate more multicast receivers through the same=20
> stream. TiVo collects its content using a broadcast schedule.
>=20
> I believe you will find the rest of the thread gives an=20
> interesting set of perspectives on how multicast fits in=20
> among other technologies; particularly, it gives you a sense=20
> of how one operational community might use to smooth spikes in usage.
>=20
> Ted
>=20
>=20
> >A distributed caching model achieves the same effect with=20
> considerably less impact on the core Internet infrastructure.=20
> Instead of doing branching in the network core we do it at=20
> the next level up in the stack. This allows us to build in=20
> security in a coherent way. It also eliminate the probably=20
> bogus assumption that all participants are interacting=20
> synchronously. This is not the case in video-on-demand due to=20
> pause features.
> >
> >What is it that is being proposed? Is it a feature that is=20
> to assist deployment of multicast or a feature that has some=20
> other advantage that happens to use multicast?
> >=20
> >
> >I would like to see a concise statement of objectives and=20
> requirements that does not reference a previous post in the thread.
> >
> >
> >> -----Original Message-----
> >> From: owner-nam...@ops.ietf.org=20
> >> [mailto:owner-nam...@ops.ietf.org] On Behalf Of Pekka Savola
> >> Sent: Friday, January 12, 2007 4:37 AM
> >> To: Paul Vixie
> >> Cc: bman...@karoshi.com; pars....@int-evry.fr;=20
> >> namedr...@ops.ietf.org; ip...@ietf.org
> >> Subject: DNS opcode DISCOVER [Re: multicast DNS without=20
> multicast (in=20
> >> IPv6 only)]
> >>
> >> [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 and useful and interesting, and the current=20
> >> > 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.
> >>
> >> The problem was, AFAIR, that allocating opcodes requires a=20
> Standards=20
> >> Action. No experimental spec can do that. If DISCOVER is to be=20
> >> revived it will need to use one of other publication processes.
> >>
> >> --
> >> Pekka Savola "You each name yourselves=20
> king, yet the
> >> Netcore Oy kingdom bleeds."
> >> Systems. Networks. Security. -- George R.R. Martin: A=20
> Clash of Kings
> >>
> >> --
> >> to unsubscribe send a message to
> >> namedroppe...@ops.ietf.org with the word 'unsubscribe'
> >> in a single line as the message text body.
> >> archive: <http://ops.ietf.org/lists/namedroppers/>
> >>
> >
> >--
> >to unsubscribe send a message to=20
> namedroppe...@ops.ietf.org with=20
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://ops.ietf.org/lists/namedroppers/>
>=20
>=20
bman...@karoshi.com
> On Thu, Jan 11, 2007 at 05:41:26PM +0100,
> Pars Mutaf <pars....@int-evry.fr> 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 French :-) Because, obviously,
> if it is unicast, it is not multicast :-)
unicast is a degenerative case of multicast.
> Also, it is not really DNS, it is LLMNR (same packet format, many
> 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
bman...@karoshi.com
> > do you want the code (8.1.2 based and haq'ed into 9.3.1 ) or do you
> > want to start fresh?
>
> a look at them.
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.
>
> thanksly.
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
ietf...@ietf.org.
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.
Christian Huitema
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.=20
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.=20
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
bman...@karoshi.com
> > > I really do not understand you. Try in French :-) Because,
> obviously,
> > > if it is unicast, it is not multicast :-)
> >
>
> Bill, this is emphatically not true for high speed wireless links, such
> as the upcoming IEEE 802.11n standard.
>
> sender and receiver, resulting in huge gains in transmission quality.
> 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.
> 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.
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.
> Transmission tuning and power saving are both very desirable. The
> natural consequence is to try avoid multicast operation whenever
> possible.
The first i agree with, the second depends on design goals.
--bill
Masataka Ohta
>>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.
> 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.
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.
Paul Vixie
> 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:
>
>
> that 64bithash("johnsmith.local") is the IPv6 interface ID.
> The link-local subnet prefix is constant and well-known.
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.
> 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?
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.
--
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.
>
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?
> > 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.
>
> I have no problem with that.
yo, bill!
--
Paul Vixie
> > > > suggest we revive bmanning's old DNS DISCOVER proposal.
> > >
> > > I have no problem with that.
> >
> > yo, bill!
>
yes, you.
> you mean the DISCOVER ID that is -still- in the RFCED queue?
yes, that one.
> (and has been in one form or another for the past eight years?)
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 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.
--
Paul Vixie
> 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.
--
bman...@karoshi.com
> 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...
and this would be bad in what way? :)
> 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.
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.
>
> Jari
Christian Huitema
> 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 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.=20
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
Mark Andrews
> 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, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Masataka Ohta
>>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 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
Pars Mutaf
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
Pars Mutaf
> 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.
>
> 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?
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.
> > 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.
> [...]
> > 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?
Right. Please let me know if you see a problem with this.
Thanks!
pars
Pars Mutaf
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:
> > ...
> > 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.
>
> 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)
> and 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.
> > 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?
>
> 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.
I have no problem with that.
Thanks
Pars Mutaf
> Pars Mutaf <pars....@int-evry.fr> 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.
>
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
> 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
Pars Mutaf
> On Thu, Jan 11, 2007 at 03:30:26PM +0100,
> Pars Mutaf <pars....@int-evry.fr> wrote
>
> > I used the term .local with no particular reason. If recent advances
> > showed that it is unnecessary.
>
> 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
Pars Mutaf
> 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.
>
> 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.
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)
Pars Mutaf
On Thu, 2007-01-11 at 17:53 +0000, Paul Vixie wrote:
> > My question to Paul Vixie:
> >
> > > matter aren't using a 64-bit netmask.
> >
> > Is this an important limitation? (I'm asking the question)
>
> 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.)
>
Yes I'm from mobile/stateless school :-)
> > > 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?
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
> > > 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.
> >
> > I have no problem with that.
>
> yo, bill!
Pars Mutaf
wrote:
>=20Le=20mercredi=2010=20janvier=202007=2017:14,=20Pars=20Mutaf=20a=20=C3=A9=
crit=20:
>=20>=20>=20So,=20the=20proposal=20is=20that=20if=20the=20hash=20collides=20=
for=20different=20names,
>=20>=20>=20then=20"johnsmith.local"=20must=20rename=20himself,=20right?
>=20>
>=20>=20Right.=20Please=20let=20me=20know=20if=20you=20see=20a=20problem=20=
with=20this.
>=20
>=20My=20understanding=20of=20James=20remarks=20is=20that=20your=20proposa=
l=20merely=20moves=20the=20>=20problem=20away=20from=20DNS=20to=20Neighbor=
=20Discovery,=20but=20does=20not=20solve=20the=20
>=20core=20issue=20at=20all,=20which=20is=20that=20some=20kind=20of=20mult=
icast/broadcast=20is=20
>=20needed=20for=20non-point-to-point=20IPv6=20links.
Hi=20Remi,=20
(Sorry=20for=20the=20delay,=20I'm=20trying=20to=20respond=20to=20each=20ma=
il=20but
I=20rate=20limited=20myself)
The=20main=20idea=20of=20my=20proposal=20was:
"If=20it=20works=20using=20unicast,=20then=20we=20*really*=20don't=20care=20=
what=20
happens=20at=20L2."
Is=20it=20multicast=20capable=20or=20not?=20It=20is=20poor=20design=20or=20=
not?=20Is=20it=20
costly=20or=20not=20?=20(in=20terms=20of=20energy=20and=20signaling)...=20=
All=20these=20
questions=20would=20disappear.=20That=20was=20my=20point.
But=20folks=20say:=20multicast=20is=20a=20MUST.=20I=20can't=20really=20arg=
ue=20
against=20that.
pars
(I=20CCed=20again=20namedroppers=20without=20your=20permission,=20supposin=
g=20
that=20is=20not=20a=20problem=20for=20you)
--------------------------------------------------------------------
IETF=20IPv6=20working=20group=20mailing=20list
ip...@ietf.org
Administrative=20Requests:=20https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
PLEASE=20NOTE:=20THE=20ABOVE=20MESSAGE=20WAS=20RECEIVED=20FROM=20THE=20INT=
ERNET.
On=20entering=20the=20GSI,=20this=20email=20was=20scanned=20for=20viruses=20=
by=20the=20Government=20Secure=20Intranet=20(GSi)=20virus=20scanning=20ser=
vice=20supplied=20exclusively=20by=20Cable=20&=20Wireless=20in=20partnersh=
ip=20with=20MessageLabs.
In=20case=20of=20problems,=20please=20call=20your=20organisational=20IT=20=
Helpdesk.
The=20MessageLabs=20Anti=20Virus=20Service=20is=20the=20first=20managed=20=
service=20to=20achieve=20the=20CSIA=20Claims=20Tested=20Mark=20(CCTM=20Cer=
tificate=20Number=202006/04/0007),=20the=20UK=20Government=20quality=20mar=
k=20initiative=20for=20information=20security=20products=20and=20services.=
=20=20For=20more=20information=20about=20this=20please=20visit=20www.cctma=
rk.gov.uk
**************************************************************************=
**
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=
for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=
disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the
intended=20recipient,=20please=20notify=20post...@gchq.gsi.gov.uk.=20=20=
This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email
inf...@gchq.gsi.gov.uk
**************************************************************************=
**
______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________
Stephane Bortzmeyer
Pars Mutaf <pars....@int-evry.fr> wrote
> 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).
> 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")
It really looks like PNRP :
http://www.microsoft.com/technet/itsolutions/network/p2p/pnrp.mspx
http://en.wikipedia.org/wiki/PNRP
Stephane Bortzmeyer
Pars Mutaf <pars....@int-evry.fr> wrote
> 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.
> 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).
Stephane Bortzmeyer
Pars Mutaf <pars....@int-evry.fr> wrote
> > 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 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).
James Carlson
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
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 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?
> 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.
[...]
> 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 <james.d...@sun.com>
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
Jeroen Massar
--------------enig44AD8A17B11586C8EDAF0793
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hallam-Baker, Phillip wrote:
> I still don't understand what the plan is.
>=20
> 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).
But Big Companies(tm) are not the only users of the Internet!
Multicast allows EVERY user of the Internet to very easily use a small
amount of bandwidth to send one single copy into the Internet and have
tens of thousands of other users enjoy it.
You could argue "just upload your video's up to youtube". Some users
don't want their works to be owned by third parties, some people want to
provide it in different formats. The Internet is about freedom, freedom
in what you do and how you do it. Having multicast available to end
users gives extra freedom to the users of the Internet.
Multicast will allow that for anything without having to play around in
the application stack and having to make application/protocol specific
caches for every sort of application. Of course we could just do
everything over HTTP, but hey where is the fun in that?
Also, what is the largest cost for ISP's anyway associated by those
traffic hogs like P2P? They are transmitting the same kind of data over
and over over their transit links.
Multicast would solve that as the data is only sent ones and fanned out
to the end users that want it. Read: your data goes over the transit
once, and only once: that actually saves money... and that is where one
of the catches lies, do transit providers want ISP's to save money!? :)
For warez-content distribution it seems that NNTP is nowadays the clear
winner anyway, with companies solely dedicated to providing access to
the TeraBytes of "NNTP Caches" that they have set up.
The big problem with multicast of course is the configuration of it and
the trust one has to have in its peers, as it can create a lot of havoc
when something goes bad, see for nice cruel bedtime horror stories the
various mbone,m6bone etc lists ;)
Greets,
Jeroen
--
Additional lesson on how to send bypass greylists, especially:
telnet sa.dom.com 25
EHLO purgatory.unfix.org
250-sa.dom.com
250-PIPELINING
250-SIZE 102400000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <jer...@unfix.org>
250 2.1.0 Ok
RCPT TO: <p...@dom.com>
450 4.7.1 <p...@dom.com>: Recipient address rejected: Greylisted for 1
minutes
And then send your mail ;)
--------------enig44AD8A17B11586C8EDAF0793
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iHUEARECADUFAkWo5GcuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I9wqAJ4qqg+kH5A2Li5F6l29DAQ2n7DB
ZwCfVUBPwQRviFPE6S5pUGwE1SnClyc=
=ZCeZ
-----END PGP SIGNATURE-----
--------------enig44AD8A17B11586C8EDAF0793--
Jari Arkko
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
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
Pars MUTAF
> 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). 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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Christian Huitema
> phone. They are simply in trouble. They have hard time recovering the
cell
> phone numbers of their friends, colleagues, family members etc.
Do you mean that the only copy of their address book was inside their
cell phone? If that is the case, they will indeed have a hard time
retrieving all these numbers. On the other hand, there are many ways to
synchronize a cell phone with a PC or a server that keeps a safe copy.
You can even use vCards (RFC2426) do describe these entries in a
standardized way.
> I have seen users (including myself) exchanging phone numbers in
> ridiculous ways. The first number is read to the other user, and the
> other user returns his/her number via the cellular network. It should
be
> noted that this also requires short distance user contact. If the
other user
> is 100 meters away, you see each other but you are in a crowded place
and
> you can't reach each other, you simply cannot communicate. You have
> cellular phones but are unable to communicate.
That's ridiculous indeed, when you could simply attach vCard to an
e-mail. Not to mention publishing it in a web page, or make it available
to your friends in an instant-messaging service.
The problems that you describe hardly seem related to server-less name
resolution in a local network!
-- Christian Huitema
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Hello Pars,
A few thoughts...
On 12Feb 2007, at 2:35 PM, Pars Mutaf wrote:
>> The problems that you describe hardly seem related to server-less
>> name
>> resolution in a local network!
>
>
>
> The proposed protocol could also use infrastracture DNS (i.e.
> standard DNS). This would look as follows:
>
> Let us assume that Alice Collins has a personal DNS name
> "alicecollins.domain.com". Her phone has an IP address that is
> registered to this DNS name.
>
So instead of having to remember Alice Collins' phone number you have
to remember the domain name under which her telephone-number-recovery-
services is located.
> The requestor user enters the name Alice Collins, the proposed
> application generates the corresponding DNS name,
How does the proposed application do that unambiguously? Given that
the 'Alice Collins' you are looking for might be a completely
different "Alice Collins" than I know. The namespace collision will
be a problem that you will need to solve.
> makes a
> standard DNS query, and obtains the IP address. At this point the
> proposed application can send a private information query to
> Alice's phone. If approved by Alice (in real-time), her phone
> number can be learned.
>
> This would work globally, but I don't think this is realistic.
> (BTW, it can be noted that, one would ask why I need a phone
> number in this case.)
Indeed, that is the argument above.
>
> Using multicast name resolution (or, name-based IPv6 addresses)
> with human names that have local significance only, seem
> realistic to me. Here the term "local" may take different
> meanings. It may be a local cellular network that covers a large
> number of cells, or a localized mobility management domain.
>
> Such a local cellular zone can cover a large geographical area.
> This is an important progress compared to using a technology
> like Bluetooth (for exchanging private info). But the proposed
> protocol cannot work globally. That's why we need phone numbers
> and our goal is to allow people to share their phone numbers
> more easily.
I think the main problem will be to find a balance between size of
your "locality" and the amount of collisions in your namespace. That
will be problematic, as an illustration: Travel to Volendam (a
village in the Netherlands), walk down the street, and shout "Hey
Piet Veerman" and count the amounts of angry faces.
With the problem you are describing the number of angry faces if
relevant. If I were to activate the feature on the phone that would
provide me with the "Do you want to provide your phone number to
<foo>" and I were to receive more than 2 false positive requests for
my phone number, I would turn of the feature. So if I were the target
group solving the name collisions will be important.
--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/
--Apple-Mail-16--112934156
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFF0y4XtN/ca3YJIocRArjbAJ0eMFBszeLkTCvlKAyAXy5IMVH7BACglcTN
gjF7VvRG1sgC5QZrevCWaFQ=
=+D4b
-----END PGP SIGNATURE-----
--Apple-Mail-16--112934156--
Pars MUTAF
Hello,
Thanks much for all good questions. Please see below:
Selon "Manfredi, Albert E" <albert.e...@boeing.com>:
> > -----Original Message-----
> > From: Pars Mutaf [mailto:pars....@int-evry.fr]
> > Dear all,
> >
> > Quick reminder: the problem that I'm bringing to your
> > attention is:
> >
> > http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-00.txt
>
> Pars, it seems to me that the reason cell phone numbers are hard to get
> is that cell phone users have long preferred it to remain that way.
I don't agree with you here. Cell phone users had no choice. They were and
still are subject to a fundamental trade-off between privacy and
reachability.
I have seen users, with broken cell phones, or who have lost their phone.
They are simply in trouble. They have hard time recovering the cell phone
numbers of their friends, colleagues, family members etc.
I have seen users (including myself) exchanging phone numbers in
ridiculous ways. The first number is read to the other user, and the other
user returns his/her number via the cellular network. It should be noted
that this also requires short distance user contact. If the other user is
100 meters away, you see each other but you are in a crowded place and you
can't reach each other, you simply cannot communicate. You have cellular
phones but are unable to communicate.
Or, just after a tsunami, someone that I know is lost. But I don't have
a cell phone (or lost it). I can borrow a phone from someone else but I
don't have the phone number.
Or simply, you need another user's phone number but you don't have it yet.
You know each other but you have not exchanged your phone numbers yet.
etc etc...
> For
> that matter, with sales people completely abusing the regular land line
> phone system, I believe the majority of land line telephone subscribers
> would have preferred that other phone system to be equally made
> difficult to abuse.
This is an excellent point. Please see below.
>
> So I don't think that making it easier to distribute cell phone
> telephone numbers is something that technology is preventing.
The main requirement is that if you need private information about Alice,
you should ask Alice. Alice will decide in *real-time* (real-time is
really the keyword here). The decision belongs to Alice.
We have Bluetooth, IrDA etc, but they require user contact. Surprisingly
we cannot exchange private information via a cellular network (i.e. over
very large distances). I suspect that this is simply because we don't have
multicast name resolution or name-based IPv6 addresses currently (in
cellular context). Please take my last sentence seriously. I mean it.
These are the only solutions for learning someone's IP address from
his/her human name. And if you don't know Alice's device's IP address,
you cannot reach her phone and request her phone number.
I think this also answers a good question like: "If this protocol is that
important why we don't have it today?"... I think the answer is above.
> In your proposal, for example, the problem will happen when obnoxious,
> over the top sales critters (as they have proven themselves to be)
> figure out how to pretend they are alicecollins making the request for
> your phone number. Your will reply "yes," and then you're screwed.
>
> Or, alternatively, an alicecollins is making this request, but the one
> you really know is called alicejcollins. Now this unknown person has
> your cell number.
These are very sane and important concerns. This protocol must be designed
carefully. My point is that, *today*, we *have* well-known security
solutions to achieve that. A serious threat analysis must be made and the
protocol must be designed accordingly. Some of the potential threats and
defenses (I'm not expert on details):
1. For example, as you have very well identified, the requesting
user's identity must be verifiable. If not, the responder user
must be notified. Again, the decision belongs to the user.
2. There will be Denial-of-Service threats if we use public key
cryptography. Same problem with IKE. In our case, we have an
advantage: the requestor is necessarily a *human*. Consequently,
CAPTCHAs (Turing test) may be used. All we need to do is to define
a CAPTCHA option in our exchanges. Work is needed of course.
URL: http://en.wikipedia.org/wiki/Captcha
3. The last threat that you identified above looks like "phishing"
to me. We have this problem on the web. I suspect that there is
ongoing work on that. But anyway, I don't think this is a
compelling enough reason to STOP this project.
Also,
some users may augment their own level of security by using a pseudonym
instead of their real name, etc etc.
If phone number information leaks (not because of the proposed protocol),
some users may periodically change their phone number (i.e. recovation).
But again, in this case, they will need the proposed protocol to
redistribute their new phone number more easily.
These decisions belong to the user.
>
> In short, I don't think it is technology that is needed here.
I think technology is needed, and we *have* this technology and the
necessary expertise. All we need to do is to put the pieces together.
Regards,
pars mutaf
>
> Bert
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--
Pars Mutaf
Quick reminder: the problem that I'm bringing to your
attention is:
http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-00.txt
Here is a better formulated question. We have choices (the above
cited application largely merits one of them):
1. IETF designs a more general purpose multicast name resolution
protocol. Thanks :-)
Currently it is too much ZEROCONF-oriented. There are possibly
many other applications that will use multicast name
resolution. The above cited example is a very good one. The
above cited problem is poorly addressed by current multicast
name resolution protocols.
2. Otherwise, the above cited application (private information
queries) can simply bypass name resolution. It can use
name-based IPv6 addresses (or HUMID addresses). No solution
will be provided for IPv4. This solution would work as follows
(briefly):
The responder application run by Alice Collins' cellular host
configures a link-local IPv6 address and listens:
link-local subnet prefix | 64bithash(alicecollins)
where '|' denotes concatenation, and link-local subnet prefix
is well-known and constant. 64bithash(alicecollins) is the
IPv6 interface ID.
The initiator user enters the name Alice Collins and hence the
application can generate a query to the above address. The
phone number of Alice Collins can be learned from her phone
directly (if approved by her).
It is also possible to search a host in multiple subnets
(using global scope addresses). I can explain this point if
you wish. It can also work with localized mobility management
and even Mobile IPv6, provided that you have the same
home/regional prefix with Alice Collins. This means that we
are not limited to link-local scope. But this needs more
investigation.
Looking forward to your suggestions.
Thanks,
pars mutaf
On Tue, 2007-01-30 at 23:22 +0100, Pars MUTAF wrote:
> 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
--
Pars Mutaf
On Sun, 2007-02-11 at 19:31 -0800, Christian Huitema wrote:
> I have seen users, with broken cell phones, or who have lost their
> phone. They are simply in trouble. They have hard time recovering the
> cell phone numbers of their friends, colleagues, family members etc.
>
> Do you mean that the only copy of their address book was inside their
> cell phone? If that is the case, they will indeed have a hard time
> retrieving all these numbers. On the other hand, there are many ways
to
> synchronize a cell phone with a PC or a server that keeps a safe copy.
> You can even use vCards (RFC2426) do describe these entries in a
> standardized way.
That's right of course. Users should backup their correspondents' phone
numbers to their PCs. However, this doesn't mean that they will do it
unfortunately.
In addition, this assumes that everyone has a PC.
In addition, even if you have a PC and even if you have a backup,
I'm not sure if the PC will be immediately available when you buy a
new phone (because the old one is broken).
Finally, I have also seen users with broken PCs.
(This happened recently, a friend has lost all his backup.)
> > I have seen users (including myself) exchanging phone numbers in
> > ridiculous ways. The first number is read to the other user, and the
> > other user returns his/her number via the cellular network. It
should
> > be noted that this also requires short distance user contact. If the
> > other user is 100 meters away, you see each other but you are in a
> > crowded place and you can't reach each other, you simply cannot
> > communicate. You have cellular phones but are unable to communicate.
>
> That's ridiculous indeed, when you could simply attach vCard to an
> e-mail. Not to mention publishing it in a web page, or make it
available
> to your friends in an instant-messaging service.
Sending the phone number via e-mail is possible indeed, but this
is a too indirect (hence slow) solution and makes some important
assumptions.
1. This assumes that you have the destination user's e-mail
address. BTW, I also think that the proposed protocol is not
limited to phone numbers. We can also request an e-mail
address.
2. This solution is too indirect in that, you need service from
e-mail servers, which may be busy, temporarily unreachable,
the network may be congested etc.
3. You have to wait until the mail arrives at the target mail box
and the user checks mail. Today we have special services
that notify the user upon new incoming mail. However, I'm not
sure how fast this is. In addition, this is an optional
service.
Using an instant-messaging service has similar (almost same)
problems.
> The problems that you describe hardly seem related to server-less name
> resolution in a local network!
The proposed protocol could also use infrastracture DNS (i.e.
standard DNS). This would look as follows:
Let us assume that Alice Collins has a personal DNS name
"alicecollins.domain.com". Her phone has an IP address that is
registered to this DNS name.
The requestor user enters the name Alice Collins, the proposed
application generates the corresponding DNS name, makes a
standard DNS query, and obtains the IP address. At this point the
proposed application can send a private information query to
Alice's phone. If approved by Alice (in real-time), her phone
number can be learned.
This would work globally, but I don't think this is realistic.
(BTW, it can be noted that, one would ask why I need a phone
number in this case.)
Using multicast name resolution (or, name-based IPv6 addresses)
with human names that have local significance only, seem
realistic to me. Here the term "local" may take different
meanings. It may be a local cellular network that covers a large
number of cells, or a localized mobility management domain.
Such a local cellular zone can cover a large geographical area.
This is an important progress compared to using a technology
like Bluetooth (for exchanging private info). But the proposed
protocol cannot work globally. That's why we need phone numbers
and our goal is to allow people to share their phone numbers
more easily.
Regards,
pars mutaf
>
> -- Christian Huitema
Pars Mutaf
> On Wed, 2007-02-14 at 16:43 +0100, Olaf M. Kolkman wrote:
> > Hello Pars,
> >
> > A few thoughts...
> >
>
>
>
>
> >
> > On 12Feb 2007, at 2:35 PM, Pars Mutaf wrote:
> >
> > >> name
> > >> resolution in a local network!
> > >
> > >
> > >
> > > The proposed protocol could also use infrastracture DNS (i.e.
> > > standard DNS). This would look as follows:
> > >
> > > Let us assume that Alice Collins has a personal DNS name
> > > "alicecollins.domain.com". Her phone has an IP address that is
> > > registered to this DNS name.
> > >
> >
> have
> > to remember the domain name under which her
> telephone-number-recovery-
> > services is located.
>
>
>
> infrastructure DNS and I am promoting MNR (or name-based local
> IPv6 addresses) as a general but local solution.
sorry. quick precision:
I'm arguing that only a local solution is realistic because
users cannot possibly remember domain names (especially if there
are many of them). They can only remember "human names". In addition,
there is no evidence that such special domains will exist.
Hence the local solution (discussed below). Within a cellular
local network, we can cover a large area and share our phone
numbers easily over long distances. This is much better than
using Bluetooth (which requires short distance user contact).
But I'm not pretending a global solution.
Thanks,
pars
>
> > > The requestor user enters the name Alice Collins, the proposed
> > > application generates the corresponding DNS name,
> >
> > How does the proposed application do that unambiguously? Given that
> > the 'Alice Collins' you are looking for might be a completely
> > different "Alice Collins" than I know. The namespace collision will
> > be a problem that you will need to solve.
>
>
>
> Right. Please see below in the context of MNR.
>
>
>
> > > makes a
> > > standard DNS query, and obtains the IP address. At this point the
> > > proposed application can send a private information query to
> > > Alice's phone. If approved by Alice (in real-time), her phone
> > > number can be learned.
> > >
> > > This would work globally, but I don't think this is realistic.
> > > (BTW, it can be noted that, one would ask why I need a phone
> > > number in this case.)
> >
> > Indeed, that is the argument above.
> >
> > >
> > > Using multicast name resolution (or, name-based IPv6 addresses)
> > > with human names that have local significance only, seem
> > > realistic to me. Here the term "local" may take different
> > > meanings. It may be a local cellular network that covers a large
> > > number of cells, or a localized mobility management domain.
> > >
> > > Such a local cellular zone can cover a large geographical area.
> > > This is an important progress compared to using a technology
> > > like Bluetooth (for exchanging private info). But the proposed
> > > protocol cannot work globally. That's why we need phone numbers
> > > and our goal is to allow people to share their phone numbers
> > > more easily.
> >
> >
> > I think the main problem will be to find a balance between size of
> > your "locality" and the amount of collisions in your namespace. That
> > will be problematic, as an illustration: Travel to Volendam (a
> > village in the Netherlands), walk down the street, and shout "Hey
> > Piet Veerman" and count the amounts of angry faces.
>
> OK. I probably won't do that if I go to Volendam :-)
>
>
>
> The automated approach to human name collisions can use a
> collision counter. The user enters his/her human name at
> configuration time: "Piet Veerman". The application will try to
> configure pietveerman0, and if it collides, pietveerman1,
> pietveerman2, etc. The user doesn't have to know which Piet
> Veerman he is. Note that as users move, these numbers may
> change. A good implementation should always look for the smallest
> possible collision count (but without being too aggresive).
>
> Then if you need the phone number of a particular Piet Veerman
> in that village, what happens?
>
> The application tries pietveerman0, if no answer, the user
> pushes on the NEXT button, it tries the next one until you
> find the searched Piet Veerman. The number of trials is left
> to the user. If you receive more than one responses, you will
> choose the right Piet Veerman, or call all of them one-by-one
> (you will say "sorry wrong number", etc).
>
> Another potential problem with colliding names is that for
> each wrong Piet Veerman, the requesting user will
> unneccessarily solve a challenge e.g. a CAPTCHA or other
> Turing tests.
>
> That's life. We cannot do more than that for colliding
> names (may be I'm wrong). Perhaps parents can use this
> application to detect collisions and avoid a colliding
> name for their baby? ;-))
>
>
>
> > With the problem you are describing the number of angry faces if
> > relevant. If I were to activate the feature on the phone that would
> > provide me with the "Do you want to provide your phone number to
> > <foo>" and I were to receive more than 2 false positive requests for
> > my phone number, I would turn of the feature. So if I were the
> target
> > group solving the name collisions will be important.
>
>
>
> Yes. If there are many many Piet Veermans in the same area, this
> application may be less efficient for these persons. May be they
> should use pseudonyms.
>
> I prefer looking at the problem the following way: this would work
> very well i.e. without or with very few collisions for many many
> users.
>
> The problem to me is the need for an efficient multicast name
> resolution protocol (or, bypassing it ;-)
>
> Regards,
>
> pars
>
>
>
>
> > --Olaf
> >
> >
> > -----------------------------------------------------------
> > Olaf M. Kolkman
> > NLnet Labs
> > http://www.nlnetlabs.nl/
> >
> >
> >
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ip...@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
Manfredi, Albert E
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
> -----Original Message-----
> From: Pars Mutaf [mailto:pars....@int-evry.fr]=20
> I'm arguing that only a local solution is realistic because
> users cannot possibly remember domain names (especially if there
> are many of them). They can only remember "human names". In addition,=20
> there is no evidence that such special domains will exist.
>=20
> Hence the local solution (discussed below). Within a cellular
> local network, we can cover a large area and share our phone
> numbers easily over long distances. This is much better than=20
> using Bluetooth (which requires short distance user contact).=20
> But I'm not pretending a global solution.
Pars, I'm not sure why a local-only solution is very helpful. The guy
across the room at a conference may well have a cell number from a
different country. If that case isn't included in this solution, I'm not
sure how attractive it is.
In any case, what makes this any different from people's e-mail address
book? E-mail addresses are global, and I guess most people do not keep
them in their heads either. They use address books, which are hopefully
backed up somewhere. Same goes for web sites in the favorites or
bookmarks folder. Easier with DNS than using IP addresses, but still not
easy enough.
I think the name collision issue is what makes these proposals
difficult.
Bert