This "if properly implemented" seems pretty critical. Do we need to leave a reminder that implementations have to know about UDP TLVs in order to properly identify all fields in the headers to be compressed?
Indeed, the protocol parser and the SCHC rules need to know about the UDPTLVs if one wants to compress them.But the same is true of all the other fields. I don't think this onewarrants a special notice.What I insist on is that, if an implementation does not know of the UDPTLVs, it will not reconstruct an erroneous UDP Length, even for a packetthat contains these TLVs, assuming that the protocol parser checks the UDPand IPv6 lengths for consistency. See my example in a separate mail.
Agreed. The issue is that UDP length can’t be reconstructed UNLESS it matches the end of packet indicated by the IP length.
In any other case, claiming it can be reconstructed is an error and should not be allowed.
That appears to be a flaw in the claim that UDP length can be computed. It’s just not true in all cases.
Joe
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call