Subject: ICMP name lookup implementation survey

From: Alain Durand <[email-masked]>
Date: Tue, 15 Jul 2003 01:21:44 -0700

I would be curious to get feedback from implementors of 
draft-ietf-ipngwg-icmp-name-lookups-10.txt
on what they have implemented and what they find useful.

For example, we only implement the unicast mode and not the multicast 
mode when the
subject of a query is an address and we do not implement queries where 
the subject is
a name, as it is completely redundant with LLMNR.

Also, we do not implement the flag to request the now deprecated  Site 
Local addresses,
but we implement the queries for IPv4 addresses.

Last but not least, we implement it also over ICMPv4 (not defined in 
the spec yet).

What do other implementors do?

	- Alain.

--------------------------------------------------------------------
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]
Date: Tue, 15 Jul 2003 17:59:51 +0900

>mode when the subject of a query is an address and we do not
>implement queries where the subject is a name, as it is completely
>redundant with LLMNR.
>

	KAME have implemented this draft well before it became wg group item,
	and always keep trying to catch up with the spec.  therefore, some
	portion is based on the old spec, and we have whole bunch of backward
	compatibility support (like support for old packet format when Qtype
	was not defined at all).

	what we have implemented:
		noop (Qtype=0)
		supported query types (Qtype=1)
		node name (Qtype=2)
		node addr (Qtype=3), except IPv4 mapped address
	what we have extended:
		node addr (Qtype=2), flag bit for anycast address
			(not sure if it is good idea, as anycast address can be
			categorized as global/site-local/link-local address)
		backward compatibility support for Qtype=2 response without
		DNS name encoding
	what we did not implement, and no plan on implmenting:
		IPv4 address query (Qtype=4)
		IPv4 mappped address in response (Qtype=3, C bit)
	user modifyable toggles:
		flag bit to decide whether or not to respond to NIQ at all
		flag bit to decide whether or not to respond to NIQ to
			RFC3041 address
		flag bit to decide whether or not to respond to node addresses
			NIQ (Qtype=2) - we may not want to reveal address on
			other interfaces when A bit is present, like intranet
			side of firewall machine

	what we see as "frills" (should be removed in -11):
		any IPv4 stuff
		site-local (Qtype=3, S bit)
		noop (Qtype=0), maybe - "anycast address" text in 6.1 looks
			a bit useful

	we think multicast portion is the most important of all usage, i.e.
	to learn link-local address of peer on a p2p link.  this is the most
	important usage in our debugging situations.
	(i.e. discover neighbor when routing protocol goes mad)

		A -p2p-- B
		  -----> NIQ, Qtype=1 to ff02::1
		  <----- NI reply with source address (fe80::B) and name

	another usage is to know the name of the machine which is sending rogue
	RA (this happens too many times in conference environment).

		admin		rogue router
		  |		  |
		==+===============+==
		  -----> NIQ, Qtype=1 to ff02::2 (or fe80::rogue)
		  <----- NI reply with source address and name

>Last but not least, we implement it also over ICMPv4 (not defined in 

	KAME does not do it.

itojun
PS: KAME folks, any clarifications/corrections are requested.

---

From: [email-masked]
Date: Tue, 15 Jul 2003 18:31:28 +0900

>>on what they have implemented and what they find useful.

	as i said during meeting, i share pekka's opinion that
	combination of Qtype and ICMP code is unneededly complex,
	however i would say it is too late to change unfortunately.

>		flag bit to decide whether or not to respond to NIQ to

	this bit also affects whether or not to include RFC3041 address
	into Qtype=3 response.

>			other interfaces when A bit is present, like intranet

	typo: Qtype=3.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Jul 2003 12:42:53 +0300 (EEST)

> 	however i would say it is too late to change unfortunately.

.. which is why I argued that we should not propagate our mistakes, and go 
for Experimental not PS and add a stronger applicability statement.

I really think some functionality like a simple version of NIQ is useful:  
but if we intend it for general consumption rather than as (still!) a
rather limited implementation of Internet-Draft, we must do it 
*properly*.

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Jul 2003 03:22:31 -0700

> 	RA (this happens too many times in conference environment).

There are actually 2 different usage of multicast. What you are 
describing is
multicast when the subject is an IP address. The other case is multicast
when the subject is a name and you're looking for an IP address.
This second case is the one I do not think is that useful.

	- Alain.

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Wed, 16 Jul 2003 20:34:20 +0900 (JST)

> on what they have implemented and what they find useful.

We, USAGI, have two implementations. One is in-kernel,
and other is user-space daemon.
We have tried supporting all qtypes and all flags.
(However, anycast and configurable policy is not supported.)

> Last but not least, we implement it also over ICMPv4 (not defined in 

type/codes?
Extension to RFC1788 "ICMP Domain Name Messages?"
It would be another issue.

-- 
Hideaki YOSHIFUJI @ USAGI Project <[email-masked]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Wed, 16 Jul 2003 05:06:28 -0700

On Wednesday, July 16, 2003, at 04:34 AM, YOSHIFUJI Hideaki / 吉藤英明 
wrote:

> In article <[email-masked]> (at Tue, 15 
> Jul 2003 01:21:44 -0700), Alain Durand <[email-masked]> says:
>

Do you implement queries with a name as subject using the multicast 
hash?
If yes, did you find this useful?

>> Last but not least, we implement it also over ICMPv4 (not defined in

experimentally same as v6. This would have to be defined and reserved 
from IANA.

	- Alain.

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Wed, 16 Jul 2003 21:55:30 +0900 (JST)

> If yes, did you find this useful?

If you mean NI Group address, yes, we support it.
Well, we can live without it, however, it is reasonable to have NI Group 
address as we do for NS (solicited node address).
Of course, if some do not support this, it becomes unuseful. :-p

> experimentally same as v6. This would have to be defined and reserved 

Hmm, okay...

---

From: [email-masked]
Date: Wed, 16 Jul 2003 23:00:32 +0900

>If yes, did you find this useful?

	KAME implements stuff with multicast address with hash(hostname) at the
	tail, but i don't think many people are using it (= we don't find it
	useful).

itojun

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 17 Jul 2003 03:05:19 +0900

>>>>> On Tue, 15 Jul 2003 17:59:51 +0900, 
>>>>> [email-masked] said:

> PS: KAME folks, any clarifications/corrections are requested.

The description basically looks correct.  A minor point:

I'm not sure if we provide the client side of "noop (Qtype=0)" and
"supported query types (Qtype=1)."  Probably we don't.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[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]
--------------------------------------------------------------------