Re: [v6ops] Are we competitive?

[Nick Buraglio <[e-mail]>]

Pointing out the use cases is important. Again, directing the conversation
is significantly more impactful than not having it.

nb



On Tue, Aug 9, 2022 at 1:42 PM Ted Lemon <[e-mail]> wrote:

> I think it would make sense to document nat66 and recommend against it
> generally, describing specific situations where it is applicable, rather
> than presenting it uncritically. Same with DHCPv6. We should not be
> encouraging the use of DHCPv6. If people think they need it, find, but it’s
> not something we should tell someone with no preference to use.
>
> On Tue, Aug 9, 2022 at 11:57 Nick Buraglio <[e-mail]> wrote:
>
>> 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
>>>>
>>> ᐧ
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> ᐧ