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

[Xipengxiao <[e-mail]>]

Hi Lorenzo,

Thank you very much for your review and comments.  This draft will definitely benefit from your ND knowledge and experience. We will issue a new version, and when it’s out, we will provide a detailed response to each one of your comments.

Best regards and thanks again to your help.

XiPeng

From: v6ops <[e-mail]> On Behalf Of Lorenzo Colitti
Sent: Friday, February 9, 2024 4:28 AM
To: Nick Buraglio <[e-mail]>
Cc: Ron Bonica <rbonica=[e-mail]>; [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".


   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.

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


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


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


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

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.


   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.


   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.


   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?


   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.

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


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
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
>
>
> Gyan Mishra
>
> Network Solutions Architect
>
> Email [e-mail]<mailto:[e-mail]>
>
> M 301 502-1347
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops