IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)
draft-ietf-behave-multicast-12

[Ballot comment]
I have chatted w/ the authors and they have given me sample text that would clear my discuss. I just need to see a draft.

[Ballot discuss]
In response Note that since routing protocols use 224 space (OSPF, RIP) and they are generally special cases. If the authors are going to think and spec in 224 space, they are going to have to address this issue as well as Mark's BonJour example.

[Ballot discuss]
>            a:  If a network is multihomed, the NATs or the network
>                configuration MUST ensure that duplicate instances of
>                the multicast data traffic do not appear on the public
>                network.  This can be accomplished by network design (an
>                access control list) or a protocol between the NATs
>                (e.g., the NAT with the higher IP address transmits
>                multicast data towards the public network and other NATs
>                drop it).

I think there needs to be a default recommendation as a "must implement" to truly satisfy the requirement. e.g., if one NAT can only support the "protocol" of transmitting or dropping based on IP address, and another NAT only via ACLs, then you have a non-interoperable situation.

>    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.

Shouldn't there be a similar requirement for "Local Network Control Block (224.0.0/24)" (a.k.a. "link local multicast')

From RFC3171:
> 3. Local Network Control Block (224.0.0/24)
>
>    Addresses in the Local Network Control block are used for protocol
>    control traffic that is not forwarded off link.  Examples of this
>    type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

[Ballot discuss]
I realize that the summarized requirements are non-normative,
but if I were the implementor I'd be reading them. And there's
a significant difference with respect to REQ-12:

http://www.arkko.com/temp/summary-from-reqs.diff.html

Can you fix this before approving the document? If so,
I will move to a Yes position, this is an overall very
good document.

[Ballot discuss]
I realize that the summarized requirements are informational,
but if I were the implementor I'd be reading them. And there's
a significant difference with respect to REQ-12:

http://www.arkko.com/temp/summary-from-reqs.diff.html

Can you fix this before approving the document? If so,
I will move to a Yes position, this is an overall very
good document.

[Ballot comment]
This document uses acronyms, such as SDP, without expansion or reference.  Please fix.

Nit:

  to IP multicast group addresses.  This profile of functionality is
  the expected best practice for residential access routers small

Missing "," between "access routers" and "small".

[Ballot comment]
Section 5., paragraph 1:
>    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
>    body takes precedence.

  Either make sure that there are no differences, or remove this section
  (the document isn't long enough to need a summary.)

[Ballot comment]
REQ-6 states:

            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.

The semantics of "MUST NOT ... unless configured to do so" are tricky.
As far as I can tell, this requirement is only imposed on the default
configuration.  If that is correct, it might be clearer to state the requirement
in terms of the default configuration:

            The NAT's default configuration MUST NOT forward
            administratively scoped IP multicast
            traffic (239.0.0.0/8) [RFC2365] from its 'inside'
            interface(s) to its 'outside' interface.

[Ballot discuss]
I found this document to be very useful, and expect to keep it close for when I need to
sort out the multicast protocols.  However, I had problems in understanding several
tables, and they are a very important feature of this document.

There are five different values in the "cells" of the table in section 2.2.4: Yes, No,
Recommended, Doesn't work, and Few implementations.  I am unsure about the
difference between Yes and Recommended, and about the difference bewteen No
and Doesn't work.  (I am assuming that Few implementations means that it would
work but isn't widely deployed?)  I believe text or a legend is needed.

Section 2.3 Learning (Active) Sources includes subsections on SSM, MSDP, and
Embedded-RP but the summary table includes bi-dir single domain and PIM-SM
single domain.  I could only  find a single sentence in the intro to 2.3 that seems
to apply:

  Learning active sources is a relatively straightforward process with
  a single PIM-SM domain and with a single RP, but having a single
  PIM-SM domain for the whole Internet is a completely unscalable model
  for many reasons.

The information in the table is consistent (Yes for IPv4 and IPv6, with a status of
"for intra-domain only"), but I have no idea what mechanisms are used to find
the sources in this case.  An extra sentence or two in section 2.3 could probably
remedy the situation.

In section 2.6.3, the technique "Host receiving SSM" indicates IGMPv3 should be
used in IPv4 environments and MLDv2 in IPv6.  The Note for this technique is
rather cryptic: "Also SSM-mapping".  After some re-reading, I concluded that
"Host receiving SSM" can also be implemented using IGMPv1 and IGMPv2 in
conjunction with SSM mapping in IPv4 environments and can be implemented
with MLDv1 and SSM mapping in IPv6 environments?  I don't know if that's
correct, but I think some clarification is in order...

Section 2.7.3, the table entry for IGMP/MLD snooping has the following note:
      "Common, IGMPv3 or MLD bad"

Is this a reference to "hosts may recieve unnecessary muticast traffic ... if IGMPv3
or MLDv2 source filters are used" as stated in section 2.7?  In that case, "bad"
means more effective techniques for flooding reduction are available, but deployment
wouldn't cause system failure, right?  Perhaps a note following the table would
clarify the issues cleanly...

[Ballot comment]
Please add RPF to section 1.1.

Section 2.1.1 PIM-SM

While this is arguably the most important of the multicast
protocols, there is very little information about the protocol
here.  In fact, I got most of my information about PIM-SM from
comparative statements in section 2.1.2 PIM-DM.  Given its
importance, consider expanding this section.

[Ballot discuss]
I found this document to be very useful, and expect to keep it close for when I need to
sort out the multicast protocols.  However, I had problems in understanding several
tables, and they are a very important feature of this document.

The Table in 2.2.4 is very confusing.  There are five different values in the "cells"
of the table: Yes, No, Recommended, Doesn't work, and Few implementations.
I am unsure about the difference between Yes and Recommended, and about the
difference bewteen No and Doesn't work.  (I am assuming that Few implementations
means that it would work but isn't widely deployed?)  I believe text or a legend is needed.

Section 2.3 Learning (Active) Sources includes subsections on SSM, MSDP, and
Embedded-RP but the summary table includes bi-dir single domain and PIM-SM
single domain.  I could only  find a single sentence in the intro to 2.3 that seems
to apply:

  Learning active sources is a relatively straightforward process with
  a single PIM-SM domain and with a single RP, but having a single
  PIM-SM domain for the whole Internet is a completely unscalable model
  for many reasons.

The information in the table is consistent (Yes for IPv4 and IPv6, with a status of
"for intra-domain only"), but I have no idea what mechanisms are used to find
the sources in this case.  An extra sentence or two in section 2.3 could probably
remedy the situation.

In section 2.6.3, the technique "Host receiving SSM" indicates IGMPv3 should be
used in IPv4 environments and MLDv2 in IPv6.  The Note for this technique is
rather cryptic: "Also SSM-mapping".  After some re-reading, I concluded that
"Host receiving SSM" can also be implemented using IGMPv1 and IGMPv2 in
conjunction with SSM mapping in IPv4 environments and can be implemented
with MLDv1 and SSM mapping in IPv6 environments?  I don't know if that's
correct, but I think some clarification is in order...

Section 2.7.3, the table entry for IGMP/MLD snooping has the following note:
      "Common, IGMPv3 or MLD bad"

Is this a reference to "hosts may recieve unnecessary muticast traffic ... if IGMPv3
or MLDv2 source filters are used" as stated in section 2.7?  In that case, "bad"
means more effective techniques for flooding reduction are available, but deployment
wouldn't cause system failure, right?  Perhaps a note following the table would
clarify the issues cleanly...

[Ballot comment]
Nit caught by Gonzalo Camarillo during Gen-ART Review:

  The word 'section' is typically capitalized in sentences
  like '... in Section 3.2 of [RFC4605]'.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
         
Magnus Westerlund has reviewed the latest version that is requested to
be published and beleives it ready.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
         
Yes, it has received review from both BEHAVE and MAGMA WG members.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?
         
No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.
         
No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?
         
The consensus is solid but it comes from a minor clique in the BEHAVE WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)
         
No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.
         
Yes, and the two warnings and errors reported by ID-nits are on purpose.
This document needs to reference IGMPv2 (RFC 2236) and it needs to reference
the 192.168.0.0/24 address range.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].
         
References are split. There are no normative references to draft.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?
         
The IANA section is correct.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?
         
No formal language used.


Technical Summary

  In order for IP multicast applications to function well over NATs,
  multicast UDP must work as seamlessly as unicast UDP.  However, NATs
  have little consistency in IP multicast operation which results in
  inconsistent user experiences and failed IP multicast operation.

  This document targets requirements intended to enable correct
  operations of Any Source Multicast and Source-Specific 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.
 
Working Group Summary

  There was a consensus in the WG to publish this document.
 
Document Quality

  This document was reviewed by both BEHAVE WG participants as well as
  participants from the MAGMA WG. This has resulted in a well reviewed
  document that addresses both the multicast and NAT aspects very well.
 
Personnel
 
  This document was shepherd by the responsible AD Magnus Westerlund due
  to the author being WG chair.

Sent back to WG for fixing issues raised in IETF last call. These issues include:
- Issues with redefining unicast UDP binding timer
- Inclusion of transmission of ASM
- Clearer and correcter language regarding transmission handling

Changes expected to require new WG and IETF last call

AD Evaluation Comments

1. There is a lack of references and explanation of abbreviations. For
example none of IGMP version talked about in the introduction has any
references.

2. Section 2:
"Sending multicast traffic is out of scope because it requires NATting
    the source IP address of such transmitted multicast traffic."

This does not motivate why NATing the source would be a problem and thus
should be done so that the receiving entity can actively participate in
a session.

3. Section 3.1:
"Hosts will periodically send IGMP Report messages to indicate
    continued interest in receiving the multicast traffic."

I think "hosts" in the above sentence should be clarified to mean the
NATed hosts.

4. Security consideration.
I think it should reference the MAGMA proxy drafts security
consideration also.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.


1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had adequate review


1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No. Clearly the multicast community needs to review this document but
I feel we have received review and input from that community.


1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.


1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus.


1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.


1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes


1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. The normative references to an
internet-draft is to magma-igmp-proxy, which is with the RFC
Editor and behave-nat-udp which is in IESG evaluation.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document places requirements on a Network Address Translator
(NAT) that supports sending IP multicast packets from the public side
to the private side. It requires the NAT to implementing an IGMP
proxy and specifies a minimal behavior for the timers.


* Working Group Summary

The draft is a product of the BEHAVE working group. There were no
objections during WGLC and this document has consensus.

* Protocol Quality

The draft and the critical text in it has been brought up on MAGMA
mailing list.