IPv6 Support for Generic Routing Encapsulation (GRE)
draft-ietf-intarea-gre-ipv6-14

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.

Thanks for addressing my DISCUSS.

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.

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?