IPv6 Support for Generic Routing Encapsulation (GRE)
Note: This ballot was opened for revision 11 and is now closed.
(Alia Atlas) Yes
(Brian Haberman) Yes
(Jari Arkko) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
Comment (2015-08-05 for -11)
I have a few minor comments: -- 3.2, 2nd paragraph: As worded, I expected to find defined procedures (or a citation to such) to accomplish the verification. I see from the following paragraph that this is not the case. I think the following change would be more clear: OLD Before activating a GRE tunnel and periodically thereafter, the GRE ingress node MUST execute procedures that verify the tunnel’s ability to carry a 1280-byte IPv6 payload packet from ingress to egress, without fragmenting the payload. NEW Before activating a GRE tunnel and periodically thereafter, the GRE ingress node MUST verify the tunnel’s ability to carry a 1280-byte IPv6 payload packet from ingress to egress, without fragmenting the payload. END -- 3.2, last paragraph: Do all such existing implementations have the ability to be configured to fragment and reassemble payload packets? That is, is there a class of existing implementation that can no longer be considered compliant? -- 3.3, last sentence: Is there a reciprocal requirement for the egress to reassemble the fragmented delivery header? -- 4.2, 2nd to last paragraph: This seems like a very subjective MUST NOT. Please consider stating this without 2119 keywords. -- 8.1, first reference: That’s probably not appropriate as a normative reference. Neither the URL or the content can be assumed to be stable. Would it make sense to reference RFC 7042 instead? ** Nits ** --1, first sentence: s/Generic Routing Encapsulation/The Generic Routing Encapsulation/ -- 3 s/carry IPv6 payload/carry an IPv6 payload/ ; (or /carry IPv6 payloads/) -- 3.1 It would be helpful to mention that this is the IPv6 ether type.
(Benoît Claise) (was Discuss) No Objection
Comment (2015-08-31 for -13)
Thanks for addressing my DISCUSS.
Alissa Cooper No Objection
(Spencer Dawkins) (was Discuss, No Objection) No Objection
Thanks for working through my Discuss about checksums and VPNs. The version of the Discuss I cleared said this: Thank you for working with me on this Discuss, and addressing my Comments. I've revised this Discuss based on conversations with Ron (and we're converging). I have three questions, but I'm ready to clear. For reference, the Checksum text in -13 now looks like this: 4.2. Checksum Considerations As stated in [RFC2784], the GRE header can contain a checksum. If present, the GRE header checksum can be used to detect corruption of the GRE header and GRE payload. The GRE header checksum cannot be used to detect corruption of the IPv6 delivery header. Furthermore, the IPv6 delivery header does not contain a checksum of its own. Therefore, no available checksum can be used to detect corruption of the IPv6 delivery header. In one failure scenario, the destination address in the IPv6 delivery header is corrupted. As a result, the IPv6 delivery packet is delivered to a node other than the intended GRE egress node. Depending upon the state and configuration of that node, it will either: a. Drop the packet b. De-encapsulate the payload and forward it to its intended destination c. De-encapsulate the payload and forward it to a node other than its intended destination. For example, the payload might be intended for a node on one VPN, but delivered to an identically numbered node in another VPN. Behaviors a) and b) are acceptable. Behavior c) is not acceptable. However, behavior c) is possible only when the payload destination address is not globally unique and the GRE egress node provides disambiguating context to that address. Before deploying GRE over IPv6, network operators should consider the likelihood of behavior c) in their network. GRE over IPv6 MUST NOT be deployed other than where the network operator deems the risk associated with behavior c) to be acceptable. The risk associated with behavior c) could be mitigated with end-to- end authentication of the payload. So, my questions are: (1) how likely is it that endpoints in different VPNs would have overlapping address ranges? (2) is it correct that if endpoint A gets traffic that was intended for an identically addressed endpoint B in another VPN using an overlapping address range, and that traffic is authenticated, endpoint A can say "this isn't for me", but if that traffic is not encrypted, is traffic intended for endpoint B leaking to endpoint A? (3) if I'm not completely in the weeds so far, is "end-to-end authentication" something an operator can do? If the answer to (2) is "yes", is "end-to-end encryption" something an operator can do?
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
Barry Leiba No Objection
(Terry Manderson) No Objection
(Kathleen Moriarty) No Objection
Comment (2015-08-04 for -11)
The draft looks good, but I do have one item to chat about that should be very easy to address. Its subtle wording, but I think it is important. Thanks. Surprisingly, RFC4023 does a pretty good job explaining the threats that IPsec encryption and authentication help mitigate. The wording in the security section of this draft reads to me as if you can use either encryption or authentication to address those threats. I'm pretty sure that was not intended as each assists to mitigate different threats, clearly described in RFC4023. The Security Considerations has the following text right now: These threats apply to any GRE payload. As stated in RFC 4023, these threats can be mitigated by authenticating and/or encrypting the delivery packet using IPsec [RFC4301]. Alternatively when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPsec, instead of the delivery packet. How about something like the following (feel free to propose something else): These threats apply to any GRE payload. As stated in RFC 4023, the various threats can be mitigated through options such as authenticating and/or encrypting the delivery packet using IPsec [RFC4301]. Alternatively when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPsec, instead of the delivery packet. If it is changed in the first sentence, I think it makes the second one follow a bit better without changes.