Subject: Resolution to open comments on ICMP Name Lookups

From: Brian Haberman <[email-masked]>
Date: Wed, 16 Nov 2005 13:59:10 -0500

All,
      As promised during the IPv6 WG session in Vancouver, this is
my attempt to resolve the open issues with the ICMP Name Lookup
draft.  From my review of my e-mail and the mailing list archive, there
are three open issues on the table.  I will list each and propose a
resolution to each.

      I will accept comments on these changes until 5:00pm on 12/2/05.
After that, I will incorporate the changes and submit the draft.

Issue 1: Restrict operation of the protocol to link-local use.

Resolution:
      The consensus is to retain the more flexible multi-hop capability.
      An additional sentence or two will be added to the Security
      Considerations section recommending the filtering of these
       messages at administrative boundaries.

Issue 2: Change multicast range used for Queries.

Resolution:
      This change will be made.  There will not be a "compatibility"
      knob for operation with older implementations.  The addition
      of such a knob will make operational use too complex.  This
      should simplify the use, but will require a code change.

Issue 3: Discovery of tunnel endpoints.

Resolution:
      This change will be made and will be based on the text proposed
      http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html

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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 16 Nov 2005 21:55:23 +0100

>      http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html

I missed out on the discussion of the above, but I do hope that there is
 going to be a huge warning that this reveals the endpoints of the
tunnel, which then can usually be abused for injecting fake tunneled
data into tunneling protocols that don't have any authentication (read:
proto-41)

Example (ab)usage:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-disco.pdf

Though in this case it is 'sort of good', I can think of many cases
where one doesn't want to see the above happening. Filtering is always
essential of course.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Nov 2005 08:43:29 +0200 (EET)

>      messages at administrative boundaries.

I did not see such consensus.  I saw about 5 people agreeing to the 
(by-default) limitation, and one person (Alain Durand) opposed. 
Rather, to me, it seemed like rough consensus to make the change. 
Did I miss something?

-- 
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Nov 2005 16:35:49 +0900

>>>>> On Thu, 17 Nov 2005 08:43:29 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> Rather, to me, it seemed like rough consensus to make the change. 

Yes, you did.  I also agreed with Alain.

But I also agree that we did not see a clear consensus on this (either
retaining or dropping the multi-hop capability).  I guess most people,
even including those who expressed the preference, actually didn't
care much about this issue, and such observation led to the Brian's
conclusion.  I'm (of course) happy with the proposal, but if others
have strong an objection, we'll then need further detailed discussion.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: David Malone <dwmalone=[email-masked]>
Date: Thu, 17 Nov 2005 10:35:05 +0000

>       messages at administrative boundaries.

FWIW, I'd be in favour of this. I usually use node information
queries on ff02::1, but I have had occasion to use them on machines
further away in an effort to figure out what was going on.

>      should simplify the use, but will require a code change.

I'm not so keen on this idea, as I occasionally do things like:

% ping6 -w -I em0 -N unconfigured.soekris.box
PING6(72=40+8+24 bytes) fe80::20d:56ff:fe22:320c%em0 --> ff02::2:52c0:b234
46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box.
46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box.
46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box.
46 bytes from fe80::20d:56ff:fe22:320c%em0: unconfigured.soekris.box.
% ssh fe80::20d:56ff:fe22:320c%em0

I haven't scripted this yet, so during the transition I'll just
have to remember to use twice as many pings or the address ff02::1
instead. I guess that won't kill me ;-)

I note that Apple's Airport Express partially supports node information
queries. If you leave a "ping6 -w ff02::1" running while it boots,
you can see its initial hostname is something like "vxworksimage"
before being set to its configured value. However, my Airport doesn't
seem to join a name-specific multicast group, so this change probably
won't have any impact on Airports.

	David.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 18 Nov 2005 14:25:59 -0800

> Rather, to me, it seemed like rough consensus to make the change.  

I support Brian's proposal to retain the multi-hop capability.

Bob