Re: [v6ops] seek comments and contributions to: draft-xiao-v6ops-nd-deployment-guidelines

[Xipengxiao <[e-mail]>]

Hi Ted,

Thank you for providing feedback.  From your objection, I realize that the draft title may lead people to think that we universally recommend “host isolation”.  That is not the case.  The draft clearly states the pros and cons of L2 & L3 host isolation (Section 3.1), and how to decide whether to apply host isolation (Section 3.2).  Now please see my response to your comments below.

From: [e-mail] [mailto:[e-mail]]

Isolating hosts would cause a lot of damage in home networks where there is no operator to control what hosts can do what. At a minimum you need something like MUD to make this work. E.g., this would completely break existing Thread (a 6lowpan mesh netwoek) Border routers which rely on multicast working. It would also break multicast DNS service discovery for the same reason.

[XX] You are right, but the draft doesn’t recommend isolating hosts for home networks. In Section 5, the draft says “[HomeNet] will end at Step 4: using normal ND with no special host isolation.”

This is not a new insight, and unfortunately the belief that this will work causes a lot of problems that are hard for end users to diagnose. Please do not publish this advice.
[XX] By “this is not a new insight”, I think you were referring to past works like RFC8273 “Unique Prefix Per Host (UPPH)”. I would like to point out that our recommendations are not identical to RFC8273. To the best of my knowledge, this draft has the following uniqueness:

1.     It’s the 1st draft to clearly distinguish L2 isolation and L3 isolation.  UPPH is just L3 isolation.  We also analyzed the pros and cons of both L2 isolation and L3 isolation.

2.     We are fully aware of the debate before UPPH became RFC8273. We carefully analyzed it.  A good amount of insights were expressed in that lengthy debate from both sides, but such valuable insights were scattered in 100+ messages and were kind of lost. We summarized the key points from both sides in Sections 3.1 & 4 so that these insights were preserved.

3.     We provided the most comprehensive summary of known ND issues and solutions (e.g. more comprehensive than RFC6583 or RFC9099). We also provided guidelines on how to select different solutions.
In case I am mistaken and any of the above is not unique, please kindly point me to the existing literature.
This draft came from the co-authors’ desire to answer our own ND questions.  It took many months of effort and reading of large number of RFCs. We believe our summary and recommendations will benefit the community.  Therefore, I would like to plead to the community to give it a chance:  please read and comment.  Thank you very much.
XiPeng