< draft-ietf-behave-multicast-07.txt   draft-ietf-behave-multicast-08.txt >
BEHAVE Working Group D. Wing BEHAVE Working Group D. Wing
Internet-Draft T. Eckert Internet-Draft T. Eckert
Intended status: Best Current Cisco Systems, Inc. Intended status: Best Current Cisco Systems, Inc.
Practice June 20, 2007 Practice July 3, 2007
Expires: December 22, 2007 Expires: January 4, 2008
Multicast Requirements for a Network Address (and port) Translator (NAT) IP Multicast Requirements for a Network Address (and port) Translator
draft-ietf-behave-multicast-07 (NAT)
draft-ietf-behave-multicast-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2007. This Internet-Draft will expire on January 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies requirements for a Network Address (and port) This document specifies requirements for a Network Address (and port)
Translator (NAT) that supports any source multicast or source Translator (NAT) that supports any source IP multicast or source
specific IP multicast. A multicast-capable NAT device that adheres specific IP multicast. An IP multicast-capable NAT device that
to the requirements of this document can optimize the operation of adheres to the requirements of this document can optimize the
multicast applications that are generally unaware of multicast NAT operation of IP multicast applications that are generally unaware of
devices. IP multicast NAT devices.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology Used in this Document . . . . . . . . . . . . . . 3
2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in this Document . . . . . . . . . . . . . . 5 3.1. Application SSM Considerations . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NATting of IP Multicast Packets . . . . . . . . . . . . . 5 4.1. NATting IP Multicast Packets . . . . . . . . . . . . . . . 6
4.2. IGMP Versions . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Receiving Multicast Packets . . . . . . . . . . . . . 6
4.1.2. Sending Multicast Packets . . . . . . . . . . . . . . 6
4.2. IGMP Versions . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 7 4.2.1. IGMPv1 or IGMPv2 . . . . . . . . . . . . . . . . . . . 7
4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. IGMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 8 4.3. Any Source Multicast Transmitters . . . . . . . . . . . . 8
4.4. Transport Protocol Support . . . . . . . . . . . . . . . . 9
5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 9 5. Requirements Summary . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informational References . . . . . . . . . . . . . . . . . 13 9.2. Informational References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Problem Statement 1. Introduction
In order for multicast applications to function well over NATs, In order for IP multicast applications to function well over NATs,
multicast UDP must work as seamlessly as unicast UDP. However, NATs multicast UDP must work as seamlessly as unicast UDP. However, NATs
have little consistency in multicast operation which results in have little consistency in IP multicast operation which results in
inconsistent user experiences and failed multicast operation. inconsistent user experiences and failed IP multicast operation.
2. Introduction This document targets requirements intended to enable correct
operations of any source and source specific IP multicast in devices
running IGMP proxy routing and NAT and without applying NAT to IP
multicast group addresses. This profile of functionality is the
expected best practice for residential access routers small branch
routers or similar deployments.
This document describes the requirements of an IP multicast-capable Most of the principles outlined in this document do also apply when
NAT. These requirements allow existing UDP any source IP multicast using protocols other than IGMP, such as PIM-SM, or when performing
[RFC1112] applications or source specific IP multicast [RFC4607] NAT between multiple "inside" interfaces, but explicit consideration
applications to function without awareness of the multicast-capable for these cases is outside the scope of this document.
NAT device. Additionally, non-UDP IP multicast applications can be
received.
This document describes the behavior of a device that functions as a This document describes the behavior of a device that functions as a
NAT for unicast flows and also forwards IP multicast traffic in NAT for unicast flows and also forwards IP multicast traffic in
either direction ('inside' to 'outside', or 'outside' to 'inside'). either direction ('inside' to 'outside', or 'outside' to 'inside').
Hosts on the 'inside' interface(s) of a NAT indicate their interest Hosts on the 'inside' interface(s) of a NAT indicate their interest
in receiving a multicast flow by sending an IGMP message to their in receiving an IP multicast flow by sending an IGMP message to their
local interface. A multicast-capable NAT will see that IGMP message local interface. An IP multicast-capable NAT will see that IGMP
(IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376]), possibly message (IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376]),
perform some functions on that IGMP message, and forward it to its possibly perform some functions on that IGMP message, and forward it
upstream router. This causes the upstream router to send that to its upstream router. This causes the upstream router to send that
multicast traffic to the NAT, which forwards it to those inside IP multicast traffic to the NAT, which forwards it to those inside
segment(s) with host(s) that had previously sent IGMP messages for segment(s) with host(s) that had previously sent IGMP messages for
that multicast traffic. that IP multicast traffic.
Out of scope of this document are PIM-SM [RFC4601] and IPv6 Out of scope of this document are PIM-SM [RFC4601] and IPv6
[RFC2460]. The IGMP Proxy devices that are scoped in this document [RFC2460]. The IGMP Proxy devices that are scoped in this document
do not forward PIM-SM. IPv6 is out of scope because NAT is not do not forward PIM-SM. IPv6 is out of scope because NAT is not
considered necessary with IPv6. considered necessary with IPv6.
This document is a companion document to "NAT Behavioral Requirements This document is a companion document to "NAT Behavioral Requirements
for Unicast UDP" [RFC4787]. for Unicast UDP" [RFC4787].
2.1. Background 2. Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, the term "NAT" applies to both Network Address and
Port Translator (NAPT) as well as a NAT that does not translate
ports.
The term 'inside' refers to the interface(s) on a NAT which contain
hosts that wish to send or receive IP multicast traffic. The term
'outside' refers to the interface(s) the NAT forwards IGMP membership
messages to, and where the NAT routes IP multicast traffic that
originates from hosts on its 'inside' interface.
3. Background
When a NAT isn't used, a host might be connected to the Internet in a When a NAT isn't used, a host might be connected to the Internet in a
configuration such as this: configuration such as this:
+-------------+ +-------------+
+------+ | DSL modem | +------------+ +------+ | DSL modem | +------------+
| host +---+ or +-//-+ WAN Router | | host +---+ or +-//-+ WAN Router |
+------+ | cable modem | +------------+ +------+ | cable modem | +------------+
+-------------+ +-------------+
Figure 1: Network without NATting IGMP Proxy Figure 1: Network without NATting IGMP Proxy
skipping to change at page 5, line 7 skipping to change at page 5, line 19
IGMP messages are never logically forwarded by the IGMP proxying IGMP messages are never logically forwarded by the IGMP proxying
device, but rather sourced or received by it. In general, receipt device, but rather sourced or received by it. In general, receipt
of IGMP messages by the device updated IGMP state maintained by of IGMP messages by the device updated IGMP state maintained by
the device and either those changes or timers trigger the sending the device and either those changes or timers trigger the sending
of IGMP messages. "Forwarding" of IGMP protocol messages may thus of IGMP messages. "Forwarding" of IGMP protocol messages may thus
only happen implicitly by implementation optimizations that create only happen implicitly by implementation optimizations that create
shortcuts in this machinery. shortcuts in this machinery.
This specifically means that IGMP protocol packets sent by the NAT This specifically means that IGMP protocol packets sent by the NAT
device will always use IP address of th interface (inside or outside) device will always use IP address of the interface (inside or
to which they are sent, but because those packets are logically outside) to which they are sent, but because those packets are
"sourced" and not "forwarded" , NAT does not have any impact into logically "sourced" and not "forwarded", NAT does not have any impact
this. into this.
Unlike unicast flows, packets with a multicast destination IP address
do not have their destination IP address or destination port changed
by a NAT. However, their source IP address (and source UDP port, in
some cases with a NAPT) is changed if the packet goes from an
'inside' interface of a NAT to the 'outside' interface of a NAT --
similar to the behavior of a unicast packet across those same
interfaces.
Adding NAT to IGMP proxying does change the processing of IP Adding NAT to IGMP proxying does change the processing of IP
multicast data packets forwarded across the IGMP proxying device as multicast data packets forwarded across the IGMP proxying device as
described in the following sections. These changes do actually described in the following sections. These changes do actually
simplify the ability to deploy IGMP proxying over a device that does simplify the ability to deploy IGMP proxying over a device that does
NOT perform NAT. NOT perform NAT.
With an IGMP Proxy NAT Device, IP multicast data traffic sourced from With an IGMP Proxy NAT Device, IP multicast data traffic sourced from
hosts on the inside is NATed such that it will look like being hosts on the inside is NATed such that it will look like being
sourced from a directly connected host to the WAN router, thus sourced from a directly connected host to the WAN router, thus
eliminating all non-standard PIM-SM concerns/configurations described eliminating all non-standard PIM-SM concerns/configurations described
in section 3.2 of [RFC4605]. in section 3.2 of [RFC4605].
3. Conventions Used in this Document 3.1. Application SSM Considerations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, the term "NAT" applies to both Network Address and SSM requires listeners to know the SSM channel (S,G), which is
Port Translator (NAPT) as well as a NAT that does not translate comprised of the IP source address (S) and the IP multicast group
ports. (G). An SSM sender needs to communicate its IP address in its SSM
session establishment message (e.g., in its SDP). When the SSM
sender is behind a NAT and the SSM receiver(s) are on the other side
of that NAT, the SSM sender will need to determine its IP source
address relevant to the SSM receivers; generally, this will be the
'outside' IP address of the NAT. This 'outside' address needs to be
included in the SSM session establishment message (e.g., SDP) so that
listeners on the 'outside' of the NAT can receive the SSM channel.
The term 'inside' refers to the interface(s) on a NAT which contain If there are SSM listeners on both the 'outside' and 'inside' of the
hosts that wish to send or receive multicast traffic. The term NAT, it may be valuable to consider using ICE [I-D.ietf-mmusic-ice]
'outside' refers to the interface(s) the NAT forwards IGMP membership in the session advertisement; the full scope of the interaction
messages to, and where the NAT routes multicast traffic that between SSM and ICE is beyond the scope of this document.
originates from hosts on its 'inside' interface.
4. Requirements 4. Requirements
4.1. NATting of IP Multicast Packets 4.1. NATting IP Multicast Packets
Unlike unicast flows, packets with a multicast destination IP address 4.1.1. Receiving Multicast Packets
do not have their destination IP address or destination port changed
by a NAT. However, their source IP address (and source UDP port, in
some cases with a NAPT) is changed if the packet goes from an
'inside' interface of a NAT to the 'outside' interface of a NAT --
similar to the behavior of a unicast packet across those same
interfaces.
REQ-1: For IP multicast packets that are forward to a host(s) on its REQ-1: For IP multicast packets that are forward to a host(s) on
inside interface(s), a NAT MUST NOT modify the destination IP its inside interface(s), a NAT MUST NOT modify the
address or destination port of the packets. destination IP address or destination port of the packets.
Note: If a NAT were to violate this requirement and modify the Note: If a NAT were to modify the destination IP or port
destination IP or port addresses, the NAT would also need to addresses, the NAT would also need to modify session announcements
modify session announcements (e.g., electronic program guides, (e.g., electronic program guides, SAP) and session establishment
SAP) and session establishment and control (e.g., SIP, RTSP) and control (e.g., SIP, RTSP) messages. Such modification is not
messages. Such modification is not considered a best practice. considered a best practice.
Note: This behavior is required for UDP, but has a useful side- REQ-2: A NAT MUST forward IP multicast UDP datagrams from its
effect that it permits other, non-UDP multicast protocols across a 'outside' interface to multicast receivers on its 'inside'
NAT (e.g., PGM [RFC3208], RSVP [RFC2750]). interface(s).
REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g.,
PGM [RFC3208], RSVP [RFC2750]) from its 'outside' interface
to IP multicast receivers on its inside interface(s).
4.1.2. Sending Multicast Packets
The following requirement is normal NAT behavior for unicast packets, The following requirement is normal NAT behavior for unicast packets,
as described in [RFC4787], and provides support for multicast senders as described in [RFC4787], and provides support for IP multicast
behind the NAT: senders behind the NAT:
REQ-2: A NAT MUST modify the source IP address of packets that REQ-4: A NAT MUST modify the source IP address of packets that
arrive from an 'inside' interface towards the 'outside' arrive from an 'inside' interface towards the 'outside'
interface so that those packets use the NAT's public IP interface so that those packets use the NAT's 'outside' IP
address(es). address(es).
a: If the NAT also performs port translation (that is, it is a: If the NAT also performs port translation (that is, it
a NAPT), the NAT MUST also create a mapping to allow is a NAPT), the NAT MUST also create a mapping to allow
responses to that multicast packet to be received by the responses to that IP multicast packet to be received by
appropriate host. For any source multicast, also see the appropriate host. For any source IP multicast, also
Section 4.3. For source specific multicast, also see see Section 4.3.
Section 4.2.2.
b: To support learning their public transport address, the b: To allow hosts to learn the NAT's 'outside' interface
NAT MUST have "Endpoint-Independent Mapping" behavior address, the NAT MUST have "Endpoint-Independent
(REQ-1 of [RFC4787]) no matter if the destination IP Mapping" behavior (REQ-1 of [RFC4787]) no matter if the
address is a unicast address or a multicast address. destination IP address is a unicast address or an IP
multicast address.
REQ-5: A NAT MUST forward IP multicast UDP datagrams from its
'inside' interface(s) to its 'outside' interface.
As many NATs are located adjacent to bandwidth-constrained access
links, it is important that IP multicast senders communicating with
IP multicast receivers behind the NAT not have their flows consume
bandwidth on the access link. This is accomplished by applications
using administratively scoped IP addresses.
REQ-6: A NAT MUST NOT forward administratively scoped IP multicast
traffic (239.0.0.0/8) [RFC2365] from its 'inside'
interface(s) to its 'outside' interface, unless the NAT has
been configured to do so.
4.2. IGMP Versions 4.2. IGMP Versions
REQ-3: A NAT MAY support IGMPv1 (although IGMPv1 is considered REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered
obsolete). obsolete).
REQ-4: A NAT MUST support IGMPv2. REQ-8: A NAT MUST support IGMPv2.
REQ-5: A NAT SHOULD support IGMPv3. REQ-9: A NAT SHOULD support IGMPv3.
4.2.1. IGMPv1 or IGMPv2 4.2.1. IGMPv1 or IGMPv2
For IGMPv1 and IGMPv2, a NAT can successfully operate by merely For IGMPv1 and IGMPv2, a NAT can successfully operate by merely
forwarding IGMP membership reports and queries between the interested forwarding IGMP membership reports and queries between the interested
hosts (on its internal interface) towards its external interface. hosts (on its internal interface) towards its external interface.
REQ-6: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the REQ-10: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the
NAT MAY simply receive IGMP membership reports on the inside NAT MAY simply receive IGMP membership reports on the inside
interface, NAT them, and relay the IGMP membership report, interface, NAT them, and relay the IGMP membership report,
and do the same function in the opposite direction to the and do the same function in the opposite direction to the
IGMP listeners. That is, the NAT does not need to do any IGMP listeners. That is, the NAT does not need to do any
aggregation of IGMP messages. aggregation of IGMP messages.
a: However, it is RECOMMENDED that such a NAT implement a: However, it is RECOMMENDED that such a NAT implement
IGMP/MLD Proxying [RFC4605], because IGMP aggregation IGMP/MLD Proxying [RFC4605], because IGMP aggregation
provides a useful optimization. provides a useful optimization.
4.2.2. IGMPv3 4.2.2. IGMPv3
When a IGMPv3 proxying device receives an IGMP membership on an When a IGMPv3 proxying device receives an IGMP membership on an
inside interface, it creates its own IGMP proxying membership state inside interface, it creates its own IGMP proxying membership state
and its own IGMP forwarding table. It then creates an independent and its own IGMP forwarding table. It then creates an independent
IGMP membership report on its outside interface reporting the IGMP membership report on its outside interface reporting the IP
multicast groups/channels -- but there is no direct relationship or multicast groups/channels -- but there is no direct relationship or
"forwarding" of IGMP membership reports or queries across the "forwarding" of IGMP membership reports or queries across the
interfaces. The NAT device will subsequently receive a multicast interfaces. The NAT device will subsequently receive a IP multicast
data packet on the outside ('public') interface and forward the data packet on the 'outside' interface and forward the IP multicast
multicast packet to inside ('internal') interfaces based on its IGMP packet to the 'inside' interface(s) based on its IGMP forwarding
forwarding table. table.
By performing NAT on IGMPv3 membership reports, the membership By performing NAT on IGMPv3 membership reports, the membership
reports appear to originate from a single IGMPv3 reporter instead of reports appear to originate from a single IGMPv3 reporter instead of
different reporters. Because IGMPv3 has different types of different reporters. Because IGMPv3 has different types of
membership reports differentiating between status (IS_INCLUDE, membership reports differentiating between status (IS_INCLUDE,
IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if
a NAT were to interleave reports from two or more reporters (joining a NAT were to interleave reports from two or more reporters (joining
and leaving the same groups) the NAT would create a sequence of and leaving the same groups) the NAT would create a sequence of
packets that are not compliant with an IGMPv3 reporter [RFC3376]. packets that are not compliant with an IGMPv3 reporter [RFC3376].
For this reason, the following requirements are specified: For this reason, the following requirements are specified:
REQ-7: If a NAT supports IGMPv3, the NAT MUST: REQ-11: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD
Proxying [RFC4605]. Such compliance causes the NAT to
a: implement IGMP/MLD Proxying [RFC4605]. Such compliance aggregate the IGMPv3 membership reports and report only the
causes the NAT to aggregate the IGMPv3 membership reports aggregated information upstream.
and report only the aggregated information upstream, and;
b: support any source multicast listeners and transmitters
(Section 4.3), and;
c: support source specific multicast listeners and REQ-12: If a NAT supports IGMPv3, the NAT MUST implement Source
transmitters ([RFC4604], section 4.2 of [RFC4607]). Specific Multicast for IP [RFC4607] and IGMPv3/MLDv2 for SSM
[RFC4604].
Failure to implement IGMP aggregation ([RFC4605]) will cause Failure to implement IGMP aggregation ([RFC4605]) will cause
undesired temporary blackholing of multicast traffic. For example, undesired temporary blackholing of IP multicast traffic. For
consider two hosts behind the same NAT. If one host is joining a example, consider two hosts behind the same NAT. If one host is
session at the same time another is leaving the session, and the NAT joining a session at the same time another is leaving the session,
were to merely relay the join and leave upstream, the session will be and the NAT were to merely relay the join and leave upstream, the
terminated, and the join and leave announcements would not comply session will be terminated, and the join and leave announcements
with section 5 of [RFC3376]. would not comply with section 5 of [RFC3376].
Primarily due to NATs functioning as IGMP proxies with multiple
receivers behind the NAT, multicast applications are encouraged to
use identifiers, rather than IP addresses and UDP ports, to identify
specific multicast receivers (e.g., [I-D.ietf-avt-rtcpssm] encourages
SSM applications to not rely exclusively on transport addresses for
collision detection). As compared to any source multicast, the use
of such receiver identifiers removes the need for the NAT to have
long mapping timers; instead, the timers in [RFC4787] are used when a
host transmits to a source specific IP multicast address.
Note: SSM requires listeners to know the SSM channel (S,G), which
is comprised of the IP source address (S) and the multicast group
(G). An SSM sender needs to communicate its IP address in its SSM
session establishment message (e.g., SDP). When the SSM sender is
behind a NAT and the SSM receiver(s) are on the other side of that
NAT, the SSM sender will need to determine its IP source address
relevant to the SSM receivers; generally, this will be the public
IP address of the NAT. This public address needs to be included
in the SSM session establishment message (e.g., SDP) so that
listeners on the public side of the NAT can receive the SSM
channel.
If there are SSM listeners on both the public and private side of
the NAT, it may be valuable to consider using ICE
[I-D.ietf-mmusic-ice] in the session advertisement; the full scope
of the interaction between SSM and ICE is beyond the scope of this
document
4.3. Any Source Multicast Transmitters 4.3. Any Source Multicast Transmitters
Any source multicast (ASM) uses the IP addresses in the 224/8 through Any source multicast (ASM) uses the IP addresses in the 224/8 through
231/8, and 233/8 through 239/8 range [IANA-ALLOC]. 231/8, and 233/8 through 239/8 range [IANA-ALLOC].
When a host both receives an ASM stream and sends traffic into it, When a host both receives an ASM stream and sends traffic into it,
using RTP [RFC3550], there is a potential problem if a NAT merely using RTP [RFC3550], there is a potential problem if a NAT merely
followed the requirements of [RFC4787]. The problem is that RTP uses followed the requirements of [RFC4787]. The problem is that RTP uses
the source transport address (source IP address and source UDP port) the source transport address (source IP address and source UDP port)
and the RTP/RTCP SSRC value to identify session members. If a and the RTP/RTCP SSRC value to identify session members. If a
session member sees the same SSRC arrive from a different transport session member sees the same SSRC arrive from a different transport
address, that session member will perform RTP collision detection address, that session member will perform RTP collision detection
(section 8.2 of [RFC3550]). If a NAT merely followed the (section 8.2 of [RFC3550]). If a NAT merely followed the
requirements of [RFC4787] and timed out a UDP session after 2 minutes requirements of [RFC4787] and timed out a UDP session after 2 minutes
of inactivity and RTCP receiver reports are sent less often than of inactivity and RTCP receiver reports are sent less often than
every 2 minutes, RTP collision detection would be performed by other every 2 minutes, RTP collision detection would be performed by other
session members sharing the same SSRC, complicating diagnostic tools session members sharing the same SSRC, complicating diagnostic tools
and potentially interfering with jitter buffer algorithms. This and potentially interfering with jitter buffer algorithms. This
situation can occur, for example, with a multicast group of situation can occur, for example, with an IP multicast group of
approximately 300 members with a normal 50kbps audio RTP stream. approximately 300 members with a normal 50kbps audio RTP stream.
REQ-8: If a host on the inside interface of a NAT belongs to an any Source specific IP multicast does not need this long timer because
source multicast host group and the host sends a UDP packet application feedback reports are unicast (rather than IP multicast)
to the same group, the NAT SHOULD have a UDP mapping timer of and identifiers, rather than IP addresses and UDP ports, are used to
60 minutes for that mapping. identify a specific IP multicast receiver (e.g.,
[I-D.ietf-avt-rtcpssm].
a: This UDP mapping SHOULD be destroyed when the host leaves
that host group. The NAT is aware of this through
receipt of an IGMP message from the host.
b: If a NAT has exhausted its resources, the NAT MAY time
out that mapping before 60 minutes have elapsed, but this
is discouraged. Note that even in a situation with
resource exhaustion, a NAT is still required to follow
the minimum mapping duration of 2 minutes (REQ-5 of
[RFC4787]).
4.4. Transport Protocol Support REQ-13: If a host on the inside interface of a NAT belongs to an any
source IP multicast host group and the host sends a UDP
packet to the same group, the NAT SHOULD have a UDP mapping
timer of 60 minutes for that mapping.
REQ-9: A NAT MUST support transport of multicast UDP with both a: This UDP mapping SHOULD be destroyed when the host
multicast receivers and with multicast transmitters on the leaves that host group. The NAT is aware of this
'inside' interface(s) of the NAT. through receipt of an IGMP message from the host.
REQ-10: A NAT SHOULD support transport of multicast non-UDP b: If a NAT has exhausted its resources, the NAT MAY time
protocols (e.g., PGM [RFC3208], RSVP [RFC2750]) with out that mapping before 60 minutes have elapsed, but
multicast receivers on the 'inside' interface(s) of the NAT. this is discouraged. Note that even in a situation with
resource exhaustion, a NAT is still required to follow
the minimum mapping duration of 2 minutes (REQ-5 of
[RFC4787]).
5. Requirements Summary 5. Requirements Summary
This section summarizes the requirements; if there is a difference in This section summarizes the requirements; if there is a difference in
this summary and the text in the main body of the document, the main this summary and the text in the main body of the document, the main
body takes precedence. body takes precedence.
REQ-1: For IP multicast packets that are forward to a host(s) on REQ-1: For IP multicast packets that are forward to a host(s) on
its inside interface(s), a NAT MUST NOT modify the its inside interface(s), a NAT MUST NOT modify the
destination IP address or destination port of the packets. destination IP address or destination port of the packets.
REQ-2: a NAT MUST modify the source IP address of packets that REQ-2: A NAT MUST forward IP multicast UDP datagrams from its
'outside' interface to IP multicast receivers on its
'inside' interface(s).
REQ-3: A NAT SHOULD forward IP multicast non-UDP protocols (e.g.,
PGM [RFC3208], RSVP [RFC2750]) from its 'outside' interface
to IP multicast receivers on its inside interface(s).
REQ-4: A NAT MUST modify the source IP address of packets that
arrive from an 'inside' interface towards the 'outside' arrive from an 'inside' interface towards the 'outside'
interface so that those packets use the NAT's public IP interface so that those packets use the NAT's 'outside' IP
address(es). address(es).
a: If the NAT also performs port translation (that is, it a: If the NAT also performs port translation (that is, it
is a NAPT), the NAT MUST also create a mapping to allow is a NAPT), the NAT MUST also create a mapping to allow
responses to that multicast packet to be received by the responses to that IP multicast packet to be received by
appropriate host. For any source multicast, also see the appropriate host. For any source multicast, also
Section 4.3. For source specific multicast, also see see Section 4.3.
Section 4.2.2.
b: To support learning their public transport address, the b: To allow hosts to learn the NAT's 'outside' interface
NAT MUST have "Endpoint-Independent Mapping" behavior address, the NAT MUST have "Endpoint-Independent
(REQ-1 of [RFC4787]) no matter if the destination IP Mapping" behavior (REQ-1 of [RFC4787]) no matter if the
address is a unicast address or a multicast address. destination IP address is a unicast address or an IP
multicast address.
REQ-3: A NAT MAY support IGMPv1 (although IGMPv1 is considered REQ-5: A NAT MUST forward IP multicast UDP datagrams from its
'inside' interface(s) to its 'outside' interface.
REQ-6: A NAT MUST NOT forward administratively scoped IP multicast
traffic (239/8) [RFC2365] from its 'inside' interface(s) to
its 'outside' interface, unless the NAT has been configured
to do so.
REQ-7: A NAT MAY support IGMPv1 (although IGMPv1 is considered
obsolete). obsolete).
REQ-4: A NAT MUST support IGMPv2. REQ-8: A NAT MUST support IGMPv2.
REQ-5: A NAT SHOULD support IGMPv3. REQ-9: A NAT SHOULD support IGMPv3.
REQ-6: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the REQ-10: If a NAT supports IGMPv1 and/or IGMPv2 (but not IGMPv3), the
NAT MAY simply receive IGMP membership reports on the inside NAT MAY simply receive IGMP membership reports on the inside
interface, NAT them, and relay the IGMP membership report, interface, NAT them, and relay the IGMP membership report,
and do the same function in the opposite direction to the and do the same function in the opposite direction to the
IGMP listeners. That is, the NAT does not need to do any IGMP listeners. That is, the NAT does not need to do any
aggregation of IGMP messages. aggregation of IGMP messages.
a: However, it is RECOMMENDED that such a NAT implement a: However, it is RECOMMENDED that such a NAT implement
IGMP/MLD Proxying [RFC4605], because IGMP aggregation IGMP/MLD Proxying [RFC4605], because IGMP aggregation
provides a useful optimization. provides a useful optimization.
REQ-7: If a NAT supports IGMPv3, the NAT MUST: REQ-11: If a NAT supports IGMPv3, the NAT MUST implement IGMP/MLD
Proxying [RFC4605]. Such compliance causes the NAT to
a: implement [RFC4605]. Such compliance causes the NAT to aggregate the IGMPv3 membership reports and report only the
aggregate the IGMPv3 membership reports and report only aggregated information upstream.
the aggregated information upstream, and;
b: support any source multicast listeners and transmitters
(Section 4.3), and;
c: support source specific multicast listeners and
transmitters ([RFC4604], section 4.2 of [RFC4607]).
REQ-8: If a host on the inside interface of a NAT belongs to an any REQ-12: If a host on the inside interface of a NAT belongs to an any
source multicast host group and the host sends a UDP packet source multicast host group and the host sends a UDP packet
to the same group, the NAT SHOULD have a UDP mapping timer to the same group, the NAT SHOULD have a UDP mapping timer
of 60 minutes for that mapping. of 60 minutes for that mapping.
a: This UDP mapping SHOULD be destroyed when the host a: This UDP mapping SHOULD be destroyed when the host
leaves that host group. The NAT is aware of this leaves that host group. The NAT is aware of this
through receipt of an IGMP message from the host. through receipt of an IGMP message from the host.
b: If a NAT has exhausted its resources, the NAT MAY time b: If a NAT has exhausted its resources, the NAT MAY time
out that mapping before 60 minutes have elapsed, but out that mapping before 60 minutes have elapsed, but
this is discouraged. Note that even in a situation with this is discouraged. Note that even in a situation with
resource exhaustion, a NAT is still required to follow resource exhaustion, a NAT is still required to follow
the minimum mapping duration of 2 minutes (REQ-5 of the minimum mapping duration of 2 minutes (REQ-5 of
[RFC4787]). [RFC4787]).
REQ-9: A NAT MUST support transport of multicast UDP with both
multicast receivers and multicast transmitters on the
'inside' interface(s) of the NAT.
REQ-10: A NAT SHOULD support transport of multicast non-UDP
protocols (e.g., PGM [RFC3208], RSVP [RFC2750]) with
multicast receivers on the 'inside' interface(s) of the NAT.
6. Security Considerations 6. Security Considerations
The Security Considerations sections of IGMPv3 [RFC3376] and IGMP The Security Considerations sections of IGMPv3 [RFC3376] and IGMP
Proxying [RFC4605] apply to a device complying with this document. Proxying [RFC4605] apply to a device complying with this document.
When a host is using RTP and participating in an any source multicast When a host is using RTP and participating in an any source IP
session, the host's periodic RTCP receiver reports cause the NAT to multicast session, the host's periodic RTCP receiver reports cause
create a mapping. When the group size is less than approximately the NAT to create a mapping. When the group size is less than
300, the RTCP reports are sent frequently enough that a NAT's mapping approximately 300, the RTCP reports are sent frequently enough that a
will always be kept open. When the group size is larger than NAT's mapping will always be kept open. When the group size is
approximately 300, the RTCP reports are sent less frequently. The larger than approximately 300, the RTCP reports are sent less
recommendation in Section 4.3 causes the NAT mapping to be kept open frequently. The recommendation in Section 4.3 causes the NAT mapping
for the duration of the host's participation in that multicast to be kept open for the duration of the host's participation in that
session no matter the size of the multicast host or periodicity of IP multicast session no matter the size of the multicast host or
the host's RTCP transmissions. periodicity of the host's RTCP transmissions.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA registrations. This document does not require any IANA registrations.
8. Acknowledgments 8. Acknowledgments
Thanks to Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Alfred Thanks to Yiqun Cai, Stephen Casner, Remi Denis-Courmont, Alfred
Hines, Prashant Jhingran, Albert Manfredi, Marcus Maranhao, Bryan Hines, Prashant Jhingran, Albert Manfredi, Marcus Maranhao, Bryan
McLaughlin, Pekka Savola, and Magnus Westerlund for their assistance McLaughlin, Pekka Savola, and Magnus Westerlund for their assistance
skipping to change at page 12, line 26 skipping to change at page 12, line 26
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
9.2. Informational References 9.2. Informational References
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Chesterfield, J., "RTCP Extensions for Single-Source Chesterfield, J., "RTCP Extensions for Single-Source
Multicast Sessions with Unicast Feedback", Multicast Sessions with Unicast Feedback",
draft-ietf-avt-rtcpssm-13 (work in progress), March 2007. draft-ietf-avt-rtcpssm-13 (work in progress), March 2007.
skipping to change at page 13, line 42 skipping to change at page 14, line 5
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D.,
Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo,
L., Tweedly, A., Bhaskar, N., Edmonstone, R., L., Tweedly, A., Bhaskar, N., Edmonstone, R.,
Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport
Protocol Specification", RFC 3208, December 2001. Protocol Specification", RFC 3208, December 2001.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
 End of changes. 58 change blocks. 
222 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/