Re: [v6ops] WGLC: draft-ietf-v6ops-nd-considerations

[Xipengxiao <[e-mail]>]

Hi Lorenzo,

Thank you very much again for your review and comments.  We’ve released a new version to address your comments: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/.  Please see specific response inline.  Thanks.   XiPeng

From: v6ops <[e-mail]<mailto:[e-mail]>> On Behalf Of Lorenzo Colitti
Sent: Friday, February 9, 2024 4:28 AM
To: Nick Buraglio <[e-mail]<mailto:[e-mail]>>
Cc: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nd-considerations

I have reviewed this document. I find it useful and well-written and I support publication. Thanks to the authors for aggregating so much ND knowledge and protocols into one operational document.

Comments/suggestions below. I don't think any of them are particularly difficult to address.

Cheers,
Lorenzo


     7. Hosts may use multicast NSs to announce link layer address
        changes.

Should be "multicast NAs".
Corrected.


   In wireless networks, to ensure that the multicast messages reach
   even the remotest hosts, multicast messages are sent at the lowest
   modulation rate.

Should mention that some Wi-Fi networks, particularly enterprise networks, do multicast-to-unicast conversion, where each multicast packet is converted into unicast packets. In principle there could be one unicast packet for each station on the link, or one unicast packet for each member of the multicast group.

Might also mention that many mobile devices drop substantial percentages of multicast traffic on Wi-Fi by listening to only one out of N DTIM beacons.
We added some text according to your suggestion.

     . Router's periodic unsolicited RAs: may cause performance issue
        if it is sent frequently [RFC7772].

This seems unlikely to create a performance issue. I think multicast RAs are limited to one packet every 3s, and there are usually only one or two routers. So that's less than one packet per second on average. It might create battery life issues on hosts.
We revised the text to say it’s battery life issue.



     . Hosts address resolution for hosts: in a large L2 network of N
        hosts, there can be N-square such multicast messages. This may
        cause the largest performance issue.

In theory yes, but in most cases Wi-Fi networks are intended to access off-link resources (e.g., the Internet). In these networks, cross-talk is usually quite rare.
We agree with your statement, but here we are thinking of a large L2 “DC” network where host to host communication is more likely.  To be clear, we added the “DC” word.


     . Forged RAs: an attacker can send RAs to other hosts to claim to
        be a router and preempt the real router, resulting in a
        Redirect attack.

This should probably mention RA guard (RFC 6105).
Added.


     . Without an NCE, a router does not know the IP address of a host
        when SLAAC is used rather than [DHCPv6].

In general I don't think routers will snoop DHCPv6 replies to create ND cache entries. Some networks might do this, but I think most networks probably rely on ND, possibly with ND proxies.
You are right. Our point is, with SLAAC, a host forms its own IP address, and a router does not know the host’s IP address until an NCE entry is installed so the router can’t do subscriber management before that.  We reworded the text to make this point clear.

3.8. Gratuitous Neighbor Discovery

Might want to note that hosts can (and do) do this even if the router does not implement GRAND. They send NS for the router's link-local address from their global address, and  This causes the router to create an ND cache entry for the host's global address.
We believe this is one of the “Solutions Considered but Discarded” in Section 8 of [GRAND]. Since it’s not part of GRAND, we don’t want to bring it up here.


   Therefore, GRAND provides an improvement but does not
   solve the Router-NCE-on-Demand issues. For example, NCE exhaustion
   can still happen.

It can, but if the router prioritizes GRAND-learned entries over general INCOMPLETE entries, NCE exhaustion is effectively mitigated and very unlikely to cause disruption.
We agree but what you said is not specified in GRAND.  So we leave the text as is.


   RFC 7772 alleviates the multicast RA issue.

As I said above, this isn't really a performance issue. It definitely can be a battery life issue though.
You are right. The text now says “By reducing RAs, RFC 7772 reduces energy consumption of battery-powered hosts that can be waken up by RAs.”.


   RFC 6583 partially
   addresses the Router NCE Exhaustion issue.

I think "partially" is a bit pessimistic. I think RFC 6583 + GRAND effectively mitigates this, no?
We agree but here we are discussing RFC6583 not “RFC 6583 + GRAND”.  A bigger point is, we believe an “isolating host” solution like DHCP-PD or RFC8273 is cleaner than the combined solution, so we don’t want to discuss the combined solution too much.  There are too many combinations too.


   Optimistic DAD
   has not been widely deployed.

I'm not sure that's true. Android deploys it, for example. The main problem with it is that routers aren't allowed to use optimistic DAD, so if the device is doing forwarding (which happens pretty often for many reasons), then it won't be enabled. I think this is a bug in the optimistic DAD RFC. It shouldn't look at whether the device is a host or a router, it should instead look at whether the device is acting as a router for the interface that is sending the DAD packet.
Thank you for this information.  We removed the text “has not been widely deployed”.

4.3. Applicability of Subnet Isolation with Shared Medium
[...]
   o  All host communication with GUA will go through the router, and
      the router may become a bottleneck.

Should say "all host-to-host communication".
Done.
Thanks again for your review and help.  We appreciate it.

XiPeng & co-authors


On Fri, Feb 9, 2024 at 8:32 AM Nick Buraglio <[e-mail]<mailto:[e-mail]>> wrote:
I also support furthering this draft.

On Fri, Feb 2, 2024 at 1:00 PM Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:
>
> This draft is well written and highly valuable for operators deploying IPv6.
>
> I support publication.
>
> Thank you
>
> Gyan
>
> On Fri, Feb 2, 2024 at 12:37 PM Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Folks,
>>
>> This message initiates a WGLC for draft-ietf-v6ops-nd-considerations. Please submit comments by 2/16/2024.
>>
>>                                                                Ron
>>
>>
>> Juniper Business Use Only