Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation

From: Tore Anderson <[email-masked]>
Date: Sat, 11 Jun 2016 09:49:10 +0200

Hello Carlos, thank you for your review, and apologies for the much
belated reply.

* Carlos Jesús Bernardos Cano

> Overall, the document is mature, well written and I find it useful. I
> do not see any reason to hold up publication.

Thank you!

> Some minor detailed suggestions follow:
> 
> - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a
> host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising
> an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not
> required to reduce the assumed Path-MTU, but must simply include a
> Fragment Header in all subsequent packets sent to that destination.'
> 
> RFC2460 actually says '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.'
> 
> While the document states later that 'an IPv6 node cannot easily limit
> its exposure to the aforementioned attack vector by only generating
> IPv6 atomic fragments towards IPv4 destinations behind a stateless
> translator', it would help the reader to add that piece of context from
> the very beginning of the document.

Point taken. What do you think about amending Section 1 like so:

   [RFC2460] specifies the IPv6 fragmentation mechanism, which allows
   IPv6 packets to be fragmented into smaller pieces such that they can
   fit in the Path-MTU to the intended destination(s).

   An IPv4/IPv6 translator implementing the Stateless IP/ICMP
   Translation algorithm [RFC6145] may legitimately generate ICMPv6
   "Packet Too Big" messages [RFC4443] advertising a "Next-Hop MTU"
   smaller than 1280 (the minimum IPv6 MTU).

   Section 5 of [RFC2460] states that, upon receiving such an ICMPv6
   message, hosts are not required to reduce the assumed Path-MTU, but
   must simply include a Fragment Header in all subsequent packets sent
   to that destination. [...]

> - Section 2: Again, I think it would help adding the context about
>   RFC2460 using atomic fragments only for the purpose of helping an
>   IPv6- to-IPv4 translating router can obtain a suitable
>   Identification value to use in resulting IPv4 fragments.

Section 2 says:

   o  As noted in Section 3, SIIT [RFC6145] (including derivative
      protocols such as Stateful NAT64 [RFC6146]) is the only technology
      which currently makes use of atomic fragments.

And section 3 says:

   We note that SIIT essentially employs the Fragment Header of IPv6
   atomic fragments to signal the translator how to set the DF bit of
   IPv4 datagrams (the DF bit is cleared when the IPv6 packet contains a
   Fragment Header, and is otherwise set to 1 when the IPv6 packet does
   not contain an IPv6 Fragment Header).

I feel it would be redundant to duplicate this text in section 2. Isn't
the reference too section 3 sufficient?

> - Section 3: when discussing IPv4 Identification collision rates, it
> would be helpful adding some numbers/equations there to get an idea of
> what rates we are talking about.

I leave this one to Fernando.

> - Appendix A: what does 'Linux kernel current' mean? This is very
> minor, as this section is probably to be removed, but in case it
> remains after publication as RFC, current should be replaced by the
> kernel version number.

This one too; I don't know which kernel version «current» refers to.

Tore

---

From: Tore Anderson <[email-masked]>
Date: Sat, 11 Jun 2016 09:57:41 +0200

Hello Bernie, thank you for your review, and apologies for the much
belated reply.

* Bernie Volz (volz)

> A few other minor nits when I looked over this document:
> 
> In section 3:
> 
> - "2.  The IPv4  node ... 1260 bytes". It might be useful to indicate
> how this 1260 came to be (as someone might easily confuse this with a
> typo for 1280?). This is really 1280 still but because the IPv4
> header is 20 bytes shorter than the IPv6 header, the figure is 1260
> for IPv4 packets.

How about this?

   2.  The IPv4 node is located behind an IPv4 link with an MTU smaller
       than 1260 bytes. An IPv4 Path MTU of 1260 corresponds to an IPv6
       Path MTU of 1280, due to an option-less IPv4 header being 20
       bytes shorter than the IPv6 header.

> - The text "proposing as a workaround" is odd? Should "as" be dropped?

Agreed. We'll make sure to drop the "as".

> In section 6, "some of [the] tests" (the is missing). Not a bit deal
> as I'm sure RFC-Editor would fix.

Good catch, thank you.

Tore

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 11 Jun 2016 11:10:53 +0000

Hi:

Proposed changes look fine. Thanks.

- Bernie (from iPad)

> On Jun 11, 2016, at 3:57 AM, Tore Anderson <[email-masked]> wrote:
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 17 Jun 2016 16:15:38 +0200

Hi Tore,

Sorry for the late reply. Please see inline below.

>    to that destination. [...]

[Carlos] That's sounds good to me. Thanks!

> the reference too section 3 sufficient?

[Carlos] Well, I don't have a very strong position on this. IMHO, it
makes more readable the document to be a bit redundant, but make the
text clearer in Section 2, but I agree that the document, as is, is not
missing information.

Thanks!

Carlos