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

[Lorenzo Colitti <[e-mail]>]

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]>
wrote:

> I also support furthering this draft.
>
> On Fri, Feb 2, 2024 at 1:00 PM Gyan Mishra <[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]> 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]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > --
> >
> >
> > Gyan Mishra
> >
> > Network Solutions Architect
> >
> > Email [e-mail]
> >
> > M 301 502-1347
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>