Subject: [BEHAVE] 64 MTU and fragmentation handling

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Aug 2009 17:57:19 +0200

Hi,

We had a fruitful discussion about MTU and fragmentation handling in  
the online interim meeting yesterday. My original options for handing  
< 1280 MTUs on the IPv4 side for stateful translation:

1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a  
fragment header are sent after a < 1280 "too big" message, translator  
sets DF=0 when translating packets with a fragment header, DF=1  
otherwise.

The problem with this is that there is the possibility of a black hole  
when the operator disables path MTU discovery on the IPv6 side by  
setting the MTU to 1280 and filtering "too big" messages. In that  
case, the fragment header is never included, the translator generates  
a 1260-byte IPv6 packet with DF=1 and communication is impossible.  
This requires unusual, but not unheard of cases on both the v4 and v6  
sides (< 1260 MTU, PMTUD disabled), but the problem is that in the  
pure IPv4 and pure IPv6 cases these wouldn't cause trouble, it's only  
when communicating through a translator that the black hole presents  
itself.

Solution in the draft:

3. Rewrite "too big" messages to provide a 1280-byte MTU and have the  
translator set DF=0 for packets <= 1280 bytes and DF=1 for packets >  
1280 bytes.

Alternative solution:

2. Adopt the RFC 2460/2765 behavior, except that to avoid the black  
hole, packets <= 1280 are sent with DF=0 even if there is no fragment  
header.

Additional solution mentioned yesterday:

4. Let the translator track path MTU sizes for IPv4 destinations and  
fragment packets at the source where needed (just like normal IPv6  
hosts do for IPv6, and in our specification, the translator also does  
this for packets going towards the IPv6 side).

One argument that was made yesterday was the applicability to  
stateless translation. Obviously a mechanism that works for both  
stateful and stateless would be better than separate mechanisms for  
both. (However, note that the identification value handling needs to  
be different between stateful and stateless translation regardless of  
path MTU discovery handling.)

However, solutions 2 and 4 equally apply to the stateful and stateless  
cases. Solution 3 is somewhat less suited for the stateless case,  
because it requires the translator to come up with an identification  
value. If traffic is flowing through multiple translators the  
identification values could clash and result in reassembly errors.

All solutions produce fragments (except perhaps option 4 in the case  
of TCP when TCP is resegmented rather than fragmented), with the  
associated risk of incorrect reassemly and subsequent dependence on  
the weak TCP/UDP checksum to avoid data corruption.

Option 4 has the disadvantage of creating more work for the translator  
and generating more packets and bits, taking over this work from the  
router in front of the < 1280 byte MTU link on the IPv4 side.

As such, I favor option 2 for both stateful and stateless translation,  
and if implementers feel 4 is a viable option I would be willing to  
include that as a not specifically recommended alternative.

Thoughts?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 26 Aug 2009 07:55:30 -0700

Iljitsch,

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Thursday, August 20, 2009 8:57 AM
> To: Behave WG
> Subject: [BEHAVE] 64 MTU and fragmentation handling
> 
> Hi,
> 
> setting the MTU to 1280 and filtering "too big" messages.

That would not be correct behavior according to RFC2460;
ICMP PTBs that report a size smaller than 1280 are still
possible and must be handled even when a 1280 MTU is used.

> In that

Whether or not the ICMPs could be lost depends a great
deal on where the translator is placed. The closer it
is placed to the IPv4 host, the less opportunity for
lost ICMPv4 messages.
 
> hole, packets <= 1280 are sent with DF=0 even if there is no fragment

This opens the opportunity for sustained IPv4 fragmentation
at high data rates. Inclusion of the IPv6 fraghdr is the
IPv6 host's way of setting DF=0; when the IPv6 fraghdr is
not present, the IPv6 host thinks DF=1.

Fred
[email-masked]
 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Aug 2009 17:37:44 +0200

> possible and must be handled even when a 1280 MTU is used.

 From the RFC:

    It is strongly recommended that IPv6 nodes implement Path MTU
    Discovery [RFC-1981], in order to discover and take advantage of  
path
    MTUs greater than 1280 octets.  However, a minimal IPv6
    implementation (e.g., in a boot ROM) may simply restrict itself to
    sending packets no larger than 1280 octets, and omit implementation
    of Path MTU Discovery.

Now we can argue on whether it's ok to filter incoming too bigs if you  
set your MTU to 1280, but regardless of who wins that argument, I  
believe the specification is sufficiently vague on the subject that we  
must assume that there will be people who adopt the interpretation  
that this is allowed and subsequently do this. Remember that there are  
many places today that set DF=1 and filter incoming too bigs for IPv4,  
a practice that actually breaks lots of stuff. But filter too big /  
MTU 1280 doesn't create any trouble when communicating with IPv6  
correspondents, only when talking to IPv4 users on < 1260 MTU subnets  
through a translator, so it would make sense that even more people  
would do this.

> is placed to the IPv4 host, the less opportunity for

There are many IPv4 hosts all over the place, how do we locate a  
single translator such that it is close to all of them?

> not present, the IPv6 host thinks DF=1.

What do you mean? With a fragment header, the packet would be 1280 -  
20 - 8 = 1252 bytes with DF=0. Without the fragment header, the packet  
would be 1280 - 20 = 1260 bytes with DF=0. Unless the MTU is 1252 -  
1259 or < 630, the number of fragments is the same.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 26 Aug 2009 10:44:23 -0700

Iljitsch,

> Sent: Wednesday, August 26, 2009 8:38 AM
> To: Templin, Fred L
> Cc: Behave WG
> Subject: Re: [BEHAVE] 64 MTU and fragmentation handling
> 

You can't just read half of the spec and quit there. The
spec goes on to say:

   "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."

This specifically says that IPv6 nodes (boot ROMs and all)
need to be on the lookout for ICMPv6 PTBs reporting a size
smaller than 1280, and then must insert the Fragment header
in subsequent packets. This implies that the network needs
to deliver (and not block) the necessary ICMPv6 PTBs.
 
> single translator such that it is close to all of them?

No; not a single translator that is close to all IPv4 hosts.
Rather, each IPv4 network that wish to continue to provide
IPv4-only services should deploy a 6/4 translator at the edge
of their network and ensure that IPv6 is enabled all the way
to the edge. In this way, the servers will have incentive to
move to IPv6, as they would otherwise miss out on serving a
new class of clients as more and more IPv6-only clients emerge.

> 1259 or < 630, the number of fragments is the same.

I'm afraid I can't parse this as being responsive to what
I actually said...

Fred

---

From: Zhen Cao <[email-masked]>
Date: Thu, 27 Aug 2009 02:26:58 +0800

Hi Fred,

Comments in line with [zc]

Thanks,
Zhen
On Thu, Aug 27, 2009 at 1:44 AM, Templin, Fred
>   additional extension headers are used."

[zc] The specification you quote above uses "may" , but you have
changed it to "must"?
> to deliver (and not block) the necessary ICMPv6 PTBs.

[zc] Another fact is that the IPv4 network may not be able to return
back a PTB message since it is not mandated on IPv4. In this case, the
network has not PTBs to handle.

>> > not present, the IPv6 host thinks DF=1.

[zc] I believe the problem should be handled by the one who introduces
it. Having the translator keeps everything is a more reasonable and
responsible way, i.e. option. 4 as we proposed in the interim meeting.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Aug 2009 20:57:05 +0200

On 26 aug 2009, at 19:44, Templin, Fred L wrote:

> You can't just read half of the spec and quit there.

Like I said, we can debate that (I think you can or at least you  
should be able to) but wouldn't you agree that there will be some  
people that will do exactly this?

> new class of clients as more and more IPv6-only clients emerge.

I agree with that, but this is not what NAT64 is trying to solve...

>>> not present, the IPv6 host thinks DF=1.

[...]

> I'm afraid I can't parse this as being responsive to what

Apparently we're talking about two different things. What I'm saying  
is that whether we adopt option 1 or 2, the number of fragments will  
be the same, because in both cases, the IPv6 host will generate a 1280- 
byte packet which is translated into an IPv4 packet with DF=0.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 26 Aug 2009 12:08:26 -0700

> [zc] The specification you quote above uses "may" , but you have

I didn't change anything; the text above is cut-and-paste directly
out of RFC2460, Section 5.

Fred