Re: [v6ops] Are we competitive?

[Ted Lemon <[e-mail]>]

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
>