Subject: Re: Last Call: draft-atlas-icmp-unnumbered (Extending ICMP for Interface and Next-hop Identification) to Proposed Standard

From: Philip Matthews <[email-masked]>
Date: Thu, 2 Apr 2009 20:05:53 -0400

[Cross-posting to BEHAVE, since my comments directly concern ongoing  
work in that WG]

I feel that the ICMP extension defined in this draft would give very  
useful information when debugging network problems. However, I have a  
few concerns about one aspect of the encoding of the ICMP extension  
and how this interacts with NATs. I apologize for sending these  
comments so late in the draft cycle, but it is only recently that I  
have had cause to look closely at the interaction of this draft with  
NATs.

In section 5, when discussing the addresses contained in the ICMP  
Interface Information object defined in the draft, the draft says  
that: a NAT SHOULD translate private realm addresses and SHOULD NOT  
translate external (public) realm addresses, however a NAT MAY choose  
to pass the extension unaltered.

I have the following concerns with this:

1) To implement the "SHOULD" behavior, a NAT must be upgraded to  
understand the ICMP Interface Information object defined in the draft.  
In my opinion, we want NATs to have as little knowledge of packets  
passing through them as possible. I would prefer to require that any  
receiving host that understands the ICMP Interface Information object  
also understand about NATs and can handle receiving addresses in the  
private realm. I understand that some firewalls may prefer to  
translate or remove the object, but I feel this should not be the  
recommended behavior.

2) The BEHAVE WG is currently working on NATs to translate between  
IPv4 and IPv6 to replace NAT-PT (RFC 2766). As currently defined,  
there does not seem to be any way that such a NAT could implement the  
behavior defined in section 5 (specifically the part about not  
translating external realm addresses), since the encoding of the  
object assumes that all IP addresses in the packet will have the same  
family (v4 vs v6).

3) Related to point (2), I feel it is likely that we will have cases  
in the future where the ingress interface will be IPv4 and the the  
egress interface will be IPv6 (or vica-versa), and an ICMP message  
must be generated due to an error.  One way this might happen is when  
the packet is traversing a NAT64. However, as noted above, the  
encoding in the draft does not allow the ingress and egress interfaces  
to use different address families.

One way to address these concerns would be to modify the draft as  
follows:

a) Change the encoding of the ICMP Interface Information object to  
make the family of each address explicit and independent of the family  
of other addresses.

b) Change the recommendation in section 5 to say that: a NAT SHOULD  
NOT remove or translate the information in the ICMP Interface  
Information object.

c) Add a sentence or two to state that: any application that  
understands the ICMP Interface Information object be prepared to  
handle the case where the addresses come from different realms and are  
of different address families.

As a side note, if an interface has both an IPv4 and an IPv6 address,  
consider allowing both to be optionally included in the object.

Finally, as a general comment, I feel that any ICMP extension object  
(of which the IMCP Interface Information object is one example) should  
be defined so that there is no need to have it recognized and  
translated by a NAT. Draft-ietf-behave-icmp (now in the RFC editor  
queue) says that that "NATs are encouraged to support ICMP extension  
objects" and I now feel that this should be interpreted to mean only  
that NATs must be aware that the general extension mechanism exists.  
[As a regular contributor to BEHAVE, I will confess that the  
implications of all this were not clear to me when draft-ietf-behave- 
icmp passed through BEHAVE.]

- Philip