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

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,

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: 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
>
>
>
> 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.
>
Suggest to be "tolerate packet corruption or mis-delivery to the wrong address."

Thanks,
Tom

>
>
> 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,
>
>
>
> 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]
> 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>
>
>    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
>
> 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]; [email-masked]
> Cc: [email-masked]; [email-masked];
> Black, David
> Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6
>
>
>
>> 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
>
>
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

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:
> 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.
>

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

>
>
> David, what is the minimum text that we can import to satisfy the
> requirement.
>
>
>
>                                                              Ron
>
>
>
>
>
>
>
> Sent: Tuesday, March 31, 2015 3:21 PM
> To: Ronald Bonica; Black, David; [email-masked]; [email-masked]
>
>

---

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]

---

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

Hi Carlos,

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

Lucy

Hi, Lucy,

Thanks,

Carlos.

On Mar 30, 2015, at 7:47 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

> 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

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

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Black, David
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

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]<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

Lucy,

Would the following text work?

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]<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

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]<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

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)

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

---

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?

Regards,
Lucy

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>

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:48:26 +0000

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

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

Hi Ron and Carlos,

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: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:14:48 +0100

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to corruption.

SB> It is subject to corruption whether or not it has a checksum.
SB> The point is that there may be undetected corruption. However
SB> detection in only probabilistic even with a checksum. So
SB> I think that that this text should be:

Because the IPv6 delivery header does not include a checksum of its
own, it is subject to higher probability of undetected corruption.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:24:17 +0100

On 30/03/2015 22:49, Ronald Bonica wrote:
> 1)The delivery packet is dropped because the new destination address 
> is unreachable
>
> 2)The delivery packet is dropped because the new destination address 
> 3)The delivery packet is processed by a GRE egress other than that 
> a.The payload packet is dropped because the payload destination is 
> b.The payload packet is delivered to its intended destination because 
> the payload destination is reachable from the node that processed the 
> delivery packet
>
Ron, maybe I am missing a caveat, but suppose the payload is a packet 
with a non-globally unique address space (for example 10.x.x.x, but not 
limited to IP) then there is a case 3 c which is that the packet was 
delivered to a node that it was not the intended ultimate destination 
and one has to hope that there is sufficient resilency in the system 
receiving the packet that this is of no consequence.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 09:30:47 +0100

Isn't systematic rather than random corruption more likely?

Stewart

On 31/03/2015 23:04, Ronald Bonica wrote:
>
> 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 
> -That every minute, the destination address on a delivery packet is 
> corrupted
>
> -The pattern of corruption is random
>
> 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.
>
> *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,
>
> 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?
>
> *From:*Int-area [mailto:[email-masked]] *On Behalf Of 
> *Ronald Bonica
> *Sent:* Tuesday, March 31, 2015 1:43 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: [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,
>
> 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
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Apr 2015 10:38:22 -0700

> own, it is subject to higher probability of undetected corruption. 

The probability of undetected corruption is 100%. And a checksum isn't
the only way to detect errors.

IMO:

Because the IPv6 delivery header does not include error detection, it is
subject to undetected corruption.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2015 19:05:00 +0100

On 01/04/2015 18:38, Joe Touch wrote:
> .
I accept that there are other possible error checking technique, but
the original text is talking about checksum. However no check is
perfect so I still think it needs to be:

Because the IPv6 delivery header does not include error detection,
it is subject to a higher probability of undetected corruption.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Apr 2015 11:28:18 -0700

> it is subject to a higher probability of undetected corruption.

Point taken. Better.

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 2 Apr 2015 19:38:52 +0000

Lucy, Tom, Steward,

I agree with what you are saying and have tried to craft some text that addresses all of your comments. Please tell me if the following text does the trick.

                                                                                                                                                        Ron

OLD>
   As stated in [RFC2784], the Checksum field contains the IP (one's
   complement) checksum sum of the all the 16 bit words in the GRE
   header and the payload packet.  Therefore, the checksum does not
   ensure the integrity of the IPv6 delivery header.

NEW>
   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 or its own. Therefore, no 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.

Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. Network operators should deploy
GRE over IPv6 if they can tolerate the risk associated with behavior c).

<NEW

                                         Ron

---

From: Lucy yong <[email-masked]>
Date: Thu, 2 Apr 2015 19:58:06 +0000

Hi Ron,

Good Try. See inline below.

From: Ronald Bonica [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 2:39 PM
To: Lucy yong; Black, David; [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Lucy, Tom, Steward,

                                                                                                                                                        Ron

OLD>

NEW>

[Lucy] nit: “on its own”

a)      Drop the packet

Before deploying GRE over IPv6, network operators should consider the
likelihood of behavior c) in their network. Network operators should deploy
GRE over IPv6 if they can tolerate the risk associated with behavior c).
[Lucy] “can deploy” is better than “should deploy”

I am fine with the text for the corruption case. Do we need to address misdelivery as well.

Thanks,
Lucy

<NEW

                                         Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 2 Apr 2015 22:01:01 +0000

Lucy,

Both good catches. Stand by for text on misdelivery.

                                            Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 3:58 PM
To: Ronald Bonica; Black, David; [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Cc: [email-masked]; [email-masked]
Subject: RE: Start of WGLC for draft-ietf-intarea-gre-ipv6

Hi Ron,

To: Lucy yong; Black, David; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Stewart Bryant (stbryant)

Lucy, Tom, Steward,

                                                                                                                                                        Ron

OLD>

NEW>

a)      Drop the packet

Thanks,
Lucy

<NEW

                                         Ron