Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 08:08:41 +1200

Hi,

Quoting RFC 6145:

  "Path MTU discovery across
   a translator relies on ICMP Packet Too Big messages being received
   and processed by IPv6 hosts, including an ICMP Packet Too Big that
   indicates the MTU is less than the IPv6 minimum MTU."

  "...the translator can rely on IPv6
   hosts sending subsequent packets to the same IPv6 destination with
   IPv6 Fragment Headers.  In such an environment, when the translator
   receives an IPv6 packet with a Fragment Header, the translator SHOULD
   generate the IPv4 packet with a cleared Don't Fragment bit, and with
   its identification value from the IPv6 Fragment Header, for all of
   the IPv6 fragments (MF=0 or MF=1).

   In an environment where an ICMPv4 Packet Too Big message is filtered
   (by a network firewall or by the host itself) or not correctly
   processed by the IPv6 hosts, the IPv6 host will never generate an
   IPv6 packet with the IPv6 Fragment Header.  In such an environment,
   the translator SHOULD set the IPv4 Don't Fragment bit."

In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260
octets.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 17:36:50 -0300

Hi, Brian,

> In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260

Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
requiring the IPv6 source to generate atomic fragments? -- I can't see
any gain but just drawbacks:

* The translator is in a better position to generate a non-colliding
Fragment IDs

* Requiring the source to generate atomic fragments means there will be
more fragmented traffic than necessary -- which not unusually gets dropped.

* Native IPv6 hosts pay the price for the SIIT thing...

Right now, a device that wants to filter fragments, is subject to DoS
attacks just because of this little "feature" which, while present in
RFC 6145, seems rather unnecessary (unless I'm missing something).

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 08:55:15 +1200

> RFC 6145, seems rather unnecessary (unless I'm missing something).

That's not my point. My point is that if you propose this change, you
need to make specific updates to RFC 6145 at the same time, and describe
the compatibility issues if hosts that support your proposed update
to 2460 meet SIIT translators that do not support your proposed updates
to 6145.

In other words there is an important section missing from your draft:
"Updates to the IP/ICMP Translation Algorithm."

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 18:17:11 -0300

> "Updates to the IP/ICMP Translation Algorithm."

Absolutely. I was just double-cheking if there is anything I was missing
from the existing requirement/expectation to cause the sending node to
produce atomic fragments... IMO, it brings more trouble than anything
else...

But, yes: you raised a very important point. WIll fix this in the next rev.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Aug 2014 19:59:44 -0300

On 08/19/2014 07:35 PM, Philip Homburg wrote:
> In your letter dated Tue, 19 Aug 2014 17:36:50 -0300 you wrote:
> There are people who want to run IPv6-only datacenters and then use stateless v4-to-v6
> translation to handle v4.
> 
> Obviously, if traffic goes to a v4 host that is on path mtu less than 1300, the v4
> packets needs to be fragmented.
> 
> The translator being stateless (and probably redundant) implies that at best the IPv4 
> packet ID can be chosen at random. Giving a 1 in 64k chance that two flows with the
> same source and destination addresses will have the same ID.

FWIW, there are stateless algorithms with a lower frequency reuse rate
... e.g., check OpenBSD's Frag ID, generator, or some of the algorithms
in <http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id>

> One big question is how many v4 hosts would be affected by this, i.e. how 
> many v4 hosts are on a path mtu less than 1300.
> 
> Another question is whether taking 16 bits out of the 32-bit fragment ID in IPv6
> actually results in something better than random.

Certainly not, particularly if the nodes use something like
per-destination counter for the frag ID -- if you were unlucky, the Frag
IDs counters of two nodes could be "synchronized".

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Aug 2014 00:35:18 +0200

Of course, any IPv6 site that want to do DNSSEC has to be able to receive fragmented
traffic. In that sense, atomic fragments are just a easy subset of receiving 
fragmented traffic in general.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 11:49:43 -0700

> * The translator is in a better position to generate a non-colliding

Fernando,

The original motivation for this in SIIT was that since the translator 
is stateless, ECMP routing can take different fragments to different 
translators. When that happens it doesn't work to have the translator 
make up a fragment ID since different fragments of the same datagram 
would get the ID assigned by different translators.

Whether the complexity of handling that case is worth the cost is a 
separate matter.

In any case, it makes sense to document this in your draft.

    Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 16:01:09 -0300

Hi, Erik,

> would get the ID assigned by different translators.

mm.. not sure I follow. At least acording to RFC6145 (I haven't checked
RFC2765), there are two cases in which the translator can receive a
packet with a FH:

1) An atomic fragment (triggered by ICMPv6 PTB<1280) -- in which case,
the translator is getting the whole thing, since the packet is not
fragmented. But the translator still uses the Frag ID from the IPv6 FH.

2) A normal fragmented traffic. In this case, the translator may or may
not receive all the fragment (due to ECMP). In this case, the translator
also uses the Frag ID from the IPv6 FH.

The case you describe seems to be "2)", which is fine to me. The one
that I don't think makes much sense is "1)"....

> In any case, it makes sense to document this in your draft.

Please do let me know if I got the above wrong...

Thanks!

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 12:11:19 -0700

> that I don't think makes much sense is "1)"....

Sure.

When you have a mixture of 1 and 2 traffic then with RFC6145 the host is 
picking the fragment IDs for all of them. Hence it can do a reasonable 
job of keeping the fragment IDs unique - limited by ending up with only 
16 bits after the translator.

If you remove the atomic fragments then for 2 the host will pick the 
fragment IDs and for 1 the translator will pick them. That might result 
in a higher probability of colliding fragment IDs.

    Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 16:32:24 -0300

On 08/21/2014 04:11 PM, Erik Nordmark wrote:
> picking the fragment IDs for all of them.

But if there are multiple IPv6 hosts and, say, a single IPv4 address at
the translator, it's way more likely that you'll get Frag ID collisions
if it's the hosts picking the IDs as opposed to the translator.

For case 2 above, you clearly have no other option, and have to live
with it. But for case "1)" above the translator is in a better position
to pick the Frag ID (after all, the translator is the only box that
"nows" which frag IDs have been used recently).

Trivial example: let's assume that both Host A and Host B are IPv6 nodes
connected to the translator, and that Host A, Host B, and the translator
all use a global counter for selecting Frag IDs.

Say Host A sends an atomic fragment with Frag ID: 0, and that
Say Host B sends an atomic fragment with Frag ID: 0.

If the translator honors the Frag ID in the IPv6 FH (as required), then
there will be a frag ID collision as both packets would be sent to the
IPv4 world with a frag ID of 0 (and, if everyone is using counters,
collisions are likely to repeat).

OTOH, if the translator were to select the frag IDs for the
aforementioned packets, the first one (from Host A) would be assigned,
say, Frag ID 0, and the second packet (from Host B) would be assigned
Frag ID 1.

i.e., in those cases where it's possible (atomic fragments), it seems
that it's better to pick the frag ID at the translator... but RFC6145
currently requires nodes to use whatever the nodes had selected (well,
the lower 16bits of that, of course).

> in a higher probability of colliding fragment IDs.

In the case of mixed traffic (1 and 2 above), since there's no
coordination between the nodes, isn't it, at the end of the day, the
same thing if the translator picks the ID?

Cheers,

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 16:30:44 -0700

> if it's the hosts picking the IDs as opposed to the translator.

If the IPv4 address is shared then the translator isn't stateless any 
more. Needs to translate TCP/UDP port numbers etc. Hence all bets are 
off ;-)

In such a case the translator can assume it is on the path for all the 
packets. Thus it can rewrite the fragment IDs as it pleases.

I was merely commenting on the case of stateless translators that are 
used in redundant ways using e.g. ECMP routing.

    Erik

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 20:34:06 -0300

>> On 08/21/2014 04:11 PM, Erik Nordmark wrote:
[....]
> used in redundant ways using e.g. ECMP routing.

Ok, now I see what you meant. Thanks for the clarification!

Best regards,