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

From: Xipengxiao <[email-masked]>
Date: Wed, 6 Oct 2021 08:53:31 +0000

Hi folks,

We published a draft: Isolating Hosts in Layer-2 and Layer-3 to Simplify ND and IPv6 First-Hop Deployments, https://datatracker.ietf.org/doc/draft-xiao-v6ops-nd-deployment-guidelines/.  This draft summarizes information from many RFCs and drafts about the Neighbor Discovery Protocol. We believe it has value and is well readable.  Your comments will be greatly appreciated.  We also welcome your further contribution to this draft.  Thank you very much.

*       Background:
*       There are known issues with IPv6 Neighbor Discovery (ND) protocol. Multiple solutions exist for the issues. But there is no guideline on how to avoid the issues, or how to select the suitable solution
*       Contribution of the draft:
*       Summarize known ND issues
*       Analyze existing solutions to identify how they solve the issues
*       Present an insight: isolating hosts in L2 and L3 will help to avoid many ND issues
*       Present guidelines based on above insight to avoid ND issues, and recommend solutions for the remaining issues
*       Analyze impact of such guidelines to other IPv6 first-hop protocols

Regards,

Xipeng Xiao, Ph.D.
+49 162 2047 661
[email-masked]<mailto:[email-masked]>
Dusseldorf, Germany

---

From: [email-masked]
Date: Wed, 6 Oct 2021 22:12:47 +0200

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.

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.

-- 
[email-masked]

On October 6, 2021 at 04:53:31, Xipengxiao ([email-masked]) wrote:

> Hi folks,
>
>
>
> We published a draft: Isolating Hosts in Layer-2 and Layer-3 to Simplify
> ND and IPv6 First-Hop Deployments,
> https://datatracker.ietf.org/doc/draft-xiao-v6ops-nd-deployment-guidelines/.
> This draft summarizes information from many RFCs and drafts about the
> Neighbor Discovery Protocol. We believe it has value and is well readable.
> Your comments will be greatly appreciated.  We also welcome your further
> contribution to this draft.  Thank you very much.
>
>
>
> •       Background:
>
> •       There are known issues with IPv6 Neighbor Discovery (ND)
> protocol. Multiple solutions exist for the issues. But there is no
> guideline on how to avoid the issues, or how to select the suitable solution
>
> •       Contribution of the draft:
>
> •       Summarize known ND issues
>
> •       Analyze existing solutions to identify how they solve the issues
>
> •       Present an insight: isolating hosts in L2 and L3 will help to
> avoid many ND issues
>
> •       Present guidelines based on above insight to avoid ND issues, and
> recommend solutions for the remaining issues
>
> •       Analyze impact of such guidelines to other IPv6 first-hop
> protocols
>
>
>
> Regards,
>
>
>
> Xipeng Xiao, Ph.D.
>
> +49 162 2047 661
>
> [email-masked]
>
> Dusseldorf, Germany
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 7 Oct 2021 08:22:27 +0000

Is MUD the rfc8520?
Section 1.8 and 1.9 of RFC8520 have an explanation that MUD is the host communication to switch or router, not to another host on the link.
Hence, how it could intersect with draft-xiao-v6ops-nd-deployment-guidelines that proposes to isolate host-to-host?
draft-xiao-v6ops-nd-deployment-guidelines does not impose any additional restrictions on host-to-switch or host-to-router communication.
MUD looks not impacted.

For an mDNS, I have found 6 places where it was discussed in the draft-xiao-v6ops-nd-deployment-guidelines, but lets authors would comment more.
Indeed, mDNS is broken if all hosts are isolated in separate subnets.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 6, 2021 11:13 PM
To: [email-masked]; Xipengxiao <[email-masked]>
Cc: Mishra, Gyan S <[email-masked]>
Subject: Re: [v6ops] seek comments and contributions to: draft-xiao-v6ops-nd-deployment-guidelines

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.

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.
--
[email-masked]<mailto:[email-masked]>

On October 6, 2021 at 04:53:31, Xipengxiao ([email-masked]<mailto:[email-masked]>) wrote:
Hi folks,

•       Background:
•       There are known issues with IPv6 Neighbor Discovery (ND) protocol. Multiple solutions exist for the issues. But there is no guideline on how to avoid the issues, or how to select the suitable solution
•       Contribution of the draft:
•       Summarize known ND issues
•       Analyze existing solutions to identify how they solve the issues
•       Present an insight: isolating hosts in L2 and L3 will help to avoid many ND issues
•       Present guidelines based on above insight to avoid ND issues, and recommend solutions for the remaining issues
•       Analyze impact of such guidelines to other IPv6 first-hop protocols

Regards,

Xipeng Xiao, Ph.D.
+49 162 2047 661

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

---

From: [email-masked]
Date: Thu, 7 Oct 2021 10:30:23 +0200

> 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 wou…

multicast works across links. protocols limited to only work on a single data-link layer will not without help.

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

just because some protocols are poorly designed (only work if on the same L2), doesn't mean this is not valuable work.
the mDNS problem is being worked on, no? and the common solution to mDNS is to use a mDNS proxy in the network.
given how noisy mDNS is, having policy enforcement points in the network to filter mDNS is also generally useful.
even in a homenet, it's not inconceivable that the home owner would like to control what services are advertised across the home.

O.

---

From: [email-masked]
Date: Thu, 7 Oct 2021 13:24:20 +0200

Commercial mDNS proxy solutions just make mDNS stop working reliably. We
could do better, but none of the router vendors are working on it. My point
is that an ops doc that pretends that this is a solved problem is going to
encourage practices that make things worse, not better.

If you are interested in fixing mDNS proxy, let’s talk.

Similarly, the fix for ND is not to block it.

-- 
[email-masked]

On October 7, 2021 at 04:30:23, [email-masked] ([email-masked])
wrote:

> 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
> 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.
>
>
> just because some protocols are poorly designed (only work if on the same
> L2), doesn't mean this is not valuable work.
> even in a homenet, it's not inconceivable that the home owner would like
> to control what services are advertised across the home.
>
> O.
> ------------------------------
>

---

From: Xipengxiao <[email-masked]>
Date: Thu, 7 Oct 2021 20:18:25 +0000

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: [email-masked] [mailto:[email-masked]]

[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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Oct 2021 19:51:04 -0400

Okay, thanks for the clarification!

On Thu, Oct 7, 2021 at 4:18 PM Xipengxiao <[email-masked]> wrote:

> 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:* [email-masked] [mailto:[email-masked]]
>
> *[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.”*
>
>
>
> *[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.
>
> 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
>
>
>
>
>