On Aug 1, 2005, at 2:08, Pekka Savola wrote:
On Fri, 15 Jul 2005, Bob Hinden wrote:
This starts a two week IPv6 working group last call on advancing:
Title : IPv6 Node Information Queries
Author(s) : M. Crawford, B. Haberman
Filename : draft-ietf-ipngwg-icmp-name-lookups-12.txt
Pages : 14
Date : 2005-7-14
to Experimental. Please send substantive comments to the IPv6
mailing list. Editorial comments can be sent to the authors.
Sorry for missing the DL by a couple of days, but here are my comments
anyway.
I've been very critical of the node information queries in the past,
and
still am, but as it's going to Experimental, I'm not as concerned.
However,
I think there are still a couple of very important things which need
to be
settled so that a) it can be used safely and b) it won't jeopardize
the real
use of IPv6 ICMP messages.
Specifically, I'm very concerned about its use with global addresses,
over
the Internet. This has a potential to turn into a kitchen sink
protocol,
which can be used to do query anything at all from a random node.
This is
exactly the thing that makes want to firewall administrators filter out
all ICMPv6 messages just to be sure messages like this won't be used
in the systems. I don't think we want that.
I have no objection to having a protocol like this used between
consenting
adults between link-local addresses or even global addresses if done
over a
single link -- but extending it (or providing extendibility) beyond
that
seems unwise.
My suggestion how to deal with this is to:
- add that a node MUST send all non-link-local node information
queries
with Hop Count 255; HC=255 MAY [or SHOULD] be used with other
traffic
as well; and
- a node MUST, unless explicitly configured otherwise, discard any
node
information queries w/ non-link-local queries which don't have
HC=255.
This only breaks backward compat for node information queries sent w/
global
addresses, over one hop away. I think we could live with that. It
should
provide a sufficiently simple security model for ensuring NIQ's won't
be
used inappropriately.
I would like to solicit opinions from the working group on the
suggestions
above. Specifically, the proposal would render existing implementations
non-conformant to the spec. The primary goal of this work has been to
document what the existing code bases support, so I will not make this
change unless I see a true consensus to do so.
Please provide comments by Sept. 28, 2005.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
