Tom, Good point. If I don't hear otherwise by next Friday, post another version with the following change:
OLD> When the delivery protocol is IPv6, the GRE ingress router SHOULD set the Checksum Present field to zero. GRE egress routers MUST accept either a value of zero or one in this field. If the GRE egress router receives a value of one, it MUST use that information to calculate the GRE header length. However, the GRE ingress router is not required to use the checksum to verify packet integrity. <OLD NEW> When the delivery protocol is IPv6, the GRE ingress router SHOULD set the Checksum Present field to zero. GRE egress routers MUST accept either a value of zero or one in this field. If the GRE egress router receives a value of one, it MUST use that information to calculate the GRE header length and verify packet integrity. <NEW Ron > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Friday, February 06, 2015 12:25 PM > To: Ronald Bonica > Cc: [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > 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. > > > > 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. > > Thanks, > Tom > > > Ron > > > > > >> > >> Please clarify receiver checksum handling in section 2.1. > >> > >> >From the draft: > >> > >> The Checksum Present field SHOULD be set to zero by senders if IPv6 > >> is used as a delivery protocol. Receivers MUST also accept a value > >> of one in this field and use it to calculate the GRE header length > >> but they MUST NOT verify the contents of the Checksum field. > >> > >> Why is it a MUST NOT for receivers to validate checksums? Doesn't > >> this violate RFC2784? > >> > >> Thanks, > >> Tom > >> > >> > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
