Subject: 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: 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,

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,

OLD>

NEW>

<NEW

                          Ron

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

Lucy

Best,

Juan Carlos Zuniga

---

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

Hi Ron,

Regards,
Lucy

To: Lucy yong; Zuniga, Juan Carlos; [email-masked]; [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:23:17 +0000

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

Thanks,
--David

Hi Ron,

Lucy

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,

OLD>

NEW>

<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: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 31 Mar 2015 19:01:13 +0000

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.

> On Mar 30, 2015, at 7:47 PM, Black, David <[email-masked]> wrote:
> 
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> 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]>
> From: Ronald Bonica [mailto:[email-masked] <mailto:[email-masked]>]
> 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]>
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> 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]>
> From: Ronald Bonica [mailto:[email-masked] <mailto:[email-masked]>]
> 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]>
> From: Lucy yong [mailto:[email-masked] <mailto:[email-masked]>]
> 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]>
> From: Int-area [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Zuniga, Juan Carlos
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04 <http://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-04>
> 
> _______________________________________________
> 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,

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

OLD>

NEW>

<NEW

                                   Ron

Thanks,
--David

---

From: David Farmer <[email-masked]>
Date: Tue, 31 Mar 2015 18:49:56 -0500

The Security Considerations for this Draft are not sufficient by today's 
standards in my opinion.  The Security Considerations of RFC2784 does 
not even discuss data protection (encryption) or tunnel end point 
authentication issues, and this draft basically just references RFC2784. 
  Any proper discussion of Security Considerations for this topic should 
at least include references on these issues.  I point you to RFC4023 
section 8, for an much more in depth handling of Security Considerations 
of similar issues.

I'm not sure its necessary to go to that depth, but some pointers to 
IPSec and/or SSL would seem a minimum, especially since IPSec was 
suppose to be a key feature for IPv6. Also, RFC6196 has a good 
discussion of security issues with tunnels in general.

Thanks

On 3/30/15 15:27 , Zuniga, Juan Carlos wrote:
> 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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================