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

[Xipengxiao <[e-mail]>]

Hi Pascal,

Thank you very much for your thorough review.  Your comments lead to revision and improvement of our draft in the guideline section (i.e. proxy isolation is promoted) so we are grateful.  Please see my reply in line.

________________________________
De : v6ops <[e-mail]<mailto:[e-mail]>> de la part de Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Envoyé : mercredi 28 juin 2023 09
À : IPv6 Operations ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Objet : [v6ops] Review of draft-ietf-v6ops-nd-considerations-01

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?
I will read your draft and then provide a feedback. As a precaution, our draft is already long (33 pages), and we don't want to further expand it unless necessary.



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


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

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


--------

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.
We try to cover all known issues published in RFCs, so that this draft can be a one-stop reference.  If you know we missed any ND-issue RFCs please let us know.  More importantly, we claimed that all ND issues are from just 3 causes (1) multicast (2) trusting all hosts (3) installing NCE on demand.  This is useful because enumerating all issues may be impractical but if you deal with these 3 causes, you may prevent issues that are already there but not yet documented.



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


---------

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

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


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

maybe split 2.3 to separate" NCE-on-Demand Causes Performance, NCE Exhaustion" and "Lack of Subscriber Management" Issues
Why do you suggest separating out subscriber management issue?  We believe NCE-on-demand (causing router not to know a subscriber's IP address) is the root cause of lacking subscriber management capability, so we want to put all these issues in the NCE-on-demand section.


----------

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?
We added some wording and a reference to your draft.  "[IPv6-NBA] generalizes the solutions defined in WiND and defines a new solution named Subnet ND (SND). It is being discussed in 6man WG.".  Section 3.4 is now called "Wireless ND and Subnet ND".


---------

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


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

"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.
As we don't want to expose too many details, we deleted this statement.


---------

"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.
Thanks for the information.


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

" 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
You are right.  In addition to reducing broadcast behind the answering proxy, this reduces the MAC table size at the asking side - my understanding is the proxy devices also serve as a switch on the data plane and maintains a MAC table.


--------

"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.
Thank you for pointing this out.  I updated the GRAND section accordingly.


------

"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.
Right but we don't want to go into such details.


-----------


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?
RFC8929 is already covered in the WiND section.  But we will point out that WiND, SND, SARP are all ND proxy solutions.


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

4. Selectively Isolating Hosts to Prevent Potential ND Issues

Maybe add an informational ref to draft-levy-abegnoli-6man-stateless-nd-proxy ?
This draft is still in early stage.  If we need to we will reference it.


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


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.
In the new revision, proxy isolation indeed takes a more important role.  We will send the draft to you and you can suggest some wording.


--------

" 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.
I added "in the same broadcast domain" at the end of this sentence.


-----------

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


--------

"
     . 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.
We reworded it as "GUA isolation for hosts in the same subnet and broadcast domain".  We now also recommend proxy isolation before GUA isolation.  please take a look at the new version and see if you agree.

----------

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.
To support subnet isolation, only the router needs new functionality.  But a particular solution may also require host support, e.g. [Collink], but that's a different matter.  RFC8273 doesn't require additional host support.  I will read draft-levy-abegnoli-6man-stateless-nd-proxy and see how it is relevant to Subnet Isolation with Shared Medium.


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

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.
I deleted "This reduces the largest source of multicast in ND.".


-----------

" This prevents the most ND issues"
reword?
Changed to "The guidelines start from the strongest isolation method. This prevents the largest number of ND issues"


-----------


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.
When we say "none", we refer to the issues and solutions reviewed in the draft.  We don't consider privacy issue an ND issue.  If privacy is a major requirement, then the network admin should not choose Unique Prefix Per Host.


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

"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.
Again, we revised the guideline to use GUA isolation only for hosts in the same subnet & broadcast.  MLSB & MLTG are covered in proxy isolation instead.


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

"
  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.
Thanks for pointing this out but we cannot enumerate every possible scenario.  We just provide a few examples instead.


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

"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.
I am still not that familiar with your routing proxy and bridging proxy concepts. Can you please suggest some wording here? Thank you.

Voila! I hope this helps : )
Your comments are indeed very helpful.  Thank you very much!  They are much appreciated.  XiPeng


Pascal

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