Subject: Re: "Deprecate"

From: RJ Atkinson <[email-masked]>
Date: Thu, 1 Aug 2013 10:35:20 -0400

On Tuesday 30th July, Ron Bonica wrote, in part:
> I think that we heard the following at yesterday's meeting:
> 
> Title
> =====
> The document should be renamed "IPv6 Fragmentation Considered Ineffective"

That is an improvement because it more accurately describes 
the content of the draft.

One might also consider a title that reframed it in terms
of advice to application designers.

> Deprecation
> ===========
> All instances of the word "deprecate" should be removed
> from the document.
>  
>    Therefore:
> -- The document should not request any IANA actions
> -- The document doesn't UDPDATE 2460
> -- The document doesn't need to be PS. BCP is good enough

Agree with all of the above.
Either BCP or Informational is fine.

> Recommendation
> ===============
> The Recommendation section should be renamed "Conclusion".
> It should include the following statements:
> 
> - The IETF SHOULD NOT standardize an new protocols that
>   rely on IPv6 fragmentation

I think we should allow the IESG/IETF more leeway to handle
situations currently unforeseen.

So I would suggest an edit along these lines:

s/rely on IPv6 fragmentation/rely on IPv6 fragmentation if a 
practical alternative to fragmentation exists for that protocol./

> ---*New* applications and transport layer protocols SHOULD support
> effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is unreliable

Neither approach is 100% reliable in the most general case.

So, I'd suggest that new apps and transport-layer protocols 
SHOULD support both PLMTUD and ICMP-based PMTUD.  Supporting 
both enhances the chances that some form of Path MTU Discovery 
will work for a given session.

> --*New* applications or transport layer protocols that cannot
> support effective PMTUD MUST NOT in any circumstances send IPv6
> packets that exceed the IPv6 minimum MTU of 1280 bytes.

I would change s/MUST NOT/SHOULD NOT/. 

I'd delete the phrase "of 1280 bytes" as well,
mainly because it is redundant, and partly so
that this BCP would not need updating if the 
1280 number changed in future.  (It has already
changed from unspecified to 576 to 1280 over time.)

This document is all good advice, but I know of multiple IPv6 
deployments where PMTUD works quite well.  If an application 
is deployed in such an environment, and knows that it is 
(e.g. some locally-developed application as different from 
a standard application such as HTTP), then the application 
ought to be able to use the IETF standards-track PMTUD mechanism
without violating other IETF standards-track specifications.

> - Legacy applications and transport layer protocols will continue
>   to generate fragments

Since this is basically a document with lots of good advice, 
I'd also add some very clear and specific recommendations that 
middleboxes and firewalls:

A) MUST NOT block ICMP-based PMTUD messages where the indicated
   link MTU is equal-to or greater-than the standard IPv6 minimum
   link MTU.

B) SHOULD NOT block ICMP-based PMTUD messages where the indicated
   link MTU is less than the standard IPv6 minimum link MTU in order
   to avoid breaking real-world nested tunnel deployments using
   IETF standards-track technologies.

Discussion:
   Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode,
   or some other IETF specified technology, are NOT going away.  If
   the physical MTU is 1280, then the tunnel MTU will be smaller.
   Nested tunnels are not unusual and can be difficult to detect
   absent a working PMTUD mechanism (whatever that might be).

   Tunnel-based deployments are just as real, and just as unlikely
   to disappear, as the current issues with PMTUD deployments.  The
   document should be clear about this.

> --- In the interest of backwards compatibility, IPv6 stacks and forwarding
> nodes MUST continue to support inbound fragmented IPv6 packets as specified
> in [RFC2460].

Yes.  In particular, receiving hosts will need to continue to support
IPv6 fragment reassembly for sessions terminating at such hosts.  

> - Implementers and operators need to be aware that on many paths through
> the Internet, IPv6 fragmentation will fail. Legacy applications and transport
> layer protocols that do not conform to the previous paragraph can expect connectivity failures as a result.

s/can expect/might experience/

We don't want to use words that a naive reader/implementer
would misinterpret as consent for violating RFC-2460 et seq.

> --- Therefore, if a legacy protocol is capable of breaking its
> dependence on IPv6 fragmentation, it should consider doing so.

Agreed.

Yours,

Ran

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 2 Aug 2013 07:58:16 +0000

Hi Ran,

Thanks for the review. Comments inline.....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> RJ Atkinson
> Sent: Thursday, August 01, 2013 4:35 PM
> To: [email-masked]
> Subject: Re: "Deprecate"
> 
> That is an improvement because it more accurately describes the content
> of the draft.

Agree. I think that we should go with Brian's proposed title.

> 
> One might also consider a title that reframed it in terms of advice to
> application designers.
> 
> > Deprecation
> > ===========
> > All instances of the word "deprecate" should be removed from the
> > document.
> >
> >    Therefore:

Agree

> I think we should allow the IESG/IETF more leeway to handle situations
> currently unforeseen.
> 
> s/rely on IPv6 fragmentation/rely on IPv6 fragmentation if a practical
> alternative to fragmentation exists for that protocol./

Also agree. Furthermore, we can now make clear that the two following statements regarding *New* applications offer practical alternatives. These are a) PMTUD/PLMTUD and b) short PDUs

> So, I'd suggest that new apps and transport-layer protocols SHOULD
> support both PLMTUD and ICMP-based PMTUD.  Supporting both enhances the
> chances that some form of Path MTU Discovery will work for a given
> session.
> 

How about MUST support PMTUD and SHOULD support PLMTUD, just in case ICMP PTB is filtered. This statement would make most currently deployed TCP stacks compliant. So, if a new protocol runs over TCP, it is compliant.

> > --*New* applications or transport layer protocols that cannot support
> > effective PMTUD MUST NOT in any circumstances send IPv6 packets that
> > exceed the IPv6 minimum MTU of 1280 bytes.
> 
> I'd delete the phrase "of 1280 bytes" as well, mainly because it is
> redundant, and partly so that this BCP would not need updating if the
> 1280 number changed in future.  (It has already changed from
> unspecified to 576 to 1280 over time.)

I think that MUST is OK, so long as we are clear that we are talking about an application for which IP fragmentation has already been ruled out.

> deployments where PMTUD works quite well.  If an application is
> deployed in such an environment, and knows that it is (e.g. some
> locally-developed application as different from a standard application
> such as HTTP), then the application ought to be able to use the IETF
> standards-track PMTUD mechanism without violating other IETF standards-
> track specifications.

Ack.

> Since this is basically a document with lots of good advice, I'd also
> add some very clear and specific recommendations that middleboxes and
> firewalls:
> 

I would say that ICMP PTB messages MUST never be blocked, even if the MTU is small. RFC 2460 specifies one corner case where the MTU can be small.

>    document should be clear about this.

Yes. Currently the section on Tunnels contains one word of text, "TBD". I will fix that in the next revision.

> 
> > --- In the interest of backwards compatibility, IPv6 stacks and
> > forwarding nodes MUST continue to support inbound fragmented IPv6
> > packets as specified in [RFC2460].
> 

Agree

> 
> > - Implementers and operators need to be aware that on many paths
> > through the Internet, IPv6 fragmentation will fail. Legacy
> > applications and transport layer protocols that do not conform to the
> previous paragraph can expect connectivity failures as a result.
> 

OK

                        Ron

> 
> We don't want to use words that a naive reader/implementer would
> misinterpret as consent for violating RFC-2460 et seq.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 02 Aug 2013 10:48:12 +0200 (CEST)

> the content of the draft.

I'm not entirely certain I agree.  The suggested title indicates
admittance of defeat against mis-configured middleboxes and over-
paranoid network administrators, and an implicit willingness to
surrender the authority to define our protocols.

I'm at the moment not entirely certain I have a suggested
alternative title; I may need to give that a bit of thought.
Something perhaps about "deployment considerations"?

>    IETF standards-track technologies.

Yes, please, thank you!

Much throughout this discussion there seems to have been a lack
of will to retain the authority to define the protocols with the
IETF, and I see the above two points as good steps to amend that on
this particular issue.

>>   applications and transport layer protocols that do not conform to
>>   the previous paragraph can expect connectivity failures as a
>>   result.
>

For basically the same reasons as above, I agree with this change.

Best regards,

- Håvard

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Aug 2013 08:34:27 -0400

On 02  Aug 2013, at 03:58 , Ronald Bonica wrote:
> Furthermore, we can now make clear that the two following
> statements regarding *New* applications offer practical
> alternatives.
> 
> These are:
> a) PMTUD/PLMTUD
> and b) short PDUs

Agree.  I am reluctant to say that any of those are sufficient
in all deployments, because there are too many IPv6 deployments
to evaluate, but clearly each of those mechanisms can be useful.

> How about:
>    MUST support PMTUD and SHOULD support PLMTUD,
> just in case ICMP PTB is filtered.

Fine.  "MUST support PMTUD" and "SHOULD support PLMTUD".

> I think that MUST is OK, so long as we are clear that we are talking
> about an application for which IP fragmentation has already been
> ruled out.

I'd like to read the draft text in an I-D first.

> I would say that ICMP PTB messages MUST never be blocked,
> even if the MTU is small. RFC 2460 specifies one corner case
> where the MTU can be small.

Agree.  Fernando has identified some scenarios where the advertised 
MTU will be smaller than 1280.  Additionally, I've seen some other 
real-world scenarios where it happens.

So, I'd suggest that the document outline several scenarios where
the MTU can be small, so that implementers and operators reading
the document will realise that smaller MTUs can appear in the wild.

> Yes. Currently the section on Tunnels contains one word of text,
> "TBD".  I will fix that in the next revision.

From an implementation perspective, most often it is expensive
& complex for a tunnel endpoint reassemble transit fragments.  

In the current global Internet, few router implementers are 
comfortable trying to reassemble anywhere in the middle of the 
path,  in part because of the additional attack surface that
reassembling transit traffic would create.

Instead, at tunnel egress, any fragments are likely to be 
merely decapsulated and then forwarded.  So, it is critical 
that end systems be able to reassemble fragments as fragments 
will continue to exist in the real world.

Yours,

Ran

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 Aug 2013 11:14:45 +0200

Ran,

> will continue to exist in the real world.

that would also be a significant change in the IPv6 architecture.
IPv6 over IPv6 tunnels do outer fragmentation today (RFC2473) and tunnel egress must perform reassembly.

cheers,
Ole

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 5 Aug 2013 17:16:14 -0400

> that would also be a significant change in the IPv6 architecture.

Actually, suggesting that hosts need to be able to perform
reassembly (which what I was suggesting) is NEITHER an 
architectural change NOR a change to existing IPv6 host requirements, 
because IPv6 hosts ALREADY have to be able to reassemble an IPv6 
packet from fragments.

For example, consider that an original NFS/UDP/IPv6 frame might be 
larger than link MTU (e.g. in a tunnelled environment with some 
DSL/PPPoE encapsulation overhead), relying upon IPv6 fragmentation 
inside the originating host to be sent through to the destination 
host.

At the point that a receiving host is receiving fragments, each
received fragment will have an IPv6 Fragmentation Header.  The
process of reassembly within a destination is identical,
regardless of who sent the packet to that receiver.  

Kindly note that I have implementation experience with this 
in 4.4 BSD, in Cisco IOS, and in another IPv6 implementation.  
The receiving system's reassembly procedure does not care why 
it is receiving fragments, and does not need to care why, 
because the reassembly process is identical.  Reassembly is 
computationally expensive, of course, which is why I earlier said 
I thought it desirable to pursue the ideas from C.M. Heard et alia.

RFC-2460 covers reassembly by hosts in a lot of detail, 
primarily in Section 4.5, but also in other places.  
There can be no doubt that IPv6 hosts already are
required to be able to perform IPv6 fragment reassembly.

Some example text fragments (supporting the notion that IPv6
hosts ALREADY need to support reassembly) from RFC-2460 follow...

RFC-2460, page 18:
	"In order to send a packet that is too large to fit 
	in the MTU of the path to its destination, a source node 
	may divide the packet into fragments and send each fragment 
	as a separate packet, to be reassembled at the receiver."

RFC-2460, page 21:
	"At the destination, fragment packets are reassembled 
	into their original, unfragmented form, as illustrated:
	..."

RFC-2460, page 24:
	"In order to send a packet larger than a path's MTU, a node 
	may use the IPv6 Fragment header to fragment the packet at 
	the source and have it reassembled at the destination(s).  
	However, the use of such fragmentation is discouraged in any 
	application that is able to adjust its packets to fit the 
	measured path MTU (i.e., down to 1280 octets).

RFC-2460, page 25:
	"A node must be able to accept a fragmented packet that, 
	after reassembly, is as large as 1500 octets.  A node is 
	permitted to accept fragmented packets that reassemble 
	to more than 1500 octets.  An upper-layer protocol or 
	application that depends on IPv6 fragmentation to send 
	packets larger than the MTU of a path should not send packets 
	larger than 1500 octets unless it has assurance that the 
	destination is capable of reassembling packets of that 
	larger size."

Yours,

Ran Atkinson

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2013 12:52:44 +0200

> because IPv6 hosts ALREADY have to be able to reassemble an IPv6 

the significant change to the architecture in your proposal, is that intermediate routers (in this case the tunnel ingress)
are allowed to fragment packets.

cheers,
Ole

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 6 Aug 2013 13:06:04 -0400

On 06  Aug 2013, at 06:52 , Ole Troan wrote:
> the significant change to the architecture in your proposal,
> is that intermediate routers (in this case the tunnel ingress)

That is a misunderstanding of what I wrote.

Tunnel ingress devices already are allowed to fragment 
IPv6 packets by various IETF approved tunnelling 
specifications, as you have agreed.  

To be VERY clear, I am not proposing ANY change to specs.
If one thinks I have proposed a specification change,
that is a misunderstanding.

I am simply observing that end systems ALREADY are required
to support IPv6 fragment reassembly -- e.g., for reasons 
unrelated to tunnels.

Yours,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Aug 2013 17:21:09 +0000

> specifications, as you have agreed.

Fragmentation of the inner packet before encapsulation is different
from fragmentation of the outer packet after encapsulation. Ole was
referring to the latter case, where the tunnel ingress is acting as
a host when it fragments the encapsulated packet and the tunnel
egress gets to reassemble.

The tunnel MUST uphold the IPv6 minMTU of 1280; otherwise, it would
be a degenerate link. The tunnel SHOULD allow larger packets through
when it can do so without resulting in an MTU-related black hole;
otherwise, it would fail to take advantage of larger path MTUs when
they are available. And, the whole thing needs to work when ICMP
PTBs are unavailable.

This discussion is coming full circle to what we discussed earlier
when we already established that tunnels MUST support the IPv6
minMTU even if some fragmentation and reassembly is necessary.

Thanks - Fred
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 6 Aug 2013 20:49:58 -0400

On 06  Aug 2013, at 13:21 , Templin, Fred L wrote:
> Fragmentation of the inner packet before encapsulation
> is different from fragmentation of the outer packet after
> encapsulation. 

I've coded this for IPv6.  It is the SAME fragmentation 
code AND the SAME reassembly code for both cases.

The operational scenarios can and do vary, but the 
code path (and the specification for how to perform it) 
are IDENTICAL - not DIFFERENT.

> ...
> This discussion is coming full circle...

(I agree this sub-thread is looping.  So can we please
let this rest on grounds that no one has proposed any
specification change ?   :-)

Yours,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Aug 2013 14:55:32 +0000

Hi Ran,

> Sent: Tuesday, August 06, 2013 5:50 PM
> To: [email-masked]
> Subject: Re: "Deprecate"
> 
> 

I have coded fragmentation and reassembly code too. Many of
the readers of this list have as well, so I don't know that
you can claim to be uniquely qualified to speak on this point.
 
> specification change ?   :-)

SEAL is proposed. SEAL addresses tunnel and transport mode
operation in environments where ICMP PTBs may be absent or
untrustworthy.

Thanks - Fred