Skip to main content

Last Call Review of draft-ietf-v6ops-nd-considerations-06
review-ietf-v6ops-nd-considerations-06-genart-lc-robles-2024-10-18-00

Request Review of draft-ietf-v6ops-nd-considerations
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-10-18
Requested 2024-10-04
Authors XiPeng Xiao , Eduard V , Eduard Metz , Gyan Mishra , Nick Buraglio
I-D last updated 2024-10-18
Completed reviews Genart Last Call review of -06 by Ines Robles (diff)
Secdir Last Call review of -06 by Barry Leiba (diff)
Tsvart Last Call review of -06 by Magnus Westerlund (diff)
Assignment Reviewer Ines Robles
State Completed
Request Last Call review on draft-ietf-v6ops-nd-considerations by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/5xARVYAYmZg5v_WLItcw2OjSytI
Reviewed revision 06 (document currently at 08)
Result Ready w/issues
Completed 2024-10-18
review-ietf-v6ops-nd-considerations-06-genart-lc-robles-2024-10-18-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-v6ops-nd-considerations-06
Reviewer: Ines Robles
Review Date: 2024-10-18
IETF LC End Date: 2024-10-18
IESG Telechat date: Not scheduled for a telechat

Summary:

Summary:

The Draft provides a comprehensive review of the challenges associated with
IPv6 Neighbor Discovery (ND) and summarizes existing mitigation solutions
documented across more than 20 RFCs.

Please find below my comments/suggestions below:

Major Issues: None

Minor Issues/Nits:

Section 1.1

"..link-layer addresses are referred to as MAC addresses in this document" -->
"In this document, link-layer addresses specifically refer to Media Access
Control (MAC) addresses." ?

Section 2.1

"..by listening to only one out of multiple Delivery Traffic Indication Message
(DTIM) beacons..." — The statement implies that devices may be missing DTIM
beacons themselves, which is unclear.

I understand that devices rely on DTIM beacons to know when multicast or
broadcast traffic is available. Devices wake up for every DTIM beacon, but DTIM
beacons occur less frequently than regular beacon frames due to the DTIM period
setting. Devices do not selectively ignore DTIM beacons; rather, they may
ignore regular beacon frames and only wake up for DTIM beacons. For instance,
if the DTIM period is set to a high value (e.g., 10), devices will only wake up
every 10 beacon intervals. This can introduce delays in receiving multicast
traffic, but devices are not missing DTIM beacons unless they are asleep for
extended periods. Therefore, because devices wake up less frequently for DTIM
beacons, latency can occur in receiving multicast traffic. Additionally,
multicast frames are transmitted at lower data rates and are not retransmitted
upon loss, which can lead to packet loss.

Thus, for improved clarification, a suggestion as follows:
"..In Wi-Fi networks, mobile devices often employ power-saving modes, where
they may sleep through multiple beacon intervals and wake up only for Delivery
Traffic Indication Message (DTIM) beacons [RFC9119]. Since DTIM beacons occur
less frequently, this can introduce delays in receiving multicast traffic.
Moreover, multicast frames are transmitted at lower data rates without
retransmissions, leading to potential packet loss. As a result, multicast
traffic over Wi-Fi can suffer from reduced performance and reliability..."

Section 3.3:
* Which are the privacy considerations? what about RFC 8981 to mitigate privacy
risks? * What it is the meaning of "upstream multicast"?

Section 3.11:

"...Rate-limiting the NDP queue to avoid CPU/memory overflow..." -->
"...Implement rate-limiting mechanisms for NDP (Neighbor Discovery Protocol)
message processing to prevent CPU and memory resources from being
overwhelmed..."?

Thanks for this document,

Ines.