Multicast Considerations over IEEE 802 Wireless Media

Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alissa Cooper Discuss

Discuss (2020-01-06)
Section 8: Are there plans for the IETF community to develop the guidelines mentioned? I'm wary of publishing an RFC that says the IETF should do something if there are in fact no plans for the IETF to do the thing. RFCs are not necessarily good motivators.

Overall this is an interesting document, but it seems to be written in an overly casual way and assumes readers have a lot of context that is not included in the document itself. The Gen-ART review pointed out a number of bits of text that left this impression. It was posted in October and never responded to. I've picked out some bits of the review and added a few more of my own -- collectively addressing these would get the document into publishable shape for a wider audience I think. 

General:  (1) On first use, please add citations for all the protocols mentioned in the document, as well as a few words to describe what each protocol does. For IETF readers, this will help them understand the implications of various 802 specifications without having to go look them up right away. (2) The IETF meeting network may be interesting as an example to contemplate, but to make this document broadly valuable it would be better to generalize the problem descriptions than to focus on the IETF meeting network.

Section 3.1.4 seems a little thin to this non-expert. It is certainly true that "every station has to be configured to wake up to receive the multicast", but it seems like only a poorly designed protocol would create the situation where "the received packet may ultimately be discarded" on any kind of regular basis. If there are a class of packets that the receiver will ultimately discard, that sounds like they should be on a separate multicast address, or the sender should be determining if the packet will be discarded before sending it. Perhaps what this section is driving at is that multicast protocols are often designed without taking power-saving considerations into account, but then *that's* what this section should probably talk about. As it is, it sounds like the old joke about saying to the doctor, "My arm hurts when I do this" and the doctor replying, "The stop doing that".

In section 3.2.1, the last paragraph is missing a bunch of information:
"It's often the first service that operators drop": What is "it"?
"Multicast snooping" is not defined.
In what scenario are devices "registering"?

Section 5.1: "...and sometimes the daemons just seem to stop, requiring a restart of the daemon and causing disruption." What a strange thing to say. Does this simply mean "and the current implementations are buggy"?

Also section 5.1: "The distribution of users on wireless networks / subnets changes from one IETF meeting to the next". This document doesn't seem to be about the IETF meeting network. This sentence seems inappropriately specific. The "NAT" and "Stateful firewalls" sections are also overly specific to the IETF meeting network. Generalizing would help.

Section 8: The first paragraph has too little useful comment. There is no reference for 802.1ak, the reference to 802.1Q is inline instead of in the references section, and the content of neither of these standards is explained in this document. The paragraph doesn't really lay out what the topic of discussion is, at least for someone like myself who is not versed in the topic.
Comment (2020-01-06)
Please respond to the rest of the Gen-ART review.

Roman Danyliw Discuss

Discuss (2020-01-07)
** Section 9.  Section 7 appears to recommend using an ARP sponge per Section 5.1.  Please provide some general caution about ARP poisoning/false advertising that could undermine (DoS) this approach (that is being deployed to save battery power).
Comment (2020-01-07)
I support Alissa’s DISCUSS.  My related comments on Section 5.1 are:

-- Section 5.1  Firewall unused space.  Per “… The distribution of users on wireless networks/subnets changes from one IETF meeting to the next …”, this text seems unnecessary and it strikes me as odd to base guidance on a single network.

-- Section 5.1. NAT.  Per “To NAT the entire … attendee networks”, what is the “attendee network” in this context?

-- Section 5.1.  Stateful firewalls.  Per “But this conflicts with the need and desire of the IETF and other organizations to have the network as open as possible and to honor the end-to-end principle.  An attendee on the meeting network should be an Internet host …”, this text appears to be written about the IETF meeting network. Honoring the end-to-end principle and network nodes between Internet hosts is not universal architecture for all organizations.  Recommend rewording or removing these two sentences.

** Section 5. This section states that it is describing optimizations to address the issue discussion in Section 3.  It would be clearer if this section notes which items from Section 3 are addressed.

** Section 5.1. Per “… and sometimes the daemons just seem to stop” seems to be an implementation issue, not a reflection on the technique or associated architecture.  If this is the case, I recommend removing this text.

** Section 7. This section would be clearer if the explicitly activities in Section 4 and 5 being recommended were referenced.

** Section 9.  The first paragraph makes references to RFC4601 and RFC5796 which is helpful -- thanks.  I wasn’t sure what this meant in the context of this document which discusses multicast over wireless. This guidance doesn’t appear to be wireless specific.  Assuming you meant that “all the usual multicast security guidance applies whether you are using wireless or not”, please include clarifying text of the rough form (edit as required):

OLD: Multicast is made more secure in a variety of ways.

NEW: Multicast deployed on wired or wireless networks as discussed in this document can be made more secure in a variety of ways.

** Editorial Nits:
-- Section 3.1.2.  Typo. s/techiques/techniques/

-- Section 3.2.1.  Typo.  s/utlize/utilize/

-- Section 4.7. s/AP has do the/AP has to do the/

-- Section 5.1. Typo. s/listen for ARP requests/listens for ARP requests/

-- Section 5.1. Typo. s/to an machine/to a machine/

-- IdNits reports:
  -- Obsolete informational reference (is this intentional?): RFC 2461
     (Obsoleted by RFC 4861)
  -- Obsolete informational reference (is this intentional?): RFC 4601
     (Obsoleted by RFC 7761)

Benjamin Kaduk Discuss

Discuss (2020-01-08)
Section 9 says that "[RFC4601], for instance, mandates the use of IPsec
to ensure authentication of the link-local messages in the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol" but I
could not find where such use of IPsec was mandated.  (I do recognize
that a similar statement appears almost verbatim in RFC 5796, but RFC
5796 seems focused on extending PIM-SM to support ESP in additon to the
AH usage that was the main focus of the RFC 4601 descriptions, and does
not help clarify the RFC 4601 requirements for me.)  The closest I found
was in Section 6.3.1 of RFC 4601: "The network administrator defines an
SA and SPI that are to be used to authenticate all link-local PIM
protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM
domain" but I do not think that applies to all usage of PIM-SM.  Am I
missing something obvious?
Comment (2020-01-08)
To what extent would it be wrong to use the common "BUM" abbreviation
("Broadcast/Unknown-Unicast/Multicast" to discuss the classes of traffic
discussed in this hdocument?  That is, we say "multicast" a lot but in
several places the discussion suggests that broadcast is treated
similarly, and it would be nice to have a uniform treatment for the
cases where broadcast and multicast are effectively equivalent, so that
it's easier to call out when there is an actual distinction between the
handling for the two.  (I guess that the "unknown unicast" case doesn't
really apply at the MAC layer...)

I have very little background on IEEE radio technologies, or radio
technologies in general; my apologies in advance for the many questions
I ask that betray my ignorance.  I understand that I'm not exactly the
target audience for this document and that it's not going to be
appropriate to add clarifying text at all locations where I ask for help
understanding the content.


   This document describes the problems of known limitations with
   wireless (primarily 802.11) Layer-2 multicast.  Also described are

nit: this doesn't flow very well; maybe just "describes the known limitations
of wireless" would suffice?

Section 1

   send duplicate data to each recipient.  With broadcast traffic, data
   is sent to every device regardless of their interest in the data.

nit: maybe "expressed interest"?  I expect there are some
infrastructure-type broadcast traffic that is of interest to all
participants in many IP networks.

   problem.  Wi-Fi traffic classes may help.  This document is intended
   to help make the determination about what problems should be solved
   by the IETF and what problems should be solved by the IEEE (see
   Section 8).

Do we need formal IEEE buy-in before making this kind of statement?

   rates, no acknowledgements, and low data rate.  It also explains some
   enhancements that have been designed at the IETF and IEEE 802.11 to
   ameliorate the effects of multicast traffic.  Recommendations are

I suggest clarifying whether this is "ameliorate the effects of
multicast traffic on other users of the spectrum" or "ameliorate the
effects of the radio medium on multicast traffic".

Section 2

I agree with the TSV-art reviewer that a more precise definition of what
the "packet error rate" is measuring would be useful.

Section 3.1.1

   traffic.  Since multicast makes point-to-multipoint communications,
   multiple acknowledgements would be needed to guarantee reception at
   all recipients.  Since there are no ACKs for multicast packets, it is

nit: there seems to be an implicit "but that would be highly inefficient
and is not done" between "multiple acks would be needed" and "there are
no acks".

Section 3.1.2

   Multicast over wired differs from multicast over wireless because
   transmission over wired links often occurs at a fixed rate.  Wi-Fi,
   on the other hand, has a transmission rate that varies depending upon
   the STA's proximity to the AP.  The throughput of video flows, and
   the capacity of the broader Wi-Fi network, will change and will
   impact the ability for QoS solutions to effectively reserve bandwidth
   and provide admission control.

nit: rhetorically, this sentence doesn't say when/why the throughput
will change, but rather treats it as a spontaneous and independent

   For wireless stations associated with an Access Point, the power

nit: I assume "associated with" refers to the current radio traffic, and
not some administrative or organizational grouping, as a naive reader
might expect using the default meaning of "associated"; some additional
lead-in might be helpful.

   In fact, backward compatibility and multi-stream implementations mean
   that the maximum unicast rates are currently up to a few Gbps, so
   there can be more than 3 orders of magnitude difference in the
   transmission rate between multicast / broadcast versus optimal
   unicast forwarding.  Some techiques employed to increase spectral

nit: I think "backward compatibility" is only applicable to the 3 orders
of magnitude difference in tx rate, and is not applicable to the maximum
unicast rates being a few Gbps.

Section 3.1.3

   communications and degrade the overall capacity.  Furthermore,
   transmission at higher power, as is required to reach all multicast
   STAs associated to the AP, proportionately increases the area of

nit: it's most precise when talking about interference to say what
interferes with what else; in this case it would be (IIUC) the area in
which multicast traffic causes interference with other consumers of the
radio spectrum.

Section 3.1.4

   One of the characteristics of multicast transmission is that every
   station has to be configured to wake up to receive the multicast,
   even though the received packet may ultimately be discarded.  This

This seems like something of a non sequitur -- the text would work if we
were discussing broadcast traffic, but for multicast aren't the intended
recipients known?

   o  Both unicast and multicast traffic can be delayed by power-saving

Just to check my understanding: this is "works poorly" just because of
the additional latency?  (Is this effect more pronounced for multicast
than for unicast?)

   o  A unicast packet is delayed until an STA wakes up and requests it.
      Unicast traffic may also be delayed to improve power save,
      efficiency and increase probability of aggregation.
   o  Multicast traffic is delayed in a wireless network if any of the
      STAs in that network are power savers.  All STAs associated to the
      AP have to be awake at a known time to receive multicast traffic.

These kind-of feel like sub-bullets of the previous point.

Section 3.2.1

   o  ARP
   o  DHCP
   o  mDNS [RFC6762]
   o  uPnP [RFC6970]

   After initial configuration, ARP (described in more detail later) and
   DHCP occur much less commonly, but service discovery can occur at any
   time.  Some widely-deployed service discovery protocols (e.g., for
   finding a printer) utilize mDNS (i.e., multicast).  It's often the

nit: doesn't uPnP also fall under the "service discovery protocol"
mantle?  It's a little weird rhetorically to only mention the one but
not the other, and leaves the uninformed reader wondering what the story
is about uPnP.

   first service that operators drop.  Even if multicast snooping is

nit: rhetorically, this is missing some causality for "first of what".

Section 3.2.3

On the whole this section is hard for me to follow.  I make a couple
specific points, but a broader rewrite may be in order.

   Multicast Listener Discovery (MLD) [RFC4541] is used to identify
   members of a multicast group that are connected to the ports of a
   switch.  Forwarding multicast frames into a Wi-Fi-enabled area can
   use such switch support for hardware forwarding state information.

Er, what switch support -- where did we previously discuss this?

   However, since IPv6 makes heavy use of multicast, each STA with an
   IPv6 address will require state on the switch for several and
   possibly many multicast solicited-node addresses.  Multicast

Am I supposed to know what a "solicited-node address" is based on the
references already provided?

Section 4.1

Is there an actual specification for Proxy ARP that can be referenced in
addition to the powerpoint deck?  I note that the toplevel Section 4
describes this content as "has been specified", which would seem to
exclude speculative proposals.

   The AP knows the MAC address and IP address for all associated STAs.
   In this way, the AP acts as the central "manager" for all the 802.11
   STAs in its basic service set (BSS).  Proxy ARP is easy to implement
   at the AP, and offers the following advantages:

Does it make sense to lead in this passage with "In Proxy Arp,"?

Section 4.3

I'm not sure how accessible this content will be to readers that do not
already have some background knowledge on wifi operation -- there are
some logical connections between sentences that are left fairly

Section 5.1

         Some routers (often those based on Linux) implement a "negative
         ARP cache" daemon.  Simply put, if the router does not see a
         reply to an ARP it can be configured to cache this information
         for some interval.  Unfortunately, the core routers in use
         often do not support this.  When a host connects to a network
         and gets an IP address, it will ARP for its default gateway
         (the router).  The router will update its cache with the IP to
         host MAC mapping learned from the request (passive ARP

nit: the transition between first three and last two sentences seems a
bit lacking.

   Firewall unused space

         The distribution of users on wireless networks / subnets
         changes from one IETF meeting to the next (e.g SSIDs are
         renamed, some SSIDs lose favor, etc).  This makes utilization
         for particular SSIDs difficult to predict ahead of time, but
         usage can be monitored as attendees use the different networks.

nit: I don't think the reference to the IETF meeting network adds any
value here; the operational practice can be equally well described
without such reference.


         The broadcasts are overwhelmingly being caused by outside
         scanning / backscatter traffic.  To NAT the entire (or a large
         portion) of the attendee networks would eliminate NAT
         translation entries for unused addresses, and so the router
         would never ARP for them.  However, there are many reasons to
         avoid using NAT in such a blanket fashion.

"attendee networks" seems to be another (implicit) reference to IETF
meeting networks; I suggest rewording.

   Stateful firewalls

         Another obvious solution would be to put a stateful firewall
         between the wireless network and the Internet.  This firewall
         would block incoming traffic not associated with an outbound
         request.  But this conflicts with the need and desire of the
         IETF and other organizations to have the network as open as
         possible and to honor the end-to-end principle.  An attendee on
         the meeting network should be an Internet host, and should be
         able to receive unsolicited requests.  Unfortunately, keeping

Again, a focus on the (IETF) meeting network that is not justified by
the scope presented in the Abstract and Introduction.

Section 5.2

Is there more that could be said about how this constraining is to be
done?  Are there well-known techniques to "segment off" (pun intended)
small areas of service-discovery traffic within a larger multicast
domain, that fall short of just blocking mDNS entirely?

(Also, why is this section indented at the level of the sub-topics of
the previous section, instead of normal section-level indentation?)

Section 7

   Future protocol documents utilizing multicast signaling should be
   carefully scrutinized if the protocol is likely to be used over
   wireless media.

It's not entirely clear that this advice is going to make it to the
authors of such future protocol documents, given the current intended
status of this document.  I might consider rephrasing in terms of the
potential consequences if such future protocols do not take into account
the considerations for wireless media, though that would of course make
the statement fit less well into a section entitled "Recommendations".

   Proxy methods should be encouraged to conserve network bandwidth and
   power utilization by low-power devices.  The device can use a unicast

nit: I think this should be something like "The use of proxy methods
should be encouraged"; right now the text has to be parsed as having
"proxy methods" as the subject that is getting encouraged to conserve
resources.  Alternately, just add a comma.

   Multicast signaling for wireless devices should be done in a way
   compatible with low duty-cycle operation.

Is there any further guidance to give on how this is to be done?  Do any
previous sections of this document offer specific advice that is
relevant to this point?

Section 8

   The IETF should determine guidelines by which it may be decided that
   multicast packets are to be sent wired.  For example, 802.1ak works
   on ethernet and Wi-Fi.  802.1ak has been pulled into 802.1Q as of
   802.1Q-2011.  If a generic solution is not found, guidelines for
   multicast over Wi-Fi should be established.

I don't understand how these sentences are related to each other.  The
first one seems to be suggesting that the IETF should be telling
protocols that use IP multicast that those protocols need to
differentiate their behavior based on the physical layer in use, which
seems (AFAIK) antithetical to the idea of the Internet Protocol.  The
second and third sentences seem to be making statements about particular
IEEE technologies, I guess saying that they are available for both wired
and wireless use, but doesn't tell me much about what features the IETF
might be using from those technologies or why I should care about them.
The last sentence talks of a "generic solution", but I don't know what
problem it's supposed to be a solution for and how it relates to the
previously mentioned technologies.

   There is no need to support 2^24 groups to get solicited node
   multicast working: it is possible to simply select a number of
   trailing bits that make sense for a given network size to limit the
   number of unwanted deliveries to reasonable levels.  IEEE 802.1,

What are "trailing bits"?

   issues.  In reality, Wi-Fi provides a broadcast service, not a
   multicast service.  On the physical medium, all frames are broadcast
   except in very unusual cases in which special beamforming
   transmitters are used.  Unicast offers the advantage of being much

This observation seems like it would be very useful to have much earlier
in the document.

Section 9

It might be worth mentioning the common issue with security protocols
for multicast or group communications where there's a tradeoff between
(expensive) per-message asymmetric cryptography and (cheap) symmetric
cryptography where the shared group key allows any group member to
impersonate the expected sender.

We also discuss several mechanisms for improving efficiency that in
effect involve a proxy acting on behalf of wireless stations (whether in
the AP or a separate entity); such proxy methods in general have
security considerations that require the proxy to be trusted to not

Similarly, when using mechanisms that convert multicast traffic to
unicast traffic for traversing radio links, the AP (or other entity) is
forced to explicitly track which subscribers care about what multicast
traffic.  This is generally a reasonable tradeoff, but does result in
another entity that is tracking what entities subscribe to which
multicast traffic.  While such information is already (by necessity)
tracked elsewhere, this does present an expansion of the attack surface
for that potentially privacy-sensitive information.

There are probably some privacy considerations worth mentioning for the
"backbone router" model discussed in Section 4.2.

   Multicast is made more secure in a variety of ways.  [RFC4601], for

Would it be accurate to rephrase this more like "There are a variety of
security mechanisms defined for multicast control- and data-plane
traffic"?  The current formulation feels confusing to me on two axes:
whether it describes current or future specifications, and the nature of
security improvements provided.  (Actually, are the listed mechanisms
only really applicable to control-plane traffic but not data-plane?)

Éric Vyncke Yes

Deborah Brungard No Objection

(Suresh Krishnan) No Objection

Comment (2020-01-08)
* Section 3.1.4.

Is this really the case? I thought multicast was best effort. Can you add a reference to the relevant section of the 802.11* spec for this 

"Multicast traffic is delayed in a wireless network if any of the
  STAs in that network are power savers.  All STAs associated to the
  AP have to be awake at a known time to receive multicast traffic."

* Section 3.2.2.

-> What does PIM have to do with IPv6 to be listed here? It applies just as well to IPv4. Can you clarify?
-> What is "Geographic Routing"?

-> Please add a reference to RFC4941 for this IPv6 privacy addresses in this sentence

"IPv6 node will typically use multiple addresses, and may change them often for privacy reasons"

* Sections 3.2.3. and 3.2.4. 

For the "solicited-node addresses" I think a reference to RFC4291 Section 2.7.1. would be extremely useful since this term is not used widely known outside hardcore IPv6 circles. 

* Section 3.2.4.

-> The correct reference for IPv6 Neighbor Discovery should be RFC4861. RFC2461 has been obsolete for more than a decade now. Is there a specific reason you are referring to the older version of ND here while the rest of the document uses the right reference?

-> I think it might be better to separate out the ARP issues into a separate section instead of lumping into this one titled "Spurious ND"

* Section 8

"The IETF should determine guidelines by which it may be decided that multicast packets are to be sent wired..."

I had the same question as Benjamin and would like to see this clarified.

(Mirja Kühlewind) No Objection

Comment (2020-01-07)
As TSV-ART reviewer, Gorry Fairhurst provided an extensive review of this doc in Last Call and a re-review of the current version just recently (Thanks!). There are still a large number of comments that have not been addressed and no response was provided from the authors so far. While many of his comments are mostly editorial, I believe that this doc could really benefit from addressing them. There are a couple of relevant references that Gorry provides in his review which I think should be cited by this document. Further as Gorry mentioned, there are congestion control schemes for multicast and also high-layer mechanism to make use of multicast support more reliable. This is not discussed at all. So I'm not even sure if the conclusion in section 8 is correct that multicast on 2-layer must be reliable. Given the number and details of problems listed, I find the discussion in section 8 way to high level anyway.

Also probably editorial: I find it a bit confusion that section 5.1. suddenly speak all about the IETF network while the rest of the doc seems more general. Is that on purpose or is that a left over from merging two docs?

I'm not raising any points on the Discuss-level as I believe most (TSV-ART) points are rather editorial (also some may touch technical points well), however, I also support the points raised by Alissa and the GEN-ART review and would really like to see them addressed before publication (ideally they would have been addressed before IESG evaluation...).

Barry Leiba No Objection

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

Comment (2020-01-08)
I support Alissa's DISCUSS.

Documentation nit:  this document should be tagged in the Datatracker as also replacing draft-perkins-intarea-multicast-ieee802 [1].


(Adam Roach) No Objection

Martin Vigoureux No Objection

Comment (2020-01-07)

thank you. Interesting read. However, a bit like Alissa, I'm not sure what the IETF should do (in terms of protocol design/extension), if anything.
In fact, it seems that some solutions exist / have been standardized but are simply not yet implemented.

Warren Kumari Recuse

Comment (2019-12-23)
I'm an author, and so am recusing myself from the ballot.

Thanks to Eric for being willing to be the responsible AD.

Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Magnus Westerlund No Record

Robert Wilton No Record