Subject: Re: IPv6 WG Last Call: <draft-ietf-ipngwg-icmp-name-lookups-12.txt>

From: Brian Haberman <[email-masked]>
Date: Tue, 20 Sep 2005 13:12:49 -0400

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Sep 2005 08:06:25 +0300 (EEST)

On Tue, 20 Sep 2005, Brian Haberman wrote:
> I would like to solicit opinions from the working group on the suggestions

In all fairness, I think it should be emphasized that even though 
implementations not doing those would not be conformant, they'd still 
continue to work just fine with the regular "link-local" scenario.

As such, I personally don't see making implementations non-conformant 
a big issue considering they'd still continue to work fine in the 
typical scenarios.

-- 
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: Francis Dupont <[email-masked]>
Date: Wed, 21 Sep 2005 08:50:06 +0200

suggestions above.

=> I've always used the protocol for destinations on the link so
I have not operational issue with the restriction but for future
usage I believe it should be better to restrict only to the site
(the problem is this can be not so easy to do, my opinion is
a limit to the local link is better than no protocol).

Regards

[email-masked]

PS: BTW it is very useful and I'd like to make its support mandatory
for any node providing a service, including routers (its first usage
is to find what/where is the router sending this bogus RA/route).

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 21 Sep 2005 17:50:20 +0100

Brian Haberman wrote:

>> <<snip>>
>> single link -- but extending it (or providing extendibility) beyond that
>> seems unwise.
>>
>>  - 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
>> provide a sufficiently simple security model for ensuring NIQ's won't be
>> used inappropriately.
>>
>

Since the capabilities that use multicast addresses are restricted to 
link local scope addresses, it seems sensible to be consistent and make 
it so that the protocol can only be used for link local queries in all 
cases.  I support this change.

Regards,
Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 21 Sep 2005 18:00:13 +0100

Elwyn Davies wrote:

> Some comments:
>
> <<snip>>
> s6.4.1: [wish list] It occurs to me with the mention of tunnels that a 
> Qtype to find out about the addresses associated with (e.g.) 
> configured tunnels would be useful (v6 in v4 for example).
>
Brian asked me to propose some text for this.  Here is my suggestion - 
adds an 'E' flag to the two Node Address queries ('E' stands for 
Encapsulated).  These two additions would allow a querier to find out 
what 'inner' tunnel addresses were in use on a node - these are the 
tunnel interface addresses of the node which are in addition to the 
direct interfaces.

The updated text (scetins 6.3/6.4/6.4.1 is:
6.3.  Node Addresses

  The NI Node Addresses Query requests some set of the Responder's IPv6
  unicast addresses.  The Reply Data is a sequence of 128-bit IPv6
  addresses, each address preceded by a separate 32-bit TTL value, with
  Preferred addresses listed before Deprecated addresses [9], but
  otherwise in no special order.  Six flag bits are defined in the
  Query, and seven in the Reply.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Qtype=3            |       unused    |E|G|S|L|C|A|T|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 3: Node Information Address Query

  o  G - If set to 1, Global-scope addresses [10] are requested.

  o  S - If set to 1, Site-local addresses [10] are requested.
     However, Site-local addresses are now deprecated [14] and this
     flag is for backwards compatibility.

Crawford & Haberman     Expires February 20, 2006               [Page 9]

Internet-Draft              ICMP Name Lookups                August 2005

  o  L - If set to 1, Link-local addresses [10] are requested.

  o  C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are
     requested.  As the IPv4-compatible addresses are now deprecated,
     this flag is for backwards compatibility with older
     implementations,

  o  A - If set to 1, all the Responder's unicast addresses (of the
     specified scope(s)) are requested.  If 0, only those addresses are
     requested which belong to the interface (or any one interface)
     which has the Subject Address, or which are associated with the
     Subject Name.

  o  T Defined in a Reply only, indicates that the set of addresses is
     incomplete for space reasons.

  o  E - If set to 1, tunnel end-point addresses are requested. This
     requests the 'inner' addresses of tunnels (v6 in v6 and/or v6 in v4,
     depending on the type of the Subject field) terminating on the node.
     This is treated as a 'scope' for the purposes of the 'A' flag.  If
     the subject is a Name then all IPv6 tunnel addresses are returned;
     otherwise only addresses for tunnels with the same type of 'outer'
     address as the Subject.

  Flags G, S, L, C, A and E are copied from a Query to the corresponding
  Reply.

  The TTL associated with each address MUST be zero.

6.4.  IPv4 Addresses

  The NI IPv4 Addresses Query requests some set of the Responder's IPv4
  unicast addresses.  The Reply Data is a sequence of 32-bit IPv4
  addresses, each address preceded by a 32-bit TTL value.  Two flag bits
  are defined in the Query, and three in the Reply.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Qtype=4            |       unused            |E|A|T|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 4: Node Information IPv4 Address Query

  o  A - If set to 1, all the Responder's unicast addresses are
     requested.  If 0, only those addresses are requested which belong
     to the interface (or any one interface) which has the Subject
     Address.

  o  T Defined in a Reply only, indicates that the set of addresses is
     incomplete for space reasons.

  o  E - If set to 1, tunnel end-point addresses are requested. This
     requests the 'inner' addresses of tunnels (v4 in v4 and/or v4 in v6,
     depending on the type of the Subject) terminating on the node.  Only
     tunnel end-point addresses are returned if this flag is set. If
     the subject is a Name then all IPv4 tunnel addresses are returned;
     otherwise only addresses for tunnels with the same type of 'outer'
     address as the Subject.

  Flags  A and E are copied from a Query to the corresponding Reply.

  The TTL associated with each address MUST be zero.

6.4.1.  Discussion

  It is possible that a node may treat IPv4 interfaces and IPv6
  interfaces as distinct, even though they are associated with the same
  hardware.  When such a node is responding to an NI Query having a
  Subject Address of one type requesting the other type, and the Query
  has the A flag set to 0, it SHOULD consider IP interfaces, other than
  tunnels, associated with the same hardware as being the same
  interface.  If tunnel addresses are requested, the addresses returned
  SHOULD be the 'inner' addresses of any tunnels terminating on the same
  Hardware.

Regards,
Elwyn