> 
> 
> So, publish the current draft as Informational with a suitable note  
> saying that this is the currently deployed practise, stating that  there 
> are architectural problems in the way it is done, and that the  practise 
> should not be extended?  And at the same time, try to do the  right 
> thing for IPv6, and possible future IPv4 extensions?
> 
> --Pekka Nikander
> 

Pekka,

On one hand, I would be happy to do this because it solves the problem
for MPLS. Let's keep this in mind in case we don't reach a more
satisfying solution.

One the other hand, the solution is not altogether satisfying because it
leaves ICMP inextensible. Let's discuss the issue for a little while,
while it is fresh in our minds, to see if we can come up with a solution
to the more general problem of ICMPv4 extensibility.

The following ICMP messages are currently defined:

- Destination Unreachable
- Redirect
- Source Quench
- Time Exceeded
- Parameter Problem
- Echo Request/Reply
- Information Request/Reply
- Timestamp and Timestamp Reply
- Address Mask Request/Reply
- Router Advertisement and Solicitations

At the time of their definition, the Redirect and Echo Request/Reply
messages were unique in that they could not be extended. They were
inextensible because a) the final field in the message was of variable
length and b) that field did not have an associated length attribute.
So, you had a problem parsing the message if you added another field at
the end of it.

RFC 1812 added Destination Unreachable, Source Quench, Time Exceeded and
  Parameter Problem to this category by converting their final fields,
which had been of fixed length, to variable length. The final field in
these messages represented as much as possible of the original datagram
to which the ICMP message was a response. The IP header plus first 8
octets of the original datagram were required. As many subsequent bytes
as possible were desirable.

Now we are faced with the following problem: "How do we make
non-extensible messages extensible without breaking any legacy
applications, including existing implementations of MPLS-aware TRACEROUTE."

The following is a proposal:

The following ICMPv4 message types are extensible because they do not
end in a variable length field:

- Information Request/Reply
- Timestamp and Timestamp Reply
- Address Mask Request/Reply
- Router Advertisement and Solicitations

The ICMPv4 messages can be made extensible:

- Destination Unreachable
- Source Quench
- Time Exceeded
- Parameter Problem

In order to make them extensible, allocate 8 bits of the UNUSED field to
indicate the length of the final field. If these 8 bits are clear, we
can assume that we are looking at an older version of ICMP. So, the
application is on its own to determine whether the ICMP message contains
any extensions.

In order to achieve backward compatibility with existing MPLS-aware
TRACEROUTE applications, if extensions are specified, the variable
length field (containing the original datagram) must be 128 octets or
more. The original datagram may be zero padded to 128 bytes if the
device originating the message cannot send 128 bytes of the original
datagram.

This way existing mpls-aware TRACEROUTE applications should continue to
work, unless the router generating the ICMP message sends _more_ than
128 bytes of the original datagram.

Unfortunately, the following ICMP messages do not have any UNUSED bits,
so they cannot be made extensible:

- Redirect
- Echo Request/Reply

                               Ron












_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area