Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 30 Mar 2015 20:27:03 +0000

Dear Int-Area and 6man WGs,

At the Int-Area WG meeting in Dallas there were some comments on draft-ietf-intarea-gre-ipv6. It was decided to submit the document for WG Last Call to the Int-Area & 6man WGs as soon as the agreed changes were made.

The document has now been updated accordingly, so this email starts an Int-Area/6man WGs Last Call on:

http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04

Please respond to this email to support the document and/or send comments by 2015-04-06.

In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)":

Are you personally aware of any IPR that applies to draft-ietf-intarea-gre-ipv6?

If so, has this IPR been disclosed in compliance with IETF IPR rules?

(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Juan Carlos Zuniga
(as Int-Area WG co-chair)

---

From: Lucy yong <[email-masked]>
Date: Mon, 30 Mar 2015 20:49:41 +0000

Thanks authors to add section 4.1.

I am not sure if the statement of “However, even if the delivery header is corrupted, to likelihood of that corruption resulting in misdelivery of the payload is extremely low.” is proper. IPv6 requires the end point/upper layer to deal with the header corruption. Could we state that this is the difference from gre-in-ipv4 instead?

Lucy

From: Int-area [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Monday, March 30, 2015 3:27 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Best,

Juan Carlos Zuniga

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Mar 2015 21:09:18 +0000

Hi Juan Carlos,

Final passage of Section 3.1 says:

   “However, in an alternative configuration, the GRE ingress MAY:

   o  discard the IPv6 packet

   o  send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6
      packet source.  The MTU field in the ICMPv6 PTB message is set to
      the GMTU.”

This means that there may be circumstances when the GRE ingress sends
a PTB reporting a size less than 1280. According to RFC2460, Section 5, the
standard behavior for a host that receives such a PTB is:

   “In that case, the IPv6 node
  is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets”

So, hosts that obey RFC2460 Section 5 will see a perpetual black hole if the
GMTU is smaller than 1280 which is probably not what we want.

‘draft-templin-6man-linkadapt’ attempts to provide guidance to hosts on
how to react to PTB messages that report a small size. But, as of right now,
RFC2460 Section 5 is the normative behavior.

Thanks – Fred
[email-masked]

Sent: Monday, March 30, 2015 1:27 PM

Best,

Juan Carlos Zuniga

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Mar 2015 21:11:47 +0000

On an even higher level note, RFC2473 already specifies generic encapsulation
within IPv6 which implicitly includes GRE. So, if this document goes through it
needs to say that it updates RFC2473.

Thanks – Fred

Best,

Juan Carlos Zuniga

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 30 Mar 2015 21:49:10 +0000

Lucy,

Would the following text work?

OLD>
   Because the IPv6 delivery header does not include a checksum of its
   own, it is subject to corruption.  However, even if the delivery
   header is corrupted, to likelihood of that corruption resulting in
   misdelivery of the payload is extremely low.
<OLD

NEW>
   Because the IPv6 delivery header does not include a checksum of its
   own,  the destination address in the delivery header is subject to
   corruption. If the destination address in the deliver header is corrupted,
   the following outcomes are possible:

1)      The delivery packet is dropped because the new destination address is unreachable

2)      The delivery packet is dropped because the new destination address is reachable, but that node is not configured to process GRE delivery packets from the ingress

3)      The delivery packet is processed by a GRE egress other than that which was originally specified by the GRE ingress. Processing options are:

a.       The payload packet is dropped because the payload destination is unreachable from the node that processed the delivery packet

b.      The payload packet is delivered to its intended destination because the payload destination is reachable from the node that processed the delivery packet

All of these outcomes are acceptable.

<NEW

                          Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 30, 2015 4:50 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy

From: Int-area [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Monday, March 30, 2015 3:27 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Best,

Juan Carlos Zuniga

---

From: Lucy yong <[email-masked]>
Date: Mon, 30 Mar 2015 22:05:06 +0000

Hi Ron,

1)      and 2 ) are fine. IMO: 3) works under certain conditions but not all.

I add David Black (TSVWG chair) to the thread. He can provide the thorough check.

Regards,
Lucy

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, March 30, 2015 4:49 PM
To: Lucy yong; Zuniga, Juan Carlos; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy,

OLD>

NEW>

<NEW

                          Ron

To: Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Lucy

Best,

Juan Carlos Zuniga

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 30 Mar 2015 22:14:09 +0000

Lucy,

Why would you object to 3a? Dropping the packet is the preferred behavior?

Also, why would you object to 3b? The packet ends up at the right node, just via an unexpected route. Recall that the destination address in the payload header is protected by the UDP/TCP checksum.

Are you thinking that there might be a 3c)?

                      Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, March 30, 2015 6:05 PM
To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked]; [email-masked]; Black, David
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Regards,
Lucy

To: Lucy yong; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Lucy,

OLD>

NEW>

<NEW

                          Ron

Lucy

Best,

Juan Carlos Zuniga

---

From: Lucy yong <[email-masked]>
Date: Mon, 30 Mar 2015 22:31:07 +0000

Hi Ron,

3b) is the concern. GRE payload may be non-IP type. If a gre-in-ipv6 tunnel is used for mux of different payload types, the outcome may be unknown and can be unacceptable upon IP address and/or GRE header are corrupted.

Lucy

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, March 30, 2015 5:14 PM
To: Lucy yong; Zuniga, Juan Carlos; [email-masked]; [email-masked]; Black, David
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy,

                      Ron

To: Ronald Bonica; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David

Hi Ron,

Regards,
Lucy

Lucy,

OLD>

NEW>

<NEW

                          Ron

Lucy

Best,

Juan Carlos Zuniga

---

From: "Black, David" <[email-masked]>
Date: Mon, 30 Mar 2015 23:47:52 +0000

> Also, why would you object to 3b? The packet ends up at the right node, just via an unexpected route.

That assertion is based on the assumption that the payload destination address is worldwide unique.

There are lots of counterexamples that void the assumption, e.g., 10.0.0.0/8.

Thanks,
--David

Sent: Monday, March 30, 2015 6:31 PM

Hi Ron,

Lucy

To: Lucy yong; Zuniga, Juan Carlos; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David

Lucy,

                      Ron

Hi Ron,

Regards,
Lucy

Lucy,

OLD>

NEW>

<NEW

                          Ron

Lucy

Best,

Juan Carlos Zuniga

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 18:43:19 +0000

Resend…

From: Ronald Bonica
Sent: Tuesday, March 31, 2015 2:23 PM
To: 'Black, David'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

David, Lucy,

You are correct.  Maybe the following text will address the issue:

OLD>

NEW>

b.      The payload packet is delivered to its intended destination

c.       The payload packet is erroneously delivered to a node other than its intended destination. The intended destination and the node to which the payload is actually delivered are numbered identically, but reside in different VPNs.

Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not acceptable, but it extremely unlikely. Because IPv6 address space is so large and so sparsely populated, outcome 1) is by far the most probable. Therefore, the combined likelihood of all acceptable outcomes by far exceeds the likelihood of the one unacceptable outcome.

Furthermore, even if the payload is erroneously delivered to a node other than its intended destination, that node will discard the packet if the payload is also corrupted or if there are no applications waiting to consume the packet.

<NEW

                                   Ron

From: Black, David [mailto:[email-masked]]
Sent: Monday, March 30, 2015 7:48 PM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Thanks,
--David

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Mar 2015 19:21:15 +0000

Hi Ron,

3c) may happen for a VPN or non-VPN case. The payload can be in non-IPv6 space.  Is “Outcome 3c) is not acceptable, but it extremely unlikely.” for particular network/usage in your mind?

Is the goal here to prove such corruption is acceptable or extreme unlikely?

Regards,
Lucy

From: Int-area [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, March 31, 2015 1:43 PM
To: Black, David; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Resend…

From: Ronald Bonica
Sent: Tuesday, March 31, 2015 2:23 PM
To: 'Black, David'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

David, Lucy,

OLD>

NEW>

<NEW

                                   Ron

Thanks,
--David

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Mar 2015 19:48:26 +0000

Hi Carlos,

I am not clear what you propose here. UDP checksum includes IP header, GRE checksum does not.

Regards,
Lucy

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 2:01 PM
To: Black, David; Lucy yong
Cc: Ronald P. Bonica; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi, Lucy,

One approach is to add a 3.c) to the list that Ron shared. I think there is another potential approach to your initial comment: we could note that for a tunneling protocol (GRE), this is equivalent to the relaxation of the UDP checksum in RFC 6935, and keep the existing text.

Fred, RFC 2473 does not mention checksums.

Thanks,

Carlos.

---

From: "Black, David" <[email-masked]>
Date: Tue, 31 Mar 2015 20:06:49 +0000

Hi Carlos,

> One approach is to add a 3.c) to the list that Ron shared. I think there is another potential approach to your initial comment:
> we could note that for a tunneling protocol (GRE), this is equivalent to the relaxation of the UDP checksum in RFC 6935, and keep the existing text.

It’s not that simple (I wish it was).   The short summary is RFC 6935 does not set a precedent that can just be cited - in particular a single sentence pointing to RFC 6935 to say “therefore this is ok” is likely to garner multiple IESG Discuss positions for not explaining why, sorry (Lucy and I are in the midst of working through this for GRE-in-UDP).

For the long version, please start with Section 3.1 of the MPLS-in-UDP draft (in AUTH48 at the RFC Editor):

http://tools.ietf.org/html/draft-ietf-mpls-in-udp-11#section-3.1

Section 3.2 is also applicable, but much shorter and reasonably straightforward by comparison.

Thanks,
--David

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 3:48 PM
To: Lucy yong; Carlos Pignataro (cpignata); Black, David
Cc: Ronald P. Bonica; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Carlos,

Regards,
Lucy

Hi, Lucy,

Thanks,

Carlos.

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Mar 2015 20:41:38 +0000

Hi Ron and Carlos,

There is the proposed text for the second paragraph in Section 4.1

Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption.  Thus the use of gre in IPv6 must be in either the case where an IPv6 delivery network can ensure packet corruption extremely unlikely or the case where GRE payload is able to tolerate the packet corruption.

Thanks,
Lucy

From: Lucy yong
Sent: Tuesday, March 31, 2015 2:23 PM
To: 'Ronald Bonica'; Black, David; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Regards,
Lucy

To: Black, David; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Resend…

From: Ronald Bonica

David, Lucy,

OLD>

NEW>

<NEW

                                   Ron

Thanks,
--David

---

From: Lucy yong <[email-masked]>
Date: Tue, 31 Mar 2015 20:45:36 +0000

Minor tweak. ☺

From: Lucy yong
Sent: Tuesday, March 31, 2015 3:42 PM
To: Lucy yong; Ronald Bonica; Black, David; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron and Carlos,

Here is the proposed text for the second paragraph in Section 4.1

Because the IPv6 delivery header does not include a checksum of its own, it is subject to corruption.  Thus the use of gre in IPv6 must be in the case where an IPv6 delivery network can ensure packet corruption extremely unlikely and/or the case where GRE payload is able to tolerate the packet corruption.

Thanks,
Lucy

From: Lucy yong
Sent: Tuesday, March 31, 2015 2:23 PM
To: 'Ronald Bonica'; Black, David; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Regards,
Lucy

Resend…

From: Ronald Bonica

David, Lucy,

OLD>

NEW>

<NEW

                                   Ron

Thanks,
--David

---

From: Tom Herbert <[email-masked]>
Date: Tue, 31 Mar 2015 14:07:38 -0700

On Tue, Mar 31, 2015 at 1:45 PM, Lucy yong <[email-masked]> wrote:
> Minor tweak. J
> Because the IPv6 delivery header does not include a checksum of its own, it
> is subject to corruption.  Thus the use of gre in IPv6 must be in the case
> where an IPv6 delivery network can ensure packet corruption extremely
> unlikely and/or the case where GRE payload is able to tolerate the packet
> corruption.
>
Suggest to be "tolerate packet corruption or mis-delivery to the wrong address."

Thanks,
Tom

> 3c) may happen for a VPN or non-VPN case. The payload can be in non-IPv6
> space.  Is “Outcome 3c) is not acceptable, but it extremely unlikely.” for
> particular network/usage in your mind?
>
>
>
> 2)      The delivery packet is dropped because the new destination address
> is reachable, but that node is not configured to process GRE delivery
> packets from the ingress
>
> 3)      The delivery packet is processed by a GRE egress other than that
> which was originally specified by the GRE ingress. Processing options are:
>
> a.       The payload packet is dropped because the payload destination is
> unreachable from the node that processed the delivery packet
>
> c.       The payload packet is erroneously delivered to a node other than
> its intended destination. The intended destination and the node to which the
> payload is actually delivered are numbered identically, but reside in
> different VPNs.
>
>
>
> Outcomes 1), 2), 3a) and 3b) are acceptable. Outcome 3c) is not acceptable,
> but it extremely unlikely. Because IPv6 address space is so large and so
> sparsely populated, outcome 1) is by far the most probable. Therefore, the
> combined likelihood of all acceptable outcomes by far exceeds the likelihood
> of the one unacceptable outcome.
>
>
>
> Furthermore, even if the payload is erroneously delivered to a node other
> than its intended destination, that node will discard the packet if the
> payload is also corrupted or if there are no applications waiting to consume
> the packet.
>
>
>
> <NEW
>
>
>
>                                    Ron
>
>
>
>
>
> To: Ronald Bonica; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> Black, David
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 31 Mar 2015 22:04:30 +0000

Lucy, David,

The proposed text says that outcome 3c) is unacceptable but highly unlikely. For example, assume the following:

-          That an IPv6 address is assigned to every milligram of matter on earth, including every drop of water. (2**95 IPv6 addresses are assigned)

-          That every minute, the destination address on a delivery packet is corrupted

-          The pattern of corruption is random

Every time a destination address is corrupted, the odds are 1 / 8,589,934,592 that the result will be an assigned address. This should happen one ever 16, 331 years.

Now, assume that only 1% of those of those 2**95 IPv6 addresses are configured on devices that de-encapsulate GRE. In this case, outcomes 3a), 3b) and 3c) will occur only once every 1,633,100 years!

So, practically speaking, we don’t have much to worry about. But for the purposes of the pedantry, we may need to say that GRE over IPv6 is only practical when operators can deal with that risk.

David, what is the minimum text that we can import to satisfy the requirement.

                                                             Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 3:21 PM
To: Ronald Bonica; Black, David; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

Regards,
Lucy

Resend…

From: Ronald Bonica

David, Lucy,

OLD>

NEW>

<NEW

                                   Ron

Thanks,
--David

---

From: Tom Herbert <[email-masked]>
Date: Tue, 31 Mar 2015 15:56:33 -0700

On Tue, Mar 31, 2015 at 3:04 PM, Ronald Bonica <[email-masked]> wrote:
> -          That an IPv6 address is assigned to every milligram of matter on
> earth, including every drop of water. (2**95 IPv6 addresses are assigned)
>
> Every time a destination address is corrupted, the odds are 1 /
> 8,589,934,592 that the result will be an assigned address. This should
> happen one ever 16, 331 years.
>
>
>
> Now, assume that only 1% of those of those 2**95 IPv6 addresses are
> configured on devices that de-encapsulate GRE. In this case, outcomes 3a),
> 3b) and 3c) will occur only once every 1,633,100 years!
>
>
>
> So, practically speaking, we don’t have much to worry about. But for the
> purposes of the pedantry, we may need to say that GRE over IPv6 is only
> practical when operators can deal with that risk.
>

You are assuming that failures will nicely follow a random
distribution, this is not always the case. For instance, we have had
issues in the past where a packet was queued to NIC on the host, but
then addresses we're overwritten due to loss of synchronization
between host and device as to rather packet was completed, so the
result would be mis-delivery if there is not checksum to catch that.

It is necessary prudence to assume that the risk of mis-delivery is
non-zero and that risk is probably greater in IPv6 than IPv4. An
operator should be aware of these risks and be able to evaluate the
ramifications of mis-delivery. Probably, in most cases the risk is in
fact inconsequential, but that really needs to be determined by the
operator-- of course if the operator's network is carrying nuclear
launch codes I would hope they worry about mis-delivery a little more
:-)

Tom

---

From: "Black, David" <[email-masked]>
Date: Tue, 31 Mar 2015 23:22:54 +0000

Ron,

Tom comments:
> distribution, this is not always the case

+1, and likewise, IPv6 addresses are also not uniformly randomly
distributed in practice ;-).  Nice try, though ...

> > David, what is the minimum text that we can import to satisfy the

I'm not sure I can dictate the text, but let me suggest where to "dig."

A motivating observation is that if the likelihood of destination
IPv6 address corruption causing misdelivery is very small, then the
likelihood of that corruption in combination with an offsetting
corruption in the source IPv6 address is something like (very small)**2,
i.e., truly miniscule.  Hence, if one can pair off tunnel source and
destination IPv6 addresses so that both have to be corrupted for
misdelivery to occur, then misdelivery should be sufficiently unlikely.
(NB: a number of words in this paragraph are "hand waves" - that's
deliberate).

So, what is it safe to say (without breaking running code) on the
subjects of:
	- GRE encapsulator use of separate IPv6 source addresses for
		separate tunnels? (NB: "tunnels" not "destinations" to
		allow for multicast).
	- GRE decapsulator check of IPv6 source address?

For MPLS/UDP, the answers were versions of SHOULD and MUST in that
order (see items c and d in Section 3.1 of draft-ietf-mpls-in-udp).

OTOH, GRE "running code" is a crucial consideration here and the
comment that "GRE over IPv6 is only practical when operators can
deal with that risk" is also useful, IMHO.

Thanks,
--David

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: Tuesday, March 31, 2015 6:57 PM
> To: Ronald Bonica
> Cc: Lucy yong; Black, David; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; [email-masked]