[v6ops] Review of draft-ietf-v6ops-nd-considerations-01

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear authors;

please find some comments below:

General:

there's some overlap between section 3 here and section 3 of draft-ietf-6man-ipv6-over-wireless. Lorenzo and Jen suggested on the 6MAN list that there's too much stuff in draft-ietf-6man-ipv6-over-wireless. Would it make sense to merge it all in your document?


1. Introduction

"   Neighbor Discovery [ND] is specified in RFC 4861."

Arguably RFC 4862 should be listed too, since a number of the listed issues are related to SLAAC.

-------------

   "  5. When a packet is to be sent, hosts use multicast NSs to perform
        address resolution for the destination host."

->

   "  5. When a packet is to be sent to a destination that is determined to be on link, hosts use multicast NSs to perform address resolution for the destination host, and forward the packet to their default router otherwise."

--------

2. Review of ND Issues

Note that the section and the draft in general only observe a subset of the ND issues. Maybe it could be clarified that the draft is non exhaustive. 
https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-over-wireless-04.html#name-issues-with-ipv6-nd-based-a list issues and references this document.


"ND uses multicast extensively for Node Solicitations (NSs), Router  Solicitations (RSs) and Router Advertisements (RAs). "

NA(O) can be sent to all hosts. Worth mentioning too?

---------

" This prolongs receiving time and consumes more power of the hosts."

maybe consider using "channel occupancy" or "air time" rather than "receiving time"

----------------

maybe split 2.3 to separate" NCE-on-Demand Causes Performance, NCE Exhaustion" and "Lack of Subscriber Management" Issues

----------

3.4. Wireless ND

6MAN decided to call it SND for Subnet ND. Maybe you could change all and reference draft-ietf-6man-ipv6-over-wireless for the definition of this and other terms like SGP?

---------

"Routers use unicast to communicate with hosts and  become the central address register and arbitrator for the hosts."
->
"Routers use unicast to communicate with hosts and form an abstract registrar and arbitrator for address ownership."

-------------------

"Trusting-all-host related issues may happen"
At least RFC 8928 mitigates SAVI issues. For RS multicast, they can be blocked by the first hop router which replies. The problem becomes trusting that router, which can be alleviated by section 9.2.4. of RFC 3971, though nobody seems interested in zerotrust in actual practice.

---------

"The switch will snoop and install (IP, MAC) proxy table for the local hosts. The switch will also reply to address resolution requests from other sites to its hosts with its own MAC. "

 This is sometimes called "Routing Proxy" (eg RFC 8929) by opposition of "bridging proxy" where the proxy replies with the MAC of the Target.

--------------

" This way, all hosts in a site will appear to have a single MAC to other sites."

This does not reduce the number of IP addresses nor the amount of lookups, does it?
The structure of NCEs may be optimized, though, but what really reduces the broadcast on the last hop is proxy ND by the switches for their attached nodes.  The problem of having a full state about all IP/MAC bindings remains the same as in the Wi-Fi proxy ARP function or in section 3.7

--------

"hosts send unsolicited Neighbor Advertisements upon having a new IPv6 address. "

Note that this creates a cache entry at the router at the creation of the address but does not maintain it. So it improves the situation but does not solve the issue.

------

"or perform Detecting Network Attachment in IPv6 (DNAv6) procedures [RFC6059] when waking up."

DNA does not protect a sleeping device from getting its addresses stolen while asleep. A sleep proxy is needed for that.

-----------


3.14.3. ND Proxy

Since you are at it, RFC 8929 is also an ND proxy, more targeted at the Wi-Fi type of situation. Maybe another section?

------------

4. Selectively Isolating Hosts to Prevent Potential ND Issues

Maybe add an informational ref to draft-levy-abegnoli-6man-stateless-nd-proxy ?

--------------


4. Selectively Isolating Hosts to Prevent Potential ND Issues

"Proxy isolation, used in SARP, ND Optimization for TRILL, Proxy ND in EVPN"

I believe a discussion on routing proxy vs bridging proxy would be useful. Some addresses like 802.15.4 are not bridgeable and a routing proxy is mandatory. And as you point out with FBB, routing proxy makes the L2 topology stable, and isolates the broadcast domains.  see RFC 8929.

--------

" But all messages with LLA can still reach other hosts. "

Not in the NBMA / MLTG case for which this was designed. The L2 broadcast domains are isolated and LLA communication is only available within one broadcast domain (e.g., an 802.11 ESS). A STA will find its printer in the attachment ESS, hopefully very local. 2 STAs attached to the same ESS with be able to talk to one another using LLA; but that's until one of the STAs moves to another AP in the same IP Subnet but not the same ESS, e.g., the next floor or the next building in the campus. GUA communication will remain through routing with the SGP. 

-----------

"dress registration and arbition [RFC8929]"

"arbition" -> arbitration?
better use a reference to SND [draft-ietf-6man-ipv6-over-wireless].

Note that RFC 8929 employs ND on the backbone to federate a split / distributed registrar whereby every L3 AP stores only the binding entries for the locally registered addresses. With EVPN, the registrar is completely synchronized on every hop using BGP. With LISP, it is fully centralized and the LISP implementation handles the high availability concerns as necessary. As you see, the concept of registrar in SND is very abstract and can be implemented in many ways.

--------

"
     . GUA Isolation (without link or subnet isolation)
 
"

I disagree with the without link isolation.  There's a shared subnet, but the MLTG model with an SGP is part of the story. It takes an upgrade of the host, but so do other solutions such as subnet isolation. 
----------

4.3. Applicability of Subnet Isolation with Shared Medium

Here a reference to draft-levy-abegnoli-6man-stateless-nd-proxy could be handy.

" The router must support Subnet Isolation (ie. Unique Prefix Per  Host, e.g. [RFC8273] or [Collink])."

Not just the router. The host too. Hosts do not necessarily support DHCP PD today, do they?

And then there's the standard gap between the DHCPv6 relay and the router(s), which is for now left to proprietary solutions but could be handled through draft-thubert-6lo-prefix-registration. IOW SND also works with prefixes to the host. 

------------

4.5. Applicability of Proxy Isolation

"
   o  Reduced address resolution for GUA among hosts behind different proxies. This reduces the largest source of multicast in ND.

"

I'd reword. All the broadcast lookups associated to AR still occur on the L2 medium. The benefit is that the proxy can filter the multicast ND messages towards an interface iff it knows for sure that the Target Address is not reachable over that interface. Which is *very hard* to establish with certainty when SLAAC is used. The whole point of an 802.11 association and of an RFC 8505 registration is to obtain that deterministic knowledge, so as to create respectively the bridging / routing state, and filter undesirable broadcasts/multicasts.

-----------

" This prevents the most ND issues"
reword?

-----------


4.6. Guidelines for Selecting a Host Isolation Method

"
       c) Remaining issues and solutions:

            1) None.
"

Not too sure. There's a debatable privacy issue. Subnet isolation means that the host can be tracked with the /64. To avoid that, the host would need to rotate /64s (or whatever plen it's given) like it rotates privacy addresses today. 

------------

"4. Otherwise, if GUA Isolation (i.e. setting PIO L-bit=0) is feasible"

Maybe you could mention that MLTG provides a "broadcast domain isolation", and limits the scope of the issues to one broadcast domain while the Subnet may spread beyond one broadcast domain.

------------------

"
  5. Otherwise, if Proxy Isolation is feasible

       a) Applicable scenarios:

"

802.11 mandates a function called proxy ARP in the AP, and it's supposed to work for IPv6 ND too.  I guess that makes a Wi-Fi ESS an applicable scenario.

--------------

"4.7. Impact of Host Isolation on Other Protocols in IPv6 First-hops"

Maybe you could mention that there's a need for a proxy for each service, and a need for a bridging proxy for LLA communication beyond the broadcast domain.


Voila! I hope this helps : )

Pascal