RFC 2588 (rfc2588) - Page 1 of 12

IP Multicast and Firewalls

Alternative Format: Original Text Document
Next >
Network Working Group                                      R. Finlayson
Request for Comments: 2588                                     LIVE.COM
Category: Informational                                        May 1999


                       IP Multicast and Firewalls

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Abstract

   Many organizations use a firewall computer that acts as a security
   gateway between the public Internet and their private, internal
   'intranet'.  In this document, we discuss the issues surrounding the
   traversal of IP multicast traffic across a firewall, and describe
   possible ways in which a firewall can implement and control this
   traversal.  We also explain why some firewall mechanisms - such as
   SOCKS - that were designed specifically for unicast traffic, are less
   appropriate for multicast.

2. Introduction

   A firewall is a security gateway that controls access between a
   private adminstrative domain (an 'intranet') and the public Internet.
   This document discusses how a firewall handles IP multicast [1]
   traffic.

   We assume that the external side of the firewall (on the Internet)
   has access to IP multicast - i.e., is on the public "Multicast
   Internet" (aka. "MBone"), or perhaps some other multicast network.

   We also assume that the *internal* network (i.e., intranet) supports
   IP multicast routing.  This is practical, because intranets tend to
   be centrally administered.  (Also, many corporate intranets already
   use multicast internally - for training, meetings, or corporate
   announcements.)  In contrast, some previously proposed firewall
   mechanisms for multicast (e.g., [2]) have worked by sending *unicast*
   packets within the intranet.  Such mechanisms are usually
   inappropriate, because they scale poorly and can cause excessive
   network traffic within the intranet.  Instead, it is better to rely



Finlayson                    Informational
Next >