Subject: (IPng 7320) name->addr discovery

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 16 Mar 1999 13:26:01 +0900

Matt,
	In your talk in IETF44 titled 'steal this slide', you mentioned
	name->addr discovery without namesevers.  There are several attempts
	presented in nits BOF, and one of them was
	draft-manning-multicast-dns-01.txt.  I dunno if it is the right way
	to take but it is one possibility.
	(BTW it is sad that ther's no IPv6 multicast address in the draft!)

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Sam Manthorpe)
Date: Mon, 15 Mar 1999 20:51:54 -0800 (PST)

Jun-ichiro itojun Hagino wrote:
> 	name->addr discovery without namesevers.  

Unfortunately I was not able to attend the Mineapolis IETF so I didn't
follow any of this.  We have a prototype protocol, called the 
Plug and Play Name Resolution Protocol which provides name resolution 
for automatically configured IPv6 addresses and requires no centralised 
nameserver.  It is designed to work together with other name resolution
techniques such as DNS and NIS.  We have a working implementation for IRIX.

I am currently writing a document describing this protocol and will
send it to the list soon.

-- Sam

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 Mar 1999 02:32:00 -0800 (PST)

> 	(BTW it is sad that ther's no IPv6 multicast address in the draft!)

To clarify,
	There are two main techniques for doing addr<->name translation.
	The traditional nameserver techniques (we know they work and 
	pretty well) to things like ICMP hacks, which can work, in small
	scale environments.  multicast-dns-03.txt has alot of potential
	for expanding its reach, but it is specifically targeted to solving
	one problem. 

-- 
--bill

---

From: Steve Deering <[email-masked]>
Date: Tue, 16 Mar 1999 06:28:35 -0800

> 	for expanding its reach, but it is specifically targeted to solving

Bill,

Are you saying that that one problem is not relevant in IPv6?

Steve

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 Mar 1999 08:44:13 -0800 (PST)

> Are you saying that that one problem is not relevant in IPv6?

There is the stated objective to find a viable alternative to the Appletalk
Chooser.   Is that relevent to IPv6?  

--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 17 Mar 1999 09:33:09 -0600

Here are what I consider the most important differences between
name-based neighbor discovery and multicast dns.

N-ND:
	Allows discovery of addresses only, or possibly a small set
	of other data.

	Queries would be received by a very small set of nodes
	determined by the hash function, including the one of
	interest if it exists.

M-DNS:
	Allows lookup of any DNSR type.

	All participating nodes must process each query.

In addition, I have a gripe with the multicast DNS document.  It
claims that it "consists of a single change to the method of use"
of DNS, specifically, sending DNS queries to a multicast address.

But in actuality, it demands a new meaning of wildcards in queries,
where 1034 says, "A * label appearing in a query name has no special
effect, but can be used to test for wildcards in an authoritative
zone ... The result of such a query should not be cached."

Also, I don't see a clear way for a site that becomes large enough to
want to introduce a real DNS server to gather up all the data in the
devices' "stub" servers, whereas Service Location, the other naturaul
choice for this function, handles the transition from DA-less to
with-DA deployment.
______________________________________________________________________________
Matt Crawford                    [email-masked]                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the pieces."