Re: [Int-area] ICMP-MPLS
Ron Bonica <rbonica@juniper.net> Thu, 11 August 2005 19:47 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J15-0004mg-BS; Thu, 11 Aug 2005 15:47:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3J14-0004mL-DG for int-area@megatron.ietf.org; Thu, 11 Aug 2005 15:47:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24000 for <int-area@ietf.org>; Thu, 11 Aug 2005 15:47:00 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3JZR-0006zJ-8J for int-area@ietf.org; Thu, 11 Aug 2005 16:22:33 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:46:51 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:46:51 +0100
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 15:46:50 -0400
Received: from [172.25.42.155] ([172.25.42.155]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 15:46:49 -0400
Message-ID: <42FBAB29.1020309@juniper.net>
Date: Thu, 11 Aug 2005 15:46:49 -0400
From: Ron Bonica <rbonica@juniper.net>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [Int-area] ICMP-MPLS
References: <42F228E5.4070301@juniper.net> <Pine.LNX.4.61.0508100822200.28763@netcore.fi> <92CCCF8D-CE80-48A4-BCC5-DE17BBFE963C@nomadiclab.com> <42FA6756.5020900@juniper.net> <5A978E94-ECA1-44EB-8BBD-6AC2DEAE3166@nomadiclab.com>
In-Reply-To: <5A978E94-ECA1-44EB-8BBD-6AC2DEAE3166@nomadiclab.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Aug 2005 19:46:49.0809 (UTC) FILETIME=[6A318C10:01C59EAD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
Cc: Internet Area <int-area@ietf.org>
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Sender: int-area-bounces@lists.ietf.org
Errors-To: int-area-bounces@lists.ietf.org
> > > 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
- [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Pekka Savola
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Spencer Dawkins
- Re: [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Ron Bonica
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Joe Touch
- Re: [Int-area] ICMP-MPLS Joe Touch
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Joe Touch
- Re: [Int-area] ICMP-MPLS Pekka Nikander
- Re: [Int-area] ICMP-MPLS Joe Touch