Subject: [BEHAVE] Announcing an IPv4 to IPv6 multicast translator implementation

From: Teemu Kiviniemi <[email-masked]>
Date: Tue, 18 May 2010 21:39:18 +0300

Hi all,

As part of my master's thesis, I've written an IPv4 to IPv6 multicast
translator implementation. The translator is implemented as a new
component of MRD6 multicast router on Linux.

The implementation follows the architectural ideas and address
translation presented in draft-venaas-behave-mcast46. IPv4 to IPv6
protocol translation is done using an adapted version of the SIIT
algorithm. IPv6 to IPv4 translation or unicast translation is not
supported.

Both any-source multicast and source-specific multicast can be
translated. The translator can be used as a simple MLD to IGMP proxy,
or the translator can provide a translation service for a larger
network with PIM.

The protocol translator handles IPv6 path MTU discovery and
fragmentation on behalf of IPv4 multicast sources. The translator
tries to avoid unnecessary fragmentation by keeping state about the
currently known IPv6 path MTU for each multicast group address. That
way most MPEG-2 TS over UDP IPTV streams can be translated without
fragmentation.

Some systems (at least Linux) seem to enable path MTU discovery on all
sockets and send IPv4 UDP packets with the Don't Fragment (DF) flag
set, even if the destination address is a multicast group. As IPv4
routers are not allowed to send ICMP error messages about multicast,
large IPv4 multicast packets are be a bit problematic.

One solution would have been to drop too large packets, like an IPv4
router. However, it would have made some IPv4 multicast unavailable to
IPv6 hosts. Another solution would have been to send ICMP error
messages anyway. At least Linux seems to respond correctly to ICMP
error messages concerning multicast, but other systems may not.

To avoid compatibility issues with existing IPv4 multicast sources and
IPv6 networks, the translator ignores the IPv4 DF flag and fragments
those packets anyway. However, IPv4 hosts may send packets with zero
fragment identification values. The problem of zero identification
values was avoided by generating IPv6 fragment identification values in
the protocol translator. The translator ensures that the high-order 16
bits of a generated fragment identification value are always non-zero,
avoiding clashes with existing IPv4 identification values.

The translator is licenced under the GNU GPL and was recently merged
to the MRD6 git repository at: http://github.com/hugosantos/mrd6

The translator implementation is described in detail in my master's
thesis. The thesis is available in PDF format here:
http://iki.fi/teemuki/translator/

-- 
Best regards,
Teemu Kiviniemi

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 May 2010 14:10:29 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Teemu Kiviniemi
> Sent: Tuesday, May 18, 2010 11:39 AM
> To: [email-masked]
> Subject: [BEHAVE] Announcing an IPv4 to IPv6 multicast 
> translatorimplementation
> 
> Hi all,
> 
> set, even if the destination address is a multicast group.

Can they not clear the IP_MTU_DISCOVER socket option?

(And why does Linux set DF on UDP by default, anyway?  It seems
troublesome.)

-d

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

---

From: Teemu Kiviniemi <[email-masked]>
Date: Fri, 21 May 2010 16:08:25 +0300

> Can they not clear the IP_MTU_DISCOVER socket option?

Of course. However, I've seen IPTV streams running with the DF bit set.
One of the major goals of the implementation was to maximize
compatibility with existing IPv4 multicast, without modifying current
IPv4 multicast sources or IPv6 receivers.

> (And why does Linux set DF on UDP by default, anyway?  It seems

The current defaults are bad. At least multicast should be sent with
path MTU discovery disabled by default.

-- 
Best regards,
Teemu Kiviniemi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 May 2010 20:56:10 +0200

> path MTU discovery disabled by default.

As far as I know, there is no implementation of PMTUD for UDP over IPv4 anywhere. So you can't enable it, because it doesn't exist. Sending non-TCP packets with DF=1 in the hopes that the application implements PMTUD is like pushing people out of a plane under the assumption they brought a parachute.

Separately from that, doing PMTUD for multicast, even assuming that an application using UDP could arbitrarily reduce its packet size, which is rarely if ever true, is a strange concept as there are multiple receivers and the paths to the different receivers can easily have different MTUs.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 May 2010 11:17:37 +1000

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> As far as I know, there is no implementation of PMTUD for UDP over IPv4 anywh
> ere. So you can't enable it, because it doesn't exist. Sending non-TCP packet
> s with DF=1 in the hopes that the application implements PMTUD is like pushin
> g people out of a plane under the assumption they brought a parachute.

Solaris and Linux both have/had this problem.  Sun/Oracle have a
fix.  I'm not sure where the default is with Linux kernels these
days.  We turn it off where we can in the DNS servers we ship.
 
> Separately from that, doing PMTUD for multicast, even assuming that an applic
> ation using UDP could arbitrarily reduce its packet size, which is rarely if 
> ever true, is a strange concept as there are multiple receivers and the paths
>  to the different receivers can easily have different MTUs.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]