[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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf