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

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

On Thu, 28 Oct 1999, Vijay Srinivasan wrote:

> We have received a request to evaluate whether
> draft-ietf-mpls-icmp-00.txt (ICMP Extensions for MPLS) is ready for
> publication as an RFC.
>
> This note serves to commence the WG last call for this document.  The
> last call will end on Friday, Nov 5, 1999.

Greetings,

The ICMP extensions described in this draft are in conflict with certain
of the provisions of Section 4.3.2.3 of RFC 1812 (F. Baker, Editor,
Requirements for IP Version 4 Routers, June 1995) and Section 3.2.2 of
RFC 1122 (R. Braden, Editor, Requirements for Internet Hosts --
Communication Layers, October 1989).  This raises the possibility that
ICMP error messages using the extensions described in this draft will be
misinterpreted by currently deployed IPv4 routers and hosts.  I would
suggest that this draft is not ready for publication until the potential
backward compatibility problems have been addressed.

To provide some additional detail, the draft proposes to append a data
structure containing label stack information to ICMP error messages.
When present the data structure will always reside immediately after the
IP header and first 8 data bytes from the datagram that triggered the
ICMP error message.

The problem with this is that RFC 1812 Section 4.3.2.3 states that an
ICMP error message SHOULD contain as much of the original datagram as
possible without causing the length of the ICMP error message to exceed
576 bytes, and it states that the returned user data MUST be identical
to that which was received.  Similarly, RFC 1122 Section 3.2.2 states
that more than 8 octets of user data MAY be returned and that the user
data MUST be unchanged from the original datagram.

It seems to me that ICMP implementations written to those specifications
are entitled to assume that whatever data that follows the returned
IP header in an ICMP error message is user data copied unchanged from
the original datagram.  The extensions proposed in the draft would
violate this assumption.

The draft does provide a checksum to allow implementations of the ICMP
extensions to tell the difference between an ICMP error message with
label stack information and an RFC 1812-style ICMP error message with
more than 8 bytes of user data.  However, the draft does not provide any
means to prevent existing implementations -- which will be unaware of this
checksum -- from being confused by having a label stack data structure
where returned user data is expected.  At a minimum, the draft should
provide a convincing rationale that the extensions will not, in fact,
cause problems.

Cordially,

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

---

From: Ron Bonica <[email-masked]>
Date: Fri, 05 Nov 1999 23:33:55 -0500

Mike,

Thank you for these comments.

First, permit me to concede that limited
deployment of RFC 1812 style ICMP messages does
not give us the right to marginalize your comments.
If there is even a single implementation in use,
your objections must be addressed seriously.

Now to address the issue at hand.....

There is some precedent for granting exceptions
to the provisions of RFC 1812, Section 4.3.2.3, when
it makes sense to do so. See Section 4.3.3.5 of that
document for an exception.

But does it make sense to do so in the case at hand?

Section RFC 1812 states that the motivation for including
more than 8 payload bytes in an ICMP message is to preserve
relevant routing information. Specifically, RFC 1812 style
ICMP messages preserve the inner-most IP header that might
otherwise be lost when IP-in-IP tunneling is employed.

Loss of the inner-most IP header would only be an issue
when a network deploys IP-over-IP-over-MPLS.

Although it is conceivable that an network might
deploy IP-over-IP-over-MPLS, it is hard to understand why
we would want to preserve the inner-most IP header at the
cost of losing the MPLS header. After all, the LSR was routing
based on the MPLS header when it decided that the packet
was not deliverable and an ICMP message should be generated.

Does this sufficiently address your objection? If so,
do you feel that this argument should be included in the
draft before submission to IESG?

                         Ron

> -----Original Message-----
> From: C. M. Heard/VVNET, Inc. [mailto:[email-masked]]
> Sent: Friday, November 05, 1999 4:11 PM
> To: [email-masked]
> Subject: Re: Last call for draft-ietf-mpls-icmp-00.txt
>
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 06 Nov 1999 17:39:43 -0500

> So, what exactly is the reason for NOT complying with the
> requirements in the routing requirements RFC?  Is it just
> that we can't figure out how to comply with it and still
> include the MPLS shim header?  Or is it that this was not
> considered when the draft was written?
>

Eric,

Section 4.3.2.3 of RFC 1812 was considered during the development of
draft-ietf-mpls-icmp-00.txt. In fact, that section is referenced
specifically in the draft.

The problem is that there is no good way to extend the ICMP Time Exceeded
Message as it is defined in RFC 1812.

RFC 792 defined the ICMP Time Exceeded Message as a group of fixed length
fields. The final field contained a fixed length portion of the packet that
caused the ICMP message to be sent (IP header + first 64 bits of payload).

RFC 1812 made the final field a variable length field without adding a
length attribute.
This marked the end of extensibility for the ICMP Time Exceeded Message. You
can't add any more fields beyond that one because every bit beyond the
beginning
of that field is interpreted to be part of that field!

Now we have a need to extend the ICMP Time Exceeded Message. Furthermore, we
can
assume that future internauts will need to extend ICMP for reasons that time
will
reveal.

So, we must evaluate the pain involved in granting an exception to Section
4.3.2.3 of
RFC 1812. If we do not grant the exception, we lose information about the
MPLS header
that the LSR was using when it declared the packet undeliverable and decided
that an
ICMP packet was required.

If we grant the exception, existing implementations that rely upon ICMP
information
about the inner IP header of an IP-in-IP tunnel that is encapsulated in MPLS
will be broken.

Which causes more pain? Which lends itself to more future extensibility?

                                      Ron

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Sat, 6 Nov 1999 21:23:55 -0800

>>>>> Ron Bonica wrote:

Ron> There is some precedent for granting exceptions
Ron> to the provisions of RFC 1812, Section 4.3.2.3, when
Ron> it makes sense to do so. See Section 4.3.3.5 of that
Ron> document for an exception.

Section 4.3.2.3 does grants some leniency with regards to the _IP
header_ of the original datagram which is returned in an ICMP error
message:  a router ordinarily is not required to undo any changes
to the header that are part of the normal forwarding process.
There is an exception to this if the error is a Parameter Problem,
which is the situation discussed in Section 4.3.3.5.  In that case
the header field indicated by the ICMP pointer field must be returned
unaltered from the original datagram.  So, this exception actually
_removes_ a degree of freedom that a router might otherwise have.

>>>>> Eric Gray replied:

Eric> Section 4.3.3.5 refers back to section 4.3.2 for an
Eric> exception to the requirements defined in 4.3.3.5 - I
Eric> do not see an exception in 4.3.3.5 to anything in
Eric> 4.3.2.3.  Perhaps I'm not looking at it correctly.

I think the exception mentioned in the last sentence of 4.3.3.5
means an exception to the general requirement that a Parameter
Problem message be sent for any error not specifically covered by
another ICMP message.  That requirement is overridden in certain
cases by Section 4.3.2.7, "When Not to Send ICMP Errors".

In any case, there is nothing in RFC 1812 that would permit the
returned _user data_ in an ICMP error message to be different from
that in the original packet, apart from being truncated.

Eric> So, what exactly is the reason for NOT complying with the
Eric> requirements in the routing requirements RFC?  Is it just
Eric> that we can't figure out how to comply with it and still
Eric> include the MPLS shim header?  Or is it that this was not
Eric> considered when the draft was written?

Ron> Section 4.3.2.3 of RFC 1812 was considered during the development
Ron> of draft-ietf-mpls-icmp-00.txt. In fact, that section is
Ron> referenced specifically in the draft.
Ron>
Ron> The problem is that there is no good way to extend the ICMP Time
Ron> Exceeded Message as it is defined in RFC 1812.
Ron>
Ron> RFC 792 defined the ICMP Time Exceeded Message as a group of fixed
Ron> length fields. The final field contained a fixed length portion of
Ron> the packet that caused the ICMP message to be sent (IP header +
Ron> first 64 bits of payload).
Ron>
Ron> RFC 1812 made the final field a variable length field without
Ron> adding a length attribute.  This marked the end of extensibility
Ron> for the ICMP Time Exceeded Message. You can't add any more fields
Ron> beyond that one because every bit beyond the beginning of that
Ron> field is interpreted to be part of that field!

As a point of historical accuracy, allow me to point out that allowing
the amount of returned user data in ICMP error messages to be
variable predates RFC 1812.  It goes back at least to RFC 1122 (October
1989) -- see section 3.2.2 of that document.  (This applies, by the
way, to all ICMP error messages, not just Time Exceeded.)

Ron> Now we have a need to extend the ICMP Time Exceeded Message.
Ron> Furthermore, we can assume that future internauts will need to
Ron> extend ICMP for reasons that time will reveal.
Ron>
Ron> So, we must evaluate the pain involved in granting an exception
Ron> to Section 4.3.2.3 of RFC 1812. If we do not grant the exception,
Ron> we lose information about the MPLS header that the LSR was using
Ron> when it declared the packet undeliverable and decided that an ICMP
Ron> packet was required.
Ron>
Ron> If we grant the exception, existing implementations that rely upon
Ron> ICMP information about the inner IP header of an IP-in-IP tunnel
Ron> that is encapsulated in MPLS will be broken.

It is not, in fact, necessary to give up the inner-most IP header
(or other interesting stuff beyond the first 8 bytes of user data)
in order to have the MPLS header.  It is possible to have the MPLS
data structure at the end of the ICMP packet, with a variable amount
of data in front of it, if a field specifying the amount of user data
that precedes the MPLS data structure appears at some fixed offset
relative to the end of the packet.

However, even with that modification, a significant objection would
remain -- namely, that putting a data structure containing the MPLS
shim header where returned user data is expected has the potential
to break existing implementations.  The burden of proof that there
would not, in fact, be significant harm -- or that the harm done
would be outweighed by the benefit -- is on those who propose the
modification.  I do not think that the draft meets that burden, and
I do not think that it should be submitted to the IESG until it does.

Cordially,

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

---

From: Eric Gray <[email-masked]>
Date: Sat, 06 Nov 1999 09:30:14 -0500

Ron,

> not give us the right to marginalize your comments.

If this is true, why do you make it?

> document for an exception.

Section 4.3.3.5 refers back to section 4.3.2 for an
exception to the requirements defined in 4.3.3.5 - I
do not see an exception in 4.3.3.5 to anything in 
4.3.2.3.  Perhaps I'm not looking at it correctly.

Also, I'm not sure that you've established that 'it 
makes sense to do so' - please see below.

> was not deliverable and an ICMP message should be generated.

Let's see, all this over and under stuff is confusing.  I
think that IP-over-IP-over-MPLS means you have some layer
1 framing start, followed by some layer two encapsulation,
followed by an MPLS shim header, followed by two levels of
IP encapsulation.

Is that correct?

If so, then you're looking at the question of deployment
incorrectly.  If one deploys MPLS, then one may expect 
to receive IP encapsulated packets and one could expect
that some of these packets may include nested IP layers.
One does not necessarily 'deploy IP-over-IP-over-MPLS' so
much as one deploys MPLS and find it being used this way.

Therefore, let's dispense with any attempts to make the
likelihood of this happening look small - shall we? :-)

> > [...]

---

From: Ron Bonica <[email-masked]>
Date: Sun, 07 Nov 1999 23:05:03 -0500

> to break existing implementations.

Mike,

We are getting closer to a ICMP format that meets everybody's
needs, but we are not quite there, yet.

Would everybody's needs be met if routers sending the ICMP extensions
were obliged to send enough user data to contain the second IP
header plus 8 additional bytes, or the entire packet, whichever is shorter.

Hopefully, no existing applications look deeper than this into RFC 1812
style
ICMP messages.

                                          Ron

---

From: Ron Bonica <[email-masked]>
Date: Sun, 14 Nov 1999 21:31:03 -0500

Mike,

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.

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?

                                                 Ron