Re: [Ietf-behave] Last Call: 'Multicast Requirements for a Network Address Port Translator (NAPT)' to BCP (draft-ietf-behave-multicast)
On Mon, 18 Sep 2006, The IESG wrote:
> 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
...
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
