Subject: RE: Last call for draft-ietf-mpls-icmp-00.txt

From: Joel Halpern <[email-masked]>
Date: Tue, 16 Nov 1999 16:43:18 -0500

I would like to strongly suggest that we not move to a trailers approach
to extending the ICMP messages:
1) While theoretically equivalent, in practice parsing messages
backwards is distinctly error prone and non-robust.
2) There would be no reliable way to determine whether the trailer (with
length) was actually present.  These are after all extensions to
existing messages.  

Please don't.
Joel M. Halpern

-----Original Message-----
From: C. M. Heard/VVNET, Inc. [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 4:36 PM
To: Ron Bonica; [email-masked]
Subject: RE: Last call for draft-ietf-mpls-icmp-00.txt

Ron Bonica wrote:
>
> To date, I have not found any applications that rely upon the extra
user
> data provided by RFC 1812 style ICMP messages. This, however, doesn't
prove
> much of anything. I may have looked in the wrong places.

Neither have I, although I just posted a message to the tcp-impl list
asking if any such applications exist.

> Therefore, I suggest the following course of action:
>
> Wait a reasonable period of time (2 weeks?).
>
> If nobody finds any applications that rely upon the extra user data
provided
> by RFC 1812 style ICMP messages (beyond displaying it), issue a new
version
> of draft-ietf-mpls-icmp with some verbage that stating that
> draft-ietf-mpls-icmp supersedes of RFC 1812 wrt this issue.
>
> If somebody finds an application that relies upon the extra user data
in RFC
> 1812 style ICMP messages (beyond displaying it), issue a new version
of
> draft-ietf-mpls-icmp. The new draft will include some verbage stating
that
> when a router emits an ICMP message with extensions, it must include a
64
> byte user data field. The 64 byte user data field contains the first
64
> bytes of the original IP datagram and is likely to contain all IP and
> transport layer headers. Extensions will follow the user data.
>
> Is this agreeable to you?

Instead of forever fixing the amount of returned user data allow me to
suggest an alternative:  replace the common header and object headers
with a common trailer and object trailers.  The common trailer would
appear at the _end_ of the ICMP packet, and the first object trailer
would immediately precede it.  Under this proposal extended Destination
Unreachable, Parameter Problem, Source Quench, and Time Exceeded mesages
would look something like this:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Pointer/unused |             unused                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Header + 8 or more bytes of payload from original datagram |
       //              ^^^^^^^
//
  +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    //
//
  |    |           (Object Contents, e.g., MPLS label stack)           |
  |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +--- |             Length            |   Class-Num   |     C-type    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Vers |     (Reserved)        |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format would allow a router to return as much of the original user
data as it wishes, subject to the 576-byte limitation on the total
length
of the IP datagram containing the ICMP error message.  You might want to
require that the returned user data be chopped on an 8 byte boundary;
in
that case one would need to suppress the extention trailer or else pad
the
returned user data if the original datagram contained less than 8 bytes
of
user data.

As for how much user data a router SHOULD return (and whether to
suppress
the trailer or pad the user data in case of a short datagram), that
depends
on what turns up regarding applications which use the extra data.  A two
week wait is enough time for me.

One other point:  regardless of how these issues are resolved, if the
draft goes forward it not only must explicitly state that it suspersedes
RFC 1812 but also must include some words stating why it is not expected
to harm existing applications.  This need not be much -- if (as appears
likely) we are not able to find any applications that make use of
returned
user daya beyond the first 8 bytes then one a sentence say just that
would
be sufficient.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 16 Nov 1999 16:48:58 -0800 (PST)

> backwards is distinctly error prone and non-robust.

There are precedents for it, however;  PPP's "self-describing padding"
is one.
 
> length) was actually present.  These are after all extensions to

If that were a problem, if would apply equally to the draft and the
proposed trailer modification.  But it's not a problem, because there

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 Nov 1999 22:43:15 -0500

Folks,

Joel's first point is correct. Parsing messages backwards is somewhat
challenging. Mike's point is also valid. We don't want to "forever fix the
amount of returned user data". Therefore, we are compelled to find a
compromise position.

Permit me to propose the following:

	1) The user data field is fixed exactly as it is defined in RFC 792.
	2) The ICMP extension header remains exactly as it is defined in
draft-ietf-mpls-icmp-00.
	3) ICMP extension objects currently defined in draft-ietf-mpls-icmp-00 are
unchanged.
	4) We add a new ICMP extension object that contains additional user data
(i.e., bytes beyond those supported in RFC 792). This object, like all
objects defined to date, is optional.

Is this agreeable to all parties?

Mike,

You are correct in that we will have to add some text about
superseding/breaking RFC1812.

                                                   Ron

> From: [email-masked] [mailto:[email-masked]]On Behalf Of C. M.
> Heard/VVNET, Inc.
> Sent: Tuesday, November 16, 1999 7:49 PM
> To: [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Wed, 17 Nov 1999 07:47:51 -0500

Ron,

	I wonder if this proposal might not make it 
necessary to have an applicability statement for the
draft - to make it clear which optional extensions 
are required when.  With that one comment made, however,
I think this proposal is sound.  The fact that it breaks
RFC1812 should not impact on implementations that rely
on it if the ingress to an LSP is able to convert the
ICMP messages it receives to match the requirements of
the previous RFC using the included _optional_ user data
object...

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 19 Nov 1999 11:38:58 -0800 (PST)

> the previous RFC using the included _optional_ user data

If I correctly understand Eric's comments, they are suggesting that an
ICMP message with MPLS extensions will be converted into an ordinary
ICMP message without extentions when it leaves an MPLS domain.  While
that would certainly address the backward compatibility concerns, it
would also defeat the purpose of draft-ietf-mpls-icmp-00.txt, which
is to propagate the label stack information all the way back to the
host that originated the undeliverable IP datagram.

Rather than add another optional ICMP extension object -- which would
in any case not be understood by existing applications -- it might be
simpler just to expand the size of the returned user data field in an
extended ICMP error message from 8 bytes to some larger but still
fixed size which is sufficient to accomodate all transport headers of
potential interest.  If the user data field of the original datagram
is smaller than this fixed size, then the returned data field could be
padded with zeroes.  The total length field in the returned IP header
will allow the application analyzing the error message to determine
when the user data has been padded.

The question arises as to how much user data is enough.  RFC 1812
recommends than an ICMP error message should contain as much of the
original datagram as possible while not exceeding a total length of
576 bytes.  If one assumes that both the original datagram and the
ICMP error message have maximum-sized IP headers then the amount of
returned user data would be 448 bytes.  That is probably more than
is actually needed in practice.

There would, of course, still be a chance that the extension objects
appended to the returned user data might be misinterpreted in cases
where the original datagram contained more user data than was actually
returned.  But I think that the likelihood would be quite small if the
amount of returned user data were sufficiently large.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Eric Gray <[email-masked]>
Date: Sun, 21 Nov 1999 18:20:48 -0500

Mike,

You wrote (in part):
> potential interest.  ...

"Sufficient to accommodate all transport headers of potential 
 interest" is about as open ended as you'd care to imagine.

The issue - if I understand it correctly - is that, in cases
where an ICMP error is needed, if it does not get back to the
host which provoked the need, either that host will provoke
the need repeatedly, or some intermediate device will need to
either generate another ICMP error that does reach the host,
or filter the annoying provocation.  Since the latter choice
is probably not feasible, then it is necessary to notify the
sender of the offending packets that they are not getting
through.

The question, then, is whether it is possible that the offending
packets may have been IP encapsulated N times after leaving the
sending host and before reaching the MPLS domain in which the 
error condition is being detected - with N greater than zero.

If this is the case, then a secondary issue is whether or not 
the current specifications and _any_ implementations currently
support appropriate error reporting in this case.  If so, then
the proposal for ICMP support in MPLS would result in breaking
this 'appropriate error reporting' - and this is anathema.

Further, if people feel that the absence of specification support
and _any_ implementation that handles this situation properly is
an oversight that should be corrected, then it is incumbent on
all of us to correct this newly discovered oversight _before_ we
make such a correction impossible.

I feel that this may be the case, but I do not know if there is
any agreement on this.  If there is, then the proposal to include
an extension that may be optionally included within MPLS ICMP
messages to carry an arbitrary amount of additional data from the
original message will work - provided that the specification gives
at least a basic description of how such an optionally included
object is to be handled at each LSR and especially at the ingress
LSR (where - presumably - the MPLS ICMP message must be converted
to a _legacy_ ICMP message).

Note that - as with many other such 'optional' objects - the option
is in whether or not the ICMP message originator includes it, not
whether that LSR or any other is _able_ to include it.  Otherwise,
it simply will not work.

> ...

---

From: Ron Bonica <[email-masked]>
Date: Sun, 21 Nov 1999 22:50:56 -0500

Mike, Eric, and all,

I would like to issue an updated version of the draft. Please advise as to
whether the proposed updates are acceptable.

The following is a brief outine of changes:

1) The user data field is fixed exactly as it is defined in RFC 792 except
that if it is to be followed by ICMP/MPLS  extensions, it must be exactly 64
bytes long. If the packet that caused the ICMP message to be sent is shorter
than 64 bytes, the user data field is padded with 0's. (This is for "legacy"
applications that can't parse the extensions.)

2) The ICMP extension header remains exactly as it is defined in
draft-ietf-mpls-icmp-00, except that the version number is incremented.

4) We add a new ICMP extension object that contains additional user data
(i.e., bytes beyond the 64th). This object, like all objects defined to
date, is optional.

5) A statement as to which objects are required under what circumstances is
added.

                                     Ron

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 22 Nov 1999 18:28:44 -0800 (PST)

> applications that can't parse the extensions.)

If the objective is to return enough user data to accomodate one level
IPv4-in-IPv4 tunnelling then the fixed size area should be at least 68
bytes long.  That would accomodate a maximum-size IPv4 header plus the
first 8 bytes of the transport header.

Of course, that would not necessarily help "legacy" IPv6-in-IPv4 tunnel
implementations since the leading IPv6 header plus extension headers could
add up to quite a bit more than 60 bytes.  "Legacy", in this case, means
anything that is currently deployed.

> 5) A statement as to which objects are required under what circumstances is

In an earlier message Eric Gray mentioned a provision that that is not
included in this list:

% [ ... ] at least a basic description of how such an optionally included
% object is to be handled at each LSR and especially at the ingress
% LSR (where - presumably - the MPLS ICMP message must be converted
% to a _legacy_ ICMP message).

I fully understand the reason for this omission:  the MPLS ICMP extensions
will not serve their intended purpose if they cannot be conveyed all the
way back to the originating host.  However, in the absence of such a
provision, the proposal amounts to an incompatible change to the existing
ICMPv4 specification, and it should be presented that way.  That means
_at least_ changing the title of the draft so that it will attract wider
review than just the MPLS community.

From my perspective it does not seem wise to modify something so basic
as ICMPv4 error messages in order to accomodate the special requirements
of a specific mechanism used to transport IPv4 datagrams -- it has the
potential to affect too many unknown things.  I might also point out that
ICMPv6 poses the same problem for MPLS as does ICMPv4, and would require
similar modifications -- cf. RFC 2463, Section 2.4:

+ Implementations MUST observe the following rules when processing
+ ICMPv6 messages (from [RFC-1122]):
...
+  (c) Every ICMPv6 error message (type < 128) includes as much of the
+      IPv6 offending (invoking) packet (the packet that caused the
+      error) as will fit without making the error message packet
+      exceed the minimum IPv6 MTU [IPv6].
                  ^^^^^^^^^^^^^^^^
                     1280 bytes
+
+  (d) In those cases where the internet-layer protocol is required to
+      pass an ICMPv6 error message to the upper-layer process, the
+      upper-layer protocol type is extracted from the original packet
+      (contained in the body of the ICMPv6 error message) and used to
+      select the appropriate upper-layer process to handle the error.
+      If the original packet had an unusually large amount of
+      extension headers, it is possible that the upper-layer protocol
+      type may not be present in the ICMPv6 message, due to truncation
+      of the original packet to meet the minimum IPv6 MTU [IPv6]
+      limit.  In that case, the error message is silently dropped
+      after any IPv6-layer processing.

Having said that, I think it's time for me to bow out of the discussion.
If the consensus in the WG is that the proposal should go forward, with
or without the modifications Ron has suggested, I'll defer ... but I do
think that it should be made very clear to the community that the draft
proposes changes to ICMPv4 that are not entirely compatible with the
existing specification.

Thanks,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 22 Nov 1999 23:47:11 -0500

> first 8 bytes of the transport header.

Agreed. Given that a) it is better to send too much user data than too
little, and b) we prefer field lengths that are even powers of 2, the
right field length is probably 128 bytes.

If someone thinks that 128 bytes is too much or too little, please speak up
before I re-submit the draft.

> anything that is currently deployed.

The draft addresses extenstions to ICMPv4 only. The equivalent extensions to
ICMPv6 should be discussed in another draft. IPv6/ICMPv6 may offer cleaner
ways to deal with this problem.

I will change the title to reflect that these extensions address ICMPv4
only.

> the proposal amounts to an incompatible change to the existing

I agree to some extent. Legacy applications parsing beyond byte 128 of the
ICMP user data will be adversely effected. As Eric suggests, I will put some
text to that effect in the next version of the draft.

This should not stop us from going forward with the draft. We must weigh the
value
of these extensions against the harm done to those applications that parse
beyond
byte 128.

As for changing the title of this draft and seeking wider review, I look to
the
WG chairs and old hands of the IETF for guidance.

                                              Ron