OK so I took a fresh look at all this this morning. Took two cups of coffee.
RFC 7915 section 4.5 is definitely relevant. It says the IPv4-to-IPv6 translator SHOULD either drop the packet or recalculate the checksum. I agree this is a reasonable burden for the CE but too expensive for the BR. Maybe we can proceed as follows: 1. Add RFC 7915 as a normative reference. 2. Clarify that as stated in RFC 7915, the CE SHOULD recalculate the checksum for upstream traffic. 3. Discuss that recalculating the checksum is an unreasonable burden on the BR. The BR MAY recalculate the checksum. If the BR does not recalculate the checksum, it MUST provide a configuration to forward the IPv6 packet with a zero checksum to promote interoperability. Does this seem reasonable? Michael Overcash Principal Architect, Premises Technology C 678.637.5649 [cid:[email protected]] From: Gottlieb, Jordan J <[email protected]> Sent: Friday, November 4, 2022 5:29 PM To: Overcash, Michael (CCI-Atlanta) <[email protected]>; Rajiv Asati (rajiva) <[email protected]>; Poscic, Kristian (Nokia - US) <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [Softwires] MAP-T issue - UDP packets with zero checksum My concern making it a "MUST" in any case. On the CE side you really do want to do UDP checksum on the MAP-T CE as a IPv4-mapped IPv6 address connection to an asset such as a edge cache would break with no checksum. There is no way for us to know what the UEs will be doing with regard to IPv4 UDP checksum. On the BR side I think it should just remain a "SHOULD". Generally speaking the operator can decide what is best for their network based on their use cases. Sincerely, Jordan ________________________________ From: Overcash, Michael (CCI-Atlanta) <[email protected]<mailto:[email protected]>> Sent: Friday, November 4, 2022 12:09 PM To: Gottlieb, Jordan J; Rajiv Asati (rajiva); Poscic, Kristian (Nokia - US) Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. @Ravij: correct, I am suggesting that the CE and BR MUST forward datagrams with zero checksum. The end-to-end goal is that if IPv4 zero-checksum datagrams go in one end, they pop out as zero-checksum datagrams on the other end. @Jordan: I’m not sure I quite follow your concern… did I just address it? Michael Overcash Principal Architect, Premises Technology C 678.637.5649 [cid:[email protected]] From: Gottlieb, Jordan J <[email protected]<mailto:[email protected]>> Sent: Friday, November 4, 2022 1:30 PM To: Rajiv Asati (rajiva) <[email protected]<mailto:[email protected]>>; Poscic, Kristian (Nokia - US) <[email protected]<mailto:[email protected]>> Cc: Overcash, Michael (CCI-Atlanta) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum I think this is going to be very implementation specific and I am in the option that changing to a MUST is too constraining. This is especially true when considering the CE case as stated at the start of the thread. Think QUIC to IPv4-Mapped IPv6 addressed CDN. Even in the BR case (though I do not apply it) I think it is not wise to employ this constraint as there are some possible use cases where this would be impactful. -Jordan From: Rajiv Asati (rajiva) <[email protected]<mailto:[email protected]>> Sent: Friday, November 4, 2022 10:49 AM To: Poscic, Kristian (Nokia - US) <[email protected]<mailto:[email protected]>> Cc: Gottlieb, Jordan J <[email protected]<mailto:[email protected]>>; Overcash, Michael (CCI-Atlanta) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: [Softwires] MAP-T issue - UDP packets with zero checksum CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Jordan’s distinction about tunneling vs translation is key here given the considerations for the normative language. Mike’s suggestion is not that BR should calculate checksum, rather that BR should forward packets with UDP checksum being 0. Is that right, Mike? If so, then it is reasonable. Cheers, Rajiv Asati VP.CTO, Cisco “Focus on what we can do with what we have, not the other way around.” On Nov 4, 2022, at 9:19 AM, Poscic, Kristian (Nokia - US) <[email protected]<mailto:[email protected]>> wrote: I agree with Jordan, that it should NOT be made a MUST. In the extreme, someone can use this as attack so that BR does nothing but recalculates checksums. Kris From: Softwires <[email protected]<mailto:[email protected]>> On Behalf Of Gottlieb, Jordan J Sent: Friday, November 4, 2022 11:12 AM To: Overcash, Michael (CCI-Atlanta) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [Softwires] MAP-T issue - UDP packets with zero checksum Hi all, I just to highlight that RFC6145 (a normative reference to RFC7599) which is obsoleted by RFC7915 covers this in detail. They very appropriately have assigned a SHOULD on the calculation function of zero checksum IPv4 traffic. I also want to point out that rfc6936 addresses tunneling protocol rather than a header translation based softwire and therefore should not be included as any kind of reference to RFC7599. I am very much opposed to making it a MUST as it has significant performance implications on the BR. It makes more sense on the CE for outgoing traffic as it has significant implications for IPv4-mapped IPv6 address traffic. Sincerely, Jordan From: Softwires <[email protected]<mailto:[email protected]>> On Behalf Of Overcash, Michael (CCI-Atlanta) Sent: Friday, November 4, 2022 7:44 AM To: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] [Softwires] MAP-T issue - UDP packets with zero checksum CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Hi, IPv4 packets are allowed to have a zero checksum, but IPv6 packets are not. The problem of tunnelling zero checksum IPv4 packets through IPv6 tunnels is described in RFC 6935. Currently RFC 7599 doesn’t address this issue, and as a result we’ve found that some existing BR and CE implementations don’t handle zero checksum UDP IPv4 packets correctly. I think it would be helpful to add RFC 6935 as a normative reference and add a new section 8.5 to discuss the issue. Something like the following would help: 8.5. UDP Checksum Considerations IPv4 UDP packets arriving at the BR or CE are can have a checksum value of zero, indicating no checksum was calculated. Historically, a zero checksum value is not permitted in IPv6 UDP datagrams, and some implementations will discard these packets. The MAP-T CE and BR MUST translate and forward zero checksum UDP datagrams in both the IPv4 and IPv6 domains as described in [RFC6935]. The text above could use some wordsmithing, but hopefully you get the idea. Michael Overcash Principal Architect, Premises Technology C 678.637.5649 <image001.png> _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/softwires__;!!Hit2Ag!wjS6zL7RadF7fHzUCc7H03UenqQsbxtrrJW3EHisODDmXva_L7ZNT4ZqehJVlqqKP_YJY06jSCVqEd_c7WdlXUw1jtsvO8E$>
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
