Subject: [Softwires] Tunnel MTU and fragmentation in draft-ietf-softwire-dual-stack-lite-08

From: Matthias van der Heide <[email-masked]>
Date: Mon, 9 May 2011 10:08:45 +0200

After reading the latest version of the Dual-Stack Lite draft, the issue of
Tunnel MTU and fragmentation got me confused.

Tunneling according to RFC2473 dictates that IPv4 packets exceeding the
Tunnel MTU (Link MTU - size of Tunnel Headers) with the Don't Fragment bit
set should be dropped and answered with an ICMP that carries the Tunnel MTU.

Packets with the Don't Fragment bit cleared that exceed the Tunnel MTU must
be encapsulated and then fragmented.

However, this distinction isn't mentioned in the Dual-Stack Lite draft.
Instead it says (section 5.3):

> However, as not all service providers will be able to increase their
>   link MTU, the B4 element MUST perform fragmentation and reassembly if
>   the outgoing link MTU cannot accommodate for the extra IPv6 header.
>   The original IPv4 packet is not oversized.  The packet is oversized
>   after the IPv6 encapsulation.  The inner IPv4 packet MUST not be
>   fragmented.  Fragmentation MUST happen after the encapsulation on the
>   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
>   IPv6 header.  Detailed procedure has been specified in [RFC2473]
>   Section 7.2.

So although it refers to RFC2473 for the detailed procedures, it modifies
these procedures by removing the distinction between packets
with and without the Don't Fragment bit set.

Is it true that tunneling in Dual-Stack Lite differs from tunneling
described in RFC2473?

If so, what should be used as the MTU value for the link on which a DS-Lite
interface is enabled? Should it be the Link MTU (for instance
1500 in Ethernet), or the Tunnel MTU (Link MTU - 40 or more bytes)? Perhaps
the draft could be extended with an example of a fragmented
flow.

If not, I think the text should be clarified.

In both cases, I hope this helps the draft to become a robust, stable
standard, and I'm willing to contribute.

  - Matthias van der Heide

---

From: Jacni Qin <[email-masked]>
Date: Mon, 9 May 2011 17:29:56 +0800

hi,

> with and without the Don't Fragment bit set.

Jacni>: It just says "Fragmentation MUST happen after the encapsulation on
the IPv6 packet" , seems to be not in conflict with RFC2473?

Cheers,
Jacni

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Matthias van der Heide <[email-masked]>
Date: Mon, 9 May 2011 11:56:27 +0200

The Dual-Stack Lite draft doesn't mention a different treatment for packets
with the Don't Fragment bit set. RFC 2473 does.

So the procedure in the draft is either incomplete (and should be ammended)
or different from RFC 2473 (so it should state how and why it is different).

Example:

If a packet of 1500 bytes and the Don't Fragment bit set is passed into a
DS-Lite tunnel with a Tunnel MTU of 1460 (1500 - 40 bytes for headers) ,
according to the draft it should be encapsulated, and fragmented in IPv6,
since it's the tunnel headers that cause it to be too big.

In a RFC 2473 compliant tunnel, such packets would be dropped (they are too
large for the Tunnel MTU, and can't be fragmented) and an ICMP Unreachable,
Packet Too Big should be sent.

2011/5/9 Jacni Qin <[email-masked]>