Subject: [Softwires] DS-Lite fragmentation RFC2473 reference

From: Daniel Roesen <[email-masked]>
Date: Tue, 11 Oct 2011 14:37:27 +0200

Hi,

the DS-Lite spec states:

5.3.  Fragmentation and Reassembly
...
   [...] The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2.

The change from "fragment the IPv4 payload" to "fragment the IPv6 tunnel
packet" came between draft-ietf-softwire-dual-stack-lite-00 and -01:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-dual-stack-lite-01.txt

The probable trigger was:

http://www.ietf.org/mail-archive/web/softwires/current/msg00756.html

No reasoning has been provided on the list, nor was the change in -01
commented.

I'm wondering what the reasoning was to mandate tunnel packet
fragmentation instead of payload. Could anyone give some insights?

Theoretically there should be no adverse impact by AFTR fragmenting the
NATted IPv4 payload packets for transmission into the tunnel to the B4.
Reassembly would be offloaded from the B4 to the endpoint behind the B4.

I've investigated a bit and found reports of SIP implementations having
serious problems with fragmented UDP, as well as Microsoft AD/Kerberos:

http://blog.tmcnet.com/third-screen/2009/03/udp_fragmentation_breaks_sip_in_todays_ip-pbxs.html
http://blogs.technet.com/b/asiasupp/archive/2006/09/19/457413.aspx

Any insight appreciated!

Best regards,
Daniel

PS: yes, fragmenting the tunnel packets is of course the most
transparent way end-to-end, but it comes at a price...

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 20 Oct 2011 02:11:44 +0000

Hi Daniel,

Host behind B4 isn't aware he tunnel between B4 and AFTR. To make the host
transparent to IPv4 fragmentation, we made the decision to mandate B4 (and
AFTR) fragment and reassemble the oversized packet. We agree that there is
a price to pay (i.e., CPU intensive operation in B4 and AFTR), but this
should affect the host least.

/Yiu

On 10/11/11 8:37 AM, "Daniel Roesen" <[email-masked]> wrote:

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

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 20 Oct 2011 09:42:31 +0200

Hi Yiu,

> should affect the host least.

Thanks for the clarification. Too bad the vendor landscape (both AFTR
and B4) grossly ignore that normative requirement of RFC6333 and either
fragment the payload instead of the tunnel, or - even worse - resort to
measures like issuing ICMPv4 "frag needed but DF set" even in response
to >1460 bytes IPv4 packets WITHOUT DF bit being set.

They all have significant problems with performance when being asked to
perform proper RFC6333 operation. And then speak of hardening AFTRs
against reassembly resources starvation attacks...

Best regards,
Daniel

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Oct 2011 11:27:03 +0200

In your previous mail you wrote:

   Thanks for the clarification. Too bad the vendor landscape (both AFTR
   and B4) grossly ignore that normative requirement of RFC6333 and either
   fragment the payload instead of the tunnel,

=> there is a feature (not a bug as it is not incorrect) in some Linux
kernels which don't use the right MTU for the encapsulated packets
(there are some lines of code to remove, cf the PS).

Thanks

[email-masked]

PS: the patch (against an old version but this is not yet fixed in
recent kernels...):

*** /usr/src/linux/net/ipv6/ip6_tunnel.c	2008-07-13 23:51:29.000000000 +0200
--- ip6_tunnel+.c	2008-12-09 01:25:33.000000000 +0100
***************
*** 888,898 ****
  		mtu = IPV6_MIN_MTU;
  	if (skb->dst)
  		skb->dst->ops->update_pmtu(skb->dst, mtu);
- 	if (skb->len > mtu) {
- 		*pmtu = mtu;
- 		err = -EMSGSIZE;
- 		goto tx_err_dst_release;
- 	}
  
  	/*
  	 * Okay, now see if we can stuff it in the buffer as-is.
--- 888,893 ----