Subject: [BEHAVE] Should NATs pass ICMP Extensions transparently?

From: Philip Matthews <[email-masked]>
Date: Tue, 14 Apr 2009 13:02:14 -0400

In between working on TURN, I have been looking at the details of  
NAT64 support for ICMP. One of the questions that has come up is:

	What should a NAT64 (or NAT44 or NAT66...) do with ICMP extensions?

The Background
==============
The syntax for ICMP extensions is defined in RFC 4884. An ICMP  
extension (or more properly, an ICMP Extension Object) is extra  
information that that can be added to certain ICMPv4 or -v6 messages:  
the Destination Unreachable, Time Exceeded, Parameter Problem, or  
Packet Too Big messages. With extension(s), one of these messages  
looks as follows:

                   +-----------------------+
                   |                       |
                   |      IP header        |
                   |                       |
                   +-----------------------+
                   |     ICMP header       |
                   |  (e.g Dest Unreach)   |
                   +-----------------------+
                   |                       |
                   |   First N bytes of    |
                   |   the IP datagram     |
                   |   that caused the     |
                   |   problem             |
                   |                       |
                   +-----------------------+
                   | ICMP Extension header |
                   +-----------------------+
                   |  Extension Object 1   |
                   +-----------------------+
                   |          ...          |
                   +-----------------------+
                   |  Extension Object M   |
                   +-----------------------+

RFC 4884 just defines the basic syntax;  individual Extension Objects  
are to be defined in separate documents.

Each Extension Object has a TLV-like structure with a type (called  
"Class-Num") and a sub-type (called "C-Type").

At present, only one Extension Object has been officially defined: the  
MPLS Label Stack Object. This Object contains the MPLS label stack  
that was on the IP message that cause the problem. One of the big uses  
of this object today is to provide a version of Traceroute that  
understands MPLS.

The Question
============
How should NATs treat ICMP Extension Objects?

BEHAVE-ICMP (just published a few days ago as RFC 5508) says "NATs are  
encouraged to support ICMP extension objects" (section 4.2.1)).  
However, it does not specify exactly what "support" means, except to  
say that the basic extension structure must be recognized and  
translated properly.

I see at least two options:

1) NATs are aware of some individual Objects and translate them as  
necessary. Objects unknown to the NAT are stripped out.

2) NATs treat Objects as opaque and pass them through transparently.  
Objects MUST be defined to be independent of Address Realm.

The Proposal
============
I propose we adopt option (2):  NATs pass individual objects through  
transparently.

I feel that we want NATs to be as transparent as possible. Option (2)  
means that new Objects can be defined and deployed without requiring  
existing NATs to be upgraded.

The MPLS Label Stack Object does not contain addresses, so it can be  
passed transparently.

The Complication
================
There is an individual draft (draft-atlas-icmp-unnumbered) which  
proposes an Interface Information object that, as currently defined,  
cannot pass through a NAT64 transparently. [The problem is that the  
syntax of this object, as currently defined, assumes that the  
addresses inside the Object are of the same family as the outer IP  
header].

This draft is currently in IESG evaluation.

If this draft is published without fixing this issue, then I propose  
that we make an exception for this Object only:    For this Object, a  
NAT MUST either drop or translate the Object.

The Summary
===========
I think NATs SHOULD pass ICMP Extension Objects transparently, with  
the possible exception of the (almost finalized) Interface Information  
Object.

Comments?

- Philip

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 15:27:09 +0200

> The Complication
i would raise this issue to the draft-atlas authors and see why is this 
the case
i mean, bascially what this means is that this object is explicitly  non 
translatable, right?
If this is so, and it is so on purpose, the goal i guess is that we drop 
the object i guess

> NAT MUST either drop or translate the Object.
i would preffer to not have exceptions... what happens if we pass this 
object as the rest of them?

regards, marcelo

> Comments?
>
> - Philip
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>