Subject: Question about <draft-ietf-6man-deprecate-atomfrag-generation-03>

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Oct 2015 16:24:16 -0700

I have a question about <draft-ietf-6man-deprecate-atomfrag-generation-03> in regard to rfc2460bis.

This draft updates RFC2460, it basically removes the text that the originating node include a fragment header in subsequent packets if it is a translator and receives an ICMPv6 packet too big message.  This creates atomic fragments.

I think this is a fine change, my question is about including this update in rfc2460bis.

It would be straight forward to remove this text in rfc2460bis now.  We are allowed to remove features when going to Internet Standard.

The current rfc2460bis draft already has the updates from RFC6946 that restrict how atomic fragments are processed.  I think these should stay, because we still want nodes to process atomic fragments as specified in RFC6946 as atomic fragments still could be an attack vector.  As part of these changes, the only case where atomic fragments would be sent is the case that this draft addresses.

Please let me know what you think about this.  I think this draft could still go forward, but might need a different status based on the timing.  At least it wouldn’t need to update rfc2460bis :-)

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Oct 2015 10:28:41 +0900

Hi, Bob,

On 10/24/2015 08:24 AM, Bob Hinden wrote:
> 
> This draft updates RFC2460, it basically removes the text that the
> originating node include a fragment header in subsequent packets if
> it is a translator and receives an ICMPv6 packet too big message.
> This creates atomic fragments.
> 
> It would be straight forward to remove this text in rfc2460bis now.
> We are allowed to remove features when going to Internet Standard.
> 
> The current rfc2460bis draft already has the updates from RFC6946
> that restrict how atomic fragments are processed.  I think these
> should stay, because we still want nodes to process atomic fragments
> as specified in RFC6946 as atomic fragments still could be an attack
> vector.  As part of these changes, the only case where atomic
> fragments would be sent is the case that this draft addresses.
> 
> Please let me know what you think about this.  I think this draft
> could still go forward, but might need a different status based on
> the timing.  At least it wouldn’t need to update rfc2460bis :-)

I personally think that this document should go forward "as is"
(updating RFC2460, but not rfc2460bis). This way,

1) We follow the practice that rfc2460bis incorporates updates to
RFC2460 made by other RFCs.

2) It is clear that the change is the result from consensus on the topic
(which this document has achieved).

3) The rationale for the change is documented. -- If you just remove
text from RFC2460bis and I were to produce a diff betwen RFC2460 and
rfc2460bis, my obvious question would be "what happened here? why was
this text removed? What's the rationale? Are there any interoperabiity
implications?" -- draft-ietf-6man-deprecate-atomfrag-generation-03
answers all these questions.

4) This document also provides the rationale for the corresponding
update to RFC6145 (via draft-bao-v6ops-rfc6145bis-02).

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Tore Anderson <[email-masked]>
Date: Wed, 28 Oct 2015 07:14:13 +0100

Hi Bob and Fernando,

* Bob Hinden

> > it is a translator and receives an ICMPv6 packet too big message.

I believe this characterisation is inaccurate. Specifically, the «if it
is a translator» part is incorrect. RFC2460 requires that any IPv6
node, regardless of being a translator or not, include the fragment
header in subsequent packets after having received an ICMPv6 PTB with
MTU<1280.

> > We are allowed to remove features when going to Internet Standard.

I think would make a lot of sense to incorporate
I-D.6man-deprecate-atomfrag-generation into RFC2460bis. If not, the I-D
would need to also update RFC2460bis too, which seems rather silly to
me.

> 2) It is clear that the change is the result from consensus on the
> topic (which this document has achieved).
> 

It appears to me that the RFC2460bis would ideally remove the text in
question and refer to I-D.6man-deprecate-atomfrag-generation in
Appendix B («CHANGES SINCE RFC2460») for the rationale. That way,
I-D.6man-deprecate-atomfrag-generation can be updated to take
RFC2460bis into account in the same way RFC6145bis already was. That
is, it wouldn't have to update RFC2460 any longer, and could be changed
to be Informational rather than Standards Track.

Tore

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Oct 2015 07:13:04 +0900

Tore,

> On Oct 28, 2015, at 3:14 PM, Tore Anderson <[email-masked]> wrote:
> 
> Hi Bob and Fernando,
> 
> * Bob Hinden
> 

You are correct, my summary summarized too much.

> would need to also update RFC2460bis too, which seems rather silly to

My thinking as well.

> to be Informational rather than Standards Track.

A good approach.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Oct 2015 15:34:28 +0900

Hi,

I made the change in my local -01 draft.  It consisted of removing the following paragraph from Section 5:

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  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.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

and a note in the changes section:

 01) Removed paragraph in Section 5 that required
     including a fragment header to outgoing packets if a ICMP Packet Too
     Big message reporting a Next-Hop MTU less than 1280.  This is based
     on the update in
     draft-ietf-6man-deprecate-atomfrag-generation-03.

The text doesn’t say to not include Fragment headers in this case, as I don’t think we need to describe what not to do.  Also, given the changes made in the Fragment Header section in the -06 individual draft, the first fragment always has the M flag value of 1 indicating more fragments.  There is also text in the reassembly procedure on how to handle whole packets with a fragment header (aka Atomic fragments).  This allows for hosts that still implement this capability and to protect from malicious senders.

Bob

> On Oct 29, 2015, at 7:13 AM, Bob Hinden <[email-masked]> wrote:
> 
> Tore,
>

---

From: Tore Anderson <[email-masked]>
Date: Thu, 29 Oct 2015 08:04:42 +0100

* Bob Hinden <[email-masked]>

> The text doesn’t say to not include Fragment headers in this case, as
> I don’t think we need to describe what not to do.  Also, given the
> changes made in the Fragment Header section in the -06 individual
> draft, the first fragment always has the M flag value of 1 indicating
> more fragments.  There is also text in the reassembly procedure on
> how to handle whole packets with a fragment header (aka Atomic
> fragments).  This allows for hosts that still implement this
> capability and to protect from malicious senders.

Hi Bob,

I just realised that this would also remove an important piece of
information that is would still be relevant to implementers:

«[An] IPv6 node may receive an ICMP Packet Too Big message reporting a
Next-Hop MTU less than 1280. In that case, the IPv6 node is not
required to reduce the size of subsequent packets to less than 1280[.]»

That is, it becomes somewhat ambigiuous what an IPv6 node should
actually do upon receiving an ICMPv6 PTB with an MTU of, say, 1000. I
can imagine three possible ways of understanding the new text:

A) the PTB may be completely ignored
B) subsequent packets must be reduced to 1280
C) subsequent packets must be reduced to 1000

Of these, option A would be damaging because it could create PMTUD
blackholes even with translators conforming to 6145bis. Both B and C
would work, though. So I think there needs to be replacement text that
mandates at least option B while at the same time does not prohibit
option C. Something like this, maybe? (Of course, do feel free to come
up with something better.)

«An IPv6 node may receive an ICMP Packet Too Big message reporting a
Next-Hop MTU less than 1280. In that case, the IPv6 node must limit the
size of subsequent packets to 1280 or less.»

(This also applies to draft-ietf-6man-deprecate-atomfrag-generation-03.)

Tore

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Oct 2015 16:39:39 +0900

Tore,

> required to reduce the size of subsequent packets to less than 1280[.]»

You may be reading this out of context.  The start of this section starts with:

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.

RFC443 ICMPv6 that defines the ICMP Packet too Big message references RFC1981 Path MTU Discovery (also referenced in this section) says:

   A node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

I think this makes it clear what to do if an ICMP Packet Too Big message is received with an MTU less than 1280.

However, this then goes on to say:

      Note: A node may receive a Packet Too Big message reporting a
      next-hop MTU that is less than the IPv6 minimum link MTU.  In that
      case, the node is not required to reduce the size of subsequent
      packets sent on the path to less than the IPv6 minimun link MTU,
      but rather must include a Fragment header in those packets [IPv6-
      SPEC].

That would also need to be updated (that is, remove this note), or file an errata once the rfc2460bis is done.  The latter would be easier.

Bob

---

From: Tore Anderson <[email-masked]>
Date: Thu, 29 Oct 2015 09:02:33 +0100

> RFC443 ICMPv6 that defines the ICMP Packet too Big message references
> RFC1981 Path MTU Discovery (also referenced in this section) says:
> 
> I think this makes it clear what to do if an ICMP Packet Too Big
> message is received with an MTU less than 1280.

Quite. Thank you for this clarification.

Then I can say that your proposed changes to -01 draft works for me. 

>       next-hop MTU that is less than the IPv6 minimum link MTU.  In
> that case, the node is not required to reduce the size of subsequent
>       but rather must include a Fragment header in those packets
> [IPv6- SPEC].
> 
> That would also need to be updated (that is, remove this note), or
> file an errata once the rfc2460bis is done.  The latter would be
> easier.

Agreed. I had missed this fact that RFC1981 mandates the generation of
atomic fragments. That should probably have been pointed out in
draft-ietf-6man-deprecate-atomfrag-generation.

Tore

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Oct 2015 17:07:10 +0900

Tore,

> On Oct 29, 2015, at 5:02 PM, Tore Anderson <[email-masked]> wrote:
> 

Good thanks!

> draft-ietf-6man-deprecate-atomfrag-generation.

It’s quoting rfc2460, but I agree it needs to be fixed.

Thanks,
Bob