Multicast Requirements for a Network Address Port Translator (NAPT)

For users to accept and enjoy multicast, multicast UDP must work as seamlessly as unicast UDP. However, today's equipment has little consistency in multicast operation which results in inconsistant user experiences and failed multicast operation.

This document describes the behavior of a device providing multicast functions similar to and that additionally functions as a Network Address and Port Translator (NAPT), as described in section 4.1.2 of . Specifically out of scope of this document are: sending multicast traffic, PIM-SM, IPv6, and, IGMPv1. Sending multicast traffic is out of scope because it requires NATting the source IP address of such transmitted multicast traffic. Similarly, PIM is used only between routers and the IGMP Proxy devices that are scoped in this document do not function as routers. IPv6 is out of scope because NAT is not considered necessary with IPv6. IGMPv1 is not significantly deployed on the Internet. This document does not describe how to implement multicast, IGMPv2, or IGMPv3 in an IGMP Proxy device. Rather, it provides requirements for an IGMP Proxy device so that hosts behind the NAT can receive multicast traffic without any knowledge of the IGMP Proxy.

As detailed in the Document Scope section, the primary functions of an IGMP proxy device are to collect IGMP traffic from one interface and relay it to another interface, and accept multicast traffic from thatinterface and route -- or replicate it -- to other interface(s).

When a NAPT isn't used, a host might be connected to the Internet in a configuration such as this:

When an IGMP Proxy device is added to such a network, its behavior is identical towards the upstream (WAN) router. Specifically, when dealing with multicast, the IGMP Proxy has the same behavior towards the WAN as if it was a host. This document is a companion document to "NAT/Firewall Behavioral Requirements".

All requirements of apply equally to NAPTs and are incorporated herein by reference. Additionally, there are some requirements particular to NATs that implement IGMP proxies:

The NAT UDP requirements document only requires that a NAT binding be kept open for inside-to-outside UDP flows. However, with multicast traffic, UDP traffic will only arrive outside-to-inside. Hosts will periodically send IGMP Report messages to indicate continued interest in receiving the multicast traffic. As long as the IGMP Proxy sees a host is interested in receiving the flow, the NAT MUST continue to receive multicast traffic from the WAN and send it to the interfaces with interested hosts. Per IGMPv3, the default transmission interval for the periodic Membership Report is one second. Per IGMPv2, the default transmission interval for the periodic Unsolicited Report Interval is 10 seconds. If a host no longer sends its periodic messages within those timeframes, the NAT MAY consider the host no longer wants to receive the multicast traffic and can inform the upstream WAN router and close the NAT binding. However, it is suggested that the NAT wait until 3 missing unsolicited reports (to account for packet loss on the LAN, especially wireless LANs), or that the NAT first query the host using IGMPv2 or IGMPv3.

Compliance with this specification does not increase security risks beyond those already discussed in the Security Considerations section of IGMPv3.

This document does not require any IANA registrations.

Thanks to Bryan McLaughlin and Yiqun Cai for their assistance in writing this document.