>
>> 4.3 - this is the largest current problem area. it's bad enough to
>> extend ICMP in a non- standards-backward-compatible way, but it is NOT
>> appropriate to **limit** this design to accommodate backward
>> compatibility with non-standards-compliant mods. This REALLY makes the
>> case that MPLS versions should have their own message protocol, or at
>> least have their own ICMP message types.
>>
Folks,
It looks like Section 4.3 presents the biggest problem. So, let's take a
look at the text. Section 4.3 begins as follows:
"When a partially compliant application receives a message that contains
fully compliant ICMP extensions, it will parse those extensions
correctly only if the "original datagram" field contains exactly 128
octets. This is because partially compliant applications are
insensitive to the length attribute that is associated with the
"original datagram" field. (They assume its value to be 128.)"
So far, we are probably in total agreement. This isn't a statement of
how things should be, but how they are.
The devil's text follows:
"Therefore, when fully compliant ICMP implementations append extensions
to the ICMP Destination Unreachable and Time Expired Messages, they
SHOULD restrict the "original datagram" field to its minimum length, 128
octets."
This paragraph is problematic because it makes a statement about how
thing should be. I would be willing to replace this text with the following:
"Provided that the entire ICMP messages does not exceed 576 octets,
there is no limitation upon the length of the "original datagram" field.
However, each vendor will decide how many octets to include. Currently,
many vendors include only the IP header and the first eight octets of
the IP payload. Some include exactly 128 octets. Those wishing to be
backward compatible with partially compliant TRACEROUTE implementations
will continue to include exactly 128 octets. Those not requiring
compatibility with partially compliant TRACEROUTE applications may
include more octets."
Ron
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
