Hi Lucy,
I am reluctant to mandate a configuration option that causes the GRE ingress
node to set the Checksum present field to one. Rationale follows:
Imagine a packet traveling across the Internet. Depending on the packet type,
some portions of the packet are protected by checksums and other portions of
the packet are not. Now encapsulate that packet in a GRE header, with the GRE
Checksum Present field set to zero. The portions of the packet that were
protected by checksums before encapsulation are still protected. The portions
of the packet that were not protected by checksums before encapsulation are
still not protected.
In light of this, the above mentioned configuration switch is a good thing to
have, but not a strict requirement.
Also, Sections 2.1 and 4.2 are very similar, because the both deal with
checksums. However:
- Section 2.1 we are talking about the GRE payload, which may be protected by
multiple, possibly redundant checksums
- Section 4.2 we are talking about the IPv6 delivery header, which isn't
protected by any checksum
Ron
> -----Original Message-----
> From: Lucy yong [mailto:[email protected]]
> Sent: Thursday, June 25, 2015 7:00 PM
> To: Ronald Bonica; [email protected]
> Subject: RE: [Int-area] FW: I-D Action:draft-ietf-intarea-gre-ipv6-09.txt
>
> Ron,
>
> Quick fix. :)
>
> The GRE ingress node SHOULD set the Checksum Present field to zero.
> However, implementations MAY support a configuration option that
> causes the GRE ingress node to set the Checksum Present field to one.
>
> Does this mean that, by default, GRE ingress node sets Checksum Present
> field to zero, and it is optional for an implementation to support GRE
> Checksum? Please clarify. Should it be "implementations MUST support a
> configuration option ...".
>
> IMHO: The text in Section 2.1 and 4.2 has some redundancy. Please check.
>
> Thanks,
> Lucy
>
> -----Original Message-----
> From: Ronald Bonica [mailto:[email protected]]
> Sent: Thursday, June 25, 2015 4:21 PM
> To: [email protected]; Lucy yong
> Subject: RE: [Int-area] FW: I-D Action:draft-ietf-intarea-gre-ipv6-09.txt
>
> Lucy,
>
> Good point. I have posted a new version of the draft that omits the
> offending paragraph.
>
> I tried to wordsmith the offending paragraph so that it would say what I
> meant. However, when I did that, it became redundant with the preceding
> paragraph.
>
> The final sentence in Section 2.1 encourages operators to evaluate the risks
> in their network and configure the GRE ingress appropriately. So, if they
> need the Checksum Present field to be set to one, they can configure that
> behavior.
>
> Ron
>
>
>
> >
> > Message: 3
> > Date: Thu, 25 Jun 2015 17:15:38 +0000
> > From: Lucy yong <[email protected]>
> > To: "[email protected]" <[email protected]>
> > Subject: [Int-area] FW: I-D Action:
> > draft-ietf-intarea-gre-ipv6-09.txt
> > Message-ID:
> <2691CE0099834E4A9C5044EEC662BB9D5718B286@dfweml701-
> > chm>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Some comments:
> >
> > Section 2.1 description is not right. GRE checksum can't detect a mis-
> > delivered packet and neither the checksum function in the payload. GRE
> > checksum only provides integrity check on GRE header and GRE payload.
> >
> > Only IPv4 payload has the equivalent payload integrity check as of GRE
> > checksum. GRE does not directly carry TCP or UDP. When GRE payload
> > protocol is not IPv6, the payload still can carry TCP or UDP. For
> > example, GRE payload is either Ethernet or MPLS that carries
> > IP/TCP/UDP flows. This satisfies "the payload carries TCP or UDP"; in
> > this case, TCP and UDP checksum does not provide the same integrity
> check as of GRE checksum.
> >
> > GRE can be used in many ways. These examples seem not sufficient for
> > the justification of GRE checksum zero.
> >
> > Since Ipv6 has flow label, it would be good for the draft to describe
> > use of flow label in IPv6 header.
> >
> > Regards,
> > Lucy
> >
> >
> >
> >
> > -----Original Message-----
> > From: Int-area [mailto:[email protected]] On Behalf Of
> > internet- [email protected]
> > Sent: Thursday, June 25, 2015 11:07 AM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: [Int-area] I-D Action: draft-ietf-intarea-gre-ipv6-09.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Internet Area Working Group Working
> > Group of the IETF.
> >
> > Title : IPv6 Support for Generic Routing Encapsulation
> > (GRE)
> > Authors : Carlos Pignataro
> > Ron Bonica
> > Suresh Krishnan
> > Filename : draft-ietf-intarea-gre-ipv6-09.txt
> > Pages : 10
> > Date : 2015-06-25
> >
> > Abstract:
> > Generic Routing Encapsulation (GRE) can be used to carry any network-
> > layer payload protocol over any network-layer delivery protocol. GRE
> > procedures are specified for IPv4, used as either the payload or
> > delivery protocol. However, GRE procedures are not specified for
> > IPv6.
> >
> > This document specifies GRE procedures for IPv6, used as either the
> > payload or delivery protocol. It updates the GRE specification, RFC
> > 2784.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-ipv6/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-09
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gre-ipv6-09
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
> >
> >
> > ------------------------------
> >
> > End of Int-area Digest, Vol 119, Issue 4
> > ****************************************
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
