Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 14:21:43 +0000

Hi Fred,

Inline.......

> 
> Message: 1
> Date: Mon, 23 Feb 2015 16:50:27 +0000
> From: "Templin, Fred L" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> Message-ID:
> 	<2134F8430051B64F815C691A62D9831832DFB25B@XCH-BLV-
> 504.nw.nos.boeing.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi, I have a comment on this document. 'draft-ietf-intarea-gre-ipv6' is very
> much in the same boat as RFC2473 in terms of MTU and Fragmentation
> considerations. So, why not just cite Sections 6.7 and 7 of RFC2473 instead of
> inventing new text here since the considerations are exactly the same?
> 
[RPB] 

RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands to reason that the two approaches would be similar. However, the text in RFC 2473 is a proper subset of the text in Section 3.1 of draft-ietf-intarea-gre-ipv6. Since much of the text in draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes sense to restate the part that is also presented in RFC 2473.

> But then, there would still be three problems inherent in both documents:
> 
> 1) There may be no way for the tunnel ingress to determine the MTU on
>      the path to the egress, e.g., if ICMP PTB messages are lost or somehow
>     forged by an attacker
> 
[RPB] 
Isn't loss or forgery of PTB messages a well-known issue for IPv6, regardless of whether any tunnels are involved?

> 2) ICMP PTB messages may be lost on the  return path from the tunnel
>     ingress to the original source
[RPB] 
Same comment as above
> 
> 3) Even in environments where 1) and 2) are not a matter of concern, the
>     original source could see an MTU smaller than 1500.
[RPB] 
This is addressed in Sections 4.1 of draft-ietf-intarea-gre-ipv6.

                                             Ron

> 
> These issues are addressed by Section 3.13 of 'draft-templin-aerolink', which
> is applicable for all tunneling environments.  What is in RFC2473 right now
> (and what 'draft-ietf-intarea-gre-ipv6' should be citing) is only applicable for
> controlled environments.
> 
> Thanks - Fred
> [email-masked]
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 15:49:27 +0000

Hi Ron,

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Tuesday, February 24, 2015 6:22 AM
> To: [email-masked]
> RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands to reason that the two approaches would be similar.

Not similar - identical.

> However, the text in RFC 2473 is a proper subset of the text in Section 3.1 of draft-ietf-intarea-gre-ipv6. Since much of the text in
> draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes sense to restate the part that is also presented in RFC 2473.

I disagree. RFC2473 is an already-published standard that specifies MTU and
fragmentation considerations that apply also to this document. This document
should therefore cite the RFC2473 text normatively.

If you think there is something new to be said in this document, then that should
also update RFC2473. But, I don't see where this document is saying anything new. 

> Isn't loss or forgery of PTB messages a well-known issue for IPv6, regardless of whether any tunnels are involved?

Tunnels can address these issues by ignoring ICMP PTB messages that report
a size smaller than 1500 bytes.

> >     ingress to the original source

What is missing is a recommendation for original sources to use RFC4821.

> This is addressed in Sections 4.1 of draft-ietf-intarea-gre-ipv6.

What I mean is, if the tunnel does not support a guaranteed minimum MTU
of 1500 bytes then a PTB message reporting a size less than 1500 bytes would
need to be returned to the sender. If that PTB message is lost, the result is
a black hole.

So, what I am saying is that tunnels should support a guaranteed minimum
MTU of 1500 bytes as in 'draft-templin-aerolink'. This is not addressed in
your document.

Thanks - Fred

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 08:23:32 -0800

On 2/24/2015 7:49 AM, Templin, Fred L wrote:
> MTU of 1500 bytes as in 'draft-templin-aerolink'.

That depends on whether this document describes "what should be" vs. 
"what is".

I had thought it was the latter.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 17:09:26 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2015 8:24 AM
> To: Templin, Fred L; Ronald Bonica; [email-masked]

The document is representing itself as a proposed standard. That would be
"what MUST be".

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 17:09:37 +0000

Fred,

Regarding you first comment, the approach taken by RFC 2473 is similar, but not identical to the approach taken by draft-ietf-intarea-gre-ipv6. Please compare the text in RFC 2473, Section 7.1.b to the corresponding text in Section 3.1 of draft-ietf-intarea-gre-ipv6.  

Even though the approaches diverge slightly, draft-ietf-intarea-gre-ipv6 should not UPDATE RFC 2473. draft-ietf-intarea-gre-ipv6 UPDATES GRE encapsulation procedures, that are defined in RFC 2784. . Therefore, draft-ietf-intarea-gre-ipv6 UPDATES RFC 2784. It does not UPDATE IP-in-IP encapsulation procedures, that are defined in RFC 2473. Therefore, it shouldn't UPDATE RFC 2473.

Regarding your second comment, I think that we can safely ignore the issue of loss or forgery of ICMP PTB. That problem is inherent to IPv6 fragmentation, and is not specific to tunnels. 

However, we must address the problem that occurs when the tunnel ingress receives an ICMP PTB with an MTU < X. First, the tunnel ingress must decide whether to update its estimate of the PMTU. This decision is beyond the scope of this document, as it is not unique to encapsulation. Every IPv6 node has to make this decision, regardless of whether it is a tunnel endpoint.

Assuming that the tunnel endpoint updates its estimate of the PMTU, and the resulting GMTU is lower than 1280, the tunnel endpoint has another decision to make. When it receives a packet with size > GMTU, it can either:

- discard the packet and send an ICMP PTB, or
- Fragment the delivery header

The current draft specifies a configuration option that governs this decision.

                                                                                                  Ron

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2015 10:49 AM
> To: Ronald Bonica; [email-masked]
> Subject: RE: draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> > > Hi, I have a comment on this document. 'draft-ietf-intarea-gre-ipv6'
> > > is very much in the same boat as RFC2473 in terms of MTU and
> > > Fragmentation considerations. So, why not just cite Sections 6.7 and
> > > 7 of RFC2473 instead of inventing new text here since the considerations
> are exactly the same?
> > >
> > [RPB]
> >
> > RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands
> to reason that the two approaches would be similar.
> 
> Not similar - identical.
> 
> > However, the text in RFC 2473 is a proper subset of the text in
> > Section 3.1 of draft-ietf-intarea-gre-ipv6. Since much of the text in
> > draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes
> sense to restate the part that is also presented in RFC 2473.
> 
> fragmentation considerations that apply also to this document. This
> document should therefore cite the RFC2473 text normatively.
> 
> If you think there is something new to be said in this document, then that
> should also update RFC2473. But, I don't see where this document is saying
> anything new.
> 
> > Isn't loss or forgery of PTB messages a well-known issue for IPv6,
> regardless of whether any tunnels are involved?
> 
> need to be returned to the sender. If that PTB message is lost, the result is a
> black hole.
> 
> MTU of 1500 bytes as in 'draft-templin-aerolink'. This is not addressed in your
> document.
> 
> Thanks - Fred
> > > These issues are addressed by Section 3.13 of
> > > 'draft-templin-aerolink', which is applicable for all tunneling
> > > environments.  What is in RFC2473 right now (and what
> > > 'draft-ietf-intarea-gre-ipv6' should be citing) is only applicable for
> controlled environments.
> > >
> > > Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 17:12:35 +0000

Joe,

The latter. The following is text from the draft:

" This document specifies GRE procedures for IPv6, used as either the
   payload or delivery protocol.  It updates RFC 2784 [RFC2784].  Like
   RFC 2784, this specification describes GRE how has been implemented
   by several vendors."

                                                         Ron

> Sent: Tuesday, February 24, 2015 11:24 AM
> > So, what I am saying is that tunnels should support a guaranteed
> > minimum MTU of 1500 bytes as in 'draft-templin-aerolink'.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 17:17:34 +0000

Hi Ron,

> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Tuesday, February 24, 2015 9:10 AM
> To: Templin, Fred L; [email-masked]
> Regarding you first comment, the approach taken by RFC 2473 is similar, but not identical to the approach taken by draft-ietf-intarea-
> gre-ipv6. Please compare the text in RFC 2473, Section 7.1.b to the corresponding text in Section 3.1 of draft-ietf-intarea-gre-ipv6.
> 
> Even though the approaches diverge slightly, draft-ietf-intarea-gre-ipv6 should not UPDATE RFC 2473. draft-ietf-intarea-gre-ipv6
> UPDATES GRE encapsulation procedures, that are defined in RFC 2784. . Therefore, draft-ietf-intarea-gre-ipv6 UPDATES RFC 2784. It
> does not UPDATE IP-in-IP encapsulation procedures, that are defined in RFC 2473. Therefore, it shouldn't UPDATE RFC 2473.
> 
> Regarding your second comment, I think that we can safely ignore the issue of loss or forgery of ICMP PTB. That problem is inherent to
> IPv6 fragmentation, and is not specific to tunnels.
> 
> However, we must address the problem that occurs when the tunnel ingress receives an ICMP PTB with an MTU < X. First, the tunnel
> ingress must decide whether to update its estimate of the PMTU. This decision is beyond the scope of this document, as it is not
> unique to encapsulation. Every IPv6 node has to make this decision, regardless of whether it is a tunnel endpoint.
> 
> Assuming that the tunnel endpoint updates its estimate of the PMTU, and the resulting GMTU is lower than 1280, the tunnel endpoint
> has another decision to make. When it receives a packet with size > GMTU, it can either:
> 

AFAICT, this is the only difference between what you are saying in your document and
what RFC2473 already says. Your document is saying that it is permissible to return a
PTB that reports a size smaller than 1280. But, that is currently reserved for IPv6/IPv4
translators.  Or, if you want to extend this feature to also apply to tunnels, you need
to also update RFC2473.

Either way, however, you are still not addressing the loss of PTB messages nor the
PTB forgery attack vector.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 17:20:38 +0000

Hi Ron,

> Sent: Tuesday, February 24, 2015 9:13 AM
> To: Joe Touch; Templin, Fred L; [email-masked]
> Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6
> 
> Joe,
> 

You are asking for Proposed Standards status. That goes beyond documenting
just "what is", and specifies once and for all "what will forever be".

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 09:23:53 -0800

> just "what is", and specifies once and for all "what will forever be".

This document will forever be "what is currently commonly used".

We've been around the block on "let's describe what SHOULD be, but isn't 
deployed". While I agree that's important, that is not the function of 
this document.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 17:35:27 +0000

Hi Joe,

> Sent: Tuesday, February 24, 2015 9:24 AM

There are two different intertwined issues that need to be teased apart.

First issue is that this document and RFC2473 are in the same boat in terms
of Fragmentation and MTU and the former should therefore cite the latter.
Or, if the former has more to say (e.g., sending PTB with a size less than
1280) then it should also update the latter.

Second issue is that both documents are susceptible to black holes if
PTB messages are lost. Take for example a source node on the far side
of the public Internet sending a too-large packet into a protected enclave
in which there is a GRE tunnel. The tunnel ingress drops the packet and
returns a PTB, but even though the tunnel is configured entirely within a
protected enclave the PTB message is vulnerable to loss within the
public Internet on the return path to the original source.

AFAICT the document is suggesting more reliance on PTB whereas I am
suggesting less.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 17:39:30 +0000

Joe,

Because RFC 2784 is PS, and this document UPDATES the procedures defined in RFC 2784, we have no choice but to ask for PS. (You can't UPDATE a PS with INFORMATIONAL).

So, I guess we have no choice other than to discuss what should be.

Please make your case that what we have in draft-ietf-intarea-gre-ipv6 is not what should be.

                                                                               Ron

> Sent: Tuesday, February 24, 2015 12:24 PM
> > You are asking for Proposed Standards status. That goes beyond
> > documenting just "what is", and specifies once and for all "what will forever
> be".
> 
> deployed". While I agree that's important, that is not the function of this
> document.
> 
> Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 17:44:30 +0000

Hi Ron,

> Sent: Tuesday, February 24, 2015 9:40 AM

The case is already made that the PTB messages this document relies on can be lost
or forged, resulting in a black hole or degenerate MTUs. So what should be is correct
continuous operation even when PTB messages are lost or forged.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 18:06:16 +0000

Fred,

The problems of PTB loss and forgery apply to IPv6 fragmentation in general. They are not specific to GRE tunneling. Therefore, they are beyond the scope of the current draft.

I invite you to a thought experiment. Imagine a network. At one end of the network is a GRE ingress and at the other end is a GRE egress. Both tunneled and non-tunneled traffic traverse the network.

The network drops ICMP PTBs. To make matters worse, somebody is forging ICMP PTBs. How do these impact tunneled packets differently from non-tunneled?

                                                                                                      Ron

> Sent: Tuesday, February 24, 2015 12:45 PM
> To: Ronald Bonica; Joe Touch; [email-masked]
> > Because RFC 2784 is PS, and this document UPDATES the procedures
> > defined in RFC 2784, we have no choice but to ask for PS. (You can't
> UPDATE a PS with INFORMATIONAL).
> >
> The case is already made that the PTB messages this document relies on can
> be lost or forged, resulting in a black hole or degenerate MTUs. So what
> should be is correct continuous operation even when PTB messages are lost
> or forged.
> 
> Thanks - Fred
> > > We've been around the block on "let's describe what SHOULD be, but
> > > isn't deployed". While I agree that's important, that is not the
> > > function of this document.
> > >
> > > Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 10:08:52 -0800

Hi, Ron,

> UPDATE a PS with INFORMATIONAL).

Sure.

> So, I guess we have no choice other than to discuss what should be.

I disagree. It's OK to have a PS focus on the currently deployed 
protocol, even if it updates another PS.

> Please make your case that what we have in
> draft-ietf-intarea-gre-ipv6  is not what should be.

I don't want to open that can of worms, and past experience with this WG 
is that they don't either.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 10:12:16 -0800

> Hi Joe,
...
> of Fragmentation and MTU and the former should therefore cite the latter.

I do agree on this point.

> 1280) then it should also update the latter.

That doesn't follow. This doc is about IPv6; it can surely augment the 
basic rules in another PS that describes an IPv4 mechanism without 
"UPDATING" that doc (i.e., it need not apply to IPv4).

> PTB messages are lost.

That may be good to point out, but it does not argue for changing what's 
in this doc. We have many protocols that are either incomplete or have 
land mines built-in; they are widely deployed and there's nothing wrong 
with documenting *what is deployed*.

When we do document what is deployed, we need to avoid addressing how to 
fix those issues, though.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 18:14:16 +0000

Hi Ron,

> Sent: Tuesday, February 24, 2015 10:06 AM
> To: Templin, Fred L; Joe Touch; [email-masked]
> The problems of PTB loss and forgery apply to IPv6 fragmentation in general. They are not specific to GRE tunneling. Therefore, they
> are beyond the scope of the current draft.
> 
> I invite you to a thought experiment. Imagine a network. At one end of the network is a GRE ingress and at the other end is a GRE
> egress. Both tunneled and non-tunneled traffic traverse the network.
> 

That is an end system problem, and for that we have RFC4821. End systems
have become conditioned to expect 1500 byte packets to be delivered or
a suitable PTB message returned. If the tunnel cannot guarantee that a
suitable PTB message can be returned, then it needs to do 1500 minimum.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 18:19:01 +0000

Hi Joe,

> Sent: Tuesday, February 24, 2015 10:12 AM

RFC2473 is about generic packet tunneling over IPv6 (not IPv4).

> with documenting *what is deployed*.

This document is going for proposed standard so, as Ron inferred, they are
trying to document "what is and what will forever be".

> fix those issues, though.

If the document is suggesting a long-term solution (which it seems to be,
according to Ron), then it needs to address how to fix the issues.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Feb 2015 10:27:42 -0800

...
> RFC2473 is about generic packet tunneling over IPv6 (not IPv4).

Mea culpa; I got the discussion threads mixed up.

RFC2473 is about IP* and other protocols over IPv6.

This doc is about GRE as both payload inside IPv6 and carrier of IPv6.

As a carrier of IPv6, this doc has nothing to do with RFC2473.

As payload inside IPv6, it does related to the general procedures in 
RFC2473, but because it is specific to GRE and RFC2473 never mentions 
GRE specifically, IMO it need not UPDATE that doc; it can exist in 
parallel to it, in a sense, as one of the carried protocols.

> trying to document "what is and what will forever be".

What is and forever will be - a snapshot of what is currently deployed.

> according to Ron), then it needs to address how to fix the issues.

That isn't what his last messages indicated; the focus is as a 
standards-track snapshot of what is deployed AFAICT.

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Feb 2015 19:04:40 +0000

Joe,

I fully agree. It *is* OK for a PS to focus on current implementation. In fact, RFC 2784 does exactly that! The current draft, because it is intended to UPDATE RFC 2784, explicitly inherits that tone.

So, let's avoid the conversation about how things should be. That conversation is not likely to converge soon.

                                                       Ron

> Sent: Tuesday, February 24, 2015 1:09 PM
> To: Ronald Bonica; Templin, Fred L; [email-masked]
> I disagree. It's OK to have a PS focus on the currently deployed protocol,
> even if it updates another PS.
> 
> I don't want to open that can of worms, and past experience with this WG is
> that they don't either.
> 
> Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Feb 2015 19:11:12 +0000

Hi Ron,

> Sent: Tuesday, February 24, 2015 11:05 AM
> I fully agree. It *is* OK for a PS to focus on current implementation. In fact, RFC 2784 does exactly that! The current draft, because it is
> intended to UPDATE RFC 2784, explicitly inherits that tone.
> 

I think that box has already been thrown open. Since I have done you the
favor of commenting on your draft it would seem reasonable to ask you
to also comment on mine.

Thanks - Fred

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Feb 2015 02:31:20 +0000

Fred,

On Feb 24, 2015, at 12:20 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ron,

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

RFC 2784, a Proposed Standard, does exactly what you say goes beyond what it should do (forever).

https://tools.ietf.org/html/rfc2784#section-1
   Finally this specification describes the intersection of GRE
   currently deployed by multiple vendors.

In other words, PS and “what is” are not conflicting.

— Carlos.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

                                                        Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 15:13:48 +0000

Hey Guys,

If you permit the tunnel ingress to send PTB with MTU<1280, the original
source will respond by sending subsequent packets with a fragment header
included so the ingress can fragment the payload packet (at least that is the
behavior expected by RFC2460, but not all hosts observe that). But, that is
exactly the behavior Fernando Gont is trying to deprecate in his “atomic
fragments” work. Then there are also others who want to deprecate IPv6
fragmentation altogether. I appreciate what you are going for, but there
are a number of factors that would appear to block it.

Thanks – Fred

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 6:31 PM
To: Templin, Fred L
Cc: Ronald P. Bonica; Joe Touch; [email-masked]
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Fred,

Hi Ron,

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred

                                                        Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Feb 2015 15:38:33 +0000

Fred,

void respond_to_thread(void) {
printf”Like RFC 2784, this specification describes GRE\n how has been implemented by several vendors.\n”;
}

Thanks,

— Carlos.
PS: Fixing PTBs and ICMPs for tunnels is great, but orthogonal to this draft. Maybe you want to start a new thread.
PSS: As mentioned already, let’s not hijack this thread and this document on the PTB and MTU manifestos.

On Feb 25, 2015, at 10:13 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hey Guys,

Thanks – Fred

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 6:31 PM
To: Templin, Fred L
Cc: Ronald P. Bonica; Joe Touch; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Fred,

Hi Ron,

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred

                                                        Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 15:42:59 +0000

Hi Carlos,

Responding to threads is made difficult by those who insist to use rich
text instead of plain text, but see below:

Fred
[email-masked]

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 7:39 AM
To: Templin, Fred L
Cc: Ronald P. Bonica; Joe Touch; [email-masked]
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Fred,

>>> Then, that would be an Informational; not a proposed standard.

}

Thanks,

— Carlos.

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred

                                                        Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Feb 2015 16:13:13 +0000

Fred,

On Feb 25, 2015, at 10:42 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Responding to threads is made difficult by those who insist to use rich
text instead of plain text,

For clarity, I am (like you) responding in multipart/alternative [1]. Feel free to tell your MUA to use the text/plain part, if that’s your preference (or be liberal in what you accept).

but see below:

but see below:

Fred
[email-masked]<mailto:[email-masked]>

Fred,

>>> Then, that would be an Informational; not a proposed standard.

Your inline broke the callback; however, the answer is in the “Like RFC 2784” part.

Thanks,

Carlos.

[1] https://tools.ietf.org/html/rfc2046#section-5.1.4

}

Thanks,

— Carlos.

Hey Guys,

Thanks – Fred

[…]

— Carlos.

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Feb 2015 16:42:15 +0000

Fred,

I can’t speak to Fernando’s work.

However, I can tell you with relative certainty that IPv6 fragmentation will not be deprecated until all transport layer protocols break their dependency upon it.

                                                                                                                                                       Ron

From: Templin, Fred L [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 10:14 AM
To: Carlos Pignataro (cpignata)
Cc: Ronald Bonica; Joe Touch; [email-masked]
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,

-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred

                                                        Ron

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 17:11:22 +0000

Carlos,

Using RTF to scold or to mock violates the sending side of the robustness principle.
But, what you are going for is informational – not standards-track.

Thanks – Fred

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 8:13 AM
To: Templin, Fred L
Cc: Ronald P. Bonica; Joe Touch; [email-masked]
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Fred,

Hi Carlos,

but see below:

but see below:

Fred

Fred,

Thanks,

Carlos.

}

Thanks,

— Carlos.

Hey Guys,

Thanks – Fred

[…]

— Carlos.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 17:16:03 +0000

Hi Ron,

Comments below:

Fred

From: Ronald Bonica [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 8:42 AM
To: Templin, Fred L; Carlos Pignataro (cpignata)
Cc: Joe Touch; [email-masked]
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Fred,

>>> That’s not good. If your design is based on atomic fragments and PTB
>>> with MTU<1280 you should be aware of the security implications.

>>> I think I already argued vigorously (with you, I think) that IPv6 fragmentation
>>> is absolutely required for RFC2473, at least. So, you won’t get any arguments
>>> from me there. There is also ‘draft-templin-aeromin’.

                                                                                                                                                       Ron

Cc: Ronald Bonica; Joe Touch; [email-masked]<mailto:[email-masked]>

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Feb 2015 17:24:00 +0000

Fred,

Having just read RFC 6946, I can’t see how that changes anything.

                                                                   Ron

From: Templin, Fred L [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 12:16 PM
To: Ronald Bonica; Carlos Pignataro (cpignata)
Cc: Joe Touch; [email-masked]
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Hi Ron,

Comments below:

Fred

Cc: Joe Touch; [email-masked]<mailto:[email-masked]>

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 17:41:07 +0000

Hi Ron,

See Section 5 of:

https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/

Thanks – Fred

Sent: Wednesday, February 25, 2015 9:24 AM

Fred,

                                                                   Ron

Hi Ron,

Comments below:

Fred

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Feb 2015 17:51:32 +0000

Fred,

This draft expires on Saturday. Do you know if Fernando intends to refresh it? Does it appear to have traction in 6man?

Even if this draft one day becomes an RFC, it wouldn’t change draft-ietf-intarea-gre-ipv6. It would only influence how people set the configuration option described at the bottom of Section 3.1.

                                                                                                               Ron

Sent: Wednesday, February 25, 2015 12:41 PM

Hi Ron,

See Section 5 of:

Thanks – Fred

Fred,

                                                                   Ron

Hi Ron,

Comments below:

Fred

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Feb 2015 21:25:22 +0000

Fred,

The approach taken by RFC 2473 is similar, but not identical to the approach taken by draft-ietf-intarea-gre-ipv6. Please compare the text in RFC 2473, Section 7.1.b to the corresponding text in Section 3.1 of draft-ietf-intarea-gre-ipv6.  They are different and need to remain different in order to accommodate future possibilities.

BTW, I think that this conversation may have come full circle. Do others on the mailing list think that it continues to be productive?

                                                                                                            Ron

Sent: Wednesday, February 25, 2015 4:01 PM

Hi Ron,

See below:

Thanks – Fred

Sent: Wednesday, February 25, 2015 11:52 AM

Fred,

I think that we have drifted off the topic of draft-ietf-intarea-gre-ipv6 and moved to a discussion of atomic fragments.

>>> Atomic fragments are really all that is interesting and different about draft-ietf-intarea-gre-ip6;
>>> otherwise, the considerations are no different than for RFC2473. So, if you don’t want to talk
>>> about atomic fragments please cite the RFC2473 text normatively.

                                                                                                                  Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 23:22:55 +0000

Hi Ron,

Somehow, the list choked on my last couple of messages so I will
convert to plaintext:

> The approach taken by RFC 2473 is similar, but not identical to the approach
> taken by draft-ietf-intarea-gre-ipv6. Please compare the text in RFC 2473,
> Section 7.1.b to the corresponding text in Section 3.1 of draft-ietf-intarea-gre-ipv6. 
> They are different and need to remain different in order to accommodate future
> possibilities.

Here is the difference:

>>>   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 is the part that would trigger atomic fragments if GMTU is less than
1280. Drop this, and you have RFC2473 exactly.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 00:01:43 +0000

Two of my messages to the list were blocked so I am converting to
plaintext and re-responding to Ron below. Ron, can you respond to
my points?

Thanks - Fred

> Does it appear to have traction in 6man?

I do not know. It was presented during 6man at one of the recent IETFs (last one
or the one before; don’t remember) and I argued against it because I think there
is value in retaining the RFC2460 text.

> Even if this draft one day becomes an RFC, it wouldn’t change
> draft-ietf-intarea-gre-ipv6. It would only influence how people set the
> configuration option described at the bottom of Section 3.1.

That would be a shame, because then the method would then revert
completely to RFC2473-mode. What makes your proposal interesting is
the opportunity for the tunnel ingress to fragment the payload packet
(instead of the delivery packet) which removes the reassembly burden
from the egress. However, it only works if you can somehow coax the
original source to include a fragment header which it seems
Fernando’s draft would prevent.

I have proposed  sending PTB with MTU less than 1280 before as well:

  http://www.ietf.org/archive/id/draft-templin-6man-linkadapt-01.txt

The idea is to enlist the original source’s aid in easing the frag/reass
burdens from the tunnel ingress and egress. It is similar to what you
are proposing, but did not say that the ingress could fragment the
payload packet. Rather, it wanted for the original source to do the
fragmentation.

However, there is one fundamental flaw in this entire line of
reasoning – it requires reliable and authentic delivery of PTB
messages in an unreliable and untrustworthy Internet.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 18:54:47 +0000

Hi Ron,

See below for rejoinders:

Thanks - Fred

Sent: Wednesday, February 25, 2015 9:52 AM

Fred,

                                                                                                               Ron

Hi Ron,

See Section 5 of:

Thanks – Fred

Fred,

                                                                   Ron

Hi Ron,

Comments below:

Fred

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Feb 2015 19:51:53 +0000

Fred,

                                                                                                                  Ron

Sent: Wednesday, February 25, 2015 1:55 PM

Hi Ron,

Thanks - Fred

Fred,

                                                                                                               Ron

Hi Ron,

See Section 5 of:

Thanks – Fred

Fred,

                                                                   Ron

Hi Ron,

Comments below:

Fred

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Feb 2015 21:00:45 +0000

Hi Ron,

See below:

Thanks – Fred

Fred,

                                                                                                                  Ron

Hi Ron,

Thanks - Fred

Fred,

                                                                                                               Ron

Hi Ron,

See Section 5 of:

Thanks – Fred

Fred,

                                                                   Ron

Hi Ron,

Comments below:

Fred

Fred,

                                                                                                                                                       Ron

Hey Guys,

Thanks – Fred

Fred,

Hi Ron,
-----Original Message-----
From: Ronald Bonica [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 9:13 AM
To: Joe Touch; Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [Int-area] draft-ietf-intarea-gre-ipv6

Joe,

— Carlos.

Thanks - Fred
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, February 24, 2015 11:24 AM
To: Templin, Fred L; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 15:22:30 +0000

Hi Ron,

> - Fragment the delivery header

There is a third option:

  - Fragment the delivery header and also send an ICMP PTB (subject to
    rate limiting)

In other words, the packet gets through and the original source gets a PTB
message indicating that future packets should include a fragment header.
That is what I was saying in 'draft-templin-6man-linkadapt', which you might
want to look at.

In this way, even if the PTB message is lost 1280byte packets will still be
delivered successfully as per any IPv6 link. When PTBs get through, however,
you get a useful optimization.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Feb 2015 14:10:35 -0800

On 2/25/2015 4:01 PM, Templin, Fred L wrote:
...
> burdens from the tunnel ingress and egress.

IMO, PTB is the wrong message for that.

We don't have a good one to express "preference" vs absolute capability; 
PTB is absolute capability, and I don't agree that it should be abused 
this way.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 23:00:55 +0000

Hi Joe,

> Sent: Thursday, February 26, 2015 2:11 PM
> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
> Cc: [email-masked]

What we have today is a "Type 0" PTB message. What I proposed was a
"Type 1" PTB message.

"Type 0" PTB is the network's way of saying "the message is too big to
deliver", while "Type 1" PTB is the network's way of saying "the message
is not too big to deliver, but it is painful". So, having the tunnel ingress
send a "Type 1" PTB message to the original source is a way to enlist
the source's aid in reducing the pain.

> PTB is absolute capability, and I don't agree that it should be abused

"Type 0" PTB is about absolute capacity, yes, and so it should not be sent
for sizes smaller than 1280 (because the tunnel ingress is required to pass
at least 1280 even if some fragmentation is needed). "Type 1" PTB is about
preference - sort of like a "quench" message. It is the network's way of
saying to the source: "You are causing me pain which in the long run will
also cause you pain. So, please help ease the pain."

Thanks - Fred

PS A legacy node that mistakes a "Type 1" PTB for a "Type 2" PTB will
    harmlessly begin sending packets as atomic fragments. The tunnel
    ingress can then fragment the payload packet, and an optimization
    will still be realized.

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Feb 2015 15:10:48 -0800

On 2/26/2015 3:00 PM, Templin, Fred L wrote:
> What we have today is a "Type 0" PTB message.

There are may types for both IPv4 and IPv6.

For IPv4, e.g., PTB is type 3, code 4.

For IPv6, it would be type 2, code 0.

> What I proposed was a "Type 1" PTB message.

For IPv6, did you mean type 2, code 1?

The problem is that legacy receivers will interpret type 2 and ignore 
the code.

If you want a new kind of message that is a "soft" "too big", you'd need 
to define a new type.

Regardless of how it's created, you're talking about a new message, and 
that's out of scope for this doc (and this thread).

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 23:32:35 +0000

Hi Joe,

> Sent: Thursday, February 26, 2015 3:11 PM

"type 2, code 0" is what I meant when I said "Type 0", yes.

> For IPv6, did you mean type 2, code 1?

Yes; "type 2, code 1" is what I meant when I said "Type 1".

> The problem is that legacy receivers will interpret type 2 and ignore

Yes, but I do not see a problem. If the size reported in the PTB is less than
1280 the source will send subsequent messages as "atomic fragments" per
Section 5 of RFC2460. The tunnel ingress will then know that it is dealing
with a legacy source, and will fragment the payload packet using the
fragment header conveniently provided by the source.

> If you want a new kind of message that is a "soft" "too big", you'd need

I don't agree, since legacy sources will not be harmed and will in fact
still benefit if they fail to distinguish the two message codes.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 10:04:51 -0800

On 2/26/2015 3:32 PM, Templin, Fred L wrote:
> Section 5 of RFC2460.

Or pick another path. Or break.

That's a code path that isn't commonly exercised.

> The tunnel ingress will then know that it is dealing
> with a legacy source,

Hosts already generate atomic fragments for other reasons, so that 
itself isn't enough to "KNOW" anything.

> and will fragment the payload packet using the

That's a violation of on-path fragmentation. RFC2460 gives a very 
specific reason for those - focusing on IPv6/IPv4 translation:

    ...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 that the
    IPv6-to-IPv4 translating router can obtain a suitable Identification
    value to use in resulting IPv4 fragments.

We could argue that this should apply to how fragments tunneled to guide 
fragmentation and reassembly in the encapsulating layer (e.g., the 
"outer" header), but not to fragment the packet that arrives.

However, all of this is out of scope of the doc we're currently discussing.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 18:25:06 +0000

Hi Joe,

> Sent: Friday, February 27, 2015 10:05 AM

I don't see anything in the standards that would support either of those
behaviors. A node that does not handle PTB with MTU<1280 as specified
in Section 5 of RFC2460 is not compliant with the standards.

> That's a code path that isn't commonly exercised.

If that code path is exercised, then the node is shooting itself in the foot
because it is not standards-compliant.

> itself isn't enough to "KNOW" anything.

Generation of atomic fragments for any reason is sufficient information
for the tunnel ingress to make a determination to fragment or drop
based on the size of the atomic fragment. If the atomic fragment is no
larger than the tunnel MTU, encapsulate  and send unfragmented. Else,
if the atomic fragment is no larger than 1500, fragment to the tunnel
MTU size. Else, drop and send PTB with code=0.

>     value to use in resulting IPv4 fragments.

It should not be so much of a stretch to update RFC2460 to allow tunnels
to use the supplied fragment header to fragment the original packet.
After all, it was the original source itself that supplied the fragment
header including an Identification value of the source's own choosing.

> "outer" header), but not to fragment the packet that arrives.

Why not? The original source included a good fragment header with
a good Identification value. Having the tunnel ingress fragment it would
be exactly the same as if the original source had fragmented it on its own
behalf.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 10:33:25 -0800

On 2/27/2015 10:25 AM, Templin, Fred L wrote:
...
> in Section 5 of RFC2460 is not compliant with the standards.

Breaking is what happens when we rely on a code path we don't typically 
use. Yes, it's not compliant.

Nothing in IP REQUIRES an endpoint to "try harder" when it gets an error 
message, though. It can always either give up or try another path - 
that's compliant.

> based on the size of the atomic fragment.

The former is a direct violation of RFC2460. The latter is what 
could/should have been done in the first place when the PTB was sent.

> to use the supplied fragment header to fragment the original packet.

It's a huge stretch to change IPv6 from "never fragment on-path" to 
"fragment on-path".

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 18:45:35 +0000

Hi Joe,

> Sent: Friday, February 27, 2015 10:33 AM

I agree; shooting its own foot because it does not follow the standards is
something we can't do anything about. But, then it is broken and needs
to get itself fixed.

> could/should have been done in the first place when the PTB was sent.

Network fragmentation of IPv6 packets that do not include a fragment
header is the behavior that is prohibited by the specs. Fragmentation
of IPv6 packets that include a fragment header is already mandated
for IPv6/IPv4 translators. So, given there is already one example of
network fragmentation we are simply introducing another example.

> It's a huge stretch to change IPv6 from "never fragment on-path" to

"Fragment on-path" is already mandated for IPv6/IPv4 translators. We
are only asking for the same behavior for IPv6 tunnels. It will work right
out of the box, so why not just do it and update RFC2460 to note the
behavior?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 13:58:18 -0800

...
> network fragmentation we are simply introducing another example.

If you use the atomic fragment ID to generate an ID for the tunnel 
encapsulation and fragment THAT, yes.

If you intend to fragment the atomic arriving datagram, no. That's not 
what the atomic ID is for - it is intended to provide an identifier for 
the tunnel, not to allow on-path fragmentation of the original datagram.

...
> "Fragment on-path" is already mandated for IPv6/IPv4 translators.

No; that's fragmenting at IPv4, i.e., the outer header. That's always 
been allowed.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 22:16:39 +0000

Hi Joe,

> Sent: Friday, February 27, 2015 1:58 PM

No, that is not correct. The ID supplied by the original source applies
to the payload packet; not the delivery packet. The tunnel ingress must
supply its own ID for the delivery packet, and it must not be based on
the ID supplied by the original source.

> the tunnel, not to allow on-path fragmentation of the original datagram.

No, the ID supplied by the original source applies to the payload packet;
not the delivery packet.

> No; that's fragmenting at IPv4, i.e., the outer header. That's always

Ah, here is the source of the confusion. IPv6/IPv4 translators do not use
encapsulation so there is no such thing as an outer header. The translator
"translates" the IPv6 header into an IPv4 header and so the packet remains
as a payload packet and does not include any "outer header". So, the ID
supplied by the original source applies to the payload packet even after
the translator has performed v6/v4 translation.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 15:01:48 -0800

On 2/27/2015 2:16 PM, Templin, Fred L wrote:
> encapsulation so there is no such thing as an outer header.

I would argue there's no such thing as an inner header.

When you translate from one to another, you take OFF the IPv6 header and 
add the IPv4 one.

That's never confused as IPv6 on-path fragmentation because the receiver 
is now IPv4.

I.e., this is consistent with IPv4 allowing on-path fragmentation, and 
consistent with IPv6 never fragmenting on-path.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 23:22:40 +0000

Hi Joe,

> Sent: Friday, February 27, 2015 3:02 PM

Right, per the correction I supplied in my last message.

> consistent with IPv6 never fragmenting on-path.

You are being dogmatic for no good reason. If a tunnel ingress is handed
an atomic fragment with a good ID, then it should fragment the packet if
necessary. It is just as if the original source had fragmented the packet itself.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 15:35:04 -0800

...
> You are being dogmatic for no good reason.

RFC2460 forbids it *explicitly*.

That's a good reason.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 23:50:36 +0000

Hi Joe,

> Sent: Friday, February 27, 2015 3:35 PM

You are still being too dogmatic. For atomic fragments, the situation is no
different than for an IPv6/IPv4 translator. In fact, it is even better because
the IPv6 tunnel ingress knows that the final destination is required to
reassemble at least 1500. For an IPv6/IPv4 translator on the other
hand, all the translator is assured is 576.

I do not see any "MUST NOTs" in RFC2460, nor any dire consequences for
allowing a tunnel ingress to fragment atomic fragments. So, if we update
the final paragraph of Section 5 of RFC2460 we should be good to go.

Thanks - Fred

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 28 Feb 2015 00:13:21 +0000

Guys,

I would like to suggest that this discussion is beyond the scope of draft-ietf-intarea-gre-ipv6. The chairs may correct me, but it might even be outside the scope of this WG.

                                                                                   Ron

> Sent: Friday, February 27, 2015 6:51 PM
> To: Joe Touch; Ronald Bonica; Carlos Pignataro (cpignata)
> Cc: [email-masked]
> > >> I.e., this is consistent with IPv4 allowing on-path fragmentation,
> > >> and consistent with IPv6 never fragmenting on-path.
> > >
> reassemble at least 1500. For an IPv6/IPv4 translator on the other hand, all
> the translator is assured is 576.
> 
> allowing a tunnel ingress to fragment atomic fragments. So, if we update the
> final paragraph of Section 5 of RFC2460 we should be good to go.
> 
> Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 16:38:51 -0800

On 2/27/2015 3:50 PM, Templin, Fred L wrote:
...
> the final paragraph of Section 5 of RFC2460 we should be good to go.

    On any link that cannot convey a 1280-octet
    packet in one piece, link-specific fragmentation and reassembly must
    be provided at a layer below IPv6.

also:
    (Note: unlike
    IPv4, fragmentation in IPv6 is performed only by source nodes, not by
    routers along a packet's delivery path -- see section 5.)

So you're talking about updating RFC2460 to allow on-path fragmentation 
of source fragments. I disagree with that, for the same reasons it was 
omitted from IPv6 in the first place.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Feb 2015 16:39:55 -0800

> I would like to suggest that this discussion is beyond the scope of draft-ietf-intarea-gre-ipv6. The chairs may correct me, but it might even be outside the scope of this WG.

Oh, I certainly agree it's outside the scope of this doc.

IMO, it's clearly within the scope of the WG to discuss this issue in 
general, but I'll stop until others jump in and suggest it's a useful 
way to go. I don't think it is.

Joe

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 28 Feb 2015 14:51:58 -0500

Hi Ron,

> I would like to suggest that this discussion is beyond the scope of draft-ietf-intarea-gre-ipv6. The chairs may correct me, but it might even be outside the scope of this WG.

Agree with you that the discussion is out of scope for the draft. I 
think it is may or may not be in the scope of the wg depending on what 
actions may be required. 6man may be a better home depending on what 
people are aiming to change.

Thanks
Suresh