Subject: "Deprecate"

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 29 Jul 2013 14:32:45 +0000

At the mike a moment ago, I referred to an existing formal definition of "deprecate". For the record, the reference is to RFC 1158, which reads:

3.1.  Deprecated Objects

   In order to better prepare implementors for future changes in the
   MIB, a new term "deprecated" may be used when describing an object.
   A deprecated object in the MIB is one which must be supported, but
   one which will most likely be removed from the next version of the
   MIB (e.g., MIB-III).

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2013 05:19:21 +0200

> At the mike a moment ago, I referred to an existing formal definition
> of "deprecate".

welll, you keep saying it is a formal definition, implying that it
applies to all uses of the term.  but, in fact, the reference is merely
how it is used in some snmp glorp.

otoh, the draft under abuse, could indeed be more specific.

randy

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Jul 2013 08:17:22 +0200

> how it is used in some snmp glorp.

A example of deprecation that is close to what we are discussing regarding fragmentation can be found in:

RFC3879  Deprecating Site Local Addresses

   4.  Deprecation

   This document formally deprecates the IPv6 site-local unicast prefix
   defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10.  The
   special behavior of this prefix MUST no longer be supported in new
   implementations.  The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action.  Future versions of the
   addressing architecture [RFC3513] will include this information.

   However, router implementations SHOULD be configured to prevent
   routing of this prefix by default.

Bob

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2013 08:52:57 +0200

>    implementations.

hmmm.  i am gonna put my foot in the cow pie.
i think what we want here is something close to
  o future implementations SHOULD not generate frags
    (note that SHOULD != MUST)
  o expect to receive frags for a long time

randy

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 30 Jul 2013 08:34:04 +0000

Folks,

I think that we heard the following at yesterday's meeting:

Title
=====
The document should be renamed "IPv6 Fragmentation Considered Ineffective"

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

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
---*New* applications and transport layer protocols SHOULD support effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is unreliable
--*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.

- Legacy applications and transport layer protocols will continue to generate fragments
--- In the interest of backwards compatibility, IPv6 stacks and forwarding nodes MUST continue to support inbound fragmented IPv6 packets as specified in [RFC2460].

- 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.
--- Therefore, if a legacy protocol is capable of breaking its dependence on IPv6 fragmentation, it should consider doing so.

Did I miss anything?

                        Ron

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jul 2013 10:38:55 +0200

>   o expect to receive frags for a long time

My understanding was that the goal was:

* New applications should avoid fragmentation where possible
* Hosts must still be able to fragment and reassemble
* Beware that some networks filter fragments

i.e., we're not arguing about removing any functionality from nodes
(whether current or new implementations), nor we're advising networks to
drop fragments.

-- i.e., something along the lines of what we did in RFC 6093 for the
TCP urgent mechanism.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 30 Jul 2013 08:42:06 +0000

I mostly agree. Some fuzz.

> The document should be renamed "IPv6 Fragmentation Considered Ineffective"

"Ineffective" has to be modified by "for some specific purpose". Is it ineffective at getting packets through end to end? Ineffective at getting through firewalls? What?

> Deprecation

I'm a little concerned by this. I understand it, I think, but ...

So, then the IETF should not standardize RTP or any protocol (voice, video, ...) that uses it, because RTP relies on its application to manage frame size, and we can't say specifically what the codec will do? s/RTP/UDP/?

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

That I agree with.

>>  o expect to receive frags for a long time

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jul 2013 10:49:31 +0200

Hi, Ron,

> - Legacy applications and transport layer protocols will continue to
> generate fragments --- In the interest of backwards compatibility,
> IPv6 stacks and forwarding nodes MUST continue to support inbound
> fragmented IPv6 packets as specified in [RFC2460].

I'm not sure I'd use RFC2119 language, since support for fragmentation
is std track -- hence recommending something in this respect would be
more std track than bcp.

Besides, if you mention support for reassembly, you should also mention
support for fragmentation.

Otherwise, I fully agree with your proposed way forward.

Thanks,

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 30 Jul 2013 09:02:46 +0000

Sure!

s/MUST/will/

        ron

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 10:50 AM
> To: Ronald Bonica
> Cc: Randy Bush; Bob Hinden; IPv6 Maintanence; Fred Baker (fred)
> Subject: Re: "Deprecate"
> 
> Hi, Ron,
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 30 Jul 2013 09:21:39 +0000

Inline.....

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Tuesday, July 30, 2013 10:42 AM
> To: Ronald Bonica
> Cc: Randy Bush; Bob Hinden; IPv6 Maintanence
> Subject: Re: "Deprecate"
> 
> "Ineffective" has to be modified by "for some specific purpose". Is it
> ineffective at getting packets through end to end? Ineffective at
> getting through firewalls? What?
> 

How about "IPv6 Fragmentation Considered Ineffective for End-to-end Transport"?

> > ---*New* applications and transport layer protocols SHOULD support
> > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is
> > unreliable
> > --*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.
> 
> So, then the IETF should not standardize RTP or any protocol (voice,
> video, ...) that uses it, because RTP relies on its application to
> manage frame size, and we can't say specifically what the codec will
> do? s/RTP/UDP/?
> 

Thinking a little more about it, RTP and UDP aren't the real culprits. The culprits are the applications that run over them. So, we should limit our statement to applications, and not "applications and transport layer protocols".

                                          Ron

> > generate fragments
> > --- In the interest of backwards compatibility, IPv6 stacks and
> forwarding nodes MUST continue to support inbound fragmented IPv6
> packets as specified in [RFC2460].
> >
> > - 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.
> 
> > --- Therefore, if a legacy protocol is capable of breaking its
> dependence on IPv6 fragmentation, it should consider doing so.
> 
> That I agree with.
> 
> > Did I miss anything?
> >
> >                        Ron
> >
> >
> >>
> >> i think what we want here is something close to  o future
> >> implementations SHOULD not generate frags

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2013 13:52:59 +0200

> How about "IPv6 Fragmentation Considered Ineffective for End-to-end

ipv6 fragmentation does not work reliably on the internet and is highly
unlikely to do so in your career's lifetime.

yes, pmtud is the right thing, but it can not be relied on.  get over
it.

> Thinking a little more about it, RTP and UDP aren't the real culprits.
> The culprits are the applications that run over them. So, we should
> limit our statement to applications, and not "applications and
> transport layer protocols".

one wednesdays if they're pink.

ip frags are not gonna work reliably no matter what generates them.
it's annoying.  it's a damned shame.  but it's reality.  get over it.

randy

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Jul 2013 14:46:34 +0000

Hi Ron,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ronald Bonica
> Sent: Tuesday, July 30, 2013 1:34 AM
> To: Randy Bush; Bob Hinden
> Cc: IPv6 Maintanence; Fred Baker (fred)
> Subject: RE: "Deprecate"
> 
> Folks,
> 

I disagree with any name of the form "Fragmentation Considered X";
otherwise, I would have called my doc "Fragmentation Considered
Useful". The "X Considered Y" naming convention came from Dijkstra's
"Go To Considered Harmful", but gotos are still widely used, e.g.,
in operating system kernel code. Plus, I personally find any use
of "X Considered Y" to be a copycat cliché.

> Deprecation

You missed tunnels. The tunnel has no way of knowing whether the
source host is doing RFC4821-style probing, so it has no way of
knowing when to drop vs forward. All it knows is that it MUST
pass packets of at least 1280 bytes (the IPv6 minMTU), and SHOULD
also pass packets of at least 1500 bytes (the minimum size most
hosts expect). For that, it needs some form of fragmentation
and reassembly, and if you want to deprecate IPv6 fragmentation
you need to replace it with something like SEAL.

Thanks - Fred
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Tue, 30 Jul 2013 17:18:27 +0200

Ron,

>                        Ron

Yes, I think the draft (especially since is headed toward BCP) should also include a message that PMTUD is useful and should not be blocked by routers/firewalls/middleboxes/etc.  There are lots of valid reasons to not want to do IPv6 fragmentation, but there was a lot of discussion about encouraging the use of PMTUD.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 Jul 2013 15:44:25 +0000

Hi Bob,

> Bob Hinden
> Sent: Tuesday, July 30, 2013 8:18 AM
> To: Ronald Bonica
> Cc: IPv6 Maintanence; Bob Hinden
> Subject: Re: "Deprecate"
> 
> Ron,
> 
> Yes, I think the draft (especially since is headed toward BCP) should
> also include a message that PMTUD is useful and should not be blocked
> by routers/firewalls/middleboxes/etc.  There are lots of valid reasons
> to not want to do IPv6 fragmentation, but there was a lot of discussion
> about encouraging the use of PMTUD.

That's all good, but there will still be end systems that do not
implement PMTUD - neither RFC1981 nor RFC4821. Plus, try as we
may there will still be paths over which PTB messages will not
be delivered - but I agree that we should still try.

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Tue, 30 Jul 2013 12:06:53 -0700

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

As I read this latest message, it would appear that this sentence I quoted above is the only remaining thing the draft will actually be telling people in my position to do with legacy host stack implementations.

How to say this politely?  I think this recommendation is, at best... unnecessary.

--
james woodyatt <[email-masked]>
core os networking

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 30 Jul 2013 21:55:49 +0000

Fred,

I was thinking of tunnels as legacy applications, but we may need to make this explicit.

                           Ron

> 
> You missed tunnels. The tunnel has no way of knowing whether the source
> host is doing RFC4821-style probing, so it has no way of knowing when
> to drop vs forward. All it knows is that it MUST pass packets of at
> least 1280 bytes (the IPv6 minMTU), and SHOULD also pass packets of at
> least 1500 bytes (the minimum size most hosts expect). For that, it
> needs some form of fragmentation and reassembly, and if you want to
> deprecate IPv6 fragmentation you need to replace it with something like
> SEAL.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jul 2013 10:24:15 +1200

> "Ineffective" has to be modified by "for some specific purpose". Is it ineffective at getting packets through end to end? Ineffective at getting through firewalls? What?

How about "IPv6 Fragmentation is Ineffective for End-to-end Transport"?

(i.e. get rid of the cliché "considered" because we are documenting a fact).

...
> So, then the IETF should not standardize RTP or any protocol (voice, video, ...) that uses it, because RTP relies on its application to manage frame size, and we can't say specifically what the cod…

With the emphasis on "new", I'm not too concerned. We're saying: unless
your packetization layer works properly, you lose. Is that so bad?

   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 30 Jul 2013 22:25:35 +0000

James,

I disagree. Aside from the advice that you quote below, the draft does two things:

- It admits that there is an operational problem
- It instructs the IETF not to make the problem worse by standardizing yet more applications that rely upon fragmentation.

                       Ron

> james woodyatt
> Sent: Tuesday, July 30, 2013 9:07 PM
> To: IPv6 Maintanence
> Subject: Re: "Deprecate"
> 
> As I read this latest message, it would appear that this sentence I
> quoted above is the only remaining thing the draft will actually be
> telling people in my position to do with legacy host stack
> implementations.
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 30 Jul 2013 15:40:14 -0700 (PDT)

On Tue, 30 Jul 2013, Ronald Bonica wrote:
> Thinking a little more about it, RTP and UDP aren't the real 
> culprits. The culprits are the applications that run over them. 
> So, we should limit our statement to applications, and not 
> "applications and transport layer protocols".

I don't agree, at least not if the principal reason why IP fragments 
get dropped is that they lack the L4 header (or at least that the 
non-initial fragments do) and thereby break stateless ACLs.  The 
problem is that UDP and its kin such as UDP-lite and DCCP lack 
transport-layer segmentation, such as is present in TCP, and are 
thereby force their clients to rely on IP fragmentation to provide 
this service.  So yes, these transport protocols are the culprits.

The idea that immediately comes to mind is to design _replacements_ 
transport protocols for UDP and kin that contain a transport layer 
segmentation mechanism.  These would be for use by applications that 
can't get by without such a mechanism; existing applications that 
don't need to rely on IP fragmentation can continue to use UDP and 
kin.  The replacement for UDP might have a header that looks 
something like this:

   0                            15 16                            31
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
  |         Source Port           |      Destination Port         |
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
  |            Length             |       Segment Offset    |Res|M|
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
  |                         Identification                        |
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
  |                            Checksum                           |
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
  |                          data octets               ...
  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...

(Other and perhaps better possibilities exist, of course.)

Having said that, I immediately imagine screaming that such a thing 
could not possibly be deployed, because operators will filter 
anything that they don't know or have an immediate use for, and so 
it would never get any traction.

Well, maybe so, but something has to give.  The operations folks 
have complained that IP fragmentation is awful, they have to filter 
fragments because it defeats their stateless ACLs.  OK; let's agree 
that's a defect that needs to be fixed.  But if you don't want the 
fix to break other important stuff (e.g., DNSSEC, as metioned in 
Section 3.1 of draft-bonica-6man-frag-deprecate-02), you need a 
replacement for IP fragmentation (or an augmentation, such as in 
http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by 
Mark Andrews).  Maybe I just lack imagination, but I can't see any 
fix that does not involve SOME change in operator behavior.

//cmh

---

From: Doug Barton <[email-masked]>
Date: Tue, 30 Jul 2013 15:41:40 -0700

On 07/30/2013 02:55 PM, Ronald Bonica wrote:
> I was thinking of tunnels as legacy applications

Yeah, please stop doing that. :)

While some of the transitional technologies like 6to4 or proto 41 
tunnels will fade away more over time, there is no Internet future where 
tunnels do not play a critical role. We need to be realistic about that, 
and plan accordingly.

Doug

---

From: james woodyatt <[email-masked]>
Date: Tue, 30 Jul 2013 17:01:19 -0700

> - It instructs the IETF not to make the problem worse by standardizing yet more applications that rely upon fragmentation.

I'm not sure how we are in disagreement, but I still sense we are disagreeing.  Somehow.

I think the above two things are useful things for IETF to do, and they are reasons to publish an RFC to do it.  I also think it isn't a good idea to advise maintainers [like me] of host stacks with legacy application and transport protocols to consider breaking their dependence on IPv6 fragmentation.  (This is one of those moments where I wish I were able to express myself candidly in a hotel lobby bar with a half-consumed beer in my hand, so you'll just have to imagine what my version of Linus's infamous "we don't break user space" rant might sound like.  I'm mellower, but it still wouldn't be pretty.)

On a different but related note, I agree with Fred Templin and others.  I still think you're missing something.

As it stands now, this document-- as you have said you plan to amend it-- can still be summarized as follows: "[Section 2] IETF wrote standards for IPv6 fragmentation and ICMPv6 path MTU discovery that many operators do not abide. [Section 3] IETF wrote standards for a raft of transport and application protocols that are broken as a result. [Section 4] Sad trombone."

I would like to see Section 4 strengthened further, so it can be summarized like so: "IETF will take the following steps to mend the damage."  To be more specific, and to repeat myself again repeatedly and for redundancy, IETF should promise-- among other things-- to do something in forthcoming drafts about the problems Fred Templin and I have been prodding the working group to deal with: the lack of PLPMTUD for tunnels like GRE, IPsec, et cetera, which need to carry encapsulated minimum MTU packets over paths where neither fragmentation nor RFC 1981 work.  Fragmentation and/or RFC 1981 is essential to those protocols, they are broken wherever both are unavailable, while this draft basically capitulates and says, "That's everywhere you care about. Sorry about that."  Most importantly, there are no standard replacements, and no promises ever to produce standard replacements.  What is to be done about that?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 31 Jul 2013 10:54:03 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> > - It instructs the IETF not to make the problem worse by standardizing yet 
> more applications that rely upon fragmentation.
> 
> I think the above two things are useful things for IETF to do, and they are r
> easons to publish an RFC to do it.  I also think it isn't a good idea to advi
> se maintainers [like me] of host stacks with legacy application and transport
>  protocols to consider breaking their dependence on IPv6 fragmentation.  (Thi
> s is one of those moments where I wish I were able to express myself candidly
>  in a hotel lobby bar with a half-consumed beer in my hand, so you'll just ha
> ve to imagine what my version of Linus's infamous "we don't break user space"
>  rant might sound like.  I'm mellower, but it still wouldn't be pretty.)
> 
> As it stands now, this document-- as you have said you plan to amend it-- can
>  still be summarized as follows: "[Section 2] IETF wrote standards for IPv6 f
> ragmentation and ICMPv6 path MTU discovery that many operators do not abide. 
> [Section 3] IETF wrote standards for a raft of transport and application prot
> ocols that are broken as a result. [Section 4] Sad trombone."
> 
> I would like to see Section 4 strengthened further, so it can be summarized l
> ike so: "IETF will take the following steps to mend the damage."  To be more 
> specific, and to repeat myself again repeatedly and for redundancy, IETF shou
> ld promise-- among other things-- to do something in forthcoming drafts about
>  the problems Fred Templin and I have been prodding the working group to deal
>  with: the lack of PLPMTUD for tunnels like GRE, IPsec, et cetera, which need
>  to carry encapsulated minimum MTU packets over paths where neither fragmenta
> tion nor RFC 1981 work.  Fragmentation and/or RFC 1981 is essential to those 
> protocols, they are broken wherever both are unavailable, while this draft ba
> sically capitulates and says, "That's everywhere you care about. Sorry about 
> that."  Most importantly, there are no standard replacements, and no promises
>  ever to produce standard replacements.  What is to be done about that?

I can write up my suggestion as a I-D.  It provides the information
stateless middleware needs to pass fragments.  It also helps firewalls
that decide they need to see the entire contents of packets by
providing protection to their reassembly queues.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Jul 2013 06:46:10 +0200

> I think the draft (especially since is headed toward BCP) should also
> include a message that PMTUD is useful and should not be blocked by
> routers/firewalls/middleboxes/etc.

i might say SHOULD NOT

but i would also be clear that the operator/user will find that it is
often the case that PMTUD does not work on man paths.  off-pissing?
yes.  but a lot of reality is.

randy