-behave-multicast-02

As background, I started -behave-multicast prior to becoming working group
chair.  During WGLC, Brian Haberman pointed out that MAGMA had an I-D that
covered much of the same material.  I recently submitted -02 as an
individual contributor, not as WG chair.

Per the consensus at the Dallas IETF meeting, I revised the BEHAVE multicast
document to normatively cite the MAGMA IGMP Proxy document
(draft-ietf-magma-igmp-proxy-06, which is in the RFC Editor's queue).  The
BEHAVE document now merely points out the one where a NAT might need to do
something specific to NATting, which is only this:

   3.1.  Keep NAT Binding Open

   The NAT UDP requirements [I-D.ietf-behave-nat-udp] 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.

Comments welcome.

-d


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Thursday, June 22, 2006 12:50 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [Ietf-behave] I-D ACTION:draft-ietf-behave-multicast-02.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for 
> Hindrance Avoidance Working Group of the IETF.
> 
> 	Title		: Multicast Requirements for a Network 
> Address Port Translator (NAPT)
> 	Author(s)	: D. Wing
> 	Filename	: draft-ietf-behave-multicast-02.txt
> 	Pages		: 7
> 	Date		: 2006-6-22
> 	
> This document places requirements on a Network Address Translator
> (NAT) and Network Address and Port Translator (NAPT) that supports IP
> multicast by implementing an IGMP proxy.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-02.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email protected] with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-behave-multicast-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email protected].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-behave-multicast-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>