Subject: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast)

From: The IESG <[email-masked]>
Date: Mon, 18 Sep 2006 09:36:09 -0500 (CDT) (envelope-from [email-masked])

The IESG has received a request from the Behavior Engineering for 
Hindrance Avoidance WG to consider the following document:

- 'Multicast Requirements for a Network Address Port Translator (NAPT) '
   <draft-ietf-behave-multicast-03.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-10-02.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-03.txt

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Sep 2006 11:02:02 -0500 (CDT) (envelope-from [email-masked])

Looks good to me.

Minor comment on first sentence of section 3.1 which states that
"Multicast traffic arrives only outside-to-inside."

It would be useful to explain briefly why this assumption is made (i.e.,

multicast orininating behind a NAT is not in-scope? or not possible?).

> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@xxxxxxxx] 
> Sent: Monday, September 18, 2006 7:36 AM
> To: IETF-Announce
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Last Call: 'Multicast Requirements for a Network 
> Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast)
> 
> The IESG has received a request from the Behavior Engineering 
> for Hindrance Avoidance WG to consider the following document:
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send any 
> comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists 
> by 2006-10-02.
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Sep 2006 11:27:04 -0500 (CDT) (envelope-from [email-masked])

> multicast orininating behind a NAT is not in-scope? or not possible?).

To do that you're doing what is now called "Any-source multicast" (ASM), the
'classic' multicast in RFC1112.  It isn't widely deployed, especially on the
Internet, for a bunch of good reasons, not the least of which anyone
broadcasting into the multicast session has to Do The Right Thing.  The
cooperative Internet faded from the world about 15 years ago.  I declared
RFC1112-style multicast as out-of-scope for this reason.  Let me know if it
should be declared in-scope.

I can add some text if that seems helpful.  How does this feel:

    >
    >    3.1.  NAPT Inbound Refresh Behavior
    >
    >    Multicast traffic arrives only outside-to-inside.
    >
    >          Discussion:  inside-to-outside multicast traffic
    >          requires Any Source Multicast (ASM) [RFC1112],
    >          which is not widely deployed on the Internet and
    >          is also considered out of scope for this document.
    >
    >    Thus, a NAPT needs to also meet REQ-6a of NAT UDP
    >    requirements [I-D.ietf-behave-nat-udp] ...
    >
    >

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Sep 2006 03:32:54 -0500 (CDT) (envelope-from [email-masked])

Dan Wing skrev:

Looks good to me.

It would be useful to explain briefly why this assumption is 
made (i.e.,

Dan,

I thought ASM would work as the document currently is specified. The 
IGMP proxy document does specify behavior for supporting senders 
(section 3.3 of RFC 4605) and with the correct translation the packets 
sent will have a good source address. So please clarify what you think 
will not work with ASM?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx

---

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Nov 2006 03:58:51 -0600 (CST) (envelope-from [email-masked])

>    <draft-ietf-behave-multicast-03.txt> as a BCP
...

This is a late comment, but -04 version was posted to address IETF LC 
comments and is still being digested.  Certainly the -04 versions 
still needs revision (see below).  The biggest issue is that the 
document only describes IGMPv1/IGMPv2 in proxy-IGMP configuration.

It would have been nice if review had been asked from MBONED WG; I 
don't recall seeing that.  I recall a query on MAGMA WG, but that WG 
has been winding down for the last couple of years and is no longer 
active.

substantial
-----------

Network Address Port Translator (NAPT) Any-Source Multicast Requirement

==> I'm slightly puzzled about this title and the current way to focus the
work.  

First, the document is supposed to support both ASM and SSM (though 
you describe in a section that SSM doesn't require anything, except 
that multicast passes through without translation) and that's what the 
WG has been charged to produce.  So, the title seems too specific.

Second, AFAICT, Behave WG doesn't produce 'NAT requirements'.  It 
documents behavioural requirements for NATs that want to conform to 
BEHAVE requirements.  I believe there is a difference between the two. 
(Similar comment applies to the Abstract.)  For example, the unicast 
UDP document seems to have a better phrased title.

...

Updates: RFC4605 (if approved)                          October 23, 2006

==> looking at point above, it is not clear whether it's in the
mandate of BEHAVE to Update Proxy-IGMP RFC.  Even if it was, it isn't 
obvious to me how this document does update it.  By imposing NAT timer 
requirements if IGMP proxy happens to implement NAT as well..?  It 
isn't clear how that relates to IGMP proxy function specified in 
RFC4605. I suggest removing the Updates: line.

...

   This document describes the behavior of a device providing any-source
   multicast proxy functions as described in [RFC4605] using ICMPv1
   [RFC1112] or ICMPv2 [RFC2236], and that additionally functions as a
   Network Address and Port Translator (NAPT), as described in section
   4.1.2 of [RFC2663].

   Specifically out of scope of this document are PIM-SM [RFC2362], and
   IPv6.  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 NAPT is not considered necessary with IPv6.

==> again this scope is more restricted than what's set out in BEHAVE
charter.  You restrict the solution to IGMPv1/IGMPv2 proxies only.  
What about IGMPv3?  What about NATs which might support multicast 
without proxying (e.g., PIM-SM -- which many routers also supporting 
NAT do support)? In any case, 'IGMP Proxy devices that are scoped in 
this document do not function as routers' requires rewording, as the 
NAT boxes do decrement TTL, so they are in fact for many purposes to 
be considered as routers.  (Also s/ICMP/IGMP/ above.)

   Packets with a multicast destination IP address do not have their
   destination IP address changed by a NAPT.

==> Actually, this could also be phrased as a behavioural requirement.  You
are assuming that this is how NAT has been implemented.  Has this 
behaviour been specified somewhere?  If yes, refer to it.  This is 
however rather obviously the way this is implemented, if multicast 
support is implemented at all, although in theory it might be possible 
to translate between global-scope and scope-relative multicast 
addresses at the border.

   If a NAPTed host is receiving any multicasts stream, and that NAPTed
   host sends UDP traffic to the same multicast address the NAPTed host
   is receiving, the NAPT MUST have a UDP mapping timer of 60 minutes.

==> this is unclear.  _Exactly_ 60 minutes?  Or the minimum (or some other
bound) of 60 minutes?  It is also unclear if the timer is meant to 
apply to transmission, receipt, or both; if draft-ietf-behave-udp 
specifies this adequately, maybe provide explicit reference. (Btw. 
s/multicasts/multicast/ or the like)

   Discussion: RTP [RFC3550] uses the source transport address (source
   IP address and source UDP port), in addition to the the RTP/RTCP SSRC
   value, to identify session members.

==> IIRC, RTP and RTCP also employ consecutive port numbers.  This is not
mentioned here.  Does that impose requirements for source port 
selection? But maybe this is already covered by 
draft-ietf-behave-nat-udp.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

==> Is this a normative reference to an informational document?  This
requires variance or moving to informative references if it's not critical
to understand this doc.
 
   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

==> this document has been obsoleted.  Is it appropriate for a BCP
document to normatively refer to an obsoleted document?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings