Re: [v6ops] [E] Re: How New Version of draft-ietf-v6ops-nd-considerations-01.txt can help discussion of other drafts

[Gyan Mishra <[e-mail]>]

>From a quick google search here is nice blog on wireless segmentation
options and how it works using Cisco’s proprietary PVLAN concept and
identity based networking and mix of some other ideas.  Can be applicable
to IPv6 ND.

http://revolutionwifi.blogspot.com/2011/01/wireless-network-segmentation-options.html?m=1#:~:text=Wireless%20Network%20Segmentation%20Requirements&text=Traditionally%2C%20wireless%20network%20segmentation%20has,as%20a%20firewall%20or%20router
.



On Sat, May 6, 2023 at 6:07 PM Brian E Carpenter <
[e-mail]> wrote:

> One other case might be worth giving as an example. I just spent a few
> days in a hotel, and it reminded me that most hotels now apply room-by-room
> WiFi isolation. Of course they usually don't provide IPv6 at all, but at
> least they are set up for isolation already. (Not sure what they do in
> public areas, but the IETF meetings team must be fully up to date on this
> topic.)
>
> (It would be a great leap forward if we could persuade the solution
> providers for hotels to enable IPv6 as standard.)
>
> Regards
>     Brian
>
> On 06-May-23 17:31, Mishra, Gyan S wrote:
> >
> > Hi Brian
> >
> > Good point.  As you mentioned SOHO or Campus WIFi can avoid all problems
> and the main focus of the draft is FBB, MBB and Enterprise networks.
> >
> > I think we could add a ND deployment considerations section to help
> operators and in there we could have a table that categorizes the issues in
> section 2 as to which are the ones to focus on by the different use cases
> you mentioned honing in on the main issue map to the particular use case.
> >
> > Hi Xipeng
> >
> >  From Brian’s really good point as we are biased here and want to
> advocate for IPv6 deployment and proliferation we want to maybe have that
> twist in the draft that we consciously in the back of our minds we want to
> help and not make it more difficult for operators deploying IPv6 and
> wherever possible can throw in a benefit of IPv6 over IPv4 where applicable
> so this draft can really pave the way for operators stuck in the mud trying
> to decide, and now we can push them over the fence to deploy IPv6.
> >
> > ..here is a good example..
> >
> > In section 2.1 you may want to mention one of the major advantages in a
> L2 environment with IPv6 as compare to IPv4 is that IPv4 has the concept of
> all Fs broadcast and unknown unicast  which is also broadcast flooded out
> all switch ports where with IPv6 the concept of broadcast does not exist
> and so all typical IPv4 broadcast and unknown unicast is done via multicast
> constraint of traffic to only interesting ports and not blindly flooding
> out all ports as done with IPv4 ARP broadcast which can lead to meltdowns
> from ARP storms.  So that is eliminated and constrained to multicast but
> requires all L2 switches to have mld snooping enabled globally and if not
> enabled the IPv6 multicast traffic still gets broadcasted out.
> >
> > Most WIFI vendors Aruba, Cisco, Juniper have a workaround that they are
> able to keep the upstream join IIL as multicast but can convert all the OIL
> downstream MLDv2 requests to Unicast and so you still conserve bandwidth as
> the incoming stream is a single multicast steam, however the OIL downstream
> joins are all converted to unicast so then you don’t have the performance
> hit with lowest common denominator for multicast issue.  So this can apply
> to ND optimization for multicast.
> >
> > Section 2.2
> >
> > So in public networks like airport or coffee spot hotspots you are using
> WIFI and not LAN connections and so in those cases use secure WIFI and not
> open unsecured WIFI.
> >
> > For enterprise LAN using 802.1x for port level access security.  That
> can prevent attack vector since now everyone has to authenticate like you
> do with secured WIFI to get on the network.
> >
> > 2.3 For DC Space NVO VXLAN and GENEVE maybe mention proxy ARP and proxy
> ND  ARP / ND suppression feature which saves on the state info being
> flooded in evpn control plane for every flow it’s only for the first packet
> and then all subsequent flows to same egress we generate suppression cache
> entry.  In what I described here it saves on ND queuing and flood within
> the domain but the remote mac are all still learned in the control plane.
> This is different then section 3.5 SARP which is traditional non NVO DC.
> >
> > Thanks
> >
> > Gyan
> >
> > On Fri, May 5, 2023 at 7:48 PM Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Hi XiPeng,
> >
> >     One question I have arises from this remark:
> >
> >      > If someone is to deploy IPv6, especially in an enterprise (i.e.
> IPv6 1st-hop), going through this draft to find out what ND issues one may
> encounter
> >
> >     How does an enterprise operator know whether their network is
> subject to the issues described in the draft? We know the two extremes (a
> small office network can probably ignore all of this, and a large campus
> WiFi with BYOD access probably needs to worry about all of it). But an
> individual network designer, even with the careful presentation in this
> draft, has to decide which issues to worry about, if any, before
> considering a solution.
> >
> >     I'm not sure how to resolve this, but I am a bit concerned that the
> document could have a "freezing" effect on IPv6 deployment unless we can
> give such guidance.
> >
> >     Regards
> >          Brian Carpenter
> >
> >     On 29-Apr-23 10:14, Xipengxiao wrote:
> >      > Hi folks,
> >      >
> >      > We just released a new version of
> draft-ietf-v6ops-nd-considerations. The main changes are:
> >      >
> >      > •New title: Selectively Isolating Hosts to Prevent Potential
> Neighbor Discovery Protocol Issues
> >      >
> >      > •Add a New Section: 4.3. Applicability of Subnet Isolation with
> Shared Medium
> >      >
> >      > •Tidy-up Section 4
> >      >
> >      > So far, this draft gets little attention and review.  We think
> it’s because this draft is like a “ND issues and solutions manual”.  When
> you are not doing THAT thing, reading a manual can be boring, especially
> because the draft gets into a fair amount of details about ND issues and
> solutions.  So we would like to highlight the value of this draft and call
> for more reviews:
> >      >
> >      >  1. It summarized various ND issues and solutions from 30+ RFCs
> into a 1-stop reference;
> >      >  2. It’s the first draft to point out that the 15 ND issues are
> triggered by just 3 causes.  This makes future protocol solution or
> operations solution much easier – it’s easier and more effective to handle
> 3 causes than 15 individual issues;
> >      >  3. This draft tabulates the solutions for each issue, and the
> applicability of the commonly used solutions. This can be handy for future
> draft discussion.  For example, lately draft-collink receives a lot of
> discussions.  This draft can help draft-collink’s development & discussion
> in the following ways:
> >      >      1. The problem that draft-collink is trying to solve, a host
> has more IPv6 addresses than the NCEs its router keeps -> packet loss, is
> essentially a “NCE exhaustion” issue described in our draft.  From the
> “issue-solution” table (Table 1) you can quickly find that among the
> solutions for this issue, Unique Prefix Per Host is one of the most
> suitable for this situation.  Draft-collink is indeed a flavor of Unique
> Prefix Per Host;
> >      >      2. Several people on the mailing list are concerned that the
> draft-collink solution has limitations, and want the co-authors to point
> out where the solutions are applicable and where it is not.  Several people
> have pointed out some limitations.  But all are done in an ad-hoc way (i.e.
> you think about it, you may find some limitations, but you may also miss
> some limitations).  In comparison, our draft already has systematic
> coverage of the advantages, disadvantages and applicability of Unique
> Prefix Per Host.  Reading and referencing our draft can save the community
> time in discussing draft-collink and future drafts.  We acknowledge that
> our draft may not be 100% complete either, but we argue that reviewing and
> completing it is a good investment, because the community will save time in
> future ND-related draft discussion.
> >      >  4. If someone is to deploy IPv6, especially in an enterprise
> (i.e. IPv6 1^st -hop), going through this draft to find out what ND issues
> one may encounter and follow the guidelines to pick a suitable solution can
> save him/her a lot of time than doing his/her own study.
> >      >
> >      > Thank you very much if you read to this point.  We hope you can
> review this draft to further improve it. We believe it’s a good investment
> for the WG.
> >      >
> >      > XiPeng & the co-authors
> >      >
> >      > -----Original Message-----
> >      > From: [e-mail] <mailto:[e-mail]>
> <[e-mail] <mailto:[e-mail]>>
> >      > Sent: Thursday, April 27, 2023 10:09 AM
> >      > To: Vasilenko Eduard <[e-mail] <mailto:
> [e-mail]>>; Eduard Metz <[e-mail] <mailto:
> [e-mail]>>; Vasilenko Eduard <[e-mail]
> <mailto:[e-mail]>>; Gyan Mishra <
> [e-mail] <mailto:[e-mail]>>; Nick
> Buraglio <[e-mail] <mailto:[e-mail]>>; Xipengxiao <
> [e-mail] <mailto:[e-mail]>>
> >      > Subject: New Version Notification for
> draft-ietf-v6ops-nd-considerations-01.txt
> >      >
> >      > A new version of I-D, draft-ietf-v6ops-nd-considerations-01.txt
> >      >
> >      > has been successfully submitted by XiPeng Xiao and posted to the
> IETF repository.
> >      >
> >      > Name:                       draft-ietf-v6ops-nd-considerations
> >      >
> >      > Revision:       01
> >      >
> >      > Title:              Selectively Isolating Hosts to Prevent
> Potential Neighbor Discovery Protocol Issues
> >      >
> >      > Document date:     2023-04-27
> >      >
> >      > Group:                       v6ops
> >      >
> >      > Pages:                        31
> >      >
> >      > URL:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=>
>
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01.txt&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=Ywtd7saGyuAHA43gP6EMvGuKaldKelZBDgRlHkXGN8E&e=>
> >
> >      >
> >      > Status:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=>
>
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ZsaoEH8o-7cZunTY45Q_50uy_e5msk0sfTsndGiyQFY&e=>
> >
> >      >
> >      > Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=>
>
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=uG6rb_NKBRlKWU1hAPQLlV-_7C1lA6FdQpN4UN1nzrI&e=>
> >
> >      >
> >      > Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=>
>
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dnd-2Dconsiderations-2D01&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=ePNyyGsiu9RxWfHKJQOxA01TC3YiKdGtlhoidp3WlhA&e=>
> >
> >      >
> >      > Abstract:
> >      >
> >      >     Neighbor Discovery (ND) is a key protocol of IPv6 first-hop.
> ND uses
> >      >
> >      >     multicast extensively and trusts all hosts. In some scenarios
> like
> >      >
> >      >     wireless networks, multicast can be inefficient. In other
> scenarios
> >      >
> >      >     like public access networks, hosts may not be trustable.
> >      >
> >      >     Consequently, ND has potential issues in various scenarios.
> The
> >      >
> >      >     issues and the solutions for them are documented in more than
> 30
> >      >
> >      >     RFCs. It is difficult to keep track of all these issues and
> >      >
> >      >     solutions. Therefore, an overview and some guidelines are
> useful.
> >      >
> >      >     This document firstly summarizes the known ND issues and
> >      >
> >      >     optimization solutions into a one-stop reference. Analyzing
> these
> >      >
> >      >     solutions reveals an insight: isolating hosts is effective in
> >      >
> >      >     preventing ND issues. Five isolation methods are proposed and
> their
> >      >
> >      >     applicability is discussed. Guidelines are then described for
> >      >
> >      >     selecting a suitable isolation method based on the deployment
> >      >
> >      >     scenario.
> >      >
> >      > The IETF Secretariat
> >      >
> >      >
> >      > _______________________________________________
> >      > v6ops mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=JTSJnPnU_XZPFiP-DTjKTxl05rWSR7oeRXQ0B4-_ok4&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=iotgBWTCFFWPOK6Psd06xuO4j8mIPUNqVXdxxCKgyjj2hisgbVsfmGvN6UBO4Opm&s=JTSJnPnU_XZPFiP-DTjKTxl05rWSR7oeRXQ0B4-_ok4&e=
> >
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > *IT Technologist & Innovations Specialist*
> >
> > *Associate Fellow-Network Design*
> >
> > /Network Solutions A//rchitect, /
> >
> > /R&S, SP SME & Protocol Design Expert/
> >
> > /Global Technology Services/
> >
> > /O 240 970-6287
> > M 301 502-1347
> > /
> >
> > /
> > /
> >
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*