Re: [v6ops] Are we competitive?

[Nick Buraglio <[e-mail]>]

On Wed, Aug 10, 2022 at 4:52 AM Vasilenko Eduard <
[e-mail]> wrote:

> Hi Nick,
>
> Why do you insist on NAT66?
>

No insistence, just to mention that it exists and point out the potential
use cases and downsides / perils / whatever.


> There is NPT that is much easy for implementation and has formal RFC 6296.
>
> Do you have any examples of when NPT is not enough?
>

Nope, not offhand. I think it should be included in the same way.


>
>
> I agree that ULA and DHCP would be needed. It would be not possible to
> convince the majority of Enterprises of the opposite.
>

Exactly. I am thinking more "steer the barge" than "turn on a dime". At
some point there will be a draft proposed that outlines some actual use
cases for ULA (think single stacked, air gapped sensor networks) that a few
of us have started writing, and that can help inform the section.


Eduard
>
> *From:* v6ops [mailto:[e-mail]] *On Behalf Of *Nick Buraglio
> *Sent:* Tuesday, August 9, 2022 6:57 PM
> *To:* Clark Gaylord <[e-mail]>
> *Cc:* IPv6 Operations <[e-mail]>; Xipengxiao <xipengxiao=
> [e-mail]>
> *Subject:* Re: [v6ops] Are we competitive?
>
>
>
> Inline [NB] (not N.B.) =P
>
>
>
> On Mon, Aug 8, 2022 at 7:10 PM Clark Gaylord <[e-mail]> wrote:
>
> Similarly, I taught networking in Virginia Tech's Business Information
> Technology program in Spring 2020, and of course IPv6 was a first class
> citizen. I did use Kurose & Ross as the textbook, which does include some
> IPv6, though certainly not at the level we would need, and I had to
> supplement some material. I believe the final edition of Stevens does
> include some IPv6 as well.
>
>
>
> Kurose & Ross is a good text, but frankly a little too "engineering" for
> the audience I was reaching then or what we need here; on the other hand it
> was far superior to Comer, which has not fared well with age and was the
> default choice for this class. That said, I encourage anyone who isn't
> familiar with *this* K&R :-) to check it out. One unique decision they made
> was to work *down* the stack in successive chapters instead of up. With
> just the IPv6 focus we're considering, this is less radical, perhaps.
>
>
>
> I would concur that our target should be this level: MIS/BIT students are
> far more likely to be employed as operational IT and networking
> professionals than Computer Science. Focusing on a trade publication that
> could be a reasonable choice for the self-learner or as an applied textbook
> (or at least supplemental/second text) in a networking class of this type.
>
>
>
> [NB] This is mostly my experience coming from UIUC - more operational
> interest from MIS, less from CS (although there is definitely some) - but
> my data is 10 years out of date at this point.
>
>
>
>
>
> I've been thinking a lot about such a resource, especially (again)
> recently; of course I thought about this a lot in 2020, but then left VT
> etc etc. I think practical advice for "this is how you use it in
> production" should be the focus. As such, mostly dual stack networks and
> hosts are the norm. I do think it should include single stack: first as
> specific hosts where you know you do not intend global Internet (e.g.
> IPv6-only ssh bastion hosts), then how NAT64 could be used. I would
> personally eschew DHCPv6 except for PD -- RA, SLAAC, and privacy addresses
> are the reality on the ground, in my experience.
>
>
>
> [NB] I would definitely not leave out DHCPv6. It's an important piece for
> the enterprise space, regardless of the similarity to the legacy function.
> Host configuration is almost universally one of the first 3-5 topics
> discussed, and this is always mentioned. I believe it's important to
> provide an impartial view, lay out the basics, describe a few use cases,
> etc..
>
>
>
>
>
> I have recently (literally today) convinced myself this text should first
> focus on hosts that live in an environment with IPv6 (both enterprise and
> home) and *then* a section on address planning and configuring the network.
> This is analogous the Kurose & Ross decision to go down the stack.
>
>
>
> Arguably the networking section could be a second volume, but I think it
> is easy to over do this section and hence that inclination should be
> discouraged. It does need routing (OSPFv3, BGP) and interface templates
> (RAs), but this isn't where we need to get into routing protocol weeds. I
> would recommend a section on polling devices (ie netdisco, others exist too
> but let's not belabor the matter), because I think it is *the* essential
> asset required for security and management. But we should stay focused on
> "this is the config you should use" (and btw here is your Cisco and Juniper
> config snippet).
>
>
>
> Chapter One: a nice pedestrian introduction focused on the home user and
> setting up a single stack ssh bastion at the data center. Assume data
> center with ssh bastion on a dual stack network, and your remote network
> (residential ISP or VPS) has IPv6 available. Go through enabling IPv6 on
> your residential ISP router, and using this to get to your bastion, binding
> ssh only to IPv6. Discuss how this remarkably reduces attack surface on
> bastion.
>
>
>
> Chapter Two: Windows ecosystem as dual stack (primarily single stack). Not
> so popular with the geek crowd, perhaps, but this gets immediately into the
> "IT professional's head". If you have a dual stack route/switch network and
> configure your AD correctly, your Windows environment will be nearly 100%
> IPv6; I have run 100% IPv6 Windows in selected zones, but in the wild
> you'll still have some legacy IP. This is a good exercise to demonstrate.
>
>
>
> [NB] 100%. This is an absolute requirement for this to be consumable and
> useful by the vast majority of the audience.
>
>
>
>
>
> I'm still working on the exact outline from here, and these ideas are
> still obviously a bit rough, but personally I'm drawing on my own
> experience running dual and single stack systems and networks over the last
> 20 years. Naturally, my perspective is colored by this experience, but as
> such, it is colored by what I know works and strong use cases for using
> IPv6, as well as the few legitimate pitfalls. NAT64 is in (admittedly a
> stretch goal), NAT66 and ULA are out; I'm disinclined to 464XLAT (again,
> predicated on what I do and what works today; I'm not TMobile nor is it our
> audience - sorry I think 464 is out). And, sad to say, I think dual stack
> by default is still in.
>
>
>
> [NB] Leaving out ULA and NAT66 would be a mistake. Commercial options
> exist for NAT66, and regardless of the ideological stance, it's a
> deployment model that will happen. Similarly, not addressing ULA and some
> valid use cases (single stacked, air gapped network, etc.) and would paint
> an incomplete picture. It would also leave the reader to draw their own
> conclusions based on random other findings. I firmly believe it is better
> to control the conversation with understood facts rather than to omit
> parts. Messaging, should be impartial, and provide examples of use cases as
> well as paint a clear portrait of the caveats and cons.
>
>
>
>
>
> N.B. I would love to consider a dissenting opinion to my strident "don't
> bother with DHCPv6 unless you need PD(*)" approach, but only from the
> perspective of someone who actually runs it in comparable environments (and
> still supports SLAAC and privacy addresses, etc).
>
>
>
> [NB] We use it in production for a number of things, most importantly
> bootstrapping hosts on an IPv6-only network, it was a hard requirement.
>
>
>
>
>
>
>
> (*) And I think *operating* PD is probably out of scope for this effort,
> but if someone can write a short how-to section for the mom & pop ISP to
> setup PD then it would be a worthy add. Consuming PD on your residential
> network is clearly in.
>
>
>
> [NB] That one clearly lands in SP space for me, I agree with some basic
> form of what it is, how it is used from the client perspective, and a rough
> overview of how it relates to host DHCP.
>
>
>
>
>
> I'm afraid that's a bit more than $0.02 worth, sorry about that. Please
> apply a few teaspoons of sugar if any of my opinions come off a bit tart.
>
>
>
> Regards
>
> Clark
>
>
>
> On Fri, Jul 29, 2022, 13:16 Nick Buraglio <[e-mail]> wrote:
>
> I have a few short chapters written on the process of migrating to
> IPv6-only. It does not cover fundamentals because I feel that it is well
> traveled information. It is also meant to be more of a pocket guide (i.e.
> short). As a potentially useless data point, at the university I was at
> prior to my current role, there was very little if any attention paid to
> operational networking in the CS department, and every student we got to do
> work for us in my entire tenure was largely unaware of IPv6, save for maybe
> one, who now works with us.
>
> I gave more guest lectures on real world networking in the MIS department
> than the CS department by an order of magnitude, and even then it was very
> entry level.
>
>
>
> nb
>
>
>
>
>
> On Thu, Jul 28, 2022 at 21:34 Brian E Carpenter <
> [e-mail]> wrote:
>
> On 29-Jul-22 10:00, Ed Horley wrote:
> > I believe Rick Graziani updated IPv6 Fundamentals, Second Edition from
> Cisco Press in 2017. Prior to that, Tom Coffeen's IPv6 Address Planning
> book was published in 2014, and mine was published in Dec 2013 but I would
> not consider Tom or my book to be one you would necessarily use in a
> classroom for instruction.
>
> I agree. For example, consider a general introduction to networking that
> you might find in a Computer Science major, which for the last many years
> has been based on IPv4 as a given. OK, sometimes you'll find a mention of
> IPv6. An example text book for such a course is Computer Networking, 8th
> Edition, James F. Kurose and Keith Ross, Pearson. I haven't seen that exact
> edition (published 2020) but the relevant bit of the contents says:
>
> 4.3    The Internet Protocol (IP): IPv4, Addressing, IPv6, and More
>      4.3.1    IPv4 Datagram Format
>      4.3.2    IPv4 Addressing
>      4.3.3    Network Address Translation (NAT)
>      4.3.4    IPv6
>
> In other words, IPv6 is an afterthought.
>
> (In the 7th edition, published 2016, but still widely in use, there are 5
> pages on IPv6 following 20 pages on IPv4+NAT. Of course they look very out
> of date today.)
>
> We want to see this:
>
> 4.3    The Internet Protocol (IP): IPv6, Addressing, Legacy IPv4
>      4.3.1    IPv6 Datagram Format
>      4.3.2    IPv6 Addressing
>      4.3.3    Legacy: IPv4 and Network Address Translation (NAT)
>
> Get students past that stage and then the dedicated IPv6 books can come
> into play.
>
>     Brian
>
> > My question would be, are you looking for a book to teach the
> fundamentals of the protocol? If so, Rick's book is more than sufficient
> and I would not be surprised if he will be updating it for a Third Edition.
> If you are not looking for a fundamentals book but something else, what is
> it you are looking for?
> >
> > On Thu, Jul 28, 2022 at 2:52 PM Xipengxiao <xipengxiao=
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     Hi Brian,
>
> >     Writing an IPv6 text book is a great idea!  I googled and the newest
> IPv6 book was from 2014.  At that time, IPv6 deployment has just started.
> Many progresses have been made since then.  I think it’s warranted to write
> a new book.   Plus, the covers of those books associated IPv6 with snails
> and turtles.  It’s time to associate IPv6 with something faster like
> dinosaurs J
> >
>
> >
> >     Who can better lead this effort than you, Fred, Eric Vyncke,
> Fernando et al?  I am willing to contribute a fair amount of time to this
> effort.  I hope other experts can contribute too.  Thanks. XiPeng
> >
> >     -----Original Message-----
> >     From: Brian E Carpenter [mailto:[e-mail] <mailto:
> [e-mail]>]
> >     Sent: Thursday, July 28, 2022 5:05 PM
> >     To: Xipengxiao <[e-mail] <mailto:[e-mail]>>;
> Gert Doering <[e-mail] <mailto:[e-mail]>>
> >     Cc: IPv6 Operations <[e-mail] <mailto:[e-mail]>>
> >     Subject: Re: [v6ops] Are we competitive?
> >
> >     Hi XiPeng,
> >
> >     Mainly I agree and this is a very useful summary.
> >
> >     However, we should question whether RFCs are the correct way
> forward, rather than some kind of collaboration to produce an ideal text
> book.
> >
> >     For example, consider the 3 volumes of "TCP/IP Illustrated" by
> Stevens & Wright. I believe that had tremendous impact (published 1994, so
> no IPv6).
> >
> >     If we go the RFC route, won't we just end up with 520 IPv6 RFCs?
> >
> >     Regards
> >
> >          Brian Carpenter
> >
> >
> >     On 29-Jul-22 06:59, Xipengxiao wrote:
> >
> >      > On Thu, Jul 28, 2022 at 02:51:43PM +1200, Brian E Carpenter wrote:
> >
>
> >
> >      >  >> Following the ongoing discussion about "IPv6-only" and why
> sites are still IPv4-only, I have a question: Are we competitive?
> >
>
> >
> >      >  > [Gert] This is a valid question, which I feel hard to answer
> for the general case.
> >
>
> >
> >      > Let me be blunt and say that IPv6 is not as competitive as we
> want/think.  If we are to improve, we need to have a common understanding
> of the current IPv6 situation, the issues and the possible solutions. Here
> is my 2c for starting the discussion:
> >
>
> >
> >      > IPv6 is currently like a messy forest:
> >
>
> >
> >      > ·littered with dead trees (obsolete features/solutions),
> >
>
> >
> >      > ·smell bad (many operations & performance issues),
> >
>
> >
> >      > ·too many roads inside the forest (too many transition solutions,
> too many address types), not well marked (without clear solution
> guidelines), and fairly confusing
> >
>
> >
> >      > ·the roads are difficult to walk (complex address architecture,
> debatable header design, many complex solutions like source/destination
> address selection, ND).
> >
>
> >
> >      > This forest has 1 big advantage: plenty of O2 (addresses).
> Consequently, many people avoid this forest but those really need O2 come.
> A small number of “grey/white wizards” (the experts) live in the forest.
> They know every tree (feature/solution) well.  But they tend to focus on
> fixing individual trees than fixing the forest.
> >
>
> >
> >      > If we want to attract more residents to the forest (IPv6
> adopters), it’s more important to fix the forest than to fix the trees.
> Some ideas:
> >
>
> >
> >      > ·Provide better tour guide book (i.e. IPv6 solution overviews):
> There are about 500 IPv6-related RFCs.  Some are obsoleted and some are
> conflicting.  I think we should summarizing them and providing guidelines,
> so that people can read fewer RFCs to master IPv6.  (e.g. the ND deployment
> guideline draft summarizing 30+ RFCs into 1 draft)
> >
>
> >
> >      > ·Among the many possible routes (e.g. solutions), recommend only
> the most popular ones (e.g. recommend only Dual-Stack, 464XLAT and MAP-T
> among the 10+ transition solutions).
> >
>
> >
> >      > ·Provide better road signs in the forest (i.e. solution
> guidelines): IPv6 solutions are almost complete.  Now it’s more important
> to write guidelines to simplify operations than to develop more solutions.
> >
>
> >
> >      > ·Identify haphazard places in the forest, and post clear
> “caution” signs (i.e. identify IPv6 operations/performance issues, and
> provide guidelines/BCPs)
> >
>
> >
> >      > ·Enlist existing residents to share experience on how to settle
> into this forest (i.e. case sharing from Cisco, Alibaba etc).
> >
>
> >
> >      > BTW, upon the request of an enterprise, a few on-site attendees
> had a small side meeting on Monday.  Their **anonymous** opinions and
> future actions are summarized in the attachment for your info.  If you are
> interested to join the discussion and contribute, please voice up.  Thank
> you.  XiPeng
> >
>
> >
> >     ___
> >     v6ops mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
> >
> > --
> > Ed Horley
> > [e-mail] <mailto:[e-mail]>| [phone]
> > Advancing Cloud, IoT, and Security with IPv6
> > https://hexabuild.io <https://hexabuild.io/>
> > And check out the IPv6 Buzz Podcast at
> https://packetpushers.net/series/ipv6-buzz/ <
> https://packetpushers.net/series/ipv6-buzz/>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> ᐧ
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> ᐧ
>
ᐧ