Ronald Bonica has entered the following ballot position for draft-ietf-6man-udpzero-06: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in Section 5.1. Bullet 5 ====== "Tunnels that encapsulate IP may rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet." - What does it mean to *significantly* increase the rate of corruption of the inner IP packet? - Shouldn't we also be concerned about corruption of the UDP header and any additional encapsulation that comes between the UDP header and the inner IP packet? - How does a tunnel ingress node know whether the tunnel will significantly increase the rate of corruption of the inner IP packet? Bullet 7 =====- " UDP applications that support use of a zero-checksum, should not rely upon correct reception of the IP and UDP protocol information (including the length of the packet) when decoding and processing the packet payload. In particular, the application must be designed so that corruption of this information does not result in accumulated state or incorrect processing of a tunneled payload." - How could any application achieve this goal? Possibly by analyzing the consequences if any field in the IPv6 or UDP header were corrupted? (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't the analysis have to include any additional encapsulation that comes between the UDP header and the inner IP header? - Wouldn't the analysis, mentioned above, have to include assurances regarding the case when the destination port is corrupted? Specifically, would it have to include a guarantee that if the encapsulated inner packet were delivered to any randomly chosen port, it would not cause any harm to the application listening on that port? -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
