Hi Tom, On 02/06/2015 12:25 PM, Tom Herbert wrote: > On Thu, Feb 5, 2015 at 12:40 PM, Ronald Bonica <[email protected]> wrote: >> Tom, >> >> Good point. I will fix this in the next version of the draft. >>h > > Hi Ronald, > > In section 2.1 of draft-ietf-intarea-gre-ipv6-02, making checksum > verification optional at the receiver still seems to change behavior > specified in RFC2784 section 2.2: > > "Note that a compliant implementation MUST accept and process this field." > > I take this to mean that if checksum field is present it must be > verified, and I believe this is consistent with other use cases of > optional checksums (like the UDPv4 checksum). > > More generally though, I don't understand why IPv6 as GRE EtherType, > or any EtherType for that matter, should have any bearing on how the > GRE checksum is handled for either transmit or receive. In fact, given > that IPv6 doesn't have a header checksum, it seems like there might be > more motivation to use GRE checksum with IPv6 than IPv4.
I just want to clarify one thing. This text is specifically about using IPv6 as the delivery protocol and not as the payload protocol (i.e. what is in the EtherType). The intention of the text was to avoid checksumming already checksummed payload packets similar to what is described for UDP in RFC6935. e.g. If the payload protocol is IPv4, it already has a checksum. Why do another checksum in the encapsulating IPv6 GRE packet? Please note that RFC2784 did not provide any guidance about setting the Checksum Present field. Do I understand correctly that you want to leave things the way they are? Thanks Suresh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
