Hi,
I reviewed -02 on the plane; mostly I agree with Joe's comments (see
below). It might be possible to convince me that the deployed base is
so big (and there aren't going to be upgrades) that the existing
implementations need to be considered.
I can send more detailed comments later if need be.
My own high level comment is that this doc needs to address ICMPv6 as
well. We're defining a generic extension mechanism, and except for
the 128 byte rules for backward-compat, the mechanism seems to apply
to both ICMPv4 and ICMPv6.
The FCFS IANA policy also seems a bit too open.
On Fri, 17 Mar 2006, Joe Touch wrote:
- this document makes a change to ICMP processing that is NOT backward
compatible with the current standard; as a result, this document must
end up in the standards track or experimental with substantial warnings
(I'm not sure if that hum will come up)
Agreed.
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.
I.e., THIS SECTION PROHIBITS USE OF THIS EXTENSION FOR DEST-UNREACHABLE
WITH MORE THAN 128-BYTE PAYLOADS. This is NOT a minor issue - this KILLS
THE UTILITY OF THIS MOD for new versions. Traceroute is a major issue -
and it may be the case that some future protocols will require full,
i.e., signed packets to be returned; this PREVENTS THIS POSSIBILITY -
even if the sender designed the packets to fit in the ICMP payload limit.
Agreed; I didn't like this either. Senders shouldn't need to restrict
the response they send to 128 bytes.
Why not just require that Length must be present to even try to parse
anything?
If there is no length field, some implementations may try to interpret
the extensions in any case (especially if the checksum matches, so
there's a high chance that it's valid), but I'm not sure how much we
need to address this "transition" issue.
In any case, the receivers can break themselves and the data they
receive as much as they want -- there's nothing the IETF can do to
prevent vendors from interpreting parts of the payload in any way they
want -- but don't put any additional restrictions on senders!
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
